Just give it to AI might be the most dangerous phrase in software development right now.
I’ve said it myself. Handed off a task, watched clean-looking code come back in seconds, skimmed it, and moved on because it looked right and the tests were green.
Then I reviewed a PR that wasn’t mine to write, just mine to check. AI-generated, clean, organized, passing every test I threw at it. I approved it the way I’d approve anything that looked competent on the surface.
The bug showed up later. Not in review, not in testing. In production, after the code had already been trusted for a while. Nothing about it had looked wrong. That was the actual problem: it wasn’t obviously wrong, it was quietly wrong, in the specific way that only announces itself once real conditions hit it.
I went back afterward and sat with that PR properly. Not skimming this time. Actually reading it, actually understanding what it was doing and why, actually treating the review like the real work instead of the formality before merging. It took a lot longer than approving it had. It’s the only way I’d have caught it before production did.
Since then, I don’t rush AI-code reviews anymore. I give them the time writing the code apparently didn’t need. And it turns out I’m far from the only one who’s landed there. 🧵
The Number That Explains What I Was Feeling
According to Harness’s 2026 State of Engineering Excellence Report, a survey of 700 engineering practitioners across the US, UK, India, France, and Germany, 81% of developers now spend more time in code review since their teams adopted AI tools. 28% report review time increasing by 30% or more.
Here’s the trade nobody advertised clearly: AI tools cut time-to-PR by roughly 58%. But those same PRs then sit in review 4.6x longer than before. Review time per developer is up an estimated 11.4 hours a week.
The speed didn’t disappear. It moved. It went from “time spent writing” to “time spent verifying,” and verifying turns out to be the harder, slower half of the job.
I’ve started calling this the Review Tax, and I don’t think that’s an exaggeration. Nearly 31% of developer time is now going toward what researchers are calling “invisible work”: reviewing AI output, fixing the subtle bugs it introduced, and context-switching to explain code nobody on the team originally wrote by hand.
Why Reviewing AI Code Is Genuinely Harder Than Reviewing Human Code
This isn’t just “more code to review.” It’s a fundamentally different, more draining kind of reviewing.
When you review a colleague’s code, you’re checking work from someone with a track record. You know their habits, their typical mistakes, roughly how they think. When you review AI-generated code, none of that context exists. You’re evaluating output from something that writes with total, uniform confidence whether it’s right or wrong, and gives you no signal to tell the two apart.
Developers surveyed named the friction directly: reviewing AI code for accuracy (53%), fixing subtle bugs in AI-generated code (52%), explaining AI-generated code to teammates (48%).
Researchers analyzing this trend describe a widening gap between two kinds of developers on a team. Builders: people who genuinely understand the system, make deliberate choices, and take ownership of what they ship. Coasters: people who generate code, open large PRs, and move on without building any real understanding of what they just shipped.
The uncomfortable part is that AI makes Coasters look more productive. They open more PRs. They touch more lines. A manager tracking output alone sees a high performer. The Builders reviewing that same work know they’re the ones actually catching what would otherwise break in production, quietly, unglamorously, off any dashboard that measures velocity.
The Accountability Problem Nobody Wants to Say Out Loud
The Godot Foundation recently banned AI-authored code contributions entirely. Their reasoning, in their own words: “AI cannot take responsibility, and we can’t trust heavy users of AI to understand their code enough to fix it.”
One maintainer described the deeper cost: when your review feedback is being absorbed by a process instead of mentoring an actual future contributor, it becomes much harder to justify spending your own time on review at all.
That’s the part of the Review Tax that doesn’t show up in any productivity metric. It’s not just slower. It’s less motivating. Reviewing a human’s code, even when it needs work, is partly an investment in a person who’ll get better because of your feedback. Reviewing AI output that will forget every correction the moment the session ends removes that entire dimension. You’re not mentoring. You’re just, endlessly, catching things.
What Actually Helps
I don’t think the answer is reviewing less carefully, and I don’t think it’s avoiding AI either. Here’s what’s actually shifted for me and what the research backs up.
1. Catch issues earlier, not just more carefully at the end.
The cost of a bug climbs sharply the later it’s caught: roughly 1x if it’s found in design, about 6x during coding, and anywhere from tens to over a hundred times that if it reaches production. Pre-commit checks catch a large share of issues before they ever reach a human reviewer’s queue, cheaply.
2. Stop measuring volume.
Lines of code and PR count were always shaky metrics for productivity. With AI in the loop, they’re actively misleading, they reward the exact behavior driving the Review Tax up.
3. Make authors explain their own PRs.
If the person opening the PR can’t explain their own approach in a couple of minutes, it doesn’t merge yet, regardless of how clean the diff looks. This single rule filters out most of what turns into a slow, painful review later.
4. Actually track the invisible work.
Only about 38% of organizations currently track time spent reviewing AI-generated code specifically. Most developers, 94% in one survey, say tech debt, validation time, and burnout aren’t showing up in the metrics leadership actually looks at. You can’t fix a cost nobody’s measuring.
5. Say the norm out loud, don’t just assume it.
“We treat AI as a drafting tool, not a shipping tool” sounds obvious until you watch a team operate without ever agreeing to it explicitly. Teams that state this clearly review differently than teams where everyone’s silently guessing at how much scrutiny is expected.
The Honest Version
The Review Tax isn’t only a productivity problem. It’s a people problem wearing a productivity problem’s clothes.
When your most careful reviewers start going quiet on PRs, that’s rarely them relaxing. More often, it’s the early, silent shape of burnout, the kind that doesn’t announce itself until someone’s already decided to leave.
Teams that build real norms around AI-assisted review will keep the developers who actually understand their systems. Teams that don’t will eventually be staffed by people shipping a lot of code that nobody, including the person who opened the PR, could fully explain if asked.
The question worth sitting with isn’t “should we use AI to write code.” It’s “who’s actually accountable when nobody on the team wrote the code they’re shipping.”
Have you felt the Review Tax on your own team? What’s the worst AI-generated PR you’ve had to untangle, and did your review process change after it? I’ll go first in the comments. 👇
답글 남기기