You can't review your way out of a context problem

Why scaling code review will not close the write-to-ship gap, and what will.

July 8, 2026 10 min read

The numbers finally caught up with the feeling. In a large study across more than a hundred thousand developers, AI tools raised the volume of code written by around 180 percent, but the number of actual releases rose only about 30 percent (Demirer, Musolff and Yang, "Writing Code vs. Shipping Code," NBER, May 2026). GitLab's 2026 accountability survey put the mechanism in one line: 85 percent of respondents "agree AI has shifted the bottleneck from writing code to reviewing and validating it," and 79 percent say overall delivery has not kept pace with coding. Writing got cheap. Shipping did not. Addy Osmani, who leads developer experience for Chrome at Google, named the shape of it early: "They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns." Generation is the cheap seventy. The expensive thirty is everything after, and the gap between them is the story of the year.

The industry has already picked its answer, and the answer is more review. The most trusted practitioners in the field have converged on it. Simon Willison, describing what he calls "vibe engineering," lists the real job of working with agents as "researching approaches, deciding on high-level architecture, writing specifications, defining success criteria" and "spending so much time on code review." Sean Goedecke, a staff engineer at GitHub, puts it flatly: "Using AI agents correctly is a process of reviewing code." They are describing the world accurately. With a capable agent, the human job has largely become review.

The trouble is what follows from it. If review has become the job and shipping still has not caught up, then adding review capacity is not the lever. The reflex to add more of it, buy an AI reviewer, staff a validation team, govern the code after the agent produces it, misdiagnoses where the defect enters. Review inspects the output. The write-to-ship gap is created by the input. You cannot inspect quality into a product that was built without it, and scaling the inspection step only makes the bottleneck it was meant to relieve more expensive.

What review actually is, and what it cannot do

Software review is a specific operation: a human or a tool examines a finished artifact and decides whether to accept it. In quality terms it is inspection, the same category as end-of-line checking in manufacturing, and the field settled the limits of inspection decades ago. W. Edwards Deming, whose methods rebuilt postwar manufacturing, made it the third of his famous fourteen points: "Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place." Inspection does not create quality. It measures whatever quality the process already produced, and it does so after the cost of producing the defect has already been paid. If your process reliably emits defects, a better inspector catches more of them and changes nothing about why they keep arriving.

Apply that to an agent. When an AI coding agent produces code that a reviewer has to reject or rework, the review did its job, but the defect was minted upstream, at generation time, and the review is now paying to detect it. Scaling review scales detection of a problem you are still manufacturing at full rate. That is precisely the shape the 2026 data shows: generation raced ahead, the inspection stage became the constraint, and total throughput barely moved. Adding inspection capacity to an input-defect problem is running the assembly line faster into the same wall.

Why the agent emits defects a reviewer has to catch

Here is the part that decides everything: a large share of what review rejects is not a bug in the usual sense. The code often runs, passes its tests, and is internally clean. It is wrong because it violates a decision the team already made and the agent could not see. The retry logic it removed was load bearing for a reason recorded in a pull request thread. The pattern it "simplified" was chosen deliberately over the obvious one. The agent did nothing irrational; it produced the most probable code given what it could read, and what it could read was the codebase, not the reasons behind it.

This is measurable, and the measurement looks exactly like statistical process control. In a controlled benchmark we published earlier this year, an agent with codebase access complied with decisions that were visible in the code essentially all the time, and with decisions that required out-of-code product context only 0 to 33 percent of the time. Read that the way a process engineer reads a defect map: the agent is already near-defect-free wherever the specification is present in the material it works from, and defects appear only in the region where the input specification is missing. It is not an unreliable process. It is a reliable process being handed an incomplete spec, and its defects cluster precisely where the spec has a hole. That hole is the class of defect that passes tests and lands on a reviewer's desk, and when the missing decisions were supplied at generation time it largely closed.

The economics of inspecting versus preventing

Treat it as a pipeline and the two strategies price out differently. Under the inspection strategy, every task pays the generation cost, then a review cost to find the context violations, then a rework cost to fix them, then re-review, with the reviewer carrying the hardest version of the task: validating code they did not write and may not fully understand. This is the cost-of-quality curve that quality engineering has measured for decades. The cost of a defect rises by roughly an order of magnitude at each stage it escapes, from design to build to inspection to the field, so a context violation caught in review is already several stages past the point where it was cheapest to remove. Under the prevention strategy, the relevant decisions are placed in front of the agent before it generates, so the violation is never produced, and the review that remains is doing its proper job of catching genuine bugs rather than re-litigating settled choices. One strategy scales the most expensive step. The other shrinks the work that step has to do.

This is why "more review" reads as progress and is not. It is visible, staffable, and buyable, so it feels like action, but it is optimizing the inspection stage of a line whose defect rate is set upstream. The leverage is upstream.

What prevention actually requires

Prevention here has a precise meaning, and it is not "write better prompts" or "hope the next model is smarter." The instinct is already in the field. Kent Beck, who gave us test-driven development, draws the line between "vibe coding," where "you don't care about the code, just the behavior of the system," and "augmented coding," where "you care about the code, its complexity, the tests, & their coverage." Caring about the code means specifying what good looks like and holding the output to it. Prevention takes that one step further upstream: the constraints the agent must honor should reach it before it generates, not after. A larger model does not change this, because it reasons better over what it can see and still cannot see a decision that exists in no input, which is a floor no model size clears. Prevention means the decisions the agent must honor, along with their rationale and whether they still hold, are retrievable at generation time, so the agent conditions on them before it writes rather than a reviewer reconstructing them after. In manufacturing terms it is poka-yoke, mistake-proofing at the workstation: the constraint reaches the worker before the part is made, so the defective part is never produced. That is a property of a store, not of a prompt, and the earlier posts in this series describe what that store must be, how you keep the right decisions selectable, and how they get captured in the first place without a documentation tax. The point of this post is narrower and, I think, harder to argue with: whatever you build, build it upstream of generation, because the stage everyone is rushing to reinforce is the wrong one.

We built Brief to be that upstream layer, so agents generate against your decisions instead of around them. But the reason the review strategy stalls is not a claim about us. It is the oldest result in quality engineering, arriving on schedule in a new medium: you do not inspect defects out, you build them out.

What this does and does not claim

It does not claim review is unnecessary. Genuine bugs need catching, and human judgment on real tradeoffs is not going away; the argument is against review as the primary lever for the write-to-ship gap, not against review. It does not claim prevention catches everything. Some decisions are genuinely new and get made during the work, and those still need a human; prevention shrinks the defect class that never should have reached review, it does not empty the queue. And the benchmark is one measurement on one task set, not a law; run the split on your own tasks and see how much of what your reviewers reject is a context violation versus a real bug. The load-bearing claim survives all of that: the write-to-ship gap is an input defect, inspection cannot fix an input defect, so the money and attention flowing into review are being spent one stage too late.

The gap is real and now well measured. The instinct to meet it with more review is the instinct to inspect harder, and inspecting harder has never been how quality got built. Move the fix upstream of the agent, and the reviewers get to go back to reviewing.

Frequently asked questions

Isn't better AI code review the obvious fix for the write-to-ship gap? It is the intuitive fix and the incomplete one. Review is inspection, and inspection detects defects rather than preventing them. If a large share of what review rejects is code that violates decisions the agent could not see, a better reviewer catches more of those violations but does nothing about why the agent keeps producing them. The leverage is upstream, at generation time.

Why does an agent write code that passes tests but still gets rejected? Because passing tests proves the code does what the code says, not that it honors what the team decided. Decisions about tradeoffs, rejected alternatives, and constraints often live in pull request threads and docs, not in the code, so an agent reading only the codebase cannot condition on them and produces a plausible answer that violates one. In our benchmark, agents complied with 0 to 33 percent of decisions that required this out-of-code context.

Will bigger context windows or better models close the gap? They help at the margin and do not close it. A model cannot honor a decision that is present in none of its inputs, regardless of window size or capability, so the fix is making the relevant decisions retrievable at generation time, not enlarging the model. A previous post in this series covers why capacity is the wrong lever.

What does "prevention instead of inspection" mean concretely for AI coding? It means supplying the agent with the decisions it must honor, and their current status, before it generates, so the violation is never written, instead of catching it in review after it is. Practically that requires a retrievable store of decisions with rationale and currency, positioned upstream of the agent rather than a gate positioned downstream.

Does this mean we should stop reviewing AI-generated code? No. Review still catches genuine bugs and weighs real tradeoffs. The claim is that review should not be your primary answer to the write-to-ship gap, because the gap is dominated by input defects that prevention removes more cheaply than inspection detects.