AI Code Review Without Code Review Is Cooked

Recently, Siddhant Khare's essay "AI Fatigue is Real" went viral in dev circles, and honestly? It hit different. Because it nailed what so many of us are feeling: coding with AI assistants has somehow become more exhausting than coding without them.

We've gone from builders to reviewers. AI ships code so fast and so inconsistently that reviewing it is genuinely draining. You can't get into flow state. You're context-switching constantly. And the micro-decisions pile up until you hit decision fatigue and just want to merge whatever and touch grass.

While promoting my open-source CLI fastfilelink (ffl), I've been lurking in dev communities. What I've seen is anxiety, hype, and mountains of AI-generated slop code that no human would ship.

The New Cope: "Don't Review Code, Review Tests"

To combat AI fatigue, a sweet-sounding narrative has emerged, especially from the Claude/Cursor crowd:

"Don't review code, just review outputs. If tests pass, ship it."

Some people even compare this to compiler output, arguing we don't review assembly code either.

This argument is dogshit. Here's why.

1. LLMs Aren't Compilers

Compilers use strict syntax for deterministic translation. LLMs are probabilistic models. When you ask an LLM to generate test cases, sometimes the tests themselves are fake or low quality. Green tests don't guarantee working systems. You have to review those test cases, so the premise of "not reviewing at all" collapses immediately.

2. No Global Vision = Architectural Collapse

Constrained by context windows and RAG limitations, LLMs only see fragments of your project. They can't comprehend the system holistically. This results in:

• Extreme code redundancy
• Complete violation of DRY principles
• Massive inconsistent bugs when requirements change

Your codebase becomes a single source of truth that isn't actually singular.

3. Context Windows Have Physical Limits

Stop fantasising that "it'll be fine when models get stronger." Context windows are bound by training data and attention mechanisms. They will always have a ceiling. And even if they get bigger, projects will just get bigger too. The architectural collapse from Point 2 is unsolvable in the foreseeable future.

4. The Chicken-and-Egg Infinite Loop

To prevent weird, unpatched edge-case bugs from Point 2, your test coverage must approach 100%, with rigorously designed tests. But here's the trap:

Test cases are code. Heavily copy-pasted AI code.

If you want to skip reviewing production code, you must spend equal (or more) effort reviewing a massive pile of test code. You're just trading one hell for another.

This Is Compute Capitalism

Sure, you can throw tokens at the problem until tests pass. As your project grows and fills with repetitive LLM logic, you can indeed just burn money letting it slowly fix things. But:

• Not reviewing is impossible: You've shifted review targets from production code to test cases. Still code. Still draining.
• Maintenance costs compound exponentially: Once technical debt stacks up, fixing minor bugs costs increasingly more tokens and time.

People are lazy. Who wouldn't want AI to do everything? (Especially since most devs don't even enjoy coding that much. It's just a job.) So this "AI can do everything" narrative excites people while simultaneously peddling anxiety.

But who benefits? AI development tool vendors. The more bloated your code, the more debugging rounds, the more money they make.

The cruel truth they don't want you to know: "No Silver Bullet" still holds.

The Real 2026 Vibe Check

Gary Marcus notes programmers now debug "somebody else's code," draining job satisfaction. Veteran engineer Steve Yegge warns of AI's "vampiric effect" and suggests capping AI-assisted work at 3 hours daily to avoid burnout. Dax Raad calls test-only, zero code review workflows "disastrous," arguing AI floods teams with low-quality output that buries skilled developers and incurs massive LLM costs (like $2,000/engineer/month).

We're not building anymore. We're judging on an assembly line.

What Actually Works

Ngl, AI code generation is powerful when used right. But the test-only workflow isn't it. What works:

• Hybrid approach: Use AI for boilerplate, humans for architecture
• Cap AI time: Steve Yegge's 3-hour limit is lowkey based
• Review what matters: Focus on system design, not syntax
• Better tooling: Open source AI code review tools that integrate with GitHub/GitLab can help, but they're not magic

The best AI code review tools in 2024 don't eliminate review. They make review bearable. They highlight what actually needs human attention. They help maintain that single source of truth.

AI-assisted coding workflows work when they augment creativity, not replace it. When they handle grunt work so you can focus on hard problems. When they reduce context-switching instead of amplifying it.

The "don't review code" methodology isn't the future. It's just another hype cycle that'll leave burned-out devs and unmaintainable codebases in its wake.

Stay based. Review your code. Ship with confidence.