More AI Code, Same Shipped Work? The Review Bottleneck

AI coding agents can turn a request into a pull request quickly. That feels productive. But a pull request still needs someone to decide whether the change solves the right problem, fits the existing system, and is safe to release.

A 2026 working paper by Fiona Chen and James Stratton offers a useful warning for engineering leaders: faster code generation does not automatically mean faster delivery.

What the study measured

The researchers analyzed roughly 300 million work events from 718 firms using the Jellyfish engineering analytics platform. Their data run through March 2026. They compared outcomes as firms adopted AI coding assistants and agents.

Following adoption of coding agents, the study estimates:

The researchers found no statistically significant increase in resolved issues or epics, which they use as measures of completed software work. That is more precise than saying no team shipped more software. The data come from firms on one analytics platform, and the findings do not establish what happened at every company or with tools released after March 2026.

The paper finds evidence that review absorbs part of the increased coding output. It does not test whether KOS, better project notes, or any specific review process reverses that effect.

Ask what the reviewer has to reconstruct

When an agent opens a change, the reviewer needs to answer five questions:

1. What outcome was requested, and how will we know it works?
2. Which existing decisions and constraints apply?
3. What changed beyond the intended scope?
4. Which checks ran, and which checks are still missing?
5. What could go wrong during release, and how would we recover?

If the pull request contains only a large diff and a confident summary, answering those questions becomes another research task. More generated code can create more work for the people responsible for accepting it.

Make the change reviewable before the agent writes it

Start with a short task brief. It should state the user-visible outcome, the relevant constraints, the files or components likely to change, and the acceptance checks. Keep the brief proportional to the task; a small copy edit does not need an architecture document.

For an existing product, point the agent to approved requirements and current project context, then have it inspect the running implementation. A project note can explain what was intended, while the code and tests show what exists today. If they disagree, ask the agent to surface the conflict before making a material change. This source-of-truth guide shows a practical way to handle that disagreement.

Next, keep the change small enough for a reviewer to understand. A focused pull request should explain what changed, why it changed, and which related files were intentionally included. The goal is not an arbitrary file-count limit. The goal is a coherent change that can be checked without reconstructing the whole project.

Finally, require evidence with the handoff: relevant tests, a manual workflow check where it matters, and clear disclosure of checks that were not run. For a production-facing change, identify the release risk and the available rollback path. “The agent finished” is a status update; it is not validation.

A practical review brief

Before the next coding-agent task, give it a brief like this:

Outcome: Users can save an inquiry with an assigned owner.
Scope: Update the inquiry form and its API validation only.
Constraints: Keep manual follow-ups; do not add automated messages.
Acceptance: Saving persists after refresh. An inquiry without an owner is rejected.
Review: Show the focused diff, tests run, remaining gaps, and release risk.

After implementation, the reviewer can compare the result with those acceptance checks instead of guessing what the prompt meant. If the task reveals a missing requirement, resolve it explicitly rather than letting the agent silently expand the scope.

KOS uses project memory for approved, durable decisions and a handoff for current work and verification. That separation can help the next person or agent find the right context; this handoff walkthrough shows how to start with one project. It is a workflow recommendation, not a measured claim that these files reduce review time.

Measure delivery, not just generation

Lines of code and pull-request counts describe activity. For your team, also watch review time, changes requested, escaped defects, and completed work that users can actually use. Compare these before and after adoption while accounting for changes in project mix and team process.

If review queues grow while completed work stays flat, adding more agents may increase pressure on the bottleneck. Narrow the work, improve acceptance criteria, and make validation visible before raising generation capacity again.

The practical question is whether the team can understand, verify, and release what it creates. Start with one project and one reviewable change. If you need a shared place for decisions and handoffs, the KOS Starter Kit provides a starting structure.