2026-09-14 · 6 min read

"How do you even review AI code?" Two Reddit threads, two hundred comments, and the twenty-minute triage nobody posted

"How do you even review ai code?" is a real question someone asked r/cscareerquestions in March, and the body is the situation most of us are in now: management pushing velocity, everyone using assistants, and PRs that arrive as "massive lines of code and different files for one feature." The poster admits they've started asking the AI to explain the AI's code instead of reading it. A month later r/SoftwareEngineering had the team-level version: a group that used to spend 30 to 60 minutes a day on review got Claude licences and is now producing PRs faster than anyone wants to read them, with "philosophical and cultural battles ahead." Between the two threads there are about two hundred comments, and I read all of them, so you don't have to. Here's what they say, what they're missing, and how I'd actually read a 900-line diff in twenty minutes.

What the threads say

The top comment on the first thread, with over four hundred upvotes, is nihilism: "if someone is pushing AI code, review it with AI. if this causes issues in production, debug it with AI. if management wants answers, write them with AI." Funny, and the upvotes say a lot of people feel it. The second thread has the same joke in a dozen forms: "You guys are reviewing it!?", "Push and pray", "Skim through it in 5s without really reading it, and writing lgtm", "Hope is not a strategy." A commenter who moved into management describes "slowly getting guard rails on things but the code bases are eroding in the meanwhile," and another, more bluntly, describes the whole arrangement as an accountability sink: you're responsible for reviewing everything, the workload makes that impossible, and if you review properly while your peers rubber-stamp, you're the one who looks slow.

Underneath the jokes there's real advice, and it clusters into three positions. One: the PR size is the problem, not the AI, so fight for smaller PRs and make the model work in parts (the second-highest comment, and true, and also not something a mid-level engineer can unilaterally impose on a team whose CTO ships AI-generated PRs himself, which one commenter reports theirs did until they got "commented the hell out" and he started over). Two: use a different model to review than the one that wrote it, Codex reviewing Claude, Cursor reviewing Claude, on the reasoning that it "adds another filter" and, as one person put it, "I've never seen Codex rubber stamp things like I've seen human do thousands of times." Three, and this is the comment I'd pin: treat AI code like code from "a junior dev who is really confident. read every line, check the edge cases yourself, and especially watch for stuff that looks right but subtly misunderstands the business logic. AI is great at producing plausible looking code which makes it harder to review not easier."

That last sentence is the whole problem. The reason AI PRs are exhausting isn't the line count alone. It's that the usual reviewer heuristic, "this bit looks off, slow down here," has nothing to grip. Every line is locally plausible, so you either read all of it at full attention, which is impossible at volume, or you skim all of it, which is the lgtm joke. Neither thread quite gets to the third option.

The third option: read for bug classes, not for lines

You cannot review 900 lines the way you review 90. What you can do is stop reading top to bottom and start reading by question, because the bugs that survive into AI-generated PRs are not evenly distributed across the diff. They concentrate at a handful of places that you can find with search rather than with reading, and once you've found those places, most of the diff is scaffolding you can skim with a clear conscience. Twenty minutes, in roughly this order:

• Three minutes: the requirements against the diff, clause by clause. Before reading any code, list what the PR is supposed to do, then find where each clause is satisfied. The one you can't find is the bug, or the half-implemented feature. This catches the "silently solved a slightly different problem" class, which is the one the confident-junior comment is describing, and it needs zero code comprehension.
• Five minutes: the trust boundaries. Search the diff for everything that arrives from outside: request handlers, query params, file reads, env vars, new entries in the dependency manifest. For each, follow it to the first place it's trusted. An export endpoint that authenticates the caller and then runs a query with no tenant filter is a three-file PR where only one line matters, and you find that line by asking "where does the org id go" rather than by reading the serialiser.
• Four minutes: the boundaries with numbers in them. Every comparison, every loop bound, every division. Feed each one its edge value in your head: the last page, the exact threshold, the empty list. This is mechanical, it needs no domain knowledge, and it catches a category that no round-numbered test fixture ever will.
• Three minutes: anything declared and never used, anything reused that already existed. A secret loaded and not touched, a parameter accepted and ignored, a feature flag or config key that another file also reads. Unused things are unfinished sentences; reused names are the Knight Capital class.
• Five minutes: the tests, read as an adversary. Not "are there tests" but "what would have to be wrong for these to fail." If the expected value is computed with the same formula as the code, or the rule under test is mocked out, the green is decorative. This is where AI PRs are weakest and where reviewers most often relax, because the presence of tests looks like diligence.

That's twenty minutes and it covers, in our experience across a couple of hundred planted bugs, the large majority of what actually ships broken. What it doesn't cover is architecture, naming, and whether the approach is the one you'd have chosen, and I'd argue that on a 900-line AI PR under velocity pressure those are exactly the things to let go of, at least at review time. The thread's second-highest comment is right that the size is the underlying problem, and the place to fight that is the team agreement, not the individual review.

Why "have another model review it" is half right

Several commenters run a second model as reviewer, and the data says that's reasonable: a different model does catch things the author model missed, and the cost is nothing. But someone in the second thread who "spends a good chunk of my day reading PRs" adds that they "still find lots of stuff Claude misses," and the benchmarks agree in a specific way. Review bots are strong on small, single-file diffs and collapse on large ones, which is precisely the PR shape both threads are complaining about. So run the bot, read its comments as leads, and then do the twenty minutes above anyway, because the bot's silence on a 900-line diff is close to no information.

The part nobody in either thread mentions

Two hundred comments about how to review AI code, and not one about how anyone learned to review. Everybody's process is something they arrived at by feel, and nobody can say what their miss rate is, because when you approve a PR and it's broken, the incident three months later never gets traced back to the approval. The questions above are only useful if they're reflexive, and they only become reflexive through repetition with feedback, which is the one thing a real code review queue never gives you.

That's the gap we built for: PRs with planted bugs in exactly these classes, where you leave your comments, give a verdict, and immediately see what you walked past. Twenty minutes a day on those, and the twenty-minute triage above stops being a checklist you consult and becomes the way you see a diff. At which point the 900-line PR is still annoying, but it's no longer frightening, and "how do you even review AI code" has an answer that isn't "with AI."