Coding agents now return working-looking changes at a speed that can feel almost absurd. I describe a goal, switch to another task, and come back to a plausible patch with a reassuring test report. Yet my work often starts again at the moment the agent says it is done.
The change may solve the task I asked for. I still need to know what else changed, what remained untouched, and whether the existing system’s promises remain intact. A green test run does not answer all of those questions.
I think of this as a proof burden shift. AI has absorbed much of the effort of writing code, but not the responsibility for proving that the change is safe to accept. That burden tends to land on the human reviewer, and it does not scale neatly with the number of lines changed.
More code does not necessarily mean faster delivery
This is more than an individual impression. In their August 2026 study, Artificial Intelligence in the Firm: Bottlenecks in Software Production, Fiona Chen and James Stratton examine roughly 300 million engineering work events across 718 firms. They report increased coding activity following AI adoption without a proportionate pass-through to completed software output, and identify code review as an important bottleneck for agent use. This is an observational study using differences in adoption timing, not a controlled experiment on my own projects. (Researcher’s summary)
I have not measured a neat multiplier between my implementation time and review time. What I have observed is simpler: generated code and an acceptable change are not the same deliverable.
I was already developing from specifications
The familiar advice is to stop giving agents vague instructions and write better specifications. That advice is reasonable, but it skips an important part of my experience. I was already doing it.
For my MI Agent work, I establish business objectives and expected outcomes before narrowing the architecture and implementation contract. With fetchdoc, I define what must survive when a reusable document template is created and used again. I keep design decisions in an evolving LLM Wiki and steer the builder back when it drifts into broader refactoring or abstraction.
Even then, an agent can satisfy the stated checklist while adding a new Helper, Wrapper, or alternate pathway that bypasses an existing function. The implementation may be locally elegant. It still expands what I must understand about callers, failure handling, and maintenance.
I call this synthetic consensus in this article: a situation where agreement on the required outcome is mistaken for agreement on the implementation route. It does not mean longer specifications always cause failures. It means passing the stated acceptance checks is not identical to earning architectural acceptance.
OpenAI has documented reward-hacking behavior in internal coding-agent monitoring, including cases in which tests or checks were changed to satisfy evaluation signals rather than the underlying task. (OpenAI report) That documented behavior is not the same as the unnecessary abstractions I have encountered. Both, however, remind us why a passing signal cannot by itself establish that the intended system was built.
Enterprise systems have gravity
Enterprise software operates under constraints that are often invisible from a source file: network policy, authorization boundaries, operational ownership, retention requirements, and existing retry behavior. I think of these constraints as enterprise gravity.
Consider an illustrative case, not a claim about a specific customer incident. A team originally designs around an inbound webhook. Later, the customer’s security boundary rules out a public inbound endpoint. The agent can replace the design with outbound API calls and polling relatively quickly.
The architectural review now has harder questions. When is a remote call ID associated with the internal work item? What happens if the response is lost? Can reconciliation replay a side effect twice? If the operation times out after a remote success, what durable fact can safely drive the next attempt? What can operations staff inspect during an incident?
The delay involved in approving a network policy is not itself a code review bottleneck. The bottleneck addressed here is the extra effort to understand and validate the new code against the changed constraints. In enterprise delivery, that effort often moves to the people who will inherit the service.
Another AI gave me more claims to adjudicate
I have also used Antigravity to audit changes built with Codex. I previously wrote about why a Builder and an Auditor can usefully perform different jobs. What interests me here is the remaining work after that separation.
In an early independent-audit attempt, read-only instructions were not enough to establish a trustworthy evidence boundary. Evidence from a later worktree appeared to contaminate a review intended for an older Git baseline. I eventually moved the audit to an isolated, frozen source snapshot.
In another inspection, an auditor correctly noticed a 50ms polling interval. That is a code fact. Actual connection-pool exhaustion, however, needs workload and resource evidence. An observed implementation detail cannot automatically be promoted to a production defect.
At that point I was no longer merely asking an AI to find possible problems. I had to decide which findings were facts, which were hypotheses, and which were contractual defects. This is what I mean by arbitration fatigue.
Two agents agreeing does not settle the matter. If both read the wrong baseline, agreement adds little value. A second model may reduce the amount of repository exploration I perform, but it can also create a new set of claims that require adjudication.
Review the invariants before reconstructing the diff
I am not proposing that engineers stop reading diffs. Code review remains necessary. I am proposing a different order of attention.
Start with the frozen Git baseline, the allowed change boundary, and the contracts that must remain stable: APIs, data shape, state transitions, retry and replay semantics. Then examine the tests actually executed against that baseline and the checks that remain missing. Finally, read the diff with particular attention to unproven risks and changes beyond the agreed radius.
By invariant-first review, I do not mean a mathematical proof that a system contains no defects. I mean asking for evidence about specific preserved contracts before spending human attention reconstructing every intention from generated code.
A deterministic tool can check changed paths, type and schema rules, test exit codes, Git identity, and whether unexpected files or external calls appeared. Architectural appropriateness, the value of a trade-off, and the acceptance of residual risk still need judgment.
No unauthorized abstraction
One constraint I find particularly useful is No Unauthorized Abstraction. This is not a universal ban on Helpers or Interfaces. It means that if the agent needs to introduce a layer that was not within the approved scope, it should explain the reason and request approval before expanding the change.
That does not require a hundred-page specification. A usable change request can identify the baseline SHA, objective, permitted paths, contracts to preserve, scope expansions requiring approval, tests, and known risks. The completion report should include the actual diff and execution evidence. A test that was never run should never be presented as passing.
This does not guarantee perfect code. It does make one recurring question cheaper: why did the agent touch this part of the system at all? And when a new abstraction is justified, that decision becomes explicit instead of hiding inside a large patch.
Measure acceptance speed, not merely generation speed
The metrics I would like to track are review queue time, actual review effort, rework rounds, first-pass acceptance, and defects found after acceptance. Queueing time and hands-on review time must be separated; otherwise, the data cannot distinguish a capacity problem from a proof-quality problem. I do not yet claim measured improvements for these metrics in my own projects.
A solo developer can commission a change and ultimately accept it personally. In enterprise delivery, the engineer and operations team who inherit that code may be different people. Today’s fast implementation can become tomorrow’s expensive attempt to reconstruct intent.
AI already produces code quickly. The next demand should be evidence of what it did not change and which existing promises still hold—not merely a description of what it built. Agents can write the patch. People and organizations still own the decision to accept and operate it.