More code, not more software: move review to the plan

Coding agents make more code, but more code is not the same as more finished software. The extra code waits in review. Our answer is to review a written plan before any code exists, so the review of the diff has less to find.

What the paper found

Fiona Chen and James Stratton of Harvard University studied engineering data from 718 firms: 300 million work events from GitHub, Jira and calendars, from January 2021 to March 2026 [1]. They compared firms that adopted AI coding agents at different times. It is a job market paper; the current version is dated 4 August 2026.

After firms adopted agents [1]:

• lines of code rose 30%, commits 20% and pull requests 23%;
• resolved Jira issues and epics showed small positive effects that were not statistically significant, and the estimates rule out an output increase larger than 12%;
• the time from a pull request being submitted to being merged rose 49%, against a baseline mean of 7.03 days;
• the share of pull requests with changes requested nearly doubled, and comments per pull request rose 35%;
• the share of workers doing code review rose 14%.

The authors' model gives two reasons why review becomes the bottleneck. AI raises the amount of draft code, and it changes the quality of the draft that enters review. The first adds volume. The second changes how much review each unit of code needs [1].

The data is observational. The sample is firms that agreed to share their data for research, and adoption is measured per firm, not per engineer.

Where review time goes

This part is our reasoning, not the paper's. A diff review asks two questions at once:

1. Is this the right change?
2. Is this change right?

The first question is expensive to answer late. If the reviewer decides the design is wrong, the code is rewritten and reviewed again. That is the "changes requested" loop.

We move the first question to a written plan. A design hole found in a plan costs an edit. The same hole found in a diff costs a rewrite.

The loop we use

Every multi-session change in our own work follows the same steps.

A task brief is written so that a subagent could work from it alone. The part that makes it reviewable is the definition of done. It lists outcomes someone can observe, not activities. A shortened example, in the style of our briefs:

## Definition of done
- [ ] The guard exits non-zero on a chain address that is not on the allowlist
- [ ] The host's build step runs the guard, and a failing guard stops the deploy
- [ ] A test plants each refused pattern and sees the guard fail

## Out of scope
- Checking pages that are not in the site directory

An example

Take a site that is published from main, so that every merge deploys it. It needs a publish guard, a script that refuses a page carrying content that must never go live.

Suppose the first plan ran the guard in CI. Plan review marks this as blocking: some hosts deploy every push to main whatever CI says, and some plans cannot make a CI check required. A red CI run would not stop a bad page from going live.

The fix is a change to the plan: the guard runs as the host's build command, so a failing guard stops the deploy. CI runs the same guard so problems show on the pull request first. Found in the plan, this cost a few lines. Found after the build, it would have meant redesigning the deploy path and reviewing the code a second time.

The diff audit still finds real bugs. In a guard like this, text files with a NUL byte, or in UTF-16, can be skipped and so pass. And scripts can still get through as inline event handlers, links using the JavaScript scheme, and inline frames with embedded documents. Each becomes a planted case in the guard's test script.

The audit no longer asked whether the guard was in the right place. It asked whether the guard's code was right. That is a narrower question, and a cheaper one to answer.

What the human reads

The author does not read every line an agent writes. The author reads:

• the plan and its list of blocking findings, which is short;
• the decision log, where each waiver or design change is dated and explained;
• the pull request's "how to verify" section: the commands that were run and what they returned;
• the diff, with the design already agreed.

Limits

• We have no controlled measurement that this shortens merge time. The paper does not test plan review. Our repository has one author.
• Plan review has a cost: six agent runs per plan, and again after any large change. For a change that fits in one session, we skip the plan.
• Reviewer agents miss things and raise noise. The orchestrating agent checks each blocking finding against the code before acting on it.
• A plan goes stale fast. We update its "resume here" section as each piece of work finishes, not at the end of the day.

Try it on your next change

1. Pick a change that will take more than a day. Write a one-page plan with a definition of done made of observable outcomes, and an out-of-scope list.
2. Have it reviewed before any code exists, by people or by agents with distinct briefs. Record the blocking findings and what you did about each.
3. In the pull request, list the commands you ran and their results. Review the diff against the plan.
4. For a month, compare merge time and changes requested on planned and unplanned changes.

What we do: our agentic coding workshop and setup sprint put this loop into a team's own repository. See https://centrob.co/#ai.