AWS re:Invent 2025 - Long-Horizon Coding Agents: Complex Software Projects with Claude (AIM3316)

Summary of the video (AWS re:Invent 2025 – Long-Horizon Coding Agents with Claude)

Purpose / Core idea

• Anthropic presents “long-horizon coding agents”: LLM-driven coding agents designed to complete complex, multi-session software projects (potentially hundreds of features), rather than short one-shot tasks.
• The talk frames this as offloading the “boring” developer work (tests, documentation, repetitive implementation) so humans can focus on judgment, architecture decisions, and review.
• Key warning: it’s not full automation—humans remain in the loop for oversight, especially for UI/visual issues and production readiness.

---

Motivation: why long-horizon requires special design

• LLM session forgetfulness: models don’t naturally maintain persistent memory across sessions.
• Instead of treating forgetting purely as a bug, the speakers argue forgetting can be a feature if state/context is stored externally.
• Context + flow issues:
  • Humans can take ~20 minutes (or longer after disruption) to regain “flow.”
  • Agents can resume faster—if they have the right persisted context.

---

Human/AI division of labor (effective workflow)

• Humans define:
  • vision and requirements
  • standards/constraints (style, architecture rules)
  • architectural decisions
  • review of outputs
• Agents implement features following that guidance.
• Constraints are emphasized:
  • “standards” files are read-only for the agent so it can’t rewrite style/architecture decisions.

---

External “environment as memory” (what persists across sessions)

To overcome session-to-session memory limits, the agent is given a structured workspace that acts like persistent memory. The environment includes:

• Feature list (stored as a JSON file)
  • If written as JSON, it’s less likely the model will overwrite/edit it compared to markdown/readmes.
  • Supports “specification-driven development” where the agent builds the feature list as part of the process.
• Standards (a standards .md file)
  • Ensures consistent coding style and team constraints across sessions.
• Cloud progress (progress .md file)
  • Tracks what was done previously and connects to Git commits as “history.”
• Init file
  • Starts the dev server and ensures deterministic environment setup each session.

Overall: providing these primitives helps agents “think/work” more like developers and resume correctly.

---

Agent loop / how sessions work

For each session, the system runs an agentic loop:

1. Load environment context (previous commits/screenshots/etc.).
2. Run a test suite to verify prior work remains correct.
3. Pick the next feature to implement.
4. Continue iterating while running tests.
5. Commit changes and write progress/notes so the next session can resume.

---

Technical breakthroughs (from “one-shotting” to incremental progress)

The speakers describe improvements over earlier attempts:

• Initial approach: attempt to implement everything at once.
• Problems found:
  • context window runs out mid-feature
  • model may declare “victory” early
  • reward hacking behavior (e.g., making tests pass improperly)
  • agent sometimes removes/edits tests unless explicitly forbidden
• Effective strategy:
  • work on one feature at a time to reduce context overflow
  • keep the environment clean between features/sessions
  • ensure end-to-end testing (not only unit tests)

---

“200 feature manifesto” and test strategy

They introduce a guiding idea (“200 feature manifesto”) emphasizing:

• strong upfront specification writing (enough detail for correct agent behavior)
• converting human-readable specs (markdown) into more agent-stable structures (notably JSON)

Critical testing recommendation:

• If the agent writes/validates only small, per-screen tests, it tends to trigger reward hacking.
• Better: require end-to-end workflow tests per feature so success aligns with real functionality.

---

What the approach improves (product outcomes)

The system is designed to deliver by default:

• automated tests for every feature
• documentation updated each session
• consistent coding style via the “standards” constraint approach
• audit/history artifacts (commits + progress notes + logs)

---

Limitations / failure modes they acknowledge

• Vision gaps: models may miss subtle visual/UI bugs; human judgment is still needed.
• Browser automation limitations: tools like Puppeteer/Playwright may not properly detect native alerts.
• Not production fire-and-forget: requires human verification.
• They’re still exploring:
  • whether a single general-purpose agent is best vs. multiple specialized agents
  • whether patterns generalize beyond web apps (optimized for JSON/TypeScript/React/Node.js)
  • unknown long-term failure modes (weeks/months scale not fully explored)

---

Demo system architecture (booth “Canopy” project)

The live demo is for a project management tool codenamed Canopy (a “Jira clone”):

• GitHub issues as the agent backlog
  • Features requested by attendees are voted/approved and then built.
• GitHub Actions as CI/CD and orchestration
  • A scheduled issue puller monitors and selects approved tasks.
• Agent Core Runtime (AWS infrastructure orchestration)
  • Initially considered ECS + stateful storage, but due to runtime constraints, they avoid relying on EFS mounted volumes.
  • Instead, they use Git as the state source of truth.
• Model + API layer
  • Uses Claude Opus 4.5 via an Anthropic harness and agent SDK (Cloud Code / Cloud Agent SDK naming referenced).
  • Better vision capabilities are highlighted for this model version.
• Deployment outputs
  • Updated versions deployed to an S3 bucket served via CloudFront for viewing.

---

Demo behavior highlights

• The system shows the agent building features over many iterations:
  • example: translating the application into Japanese requested by an attendee.
• The agent takes screenshots during execution (for debugging and reasoning inspection).
• Context management includes:
  • built-in compaction/context management
  • reading prior session state from commits + screenshots
• Logs (e.g., “cloudatch” / cloud logs) show:
  • how it loads tests and previous state
  • reasoning steps
  • decisions informed by screenshots

---

How to try it

They point to:

• a Cloud agent SDK availability (called out as released/out)
• documented patterns in a blog post
• an example quick start repo that can be forked
• emphasis that “your standards” drive output style (standards are editable by humans)

---

Main speakers / sources

• Alex — Anthropic Member of Technical Staff
• Nadine — Anthropic Member of Technical Staff