Your pull request queue has gotten out of hand. It was once under control. Now, it's become an unmanageable mess.

Each day, you log onto GitHub and see three, four, or five new PRs from your team members. The PRs are huge. The code looks...ok? But something feels wrong. It reads as if the person writing it doesn’t grasp the problem.

Because they don’t.

The Coaster Problem

Pragmatic Engineer surveyed over 900 engineers and found a trend that has been developing for a while. There is a widening gap between what he describes as "Builders," "Shippers," and "Coasters."

Builders are the type of engineers who are truly knowledgeable about the system. They make rational choices. They take ownership.

Coasters are the ones who leverage an easy way to be more efficient. They ask an AI, receive a giant blob of text, and submit it as a PR. The quantity of PRs increases. The quality does not.

Here's the tough reality: AI tools increase the apparent productivity of Coasters. They open more PRs. They change more lines of code. They close more tickets. Managers who measure by output quantity think they have a top employee. The actual engineers who review the code know that one person is all they're cleaning up after.

The Review Tax

I've taken to calling it the review tax. It's the uncounted cost that gets slapped on the Builders every time a Coaster ships a messy PR.

→ You spend 45 minutes understanding code the author didn't write and can't explain
→ You leave comments asking "why this approach?" and get back "let me check" (meaning: let me re-prompt)
→ You end up rewriting chunks yourself because it's faster than another review round
→ You quietly resent the whole process

Our survey data reflects this. The most friction of any kind on AI-heavy teams is between the two archetypes of engineer. Builders feel like they're doing a bunch of free editing. Coasters feel like they're being overly criticized for just trying to move fast. Neither is wrong about what's happening to them. But only one is risking burning out.

This Isn't an AI Problem. It's a People Problem.

Again: I don't want to make this an anti-AI-in-coding essay. I use those tools all the time myself. The problem isn't the technology itself. It's that AI magnifies your existing tendencies.

A responsible engineer utilizes AI to solve familiar problems more quickly. An irresponsible engineer uses AI to avoid understanding the problem altogether. It's the same tool but leads to vastly different results.

The real problem lies within the organization. Most teams have not adapted their code review processes to a new reality where a machine can produce a 400-line PR in a matter of minutes. We are still reviewing AI-generated code using standards created for human-written code. And this mismatch is the source of all pain.

A few suggestions that could potentially make a difference:

→ Require PR authors to annotate AI-generated sections. If you can't explain it, you can't ship it.
→ Review for understanding, not just correctness. Ask the author to walk through the logic live.
→ Stop rewarding volume. Lines of code and PR count are vanity metrics. They always were. Now they're dangerous ones.
→ Set team norms explicitly. "We use AI as a drafting tool, not a shipping tool" is a sentence worth saying out loud.

The Real Risk 🔥

The engineers who care enough are the ones most likely to walk away. They didn’t join to clean up after a code-writing robot.

When your best reviewers become increasingly silent on PRs, that’s not them enjoying some peace and quiet. That’s their silence becoming permanent — it’s when they quit. 😬

Teams that figure out healthy AI-assisted review norms will keep their Builders. Teams that don't will end up staffed entirely by Coasters shipping code nobody truly understands.

The hard question isn't "should we use AI to write code?" — it's "who's accountable when nobody on the team actually wrote the code they're shipping?"

Have you felt this on your team? Are you the Builder drowning in review, or have you found a way to make AI-generated PRs actually reviewable? I'd genuinely love to hear what's working.