Code volume grew 180 percent. Shipped output grew 30 percent. MIT research, two numbers sitting oddly side by side, and everything in the gap between them is work that ran, looked finished, and wasn't. The reconciliation that balanced against the wrong month. The outreach sequence that kept firing after the deal already closed.
Last week this column looked at who reviews the output. This week the question moved upstream, because review capacity was never the only constraint. Teams still haven't written down what done means. That's why there's nothing to review against.
Pull apart 136 open-source loops across three major repositories and the failure is identical every time: no terminal condition. The prompts are fine. Clear phrasing, logical structure, appropriate detail. The breakdowns happen where the loop is supposed to stop, and the terminal conditions are either absent or so vague they might as well be. "Optimize the code until there are no issues." What qualifies as an issue? "Iterate until satisfactory." Satisfactory to whom?
The breakdowns happen where the loop is supposed to stop, and the terminal conditions are either absent or so vague they might as well be.
The industry now has a name for the fix. Loop engineering entered mainstream AI coding discourse in June 2026, when Google Chrome engineering lead Addy Osmani named the concept and Claude Code creator Boris Cherny declared he no longer writes prompts, he writes loops. Developer Peter Steinberger posted the same sentiment; 6.5 million people saw it. But the vocabulary is doing something more interesting than it looks. "How do I make the agent stop?" is just another way of asking what done looks like for this task. Loop engineering is requirements engineering in disguise.
That's the whole shift in one sentence, and it explains why Anthropic recently told its growth team to hire more product managers, not fewer. Claude Code had turned its engineers into a team shipping at triple its headcount. The bottleneck moved from writing code to deciding what to build, which is why everything ships as a research preview — so they can get user feedback. As Microsoft's Travis Lowdermilk put it, the technology is no longer the constraint. It now takes more time to plan and reach shared understanding than to build. "We're moving so fast," he said, "misalignment is the outcome."
A 2025 MIT study found roughly 95 percent of generative AI pilots deliver no measurable impact. The instinct when a project stalls is to blame the model and wait for the next one. It rarely helps. Most AI failures are organizational, not technical — a failure of humans in the loop making unrealistic decisions. This is a Jevons Paradox moment, and the paradox is that cheaper generation makes the expensive part more visible.
Consider what the definition of done actually says today. The Scrum Guide calls it "a formal description of the state of the Increment when it meets the quality measures required for the product." Reviewed, tested, merged, deployable. Check the boxes and you're done. Matt Watson, who has shipped software for more than 20 years and sold the auto-dealer software company he co-founded, argues that definition is quietly wrecking products. Done isn't when the code ships. It's when the customer sees value. Pendo studied feature usage across hundreds of products and found 80 percent of features are rarely or never used. By the standard definition of done, all of that succeeded.
The scene that makes this concrete comes from a consultant's account of a delivery leader we'll call Alex. Piece by piece, he'd built the engine his organization now had. AI agents drafted overnight. Test scaffolding that once consumed a sprint appeared in an afternoon. Every DORA metric on his dashboard was green. Then a team lead stood in his doorway asking, for the third time that week, what should we build next? The backlog that once stretched eighteen months ran thin by mid-quarter. Work was no longer waiting on engineers. It was waiting on his calendar.
This is Goldratt's second rule. Every system has one governing bottleneck, and a constraint you elevate does not disappear. It moves, and it rarely announces its new address. Alex reran the prioritization model that had settled arguments for years. Every initiative scored do now. The math was behaving correctly; the world underneath it had changed. Cost-of-delay rankings divide value by duration, and AI collapsed the duration that once separated the options.
His second move was the instinctive one: fill the intake with AI-generated ideas. His problem got worse. Pushing more input into a decision bottleneck doesn't raise its throughput; it raises work-in-process and lengthens the very queue it was meant to feed. Gartner finds only 18 percent of CIOs practice dynamic, off-cycle reprioritization, and those who do are 24 percent more likely to be top performers.
So the load-bearing artifact isn't the prompt or the context window or the harness. It's the written statement of when a loop has converged — and that statement has to survive contact with how work actually runs.
At LinkedIn, engineers built a context layer of over 600 workflows and thousands of tools so coding agents could debug a latency spike, trace it to a downstream service, find the buggy PR, summarize the root cause, take the mitigation action, and open the fix. That's what a well-specified loop looks like at scale. But the harder lesson comes from logistics. Deniz Cihan Tiryaki, a venture CTO who has built systems across enterprise automation, found that the process an organization documents is rarely the full process that actually runs. Documents arrive through WhatsApp, out of order. Drivers upload the wrong stop's paperwork, submit duplicates. Experienced staff develop recovery moves nobody wrote down. "If we had converted that process diagram directly into software," he said, "we would have built the wrong system." Companies should not automate their SOPs directly. They should first discover the operational reality underneath them.
That is what defining done now requires. A 2025 study in Business & Information Systems Engineering examined workarounds across four organizations and found three different versions of the same workflow: the prescribed process, what the systems actually recorded, and what people really did.
One builder shipped 12 features in a month. Three were useful. The other nine passed tests, cleared code review, deployed without errors, and nobody needed them. Research from early 2026 shows AI-generated code produces 2.74 times more security vulnerabilities than human-written code — not because the model writes worse syntax, but because the humans directing it skip evaluation and trust plausibility over correctness.
The spec is where that judgment gets captured before code exists. Not a planning document. A judgment artifact. What you're building, what you're not, what done means, and what would make this feature not worth building. Kill criteria: if this requires more than N database migrations, it isn't worth the complexity. The spec's entire value isn't planning. It's filtering.
Atlassian's framing is the cleanest version: judgment is defining the problem precisely enough that an agent builds the right thing, setting the constraints it won't infer, spotting the tradeoff buried three layers down, and knowing whether the finished implementation is good enough to ship. That judgment used to be bundled into the act of typing. Now it separates out.
Which means the definition of done can no longer be a ritual performed at sprint planning and forgotten by Tuesday. It's the artifact the loop reads to know when to stop, the gate the reviewer tests against, and the contract that tells a team what they agreed to build before the agent built it. Write it down, or the 180 percent will keep arriving and the 30 percent will keep shipping.