How to review AI code without reading the code
The New Stack Ankit Jain
AI is already reviewing most pull requests at some companies, and more code ships with no human reading it. The real gap isn’t bug checks — it’s losing the team’s chance to argue about what the change was meant to do.
Based on reporting by The New Stack, Ankit Jain — 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
The old code-review argument has mostly been settled by reality. Faros AI says pull requests merged without review are up 76.3% since its April report, and many companies now let AI handle 50% to 80% of their PRs. The machines are clearly doing the first pass. What they still don’t do is help a team decide whether the thing being built was the right thing in the first place.
That’s the hole this piece is trying to close. AI review is strong on mechanics: it can read every line, stay consistent, and never get bored. But it only sees the code in front of it. It doesn’t see the decision that led there, or the trade-off that got accepted along the way. And that missing context is exactly what code review used to provide, even when everyone complained about the bottleneck.
The proposed fix is a five-layer process built around decisions instead of line-by-line inspection. Before the PR exists, one agent challenges another agent’s approach and records what was proposed, what was rejected, and why. Then the system captures intent and acceptance criteria from the coding session, turns repeated review comments into standing invariants, and pushes the human discussion onto the decisions that the agents couldn’t settle. The last layer, Own, gives those invariants a named human owner.
A concrete example helps. In a PR adding a per-installation rate limit for webhook ingest, the intent was to stop one noisy GitHub installation from starving the broker without dropping events or breaking order. The PR carried six decisions: one open product call, two accepted risks, one follow-up for Grafana metrics, and two that were settled in debate. One of those was “token bucket, not a sliding window,” chosen after profiling a webhook storm. None of that shows up in the diff, which is the point.
The reviewer’s job changes too. Instead of reading every line, they read the intent, review the decisions, argue where they disagree, and check the pieces that still don’t pass. The code is still there when needed. But the main unit of review becomes the decision trail, not the text of the patch. That’s a much more honest match for how software actually gets built.
My take — AI-written commentary, not fact-checked reporting
This is the part of AI coding most people keep missing: the danger isn’t that machines write code, it’s that teams stop remembering why the code exists. Reviews that only inspect syntax are theatre with a merge button. The smarter move is obvious and slightly annoying, which is usually how good engineering looks.
Read more about this at: The New Stack