What Developers Think About AI Code Review —

Last week, two Hacker News threads exposed a raw nerve in the AI coding world: nobody knows how to review AI-generated code anymore.

One developer asked a simple question: “How do you review and validate LLM generated code?” The thread hit 7 points and pulled honest answers from engineers struggling with the same problem. Another thread — “Does anyone find AI code review useful?” — questioned whether AI reviewers add value or just create noise.

These aren’t product launches. They’re developers admitting what the marketing doesn’t say. Here’s what they actually think.

What Happened: The Code Review Crisis

Thread 1: The Validation Problem

A developer using darkLord19 laid out the core issue plainly:

“It’s become very fast to generate code nowadays, but how do you review and test all of it? Every time you ask a model to review some piece of code, it comes back with different ‘findings.’ So, you still have to filter through the noise of their findings to get to actual defects.”

The problem isn’t generating code. It’s knowing whether what was generated is correct. Traditional code review assumes the author understood what they wrote. AI-generated code breaks that assumption.

“And if you try to do the full review manually, then it might take more time to just understand the code than writing it yourself from the beginning.”

This is the paradox: AI accelerates output but creates a verification bottleneck. The faster you ship, the more time you spend checking.

Thread 2: The AI Reviewer Skepticism

swimmingpolar questioned the entire premise of AI code review tools:

“Once an LLM generated change gets into a few hundreds or thousands of lines, a human reviewer can barely read the whole thing in any meaningful way. And even if they can, why should they spend their time reviewing thousands of lines generated by someone else’s AI?”

The question cut deeper than workflow. If an AI wrote it and an AI reviews it, what’s the human actually doing?

“If the code is going to be reviewed by another AI anyway, why doesn’t the developer opening the PR just run one more iteration before submitting it?”

Developer Reactions: The Divide

“Nope I always ignore it”

buffer_overlord kept it blunt. When asked about AI code review tools, the answer was two words. No justification, no workflow explanation. Just dismissal.

This wasn’t an outlier. Multiple commenters expressed similar fatigue. The AI-generated review comments blend into the noise. After the third false positive, developers stop reading.

The “Cut Velocity” Approach

blinkbat offered a different philosophy:

“Cut velocity and increase supervision.”

Instead of racing to ship more AI-generated code, slow down. Review less but review deeper. Accept that AI acceleration has a cost: more human attention per change.

This contradicts the productivity narrative. The promise of AI coding is speed. But if speed creates verification debt, cutting velocity might be the rational move.

The Context Blind Spot

spawrks pointed out a structural problem:

“Your previous context does create its own blind spot, but you’re also getting at a problem in non-AI reviews which is ‘what am I reviewing for?’”

AI reviewers suffer from context amnesia. They see the diff, not the decision-making that led to it. The developer who wrote the prompt has context the reviewer AI will never see.

swimmingpolar pushed back:

“Plus, I feel like any previous context a developer had before submitting the PR must have the most accurate context rather than a code review AI.”

The developer knows why they asked for a specific change. The reviewer AI only sees the result. That knowledge gap is unfixable.

The Local Review Workflow

ohans described what actually works for small teams:

“What I’ve found to work is just to bring the review cycle locally, e.g., implement with Claude and review with Codex (with my guardrails set) in the terminal.”

Instead of a separate review stage on GitHub, run the review before the PR exists. Use different models — Claude for implementation, Codex for review — to catch different issues.

“We’re a small team, so shifting left works. Just review locally. If you’re a large org, that’s a different problem space.”

The key insight: trust doesn’t scale. A small team can verify locally. A large org needs enforced processes because they can’t trust every developer to self-review honestly.

The Human-in-the-Loop Defense

othmanosx argued for ownership:

“Merging blindly is bad for you as the owner of the code, LLMs are not that good yet, we’re still finding it make mistakes and write slop and our responsibility as engineers is to take ownership and verify it.”

The AI reviewer isn’t a replacement for judgment. It’s a filter:

“The AI reviewers just make this easier for us, I’m not talking about the walls of text it adds as it is exhausting to read (I know) but the fact that it could catch real bugs before you even read the actual code is the benefit.”

They described a workflow: coder and reviewer agents take turns, then hand off to the human. The AI catches the obvious bugs. The human catches the subtle ones.

One detail stood out: they trained their review skill by distilling two years of their own GitHub comments. The reviewer AI learned their preferences, not generic best practices.

The Practical Takeaways

1. Inconsistent Findings Are a Feature, Not a Bug

When an AI reviewer returns different findings each run, developers waste time filtering noise. The solution isn’t better prompts. It’s accepting that AI review is probabilistic, not deterministic.

Treat AI findings as suggestions, not verdicts. Expect false positives. Build workflows that account for noise rather than pretending it doesn’t exist.

2. Different Models Catch Different Things

Using Claude for implementation and Codex for review isn’t just about tool preference. Different models have different blind spots. The reviewer should be structurally different from the author.

This is why local review workflows work better than cloud review services for small teams. You control both models.

3. Context Loss Is Unavoidable

An AI reviewer sees the diff. It doesn’t see the conversation that produced it. The developer’s context — why they made specific choices, what alternatives they rejected — never reaches the reviewer.

This means AI review catches syntax errors and logic bugs. It misses architectural drift and design decisions that made sense locally but fail globally.

4. For Large Orgs, Enforcement Matters More Than Accuracy

ohans admitted the truth about cloud AI review services:

“The reason I think cloud AI review companies work is that at a large org you need a way to ensure that the review indeed happens. And you can’t blindly trust that the dev did this locally.”

The value isn’t the review quality. It’s the guarantee that someone — even an AI — looked at the code before merge. For compliance-heavy industries, that audit trail matters more than catching every bug.

What This Means For You

If you’re using AI to write code, you have three options:

Option 1: Local Review Loop

Before opening a PR, run a different AI model over your changes. Use guardrails that match your team’s style. Keep the human in the loop after the AI-AI exchange. This works for individuals and small teams who trust each other.

Option 2: Cut Velocity

Accept that AI acceleration creates verification debt. Ship less, review more. This contradicts the productivity narrative but might produce better software.

Option 3: Embrace the Noise

Use AI reviewers knowing they’ll produce false positives. Train yourself to skim and filter. Treat AI review as a safety net, not a quality gate.

None of these solve the fundamental problem: AI generates code faster than humans can verify it. The HN threads show developers quietly admitting what the hype ignores. The code review crisis is real. The solutions are incomplete.

The Real Insight

One comment from jfawcett cut through the noise:

“I write code extensively with the AI, but I make sure that it knows that it must pass all gates before being checked in. I also leave sufficient documentation on the disk and in the code that the intent is clear and the implementation precise.”

The approach: don’t let them hallucinate and have ways to tell immediately when they have.

“When bugs are discovered, they must be gated by an oracle. The oracle must be red before application of the patch, and green thereafter.”

The oracle is a test, a type checker, a linter — something deterministic. AI generates code. The oracle verifies it. The human reviews the oracle’s output, not the AI’s.

This reframes the problem. Instead of reviewing AI code directly, review the tests that verify the code. If the tests pass and the tests are correct, the code is probably correct. The human attention shifts from implementation to specification.

That’s the workflow that might actually scale.

What Developers Think About AI Code Review — The Validity Crisis From HN Threads