Line-by-line code review is finally dead. Here's what replaces it.

Line-by-line code review has been a zombie for years. Everyone’s always hated doing it. AI coding tools have exploded the number of PRs and finally made it impossible.

Every org we work with runs into this fast. They start doing more AI coding, and it breaks their review process, because suddenly each developer is producing a handful of PRs a day and nobody wants to review them. The PRs are often bigger too, but that’s a separate problem.

No one signed up to be a developer because they love reading someone else’s code, so nobody’s motivated to spend half their day on it. The backlog grows. The instinctive fix - tell people to review more - doesn’t work, because it’s not a motivation problem. It’s a process built for a world where a person produced maybe one or two PRs a day, running headfirst into a world where an agent produces ten.

What review is actually for

Break “code review” apart and it’s really five different jobs wearing one trenchcoat:

1. Find bugs
2. Make sure the code is consistent with the rest of the repo
3. Check decisions that have future implications
4. Communicate the change to other developers
5. Have two sets of eyes, because your SOC2/ISO27001 auditor wants that

Once you split it up, the shift is obvious. (1) and (2) are now best done by automated tooling - including LLMs, often more than one of them - not by a human skimming a diff. (3) and (4) still need a human, unavoidably. (5) is still valid as a compliance requirement, but it doesn’t require line-by-line attention to satisfy.

Line-by-line review was always a bundle of these five jobs done at once, by one overworked human, because we didn’t have a better way to split them apart. Now we do.

The process that’s actually working

Here’s the shape we see working best right now, across the teams we talk to:

• The developer plans with the agent, then reviews the plan.
• The agent implements.
• The developer reviews the code - especially the tests and acceptance criteria. (Sometimes it helps to have the agent write the tests first, so this step is easier and can happen in parallel with implementation.)
• That review happens locally or in a draft PR. A draft PR is usually better, because CI runs in parallel while you’re still looking at it.
• The agent watches CI and any automated review feedback, and triages and fixes eagerly.
• Only then does the PR go to “Ready for Review.”

At that point, a second developer reviews it - but not line-by-line, because that ground has already been covered by multiple automated passes. They need to understand the goal, then look specifically at schema or infra changes, and check the new tests at least at the level of principle. The single most important thing they’re looking for: decisions in this PR that might have ramifications - security implications, scalability implications, anything that touches a non-functional requirement.

Your tooling should be surfacing those decisions, not making the reviewer hunt for them across a 40-file diff. That’s the whole premise behind what we’re building at Cadence: read the code and the session log together, and use both to work out what actually happened in a change and what a human needs to weigh in on. Use something else if it does that job better for you - but do something. The old model, where every line gets a human’s eyes because that’s just what review means, is not going to survive contact with the volume AI coding produces.

It’s time to rethink code review. Your developers will thank you for it.