This paper studies autonomous software development, in which LLM-based coding agents transform high-level requirements into complete, functional, and usable software systems without human intervention. We introduce Harness-of-Harness (HoH), a framework that enables coding agents to continually improve software during autonomous development. HoH operates on existing coding-agent harnesses, and organizes their executions into iterative planning-coding-testing loops. To sustain improvement across loops, HoH balances repair with capability growth, scopes development into small and verifiable increments, separates implementation-time testing from independent evaluation, and constrains verifiable outputs rather than prescribing agent workflows. It progressively exposes deliverables, role-specific tools, and skills, encourages reuse rather than recreation, and maintains versioned project histories. On GameCraft-Bench, FrontierSWE, and ProgramBench, three harness-model pairs (Codex with GPT-5.5, OpenCode with DeepSeek-V4-Pro, and Pi with MiniMax-M3), HoH consistently outperforms the corresponding standalone harnesses, achieving an average relative gain of 52.25 percent and a maximum gain of 82.86 percent after three iterations. In a multi-day deployment with more than 70 iterations, HoH autonomously develops a first-person-shooter game, featuring a coherent storyline, fully implemented core mechanics, human-playable experience, polished visuals and integrated audio. Github: https://github.com/Flesymeb/HarnessOfHarness Project Page: https://flesymeb.github.io/HarnessOfHarness/
Alex: Welcome to another episode of ResearchPod. Today, we're looking at a framework called Harness-of-Harness — HoH — which takes on the persistent problem of autonomous software development: getting AI agents to build complex software end-to-end, without human intervention.
Sam: What's the failure mode that motivates this? Why can't existing agents just... keep going?
Alex: The core problem is that autonomous agents on long-horizon tasks lose coherence over time. They'll fix a local bug and silently break something they validated three iterations ago. There's no mechanism forcing them to reconcile current changes against prior verified state, so they cycle through the same failure modes repeatedly. The agent has no memory of what it already knows doesn't work.
Sam: And HoH addresses this by decoupling the planner, the developer, and the QA tester into distinct roles?
Alex: Exactly — and the key design choice is what each role must carry across iterations. Not just the artifact state, the actual code, but the evidence state: the accumulated, validated knowledge about what works and what doesn't. Neither role can proceed without explicitly inheriting both from the previous cycle. That's the architectural constraint that distinguishes this from simply running more iterations.
Sam: That's essentially a CI/CD pipeline for AI agents. If you force the planner to reconcile against prior evidence before issuing new instructions, you prevent the system from re-proposing solutions it already knows are broken.
Alex: That's the mechanism exactly. And there's a second piece: progressive disclosure for context management. Rather than stuffing the entire project history into the context window, the system stores plans and QA reports in the file system and retrieves only what's relevant to the current task. As the project scales, the agent's working memory stays tractable. So the architecture is doing two things simultaneously — maintaining coherence across iterations and managing the context budget.
Sam: How does the evidence actually support those claims?
Alex: The load-bearing result is a multi-day deployment where the system built a playable first-person shooter game over roughly 70 iterations. That's the demonstration that the loop sustains forward progress where a standalone agent would stall. It's not that HoH scores better on a benchmark — it's that it completes tasks that single-pass agents simply don't finish. The results on GameCraft-Bench and FrontierSWE are supporting evidence, showing the pattern generalises across game design and repository-level engineering tasks, but the FPS deployment is what carries the central claim.
Sam: What do the ablations tell us about which component is actually doing the work? Is it the iteration count, or specifically the evidence handoff?
Alex: The ablations are informative here. When you remove the evidence feedback — keeping the iterative structure but stripping the validated knowledge transfer — performance drops substantially. When you remove the warm-start mechanism, which initialises each cycle from the prior artifact state rather than from scratch, you see a similar degradation. That pattern suggests the state transfer is the active ingredient, not simply the additional compute from running more iterations. More cycles without structured handoff doesn't replicate the gains.
Sam: That's an important distinction. Though I'd imagine a careful referee would push back on resource cost. More iterations, more structured artifacts — the token budget must grow considerably.
Alex: That's a real constraint. The framework is explicitly trading compute for reliability, and token usage scales with iteration count. The authors acknowledge this, and it's the most practical limitation for real-world deployment. You're buying robustness with compute, which means HoH isn't a drop-in replacement for single-pass agents in cost-sensitive settings.
Sam: And there's a deeper structural risk, isn't there? The whole framework depends on the QA tester accurately diagnosing the artifact state. If that diagnostic loop is wrong—
Alex: —the error propagates forward. If the QA agent mislabels a failure, that bad signal gets written into the evidence state, and the planner inherits it. You can end up with the agent locked onto a suboptimal path, confidently iterating away from the correct solution because its own validated knowledge is corrupted. The framework is only as reliable as the independence and accuracy of that evaluation loop. That's the most significant limitation the paper doesn't fully resolve.
Sam: So the QA tester is load-bearing in a way that isn't always visible from the headline results.
Alex: Precisely. And it points to where the next generation of this work needs to go — either more robust QA agents, or mechanisms for detecting and correcting corrupted evidence states mid-deployment. The current framework assumes the diagnostic loop is trustworthy. That assumption holds well enough in the reported experiments, but it's where a real-world deployment is most likely to diverge from the benchmark results.
Sam: So the honest read is: meaningful architectural contribution, but with a ceiling determined by QA quality.
Alex: That's right. The iterative, evidence-grounded structure is a more principled approach than single-pass generation, and the results support that. But autonomous software engineering at scale will require either much stronger diagnostic agents, or a way to bring human judgment back into the loop at the right moments — without collapsing back into the supervised workflows this framework is trying to move beyond. Thanks for listening to ResearchPod.