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. 👇
Top comments (8)
Imo, this is exactly why AI is a senior dev's tool. Not a junior and while code generation is a 10-100x speedup, it should be a flat 2x productivity, because the time you save writing the code, you should spend validating it. The other note, is that we should remember, subtle errors in production have existed since before AI, it's not an AI problem, it's a business operations problem. If a senior dev uses AI, reviews the outputs, corrects it as they go, validates when they're done, they still produce PRs at 2-3x the rate, at the same quality as if they had written it all by hand, because they spend more time validating, than writing.
To rely on writing it as a quality check, is fundamentally flawed, if you ever relied on that as a metric of correctness, then you survived on sheer dumb luck till now. People make the same mistakes AI does, except AI writes 100x more code, with more safety checks, tests, etc. That doesnt make a human more right, or less wrong, it's just a fundamental problem discovered later down the development pipeline. If your calculation logic is off, if you just wrote it, no tests, no gates, nothing, you've made the exact same mistake the AI did, with all green tests and gates. That is why it's less important to look at how it validates and more important to look what it's validating against. if you typed 55x and the AI implemented 55x, but it was meant to be 5.5x, the error is the same, except the AI built the infrastructure too to prove it's 55x. That's on the developer, not the AI, because they're meant to view the logic as they develop it. That's an error that would slip through QA testing and reviewing, until production suddenly has incorrect values. The bug is the same, but you focus less on what's important than you should. If you're validating the AI's tests, catch blocks, etc. Before you validated it's formula, you wasted 99% of the time it took to find the bug.
Personally though, I dont think relying on AI to generate code is a sound strategy for 99% of use-cases. Rather use something like Roslyn to generate template structures and have the AI fill in the blanks. That way you keep context clean, you reduce review necessary work and your codebase is cleaner and more maintainable, all at once. Eg. V.A.L.I.D. uses Roslyn to generate a MCP and Unit Tests, driven by how you define the ValidObjects in the DTO and how you set up the HTML markup, Roslyn generates everything inbetween, so all AI/You have to do, is design the UI layout and define the properties they represent. 2 files to view, instead of 20. That's how you use AI effectively, by constraining what it needs to do, to what a human reviewer can easily validate and let the system test it's logic, not have the AI write it's own tests.
Flat 2x, not 10-100x" is the reframe that should replace every AI productivity claim I've seen marketed. the 10-100x number only holds if you count generation speed and pretend validation is free. the moment validation gets its fair share of the timeline, the real number is exactly what you're describing, faster than writing by hand, nowhere close to the headline multiplier.
the 5.5x vs 55x example is the clearest illustration I've read of the actual failure mode. the bug is identical whether a human typed 55 or AI generated it, the difference is that AI also builds the tests, the gates, the green checkmarks around the wrong number, which makes the error look more validated than a human's unverified 55 ever would have looked. that's a genuinely dangerous property: confidently wrong at scale, with infrastructure vouching for the wrong answer.
it's less important to look at how it validates and more important to look at what it's validating against" might be the single most useful sentence in this whole comment section. reviewing test coverage and catch blocks before confirming the underlying formula is correct is exactly backwards, and I think a lot of review processes, mine included, default to that order because tests are easy to check and business logic correctness is hard to check.
the Roslyn-plus-DTO approach you're describing (constrain what needs generating down to what's actually reviewable, let the system own everything else) is the same principle from your earlier comment, applied to the review-tax problem specifically: you don't reduce the review tax by reviewing faster, you reduce it by shrinking what genuinely needs review down to the two things a human is positioned to catch, and removing the rest of the burden structurally rather than trying to read it more carefully.
Exactly, that's kind of why I built V.A.L.I.D. the way I did, because if you ever tried letting AI generate anything using CSLA, you'd know it's garbage as managing Business Objects, Data Access Layers, Endpoints, UI Bindings and horribly inconsistent with SQL Repo connection handling. So take out all the things it can make a mistake with, beyond what's genuinely up for interpretation (UI design and DTO) and generate the rest using fixed structures for consistency, accuracy and constraint. The amount of times i had to catch AI for putting AllowAnonymous() in a fast endpoint configuration... That's probably 1 of the most severe network security nono's you can do, yet it's default behavior for alot of models... You can try and fix it with skills files, but that just 'suggests' a better method, rather than strictly enforcing it the way a Roslyn generated template is.
AllowAnonymous() defaulting to open across models is the kind of thing review carefully was never going to catch, it's a reflex baked into training, not a one-off slip.
that's the throughline for this whole thread actually: interpretive stuff (UI, DTO shape, business rules) is where AI adds real value. anything with one non-negotiable correct answer (auth defaults, data access, connection handling) is where "generate it and review carefully" stops working, no matter how careful the review is.
a skills file suggests a better pattern. a Roslyn template removes the bad one from what's even possible to generate. those aren't the same fix at different strengths, they're different categories.
Your introduction has most of what I would have loved to contribute nevertheless. That part to me is not as emphasized as I think it ought to be.
Even if a senior developer uses an AI for a single line of code without knowing the details or surrounding implications the end result will be babash 🤣 : Without the AI software is not perfect right from when I learnt how to use a Windows PC in the earliest 2000, I saw bug updates, patches, etc and till now updates are there to fix and improve code, UX, UI, the software entirely.
With or without AI usage output will be poor if poorly inputted.
The wrong Assumptions is the "intelligence" in the AI and ignoring the artificial in it. I hope I make small sense 🤦
Exactly, it's not to do with AI makes mistakes, it's mistakes happen, that's why you have to validate and that goes for anyone and everyone, be it a monkey an AI or a human, you validate, else it might as well have not existed in the first place, because you dont know what it does or that it does it correctly.
"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." - aren't we then even getting any productivity gains at the end of the day? And at what cost - a lot of people like writing code more than reading it, and the risk is we lose some of the 'skills of the trade' ...
For these reasons I'm arguing for an approach where we still write some of the code ourselves, manually: the more interesting, logic heavy code, while we let AI write the less critical and more run-of-the-mill code (CRUD, boilerplate) ...
Thanks Leob Honest answer on the first question: net productivity gain, yes, mostly, but smaller than advertised. 58% faster to PR minus 4.6x longer in review still lands ahead of zero, just nowhere near the multiplier most pitches lead with. the real cost isn't that the gain disappears, it's that it gets quietly smaller every time review gets skipped or rushed, which is exactly how you end up with a bug in production instead of a bug in review.
the people like writing more than reading point deserves more attention than it usually gets. it's not just preference, it's how the skill gets built and maintained in the first place. you don't develop debugging instinct or a feel for a system's edges by reading someone else's output, you develop it by getting stuck and working through it yourself. reviewing doesn't build the same muscle writing does, even when you're reviewing carefully.
your split (write the interesting, logic-heavy code yourself, let AI handle CRUD and boilerplate) matches what's come up a few times in this comment section from different angles: constrain AI to the parts that are genuinely low-stakes or mechanical, keep the parts with real judgment calls in human hands. that also happens to be the split that keeps the skill from atrophying, because the code you'd actually want practice on is the code you're still writing.