Dr. Neil's Notes
Software > Development > AI in Delivery Systems
Code reviews in the age of AI
Introduction
AI can produce code at a remarkable pace. It can also produce a remarkably convincing explanation for code that does not do what anyone needs. The faster code arrives, the more important it becomes to have another engineer understand it before it becomes part of the system.
Code review is often described as a quality gate, a final chance to catch mistakes before they merge. That matters, but it is only part of the value. Review is how understanding travels through a team. It gives someone else the context to explain, maintain, and support a change when the original author is busy, on leave, or has moved on to the next exciting thing.
That makes review more important in the age of AI, not less. A coding assistant can help produce a change. It cannot take responsibility for the change in production, and it cannot make sure the team understands the system it has just altered.
The person who accepts the code owns it
AI may type the code, but the engineer who asks for it, chooses what to keep, and sends it forward is its author. There is no useful "the model wrote it" category in a production incident. The system will not care who supplied the first draft, it will do what the code tells it to do. AI assistance does not transfer authorship or accountability.
That means I need to understand the change, not merely recognize that it looks plausible. I should be able to explain, in my own words, what the important parts do, why this approach fits the system, what assumptions it depends on, and how I know it works. That understanding comes from reading the diff, tracing the behavior through the surrounding code, and validating it with relevant tests and, where needed, a real environment. A green test suite is evidence, not a substitute for knowing what the tests actually cover.
I also need to be ready to support the code after it ships, follow a failure through it, identify likely causes, and make a safe correction without asking the model to explain its own confident guess. If I cannot do that yet, the change is not ready. I should ask the assistant to clarify, test smaller slices, or stop and learn the missing context. The AI can be an excellent pair of hands. It has not been assigned to the on-call roster, and it will not answer when a customer asks why the shipment is missing.
The code is not the whole change
Automated tests can tell us whether expected examples still work. Linters can enforce conventions. AI can point out patterns that deserve a closer look. These are useful tools, but none of them answers every important question:
- Does this change solve the right problem?
- Does it fit the way this system is meant to work?
- What assumptions does it make about users, data, or other services?
- What should someone do when it behaves differently in production?
The code itself may be perfectly tidy and still be the wrong change. A review brings another person into the reasoning behind it. The reviewer can ask where an assumption came from, notice a consequence that was not in the prompt, or explain why an odd-looking part of the system is odd for a very good reason.
This is especially valuable when AI helped write the code. A polished answer is not evidence that the underlying decision is sound. The machine is very good at making a guess look like it has dressed for a job interview.
Review is how knowledge spreads
At least one other engineer should review every change before it merges. Not because the author is untrustworthy, and not because every line needs a second pair of eyes for its own sake. The point is that two people should understand what changed and why.
When knowledge stays with one person, that person becomes a queue, a bottleneck, and eventually a very inconvenient holiday calendar. When a reviewer follows the change, asks questions, and understands the answer, the team gains another person who can maintain it.
This is more than backup coverage. A review can reveal conventions that are not written down, connect a local change to a wider design, and help a colleague learn the codebase through real work. The author also benefits. Explaining a decision to another engineer often makes the decision clearer, or exposes a gap before it becomes permanent.
The strongest outcome is not simply "the code has been checked." It is "another engineer can describe what this change does, why it is here, and what to watch for when it runs."
Make review small enough to do well
A review becomes less useful when it arrives as a three-day queue of enormous changes. By then the reviewer is trying to reconstruct the author's week from a diff, and the author has forgotten why line 47 seemed like a sensible idea at the time.
Keep changes small enough to review in under thirty minutes. Small changes make the reasoning easier to follow, the risks easier to see, and feedback easier to act on. They also let the team learn continuously instead of holding a grand archaeological review after the feature has already shipped.
The review should be treated as first-priority work, not the thing everyone does after their "real work" is finished. If reviews wait indefinitely, changes wait too, context fades, and people learn that the process is optional in practice even if it is mandatory in the handbook.
Small and timely does not mean rushed. It means making the work reviewable and giving it the attention it deserves while the context is still fresh.
Ask questions, not just approve
A review is not a ceremony in which one person presses a green button and transfers responsibility to someone else. An approval should mean the reviewer understands the change well enough to help support it in production.
That is why good reviews ask questions. "What happens if this value is missing?" is more useful than silently hoping it never is absent. "Could you explain why this belongs in this layer?" can uncover a design assumption that would otherwise stay hidden. The question is not an accusation. It is an invitation to make the reasoning visible.
AI can help identify possible issues, but it should not be the only reviewer. It does not carry the team's shared history, it does not know which trade-offs were agreed in the room, and it will not be on call when a plausible suggestion meets an implausible production environment. Human review puts the change back into the context of the team that owns it.
The point is better software, built together
The argument for code review is not that humans never make mistakes. They do, often with excellent formatting. The argument is that software is a team responsibility, and a team cannot share responsibility for changes it does not understand.
AI makes it cheaper to produce code. That is a genuine advantage. It also makes it easier to produce more code than a team has had time to understand. Review closes that gap. It gives people a chance to check the intent, challenge the assumptions, and spread enough knowledge that the software does not depend on one person, or one prompt, to keep working.
Every change should leave the team stronger, the code a little better, the reasoning a little clearer, and at least one more person able to support it. That is not overhead. That is how we build software together.
Part of the AI in Delivery Systems series.