AI code review does not have to mean shipping fast and sloppy. Used with discipline, it can mean shipping slower and far better. That distinction matters because the current conversation around AI-assisted programming is often stuck on the most visible use case: generating code quickly.
The dominant image of AI-assisted coding right now is a developer leaning back, watching an agent spit out 400 lines of code, and clicking merge without reading a single line. Fast, voluminous, disposable. It is an understandable concern. Code that arrives faster than a team can inspect it does not remove engineering work; it simply shifts risk downstream, where mistakes are harder to diagnose and more expensive to unwind.
That caricature has become so entrenched that when engineers talk about AI code review, they almost always mean reviewing AI-generated slop rather than using AI to do the reviewing. Nolan Lawson, a software engineer who works on the open web and has written extensively about front-end architecture, takes the opposite view. His argument is not that machines should replace judgment. It is that they can give reviewers more places to look, more hypotheses to test, and more chances to catch a problem before it becomes someone else’s incident.
Lawson’s central point is deceptively simple: LLMs are flexible tools, not just fast ones. The same models that can generate mediocre boilerplate at speed can also be directed at existing code to look for subtle, high-impact bugs. But that only works when the task is framed as investigation rather than automatic approval. Asking an AI to produce an answer is different from asking it to challenge an implementation, trace edge cases, and explain why a change may fail under conditions the author did not consider.
That is why “AI code review” should not be treated as a synonym for a merge button with better branding. A useful review process still needs a human owner. Someone has to decide whether an alleged defect is real, whether a proposed fix fits the architecture, and whether the cost of changing code is justified. AI can widen the review surface. It cannot carry accountability for the result.
Table of Contents
AI Code Review Is Not What Most People Think It Is
The appeal of conventional automated checks is obvious: they catch repeatable mistakes cheaply. Yet many of the defects that matter most are not simple formatting errors or mechanical violations. They emerge from assumptions between modules, unusual states, incomplete error handling, or a change that makes sense locally while breaking a broader expectation. These are the kinds of questions a reviewer is supposed to ask, and they are also where an AI assistant can be useful if it is given enough context and treated with enough skepticism.
Lawson’s approach aligns with Google’s engineering practices for code review, which emphasise thoroughness over speed. That principle can sound unfashionable in an era obsessed with developer velocity, but speed without confidence is frequently just deferred work. A pull request that merges quickly and creates a subtle regression has not made the team faster. It has merely made the review stage look efficient.
The more interesting promise of AI review, then, is not that it lets teams reduce attention. It may let them spend attention more intelligently. A reviewer can start with a ranked set of concerns rather than a blank page. They can inspect the claims that multiple systems independently surfaced, reject weak suggestions, and concentrate on the parts of a change that deserve the deepest read.
This also explains why a quality-focused approach can uncover pre-existing bugs that predate the pull request entirely. Code review is usually scoped to a proposed change, but a careful examination of that change can expose assumptions already embedded in surrounding code. That discovery can be inconvenient: it may complicate a seemingly small PR, and it can be tempting to dismiss anything outside the immediate diff. Still, finding an older defect is not a failure of review. It is evidence that the review looked beyond the easiest path.
The Multi-Model Approach to AI Code Review
The core of Lawson’s technique is running multiple AI agents simultaneously against a single pull request and then synthesising their findings. His current setup chains three distinct tools: a Claude sub-agent from Anthropic, OpenAI’s Codex, and Cursor’s Bugbot. Each reviews the same PR independently. A final pass then consolidates the findings, cross-references them to eliminate false positives, and produces a ranked bug report sorted into critical, high, medium, and low categories.
Tools such as Claude sub-agents, OpenAI Codex, and Cursor Bugbot can rank bugs by severity across any pull request. The important word here is “can,” not “will.” Severity labels are useful for ordering attention, but they should not be mistaken for verdicts. A model can be persuasive about a problem that does not exist, and it can be insufficiently alarmed by one that does. The ranking is a queue for human investigation, not a substitute for it.
The multi-model approach is not a quirk; it is the key insight. Any single LLM will hallucinate occasionally. It may flag a non-issue with confidence, or miss a real bug because of a blind spot in its training. A single-model workflow therefore creates an awkward choice: trust the output too readily, or spend so much time filtering it that the tool becomes a distraction.
Independent reviews change that calculation. When three separate models flag the same problem independently, the probability that it is a genuine issue rises sharply. Conversely, when only one model flags something and the others do not, that is a signal to scrutinise it carefully before acting. Agreement does not prove correctness; systems can share bad assumptions, especially when the code or prompt makes a misleading interpretation seem plausible. But agreement is a practical way to prioritize limited reviewer attention.
Lawson describes the false positive rate under this approach as part of his account of the workflow. The larger lesson is clear even without treating AI output as authoritative: redundancy is valuable when the individual reviewers are fallible. Human teams already rely on independent perspectives in important reviews because one person’s familiarity with a codebase can become a blind spot. Multiple models offer a version of that principle, provided their findings are compared rather than piled up.
There is a trade-off. Running several agents and conducting a consolidation pass is slower than asking one assistant for a quick opinion. That is the point. The workflow rejects the idea that every engineering task should be optimized for the fastest possible first answer. For a pull request with meaningful consequences, a slower path that reduces false positives and catches more real bugs can be the faster path in the only sense that lasts: fewer avoidable problems after the code ships.
AI review is most credible when it makes the human review process more demanding, not less. Lawson’s setup does not promise perfect code, and it does not excuse anyone from reading a diff. It offers something more grounded: several independent attempts to find what the author and reviewer may have missed, followed by deliberate judgment about what deserves a fix.
