quanttype.net
Code review, autumn 2026
_By autumn, I mean northern-hemisphere autumn, when this was written._
At work, we’re talking about code review. Coding agents make it easy to produce so much code1 that it’s difficult for the reviewers to keep up. Review agents2 are now starting to produce reviews that are at least half-decent. This leads to questions: what are we trying to achieve with code review?
It’s a great question but it leads to you to top-down approach to designing your software development process. In this post, I’m going to ignore it and instead gesture towards a bottom-up way.
## On what even is review
When we talk about reviews, two things get mixed up:
1. Does a human need to review the code produced by an LLM or a coding agent at all?
2. Do we need the practice known as code review where a second3 human reviews the code?
If you answer the second question with a no, do you think humans need to collaborate on _code_ anymore at all? Does pair programming still make sense?
## On the meta
The daily work of software development is changing quickly. The change is so fast that there has not been time for best practices to emerge. Those who claim to have clear answers typically have something to sell.4
There’s no reason to think that the change is over. Even if progress in model capabilities slows down, the tokens will get cheaper. We are only starting to figure out how to use agents.
What can you do? You should experiment and iterate. Try post-merge review. Try automating review. Try asking the LLM how to do code review. Try not doing code review at all. Build a dark software factory – or maybe not, those are passé already.
Some of your experiments should be bold enough to fail. How else would you know where the limits are? Just don’t do it in production with the moneymaker app.
## On fear
Why was it so easy for software development teams to give up programming, yet we are clinging to code review?
One reason – just one – is fear. By giving up writing code to the agents, we’ve given up a lot of control and we are scared of the consequences. The code review is the last human checkpoint before shipping to production and we don’t want to let go.
How do you get over the fear? One way is to take back control by building stronger guardrails. You’ll want those type checks, CI checks, monitoring, automatic rollbacks, backups, and principle-of-least-privilege permissions. They were always a good idea and they still are.
Another way is exposure therapy. Use the agents, let go, and see what happens.
## In conclusion
Experiment and iterate. Godspeed!
* * *
1. No-one is forcing you to produce so much more code than before. OpenAI’s agents may have gone rogue, but I bet your Claude Code session hasn’t. In the times before, producing code for new features was typically additive: you add new code until the change is ready. Now the first pass from the coding agents adds too many lines and you will have to whittle it down. ↩︎
2. By review agent, I mean the thing where you connect an agent to a pull request (PR) and ask it to review the PR. GitHub’s built-in Copilot code review is probably the best-known version of this. It’s a natural way to retrofit AI into the usual PR process, but I expect that in the future the coding agent and the review agent will just talk to each other directly. ↩︎
3. A few teams have inadvertently tried a code review setup where the reviewer is the first human to read the code. These reviewers complain about the slop grenades. Don’t go there. ↩︎
4. What about those who claim to have clear questions? Subscribe and you’ll be the first to know when I launch my course on rethinking agentic code review!! ↩︎
