"Harness engineering," "loop engineering," and fully autonomous, lights-off software factories are having a moment. The pitch is simple: point a coding agent at your backlog, walk away, and come back to shipped features while the team gets on with something else. It's an appealing story, especially if you're weighing up whether to cut delivery cost by letting agents run unsupervised for days or weeks at a stretch. But the practical experience of teams who have actually run this model for months, not for a demo weekend, is a lot more sobering than the pitch suggests. It's worth taking seriously before you sell your own team, or your board, on the same idea.
At Automata AI we set up Claude Code delivery workflows for Australian businesses, and the question we hear most often right now isn't "can an agent write this feature." It's "can we go fully autonomous and skip the review step, because that's where most of the labour cost sits." The honest answer is no, not yet, and probably not for a long while yet. Here's where the lights-off model actually breaks in practice, and what we tell clients to do instead when they're deciding how much to delegate.
Where it breaks
Agents are genuinely good at producing code that passes tests quickly. Tests return a pass or fail signal in seconds, so an agent working inside a fast feedback loop can iterate its way to green efficiently, far faster than a human typing the same code by hand. What agents are not good at, left unattended, is keeping a codebase easy to change over time. Bad architecture doesn't show up in a test suite. Nothing in a green test run tells you whether the boundary between two modules is clean, whether a data model will bend or snap under the next feature request, or whether three different agents have each quietly solved the same problem a different way, in a different corner of the codebase. It shows up months later, when a change that should have taken one line touches eleven edits across three files, because nothing enforced clean boundaries while the codebase was being built.
Piling on more review agents and more tokens doesn't fix this problem, it just moves it further down the pipeline. Extra review passes catch typos, obvious bugs, and style violations, which is useful, but beside the point entirely. Program design, system boundaries, and long-term maintainability are still, and probably always will be, a human call. An agent optimising for "tests pass" has no incentive to ask whether the shape it just built is the right shape for where the product is going next quarter. That question belongs to a person who understands the roadmap, the customer commitments, and the parts of the system that are load-bearing versus the parts that are disposable. No amount of additional agent review replaces that judgement, because the judgement isn't a code-quality problem in the first place, it's a product and design problem wearing code as a disguise.
The bill arrives later, not upfront
This is the risk that never shows up in a demo. For a business considering an agent-heavy delivery model purely to cut engineering cost, the first few weeks look fast and cheap. Features ship, the backlog empties, and it feels like a clear win worth reporting up the chain. The bill arrives later, once architecture drift has compounded across enough features that nobody can safely touch the codebase without breaking something three files away that nobody remembers writing. A typical fix once that drift sets in starts at five figures, from around A$10,000 upward, in remediation work, well beyond what the upfront delegation saved in the first place. That's not a hypothetical, it's the pattern we see whenever a team treats "autonomous" as a synonym for "unsupervised," instead of as a description of the mechanical layer sitting underneath decisions a human already made.
The practical fix
None of this is an argument against agentic delivery. It's an argument about sequencing. The teams getting this right aren't slower, they're just doing the decisions in the right order. Before any code gets written, we ask clients to lock down the following:
Define product goals, system architecture, and type or function signatures upfront, so the agent is filling in a frozen shape rather than inventing one as it goes.
Split work into vertical slices that can be run and verified independently, instead of handing over one enormous delegated task with a single pass or fail gate.
Route small, well-scoped, mechanical tasks straight to the agent, and keep a human at the review checkpoint for anything that touches architecture, shared interfaces, or system boundaries.
Treat a passing test suite as necessary, not sufficient, evidence that a change is safe to ship.
Review the frozen spec itself every few sprints, because a shape that was right at project kickoff can go stale as the product moves.
Why this matters more as delegation increases
This is the same discipline that makes orchestrator-style Claude Code setups work well in the first place. In a well-run setup, the coordinator freezes a spec before handing work to an executor subagent, precisely so the agent isn't making architecture decisions on the fly, it's filling in a shape someone already chose deliberately. Skipping that step is exactly how a fast, cheap agentic build turns into a codebase nobody wants to touch six months later, and exactly how a Sydney startup's MVP becomes the thing three engineers are quietly afraid to open on a Friday afternoon. The more of your delivery pipeline you delegate, the more this discipline matters, not less, because the cost of a wrong architecture call compounds with every additional feature stacked on top of it. Delegation without a frozen spec isn't automation, it's just moving architecture decisions out of a senior engineer's head and into whatever the agent happened to generate first on a given afternoon, which is a considerably worse place for them to live, and a much more expensive place to find them later.
What to ask before you buy the "fully autonomous" pitch
If you're an Australian business evaluating a build partner, or an internal team pitching a lights-off delivery model to leadership, a short checklist separates the sober operators from the demo-driven ones:
Who owns the architecture and interface decisions, and are they frozen before an agent starts writing code?
Is work split into vertical slices that can be reviewed independently, or is it one large delegated task behind a single pass or fail gate?
Where does the human review checkpoint sit, before architecture-touching changes ship, or only after something has already broken in production?
What does the remediation plan look like if drift is discovered six months in, and who is budgeting for that risk now, before it happens?
If the agent's output looks great in the demo, ask what the plan is for the fortieth feature built the same way, not just the fourth.
Fully autonomous software factories are a genuinely useful idea for the right layer of work: mechanical, well-scoped, clearly bounded tasks where the shape is already decided by a human. They're a costly idea when applied to the whole pipeline, architecture included, no matter how good the underlying model gets. The businesses getting real value out of Claude Code right now are the ones that kept a human on architecture and let the agent run everything underneath it, not the ones that walked away entirely and hoped the tests would catch what mattered. If you're weighing up an agentic delivery model for your own team, or trying to work out how much of your build you can safely delegate, we're happy to talk it through. Get in touch.
