
AGENTIC CODING
Stop reviewing AI-generated code line by line — review the plan instead
The instinct of any senior engineer asked to oversee AI-generated code is to read every line. It feels responsible. It is also the single biggest reason agentic coding stops compounding value at most teams that adopt it. Reviewing the plan, the inputs, and the outputs scales. Reviewing the diff line by line does not.
Why line-by-line review fails
Line-by-line code review evolved for a world where humans wrote code at a roughly fixed pace and reviewers could keep up. Agentic coding breaks that ratio. A senior engineer can pair-program with three or four parallel agents, each producing several hundred lines an hour. If the human bottleneck is reading every line, you have not multiplied output — you have moved the cost from one person to another, and added a coordination tax on top.
There is also a quality argument against line-by-line review of agent output. Modern coding agents produce locally idiomatic code that mostly looks right. The bugs are not where reviewers usually look. They are in the assumptions: a wrong understanding of the data shape, a missing edge case in the spec, a misread of the existing API. Reading the diff makes you feel diligent and surfaces almost none of these.
What ‘review the plan’ actually means in practice
The pattern we use on every client engagement: before any code is written, the agent produces a plan. The plan describes the approach in 200–400 words, lists the files it will touch, names the public functions it will add or change, and explicitly states what it is NOT going to handle. The senior engineer reviews this. That review takes five minutes and prevents an hour of generated code that solves the wrong problem.
After the code is generated, review skips most of the diff and goes straight to three things: the tests (do they cover the cases the spec mentioned?), the new public surface (does it match what the plan said?), and the integration boundary (does this break anything outside the changed files?). Style, naming, and refactor noise are not reviewed. They get auto-formatted and merged.
What you should keep reviewing
Tests are the single highest-value review target. AI agents are excellent at writing tests that pass and miserable at writing tests that exercise the failure cases. Read every test the agent generated and ask one question per test: what would have to be wrong with the implementation for this test to fail? If the answer is unclear, the test is not pulling its weight.
Security boundaries, authentication paths, and anything that touches money or PII deserve a manual eyeballing. Not because agents are uniquely bad at these — they are usually fine — but because the cost of being wrong is asymmetric. A wrong CSS class costs nothing. A wrong permission check costs the company. Spend five minutes on each of these even when the agent says they’re not changed.
What you should stop reviewing
Stylistic and idiomatic decisions inside agent-generated code are no longer worth a human’s time. Variable names, function ordering, comment density, choice of one valid pattern over another equally valid pattern — let it go. Push it through your linter and formatter, and reserve human review for things that linters cannot catch.
Refactor noise inside changed files is also not a review target. If the agent moved three helper functions because that genuinely made the change cleaner, accepting that does not need a debate. Where this matters: if the agent moved code OUTSIDE the scope of the task, that is a plan violation and worth flagging — not as a code review issue, but as a ‘the agent did more than it was asked to’ issue.
How we structure agentic coding work for clients
Every engagement at AI Project Fixers runs on plan-first review. We write the plan, your team approves the plan, the agent executes against the plan, and we review against the plan rather than the diff. Reviewers stay senior, output stays high, and nobody burns out reading 4,000 lines of generated TypeScript a day.
If your team has adopted Claude Code, Cursor or Codex but the velocity gain has been disappointing, this is almost always why. We run hands-on training that retrains the review reflex — see our agentic AI coding courses — and we’d be happy to walk through how it’d map onto your codebase on a 30-minute call.
Want this workflow inside your team?