The Review Tax: Why 81% of Developers Are Buried in AI Code Review

Daniel that's a fair point on the sample size and I should've been more careful flagging it in the article. 700 across five countries is a reasonable survey, but it's still one survey, and generalizing 81% of developers from it probably overstates how universal this is right now. representativeness for any single country in that mix, Europe included, is a real limitation worth naming rather than glossing over.

and your point about adoption stage matters more than I gave it credit for. the Review Tax as I described it assumes AI is generating a large enough share of the codebase that review becomes the bottleneck. if AI's still mostly assisting on small pieces, the dynamic looks completely different, you're reviewing normally-sized changes with some AI-assisted sections inside them, not reviewing large AI-generated diffs as the default unit of work.

probably the more honest framing is that this is what happens at a certain point on the adoption curve, not a universal state every team using AI is already in. worth being clearer about that distinction.

Thanks Santiago few things that have actually helped, not just theory: for avoiding over-engineering be explicit that you want the simplest solution that solves the stated problem, nothing more. something like use the standard library or an existing pattern in this codebase before adding anything new and default to the shortest solution that passes the requirement. I wrote about a tool called Ponytail a while back that basically formalizes this into a checklist the agent runs through before writing anything, worth looking into if you want it enforced rather than just requested.

for following existing architecture: don't describe the pattern, point at it. follow the same structure as [specific existing file/function] works far better than explaining the pattern in prose, because the agent is matching against a concrete example instead of interpreting your description of one. vague architectural instructions get vague architectural compliance.

for replicating patterns on new features: same principle, give it the actual sibling implementation as context, not a summary of what that implementation does. this new endpoint should mirror the error handling, naming, and structure of [existing endpoint], changing only what's different about this specific case produces far more consistent output than describing your conventions abstractly.

the underlying thing all three have in common: specificity and concrete examples beat well-written prose instructions almost every time. the agent isn't reasoning about your intent as much as pattern-matching against whatever you actually gave it to match against.

Here is what I generally do:

• Ask it to tell me what it is going to do. That enables me to find problems earlier.
• Split the problem into smaller steps so it's easier for the AI to generate and us to review, and do it one after the other (commit each step separately instead of a single big commit).
• Ask if there is something it needs to know to complete the task, if something is unclear, and what assumptions it made.
• Tell it what NOT to do, and what our priorities are (e.g., "Do not create new api routes, reuse the existing ones. Use a simple UI for now, we will upgrade it in a later commit.").

I think current AI agents already heavily check the existing file structure. I add custom patterns and rules in AGENTS.md.

Note: I am a beginner so please point out if there are mistakes.

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.

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 🤦

The bias in faulting the AI for people debugging longer than personalizing the syntax responsibility is what attracts me to most threads.
Look at my case for example: The thing is that I have written more code my entire life in the shortest time I began to use AI assistants ~3 years ago than the last 20+ years.. 1st thing I went after the 1st time I encountered a chatbot that seemed more knowledgeable than my regular Google-Search use case was - "can you code"? Now I'm enjoying debugging the code and learning faster. Imagine there was no chatbot or AI 🤷 would I ever build a Todo app?

The thing is how we see, use, interact, romance or whatever with the AI it reflects back our intelligence.
"Using a keyboard doesn't make me smarter than someone using a pen 😂.

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.

The damned-if-you-do dynamic you opened with is real, and I don't think there's a clean fix for it beyond someone senior explicitly protecting review time as a metric, rather than leaving it to individual devs to justify being slow.

but the payment gateway story is the one that's going to stick with me. asking the AI does calling this endpoint repeatedly let someone increment credits indefinitely and getting a straight yes back is somehow both the funniest and most damning thing in this entire comment section. the AI didn't just fail to catch it while writing the code, it could articulate the exact vulnerability the moment someone asked the right question, which means the knowledge to prevent it was in there, it just never got triggered until you specifically interrogated the output instead of trusting it.

that's actually a strong argument for what you said earlier in the comment, non-critical paths can probably tolerate skipping the deep review, but did I just verify a payment endpoint is exactly the kind of area where writing it by hand, or at minimum interrogating it like you did here, isn't optional. glad you caught that one before Qoder's answer became a very expensive lesson instead of a very funny comment. 😭

That's a sharper distinction than AI review is harder and I think it's the more honest one. an 800-line PR was always going to be exhausting to review, human-written or not. AI just makes it easier to accidentally generate 800 lines in one sitting, because nothing about the tool naturally stops at a reviewable size the way manually typing four separate features tends to.

the fix for this one doesn't even need new tooling, just enforcing the same PR-size discipline good teams had before AI, and treating this should've been four PRs as a valid review comment on its own, before anyone even reads the logic.

Thank you so much, genuinely 🙏

the Coasters/Builders line resonating is exactly the reaction I was hoping for, because it's the part of this that's easiest to miss when you're only looking at output metrics. a manager tracking PR count has no way to see who's actually absorbing the tax.

and you've articulated the mentorship point better than I did in the article itself. energy that used to build a future maintainer now just evaporates into catching bugs a session will forget is the exact shape of why this specific kind of review burnout feels different from ordinary busy-ness. it's not just more work, it's work that stops accumulating into anything.

really appreciate you reading this closely enough to pull out all four threads separately. means a lot.

Reduce what actually reaches human review is a better target than make review faster and I think the article leaned too hard toward the second one without saying so directly. faster review is still reviewing everything. this is a different strategy entirely: shrink the set of things that need a human's judgment in the first place.

the framing that makes this click is separating predictable mistakes from decisions that genuinely require judgment. deterministic checks and architectural constraints can catch the first category before a PR even opens, the kind of error that's the same shape every time and doesn't actually need a human brain to catch it. what's left for review is business logic and the tradeoffs a system can't evaluate on its own, which is exactly where a reviewer's time is worth spending.

this is the same shift a few other comments on this thread have landed on from different angles one described using Roslyn-generated templates so AI only fills in narrow, well-typed slots, someone else talked about capability scoping instead of trusting the model's judgment. all three are the same underlying move: stop trying to make humans better at catching everything, and shrink what needs catching down to what actually requires a human.

Thanks Suraj this reframes the whole article in a way I think is more accurate than what I actually wrote. I was treating the Review Tax as AI writes code faster than humans can check it. you're pointing at something underneath that: the reviewer isn't just checking correctness, they're reconstructing context the agent never had access to in the first place, and that reconstruction work is invisible in every metric that just measures diff size.

that also explains something that confused me while writing this: why a small, clean diff can still take forever to review. it's not the size of the change, it's the size of the gap between what the agent knew when it wrote it and what the reviewer needs to know to evaluate it safely.

honest answer to your actual question: I don't think it's either or, but if I had to bet on which one matters more long term, it's persistent project understanding, and here's why. better review workflows are a way of managing the symptom, they make reconstructing context faster or more structured, but a human is still doing the reconstructing every time. an agent with genuine persistent understanding of the project's accumulated decisions would mean the reviewer isn't rebuilding that context from scratch on every diff, because the thing that generated the code already had it.

that said, I'd bet against this arriving cleanly anytime soon. even AGENTS.md and example implementations are still a snapshot handed to the agent per session not something the agent actually retains and updates its own understanding of over time. until that gap closes review workflows built explicitly to surface why was this decision made alongside the diff are probably the realistic stopgap, not because they solve the problem, but because they're the thing actually available right now.

Assume it's plausible until you've traced the actual data path is the security-review mindset applied exactly where it belongs, and it's a sharper standard than review carefully. plausible is the default state of AI output, that's what makes it hard to review, so treating plausibility as the starting assumption rather than a good sign flips the entire posture in the right direction.

the session state bug slipping past three reviewers is the part that should worry people more than a single missed review would. three people looked at code that was correct on every axis they were checking, and none of those axes happened to be the one that mattered. that's not a reviewer failing to pay attention, that's the code passing every test a normal review applies and still being wrong underneath it.

honest answer on your actual question: I don't know of teams tracking reviewer depth as a real metric yet, comment quality and bugs caught pre-merge aren't things I've seen show up on a dashboard the way velocity and PR count do. that's part of what makes the Builders Coasters split so hard to fix in practice, the thing that would actually reward the behavior you want is exactly the thing nobody's measuring. output count is easy to track automatically. reviewer depth basically requires someone senior manually noticing who's catching the real bugs, which doesn't scale the way a dashboard number does.

if you've seen any team actually attempt this, genuinely curious what it looked like.