You should use AI for reviewing code especially when the diff is huge
Simian Words
A blogger argues you shouldn't manually review massive AI-generated code diffs anymore. Instead, let AI catch the small stuff and save your brain for the big-picture judgment calls only you can make.
Based on reporting by Simian Words — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
There's a specific kind of dread that comes with opening a pull request and seeing 10,000 lines changed. The instinct is to either skim it and rubber-stamp it, or block off your afternoon and grind through every line. A new post from the Simian Words blog makes the case that both instincts are wrong, and that the real problem is reviewers still think their job is to spot syntax nitpicks and off-by-one errors.
The argument is blunt: large language models have already gotten better than most humans at catching low-level bugs. The post points out that these models are now finding high-severity vulnerabilities, so a human squinting at variable names or bracket placement is not adding much. If anything, treating code review as a line-by-line audit wastes the one resource a reviewer actually has that the AI doesn't — context that never made it into any commit message or comment.
That context is the real pitch here. Maybe you sat in a meeting last week where the team decided to deprecate service_A, and the author submitting this diff has no idea. Maybe your team has an unwritten rule about never adding fields to some sprawling shared object, or a preferred way of wiring up metrics that isn't documented anywhere an LLM could have ingested it. This is what the post calls out-of-distribution knowledge — stuff that lives in your head because you've been in the room, not stuff a model could infer from a training set no matter how large.
So the proposed workflow is less about abandoning review and more about redirecting it. Point the AI at the diff, let it handle the mechanical checking, and spend your own attention asking the questions only a human who knows the codebase's history and the team's Tuesday-morning meetings would think to ask. It's a division of labor, not a shortcut.
The post does flag a real limit: this only works where individual lines aren't sacred. Embedded systems, safety-critical firmware, anything where a single misplaced instruction can brick hardware or worse — that's a different game, and offloading line-level scrutiny to a model is a much riskier bet there.
My take — AI-written commentary, not fact-checked reporting
This tracks with something I've been saying for a while: the bottleneck in AI-assisted dev isn't code generation anymore, it's verification, and most teams are still verifying with tools built for a world where humans wrote every line. Reviewers clinging to nitpick-mode are optimizing for a threat model that's basically extinct. The uncomfortable part nobody wants to say out loud is that if your only value-add as a reviewer was catching typos and style violations, the model just took that job, and you'd better have the institutional memory to back up the part it can't do.
Read more about this at: Simian Words