AI-Assisted Engineering: When Review Becomes the Bottleneck

I recently read a CTO's account of working with coding agents: the team's pull request backlog was growing faster than they could clear it. Agents shift more of the work from writing code to understanding and reviewing it. The problem is simple: more generated code can look like more completed work.

In Why I Trust Verified Agent Work More Than Chat, I argued that trust comes from inspectable, tested changes. The next question is how much verification a workflow can sustain before code review becomes the bottleneck.

For example, an agent produces several large pull requests in an afternoon. If each needs hours of review and repeated corrections, the first patch arrives quickly, but the work is still waiting. This is another way a better model can become a worse tool: writing gets faster, but checking does not.

Small changes help. Google's guidance on small changes recommends one self-contained change with the context and tests needed to review it. Size is about conceptual scope, not just a line count. In simple terms, how much do you need to understand to check this change? A short patch spread across many files can still be hard to follow.

SmartBear's code review guidance, drawing on a study of a Cisco programming team, recommends reviewing 200-400 lines at a time. For me, that is a useful warning about review capacity, rather than a limit that works for every repository.

Adding a reviewer agent can help, but its findings need checking too. GitHub's documented limitations of Copilot code review include missed problems, false positives, and suggestions that may be incorrect or insecure. In that CTO's account, an agent and a reviewer agent could go back and forth on one pull request for days without visible progress, until he investigated the root cause himself. I still want to know what the problem is and whether the suggested fix works.

So, I would keep the workflow simple:

• Give each change one purpose and clear acceptance criteria: what should it do, and how can a reviewer check that it works?
• Automate repeatable checks (tests, linters, type checks in pre-commit or CI), so human review can focus on requirements, design, and consequences.
• Set a stopping condition for agent correction loops, such as a limit on review rounds. If the limit is reached and the diagnosis is still unclear, ask a person to find the root cause or split the change into smaller parts.
• Measure time to an accepted, verified change, including review and rework.

That last measure also changes the economics discussed in When the Best Model Isn't the Best Value. A cheap first attempt can become expensive when retries and reviewer time are included.

For me, that is the real test of faster generation: if it does not get us to verified delivery sooner, it simply builds a longer queue.