AI Saved Us Time Coding, Now We Spend It Reviewing AI Slop
AI has saved me a ton of time over the last year. Between automating routine operational work and speeding up boilerplate code, tasks that used to take hours now take minutes. I have written before about how AI transformed my daily workflow and how much I enjoy pair prompting with teammates.
Lately, though, I have noticed a frustrating trade-off. All the time I am saving by automating tasks is getting eaten right back up in code reviews.
I am spending way too much time reviewing massive pull requests packed with AI slop.
The 1,500-Line "Small Fix"
You know the exact kind of PR I am talking about. The ticket is for a straightforward config update, a small bug fix, or a simple new endpoint. It should be a 50-line change across two or three files.
Instead, you open the pull request and see 1,500 lines changed across 20 files.
As you scroll through the diff, you realize that only 50 lines actually solve the problem. The other 1,450 lines are pure noise. The AI assistant decided to refactor three unrelated helper functions, rename variables for no reason, reorganize imports, add verbose error wrappers nobody asked for, and leave obvious comments above every single block of code.
When good changes are buried under hundreds of lines of random refactoring, reviewing the PR takes forever. You have to play detective just to figure out which lines are the real fix and which lines are the AI trying to be helpful.
"IDK, AI Did It"
The size of the PR is annoying enough, but the real breaking point comes when you start leaving comments.
I will spot a weird piece of logic, an unnecessary loop, or a Terraform resource setting that changed for no clear reason. I will leave a comment asking, "Hey, why did we change how this works?" or "Do we actually need this extra wrapper here?"
And the reply comes back: "idk, AI did it."
Nothing drains my soul faster in a code review than reading those four words.
Having a computer science background and working as an SRE, one rule has always stuck with me: if your name is on the pull request, you own every line in that diff. AI is a tool that writes code for you, not an engineer you can blame when the code makes no sense.
When that change ships and breaks production at 2 AM, Copilot or Claude is not going to answer the pager. A human has to debug it. If the person who opened the PR does not even know why the code is there right now, nobody is going to know what it does during an incident six months from now.
If you cannot explain why a line of code is in your PR, it should not be in your PR.
Why This Keeps Happening
AI coding tools are great at generating code fast, but by default they have zero discipline about scope. When you ask an agent to fix a bug or add a feature without strict boundaries, it treats the whole file like a blank canvas. It sees a function written two years ago and decides to "clean it up" along the way.
It feels productive to the person prompting because the code runs and the tests pass. The hidden cost gets pushed onto the reviewer. Writing the code took five minutes of prompting, and now reviewing it takes an hour of untangling side quests.
How We Fix It
We do not need to stop using AI to write code. We just need better habits before hitting the "Create pull request" button.
1. Review Your Own Diff First
Before you ask anyone else to look at your PR, read through the Files Changed tab yourself. Pretend you are the reviewer. If you see the AI touched a file or rewrote a function that has nothing to do with your task, revert those lines. Clean up the AI slop before your teammates have to read it.
2. Break Big Changes Into Smaller PRs
Big PRs have always been a problem, and AI just made it ten times easier to create them. A 100-line PR gets a real, thoughtful review in ten minutes. A 1,500-line PR either sits in the queue for days because nobody wants to touch it, or gets a blind "LGTM" because the reviewer gave up halfway through.
If your AI session ended up needing a real refactor plus a feature change, split them up. Put the cleanup in one PR and the actual logic change in another.
3. Look Into Stacked PRs
One workflow I have been looking into more lately is stacked PRs, sometimes called GitHub stacks. The biggest excuse for giant PRs is that people do not want to wait around for Part 1 to get reviewed and merged before they start working on Part 2.
Stacked PRs solve that. You create a small branch for the first change, open a PR, and then immediately branch off of that to build the next piece. You end up with a stack of three or four small, focused PRs that build on top of each other instead of one massive diff. The author stays unblocked, and the reviewer can step through each layer in five minutes without losing their mind.
4. Tell the AI to Stay in Its Lane
Most of the noise can be prevented in the prompt. Tell your AI tool up front: "Only modify the code needed for this change. Do not refactor unrelated functions, do not rename existing variables, and do not add extra comments." Putting simple guardrails in your prompt or custom instructions cuts out most of the junk before it even gets generated.
Speed Only Counts If We Understand What We Ship
AI is supposed to save the whole team time, not just shift the workload from the author to the reviewer. Use AI to move fast, automate the boring stuff, and draft your code. Just take ten minutes to trim the noise, split up the diff, and make sure you actually understand what you are shipping before you send it over for review.