Harness Design for Long Running Apps
Article: Harness design for long-running application development by Prithvi Rajasekaran
Summary
Rajasekaran tackles two problems: getting Claude to produce high-quality frontend designs, and getting it to build complete applications without human intervention. Naive long-running setups fail in two ways. Models lose coherence as the context fills — some show “context anxiety” and wrap up early — and agents asked to judge their own work confidently praise it regardless of quality. Inspired by the generator/discriminator split in GANs, he separates creation from evaluation: a standalone evaluator is still lenient out of the box, but it is far easier to tune an evaluator to be sceptical than to make a generator self-critical.
The approach was first tested on frontend design, where subjective quality was made gradable through four criteria: design quality, originality, craft, and functionality — with the first two weighted highest, since Claude already handles the other two well. The evaluator used Playwright to interact with the live page before scoring, driving 5–15 iterations per run. The wording of the criteria itself shaped the output — phrases like “museum quality” steered designs in a particular visual direction.
For full-stack work the system grew to three agents. The planner expands a one-to-four sentence prompt into an ambitious product spec. The generator builds in sprints with React, Vite, and FastAPI. The evaluator acts as QA, clicking through the running app and checking UI, API, and database state against hard thresholds. Before each sprint, generator and evaluator agree on a sprint contract defining what “done” means. Getting the evaluator to this level took several rounds of prompt tuning — at first it would find issues and then talk itself into approving them.
The tradeoff is clear in the retro game maker example: a solo agent took 20 minutes and $9 but produced a game whose core didn’t work, while the full harness took 6 hours and $200 and delivered a far more polished, working application.
The most transferable lesson comes from simplifying the harness afterwards: every component encodes an assumption about what the model can’t do on its own, and those assumptions go stale. With Opus 4.6 the sprint construct could be removed entirely and the evaluator moved to a pass at the end, while the planner stayed because the generator under-scoped without it. A browser-based DAW was then built in about 4 hours for $124. The evaluator remains worth its cost when a task sits beyond what the model does reliably alone — the space of useful harnesses moves rather than shrinks as models improve.