Anthropic Taught Claude to Build Apps for Hours: Three Agents and Four Criteria

Anthropic has published an engineering write-up on how to build a harness for long-running autonomous coding sessions. The author, Prithvi Rajasekaran from the Labs team, spent several months on two related problems: getting Claude to produce strong frontend design, and getting it to build entire applications without human involvement. The result is a three-agent planner–generator–evaluator architecture that turns out rich full-stack products in multi-hour sessions. The principle is borrowed from generative adversarial networks (GANs).

Where single agents break down

The previous version of the harness used an initializer agent that broke a spec into tasks, plus a coding agent that built one feature at a time. It hit a ceiling for two reasons.

First, on long tasks the model loses coherence as its context fills up. Some models also show "context anxiety": they start wrapping up work early when they sense the limit approaching. Compaction (summarizing the older part of the conversation in place) does not give the model a clean slate, so the anxiety persists. That is why Sonnet 4.5 needed full context resets with a structured handoff of state. The price of that fix: more complex orchestration, more tokens, higher latency.

Second, self-evaluation. When an agent is asked to assess its own work, it praises it with confidence, even when a human can see the work is mediocre. This is especially noticeable in design, where there is no binary test like a unit test. Separating the "doer" from the "judge" does not fully cure the leniency: the evaluator is still an LLM and favors LLM-written output. But tuning a separate, skeptical evaluator is considerably easier than teaching a generator to criticize itself.

Design: four criteria instead of "make it pretty"

The question "is this design beautiful?" yields unstable scores, while "does it follow our principles of good design?" can actually be graded. Rajasekaran wrote four criteria and showed them to both agents:

• Design quality: a coherent mood and identity, not a collection of parts.
• Originality: deliberate authorial choices instead of templates, library defaults, and "AI slop" such as purple gradients on white cards.
• Craft: typographic hierarchy, spacing, contrast. Claude is already strong here.
• Functionality: usability, independent of aesthetics.

The weights favored quality and originality, because that is where the model produced bland results. The evaluator was calibrated with few-shot examples that included score breakdowns, so its ratings would not drift. The loop was built on the Claude Agent SDK. The evaluator got Playwright MCP, browsed the live page on its own, took screenshots, and wrote its critique. A single run took 5–15 iterations and up to four hours.

Interestingly, the wording of the criteria influenced the outcome more than expected. The phrase "the best designs are museum quality" pushed the results toward a particular visual style. Improvement was not strictly linear, and the author often preferred an intermediate iteration to the final one. In an example with a website for a Dutch museum, the ninth iteration produced a polished dark landing page. On the tenth, the model abandoned it and built a 3D room with a checkered floor using CSS perspective, paintings on the walls, and navigation through doorways.

Three agents for full-stack

For application development, QA and code review took over the role of the design evaluator. Opus 4.5 largely eliminated "context anxiety," so the resets were dropped: the session runs continuously, and the SDK's automatic compaction handles context growth.

The planner turns a 1–4 sentence request into a full product spec. It was deliberately kept at the product level and high-level architecture, because an error in granular technical details would cascade into the implementation. The generator works in sprints, one feature at a time, on React, Vite, FastAPI, and SQLite (later PostgreSQL), with git and a self-check before handing off to QA. The evaluator uses Playwright MCP to click through the running app like a user, checking the UI, the API, and the database state. It grades bugs and criteria: product depth, functionality, design, and code quality. Each criterion has a hard threshold, and failing any one of them fails the sprint.

Before each sprint, the generator and evaluator agree on a "contract": what counts as done, settled before any code is written. It bridges the gap between high-level user stories and verifiable implementation.

For teams building agents, the takeaways are practical. Move evaluation into a separate agent and calibrate it with examples. Turn subjective requirements into explicit, weighted criteria. With every model upgrade, check whether you still need heavy scaffolding such as context resets: Opus 4.5 showed that some of these workarounds go obsolete.