Why AI Code Review Is Now Secretly Killing Developers

I open a PR, the code looks clean, I run it through AI to help me review it, and I still don’t fully know whether I reviewed it or just skimmed a summary.

That’s the honest version. Not the version where I tell you I have a tidy process and a checklist taped to my monitor.

The reality is that I’m on a team of a few people, managing a handful of different digital properties across different repos. Sometimes different tech stacks entirely.

Every PR I open is a cold start.

We don’t have one codebase we all live in. We have several, and most of them aren’t new.

A lot of what we’re maintaining is legacy, somewhat monolithic, and built before half the team was even on it. There aren’t tests or linting rules in place, the kind of baseline you’d want if you were starting fresh today.

So when a PR lands, AI-generated or not, there’s rarely a running head start of “oh, I know this file, I know why this exists.” I’m reconstructing context from scratch nearly every time.

And when I bring AI in to help review it, that doesn’t remove the work. It adds a step 😬

Why? Because now I’m reading what the AI flagged, cross-checking whether I agree, and going back and forth if something looks off or if I think it missed something.

It still takes time. It just moves the time somewhere else.

If any of that sounds familiar, you’re one of the many victims of a very real problem.

This Isn’t Burnout. It’s Decision Fatigue.

Stack Overflow’s May 2026 analysis cut the fluff and said coding agents are giving everyone decision fatigue. I find this more accurate than “burnout” because it points to what actually shifted.

AI made writing code dramatically “easy,” but it didn’t remove the thinking. It just moved it somewhere else.

Where? To all the stages after the code is written, like review, verification, architecture, and deployment. These now carry the cognitive load that used to be spread out across the whole process.

Hey! Take a moment to think about this. You’re not slower because you’re worse at your job. You’re slower because the job quietly changed shape underneath you.

The Data Behind Decision Fatigue

Agentic AI PRs waited 5.3x longer for reviewer pickup than unassisted PRs, drawn from over 8 million pull requests. This means 5.3x longer for someone to open the tab; it’s not review time.

Can you feel the dread in the air?

What’s more, according to Sonar’s 2026 developer survey, 96% of developers say they distrust AI-generated code, yet 46% of new code entering production is AI-produced.

That tells you that nearly half your codebase is being reviewed with suspicion, often without the time to actually sit with that suspicion.

Note: If you’ve noticed PRs sitting in your queue longer before you even open them, that’s not a personal productivity failure. It’s showing up in industry-wide data which, small comfort, but I’ll take it 😅

There’s a reason for all this. Developers aren’t randomly unionizing against AI.

Obviously bad code is easy to reject. You see it, you flag it, you move on.

AI-generated code is rarely obviously bad, and that’s what makes it harder.

Output that’s “almost right, but not quite” is the top developer frustration these days because you can’t pattern-match your way past it. You have to actually dig in.

Why Code Review Got Structurally Harder, Not Just Busier

Think about the difference between a substitute teacher grading a stack of essays for a class they’ve never met, versus a teacher grading essays from students they’ve taught all semester.

The regular teacher already knows this kid always over-explains their thesis, or that one struggles with conclusions but nails the evidence. They’re grading with context.

But the substitute has none of that. Every essay is a cold read, and they have to reconstruct a sense of the student from the page alone.

That’s the actual shift with AI-authored PRs 💁‍♀️

When a teammate opens a PR, you usually have some shared context. You were in the planning conversation. You know their habits. Or you might already know what tradeoff they’re wrestling with.

However, when an AI agent opens the PR, none of that exists. You’re the substitute teacher for every single PR, every single time. You’re reconstructing intent (what it was told, what it considered, what it didn’t see) from a diff and a description alone.

That reconstruction is the actual work now. It’s no longer reading syntax but reconstructing intent.

Does Anyone Actually Read AI-Generated Code Anymore?

There’s a sharper, more intense version of this conversation happening online right now, and I think it’s the part that actually worries people the most. Myself included.

The concern goes like this: when AI is generating the bulk of a PR and the priority is to get through review and back to “real work,” does anyone actually read the code anymore?

Or does review quietly become skimming an AI-generated summary and rubber-stamping it?

The Honest Truth (and What It Costs)

Reading takes time. In an environment where PRs are arriving in multiples because agents can produce them faster than any one person can absorb them, “read every line carefully” isn’t free advice.

It has a serious cost, which is exactly what’s creating the bottleneck in the first place.

Reviewers simply can’t keep pace with the volume, so code is merging unread, and that is the new normal.

This is happening even at teams with mature, disciplined engineering practices. A good process didn’t protect them, because the volume arrived faster than the process was built to absorb.

But reading isn’t even the whole problem. Reading code is not the same as understanding it, and that gap is where the real risk lives.

What’s Happening to Your Own Reasoning Skills

I keep running into senior engineers online, people with 15 to 20 years in the field, saying their own reasoning is changing. That’s scary to hear.

What’s even more scary is that I recognized it in myself before I even had a name for it 😞

When you step back from writing code and spend most of your time steering an AI and reviewing what it hands back, you’re operating one level above the code.

You’re not writing it. So you’re not practicing it.

PR after PR, review after review, I’m absorbing whatever patterns the AI tends to produce, without the friction of ever having built that muscle myself.

I didn’t clock it while it was happening. I noticed it later, the same week I caught myself accepting a pattern in a PR because it “looked right,” not because I’d actually traced through why it was right.

This isn’t just a feeling people have. According to a 2026 study, developers who relied on AI assistance while learning a new async library scored nearly two letter grades lower on coding comprehension tests than developers who worked without it. Most affected was their debugging abilities, the exact skill you need to catch what AI gets wrong.

The more I lean on AI to review AI, the less I’m actually practicing the skill I need to catch problems in the first place.

The Writing Parallel That Actually Worries Me

I do a lot of writing for THT, and there’s a version of this that maps almost exactly onto content creation. I bet you’ve heard about it 👇

You draft with AI using a voice guide and specific instructions, and for a while it holds your style. But the more you’re exposed to its output instead of producing your own, the more that output starts shaping what you reach for.

You stop directing the style and start absorbing it.

Code isn’t very different. The more review becomes your main point of contact with a codebase, the more that codebase starts sounding like whatever the AI tends to produce. It’s no longer what your team would have chosen on their own.

Note 👀
This isn’t an argument to stop using AI for review. It’s an argument for knowing exactly what you’re trading when review becomes your main form of engagement with code, instead of one form among several.

What to Actually Do About It

None of this is solved by reading harder or trying to individually will yourself into being a better reviewer.

It needs structure.

These are some working suggestions if you and your team are dealing with this in 2026 (many of them I’ve either implemented or am considering myself).

You Don’t Need a Full-Time PR Reviewer. You Need Tiered Review.

The instinct when review becomes the bottleneck is to think you need a dedicated person whose whole job is reviewing PRs.

I was convinced of it a while back 🥲

But in practice, that doesn’t scale.

Teams handling this well are actually doing tiered, risk-based review.

Not every PR gets the same depth of scrutiny. A copy tweak and a change to your auth flow are not the same review, and treating them the same is exactly what burns people out.

One framing I’ve seen work is to:

block on critical issues
warn on moderate ones
suggest on minor ones

Not review everything at maximum intensity, every time. Which is easy to do when an AI reviewer flags several issues. Use your judgement.

If you’re the person setting the review process for a team, rather than just doing the reviewing yourself, this is the actual decision point.

Define what counts as high-risk for your systems (auth, payments, data migrations, anything touching a legacy system nobody fully understands). Let lower-risk changes move through a lighter pass.

One more suggestion: stacked diffs. Instead of one 2,000-line PR landing all at once, the work gets broken into a chain of smaller, dependent PRs submitted as you go.

This way, an “Activity Feed” feature becomes:

A 200-line PR for the API spec
Another PR for the server logic once that’s approved
And a PR for the UI

Now, I know, it sounds like more overhead, and in one sense it is since there are more PRs to open and merge.

But a 300-line PR you can actually hold in your head beats a 2,000-line PR you’re skimming out of exhaustion.

Tip: If your team is drowning in giant AI-generated PRs, give stacked diffs a go before you assume you need more people.

Context-First, Not Diff-First

Before opening the diff, read the ticket or the PR description for intent.

You’re not just asking: does this code work?

You’re asking: does this code do what was actually needed?

Skipping this step is exactly how you end up as the substitute teacher grading blind.

Tip 📍
In case you’re not taking advantage of it but happen to use Jira and GitHub (who isn’t), then know that you can link the two. So, reference to the Jira ticket on the commit (which is good practice; please challenge yourself to write good, succinct commit) auto-links to the ticket itself. No excuse to not review the ticket.

Explore: This Is How To Love Writing Git Commits, Meet Gac

Tests-First, When You Have Them

If the PR includes tests, read those before the implementation. They’re your fastest route to the ground truth of what the code is supposed to do.

However, if your codebase doesn’t have strong test coverage yet (and if you’re managing legacy systems like I am, it might not), this is a worthy gap to flag.

You can’t lean on tests-first review if there’s nothing there to lean on.

Note ⚠️
Writing relevant tests is yet another relatively easy thing to do with AI. I won’t tell you to not do so. But I do want to emphasize the importance of understanding what those tests are doing and what they are proving, as well as what the intention is behind each one. There have been multiple cases where it’s proven that the AI writing the test case will write it in a way so it passes because that’s one of the requirements they have to complete the task.

Give the AI a Role, Not Just a Request

“Review this code” gets you a generic pass. A role-based prompt gets you something sharper because it forces the model to be specific and a little adversarial, rather than just agreeable.

This adapted version is close to what I actually use:

You are the chief architect on this team. Review this PR as if
you'll be the one debugging it in production three months from now.

1. What assumption does this code make that isn't stated anywhere?
2. Where would this fail under load, bad input, or a network timeout?
3. Are the tests proving behavior, or just proving the function exists?
4. What's the one thing you'd block this PR for? Not style,
   the actual risk.

You can tweak according to your project’s specifics, and I highly suggest setting it up as a consistent workflow used uniformly across the team.

Tip 🔥
Keep one AI session per PR. Mixing your own daily work, multiple reviews, and unrelated questions into the same thread muddies the context the model is working from, and you’ll get vaguer answers as a result. It’s like me talking about pandas, WebMCP relay, learning Mandarin while reviewing Greek, and whether I want to go blonde for summer all at the same time 🙈

Where AI Code Review Still Needs You

AI reviewing AI-written code can share the same blind spots.

If a model missed something while generating the code, a similar model may miss it again when reviewing the code.

That’s not a reason to skip this workflow. It’s a reason to keep the final call on anything touching security, architecture, or a system you don’t fully understand yet firmly with a human.

Use AI to filter the noise (formatting, obvious inconsistencies, summarizing a big diff) and spend your own attention on the judgment calls it can’t make for you.

It’s a Wrap

The overwhelm I described at the start isn’t a sign I’m doing this wrong. It’s what review actually looks like right now, for a lot of teams working across unfamiliar, legacy, multi-repo systems without a clean baseline to lean on.

That’s not a personal gap.

That’s just what happens when the volume outpaces the process you inherited.

If you try one thing from this, make it the tiered part. Stop giving every PR the same depth of review regardless of what it touches.

That single shift does more for the overwhelm than any prompt or tool will. I’ve been inherently doing it this entire time just to stay sane; it makes a huge difference.

We’re all dealing with decision fatigue, but we can all help each other by laying down some standards where we can and then doing what humans are not fond of doing but really good at: making decisions.

What does your review backlog actually look like right now? Is anyone on your team deciding which PRs deserve the deep read, or is it still first-come, first-reviewed?

I’ll leave you with that. ‘Till next THT-ers.

Bye.

AI Developer Programming