/images/blog-generated/cost-of-code-review-now-higher-than-the-code.webp

The Cost of a Code Review Is Now Higher Than the Cost of the Code

For most of software’s history, code review was a tax on writing. A small one, paid grudgingly, and never the line item that decided whether a feature shipped on time. The work was in the writing; the review was the cherry on top.

That ratio has flipped.

When an agent produces a thousand lines of code in twenty minutes, the bottleneck in the system is no longer the typing. It is the reading. It is the careful, line-by-line evaluation of code that looks plausible, compiles cleanly, passes its own tests, and may still be doing the wrong thing in five subtle places. The work that used to be free is now the work that costs you.

Where the Tax Used to Sit

A senior engineer writing a feature by hand carried the cost of the implementation in their head as they typed. They knew which variables had been renamed, which functions had been split, which assumptions they had made about the upstream caller. By the time the PR opened, the author had already done most of the review – in their own head, in real time, as they wrote.

The reviewer’s job was small and well-defined. Catch obvious mistakes. Push back on style. Flag the architectural drift that the author was too close to see. A good reviewer could clear a PR in twenty minutes because the author had carried the cognitive load all along.

The cost of writing was high. The cost of reviewing was low. The system worked.

Where the Tax Sits Now

An agent does not carry the implementation in its head. It does not remember why it chose one approach over another. It does not feel the weight of the codebase it just touched. It produces output. The output may be excellent. It may be subtly wrong. It is not aware of the difference.

The reviewer has to do all the work the author used to do, plus all the work the reviewer used to do. They have to reconstruct the reasoning, check it against the codebase, verify that the agent did not silently break a dependent module, and confirm that what looks like a feature is in fact the feature that was specified.

The cost of writing has collapsed. The cost of reviewing has not. In some cases it has gone up, because the surface area of the diff has expanded faster than the human’s ability to read it.

What This Does to Team Economics

The first-order effect: the rate-limiting resource on your engineering org is now your senior reviewers, not your implementers. If you have ten engineers and two seniors who do most of the architectural review, the two seniors are now the bottleneck on every PR your agents produce. Add more agents and you do not get more throughput. You get a longer queue at the reviewer’s desk.

The second-order effect: the value of code you do not review at all is approximately zero. Code that lands in your repository without a human’s careful read is a liability. It compiles. It runs. It may be doing harm you cannot see. The cheap thing is no longer “write it.” The cheap thing is “delete it before anyone depends on it.”

The third-order effect: the engineers who can review well are the most expensive people on the team – and the ones least likely to be promoted out of the review path, because there is no one else who can do the work.

How We Adjust

A few things we have changed in our own delivery model:

Reviewers are paid, ranked, and respected like writers used to be. The senior who reviews fifty agent PRs a week is doing more for the codebase than the senior who personally writes ten. We track this. We compensate for it. We do not assume the writer is the one to credit.

Specifications carry the cognitive load that authors used to. A precise spec, written before the agent runs, makes review tractable. The reviewer is checking the implementation against a written contract, not reverse-engineering intent from code. The spec is the audit trail. If the agent did the wrong thing, the spec told it to.

We delete more code, sooner. When an agent produces an implementation that almost works, the cost of accepting it and fixing the bugs is often higher than the cost of throwing it away and re-specifying. We measure agent output the way a factory measures yield, not the way a craftsman measures effort. Low-yield work goes in the bin.

We bound diff size. A PR longer than a reviewer can hold in working memory is not a PR. It is a request to skip review. We split, we sequence, we refuse to merge. The agent can produce a thousand-line change in twenty minutes; the team cannot review one in less than half a day. The author – human or agent – has to respect the reviewer’s window.

We invest in review tooling like we used to invest in IDEs. Diff narrators. Spec-vs-implementation diff. Test-coverage diff over the changed lines. Anything that compresses what the reviewer has to read. The IDE was the writer’s force multiplier; the review tooling is the reviewer’s.

What This Means for Hiring

If you are still hiring engineers primarily for their ability to write code, you are reinforcing a bottleneck instead of relieving it. The skill you need is the skill of reading code critically, predicting how it will behave in production, and rejecting the parts that should not ship. That is the skill that defines a senior engineer. It is also the skill that almost no interview process is designed to test for.

Ask your candidates to review code, not write it. Show them an agent-produced PR with three plausible-looking bugs. See which they catch. See how they articulate the architectural drift. See whether they can distinguish “this is wrong” from “this is not how I would have written it.” That second distinction is what separates a reviewer who unblocks the team from one who clogs the queue with bikeshedding.

The Honest Statement

The economics of software have inverted. The thing that was expensive is now cheap. The thing that was cheap is now expensive. The engineering orgs that adjust their costs, their staffing, their tooling, and their hiring to the new ratio will scale. The ones that keep optimizing for writing speed while their review queue grows will discover, the slow way, that they have built a factory with no quality-control floor.

Code review is not the chore at the end of the pipeline anymore. It is the pipeline.