Rejecting AI Code That Works: The Review Standard Worth Stealing

“Working” is the lowest bar code can clear. Vini Brasil’s post on rejecting AI code even when it passes tests lays out a review philosophy that’s gaining traction on Hacker News (103 points, 64 comments) — and it maps to a pattern senior devs are hitting daily as AI-generated PRs flood their queues.

Brasil’s rejection triggers boil down to a short list:

• The author can’t explain it. If the person who submitted the code can’t walk through why it works — not just that it works — it’s a liability. The next person debugging it at 2 a.m. is stuck reverse-engineering someone else’s AI session.
• It ignores existing conventions. AI tools generate plausible code that often clashes with a codebase’s actual patterns — naming, error handling, module structure. Working code that breaks consistency creates drag on every future change.
• It over-engineers the solution. LLMs tend to produce verbose, abstraction-heavy output. A 40-line function where 12 lines would do isn’t a feature — it’s maintenance debt with a bow on it.
• It papers over the real problem. AI is good at fixing symptoms. Brasil flags cases where generated code addresses the surface bug but misses the underlying design issue, making the root cause harder to find later.

The thread resonates because it’s not anti-AI. Brasil uses AI tools. The argument is that code review standards shouldn’t drop just because the code compiles and tests pass. A similar post by Stuart Spence takes a harder line — declining AI-generated merge requests outright when the submitter clearly didn’t read what was generated.

Both point to the same friction: AI shifts the bottleneck from writing code to reviewing it. Teams that don’t adjust their review bar end up with codebases that work today and resist change tomorrow.

The practical takeaway: treat “can the author explain every line” as a hard gate in review. It costs five minutes per PR and catches the exact class of problems AI-generated code introduces.