The Developer Divide — What the Pragmatic Engineer's 900-Developer Survey Actually Reveals About AI

Published: May 19, 2026

"Software Developers Say AI Is Rotting Their Brains." That was the headline 404 Media ran in May 2026, based on anonymous interviews with engineers at Meta, Google and Microsoft. Around the same time, a randomized controlled trial from METR published a finding that should have stopped every AI-hype conversation cold: experienced developers using AI were 19% slower on complex tasks, yet believed they were 20% faster. A 39-percentage-point gap between perception and reality.

If you have felt lately like AI makes you work harder, not less, you are not imagining it. And you are not alone. Two weeks earlier, Gergely Orosz at the Pragmatic Engineer published the most important survey about AI and software engineering this year. 900+ responses revealed something most hot takes miss entirely. We are not all experiencing the same AI. We have split into three distinct groups and AI is making each group more of what they already were.

I have been in all three groups at different points in the last two years. I have been the builder frustrated by reviewing AI slop. I have been the coaster producing code I did not fully understand. And today, I am a deliberate shipper, someone who uses Claude Code daily to ship fast, but who has built specific practices to avoid becoming a liability. Here is what the data actually says, what it means for your team and the five rules I follow to keep AI as an accelerator instead of a tax.

The Data Worth Paying Attention To

The Pragmatic Engineer survey identified three developer archetypes in the age of AI: Builders, Shippers and Coasters. The central insight is not that one group is right and the others are wrong. It is that AI amplifies existing tendencies. It does not make everyone faster. It makes who you already are more intense.

Builders care about quality, architecture and craft. They do the large refactors, the migrations, the test coverage work.
Shippers care about output. They ship features fast and measure success by what reaches production.
Coasters are engineers who were average before AI and are now, with the right tools, producing more code than ever, but with proportionally more problems.

The critical finding: each group experiences AI completely differently. What feels like speed to a shipper feels like noise to a builder. What feels like a promotion to a coaster feels like a tax to everyone else.

This connects directly to a point I made in a previous post about choosing the right agentic workflows. The tool you pick and the habits you build determine which archetype you feed.

Builders: The Ones Carrying the Weight

Builders are the senior engineers, the architects, the people who care whether the codebase is maintainable in six months. They are also the group most negatively affected by AI adoption.

The Heidelberg University / arXiv paper from March 2026, titled "An Endless Stream of AI Slop," introduced the concept of a review tax. Builders are spending approximately 11.4 hours per week reviewing AI-generated code written by colleagues. That is time they are not spending on architecture, on their own features, or on the deep work that justified their seniority in the first place.

The Sonar 2026 State of Code survey found that 96% of developers do not fully trust AI-generated code and that AI-generated PRs have 1.7x more defects. CodeRabbit's analysis confirms the same pattern. The result is not just slower reviews, it is resentment. One engineer quoted in the 404 Media piece captured it perfectly: "We're building a rat's nest of tech debt that will be impossible to untangle."

I have felt this myself. When I review a PR where 80% of the diff is AI-generated and the submitter clearly did not read it, the cost shows up on my calendar, not theirs. Builders are subsidizing everyone else's speed.

Shippers: The Group Nobody Is Being Honest About

Shippers are the most enthusiastic group in the survey. I am one of them. I ship 2-3x faster with Claude Code than I did without it. I am not going to pretend otherwise.

But there is a tradeoff that the hype cycle does not talk about. Shippers accumulate tech debt faster. They may build the wrong things faster. Speed is not direction. A year from now, some codebases built at maximum AI velocity will be unmanageable. The shipper who built them will be on to the next project while a builder inherits the mess.

The honest take is this: shippers are winning right now. The market rewards output. But the debt compounds silently. I have had to build deliberate practices to keep my shipping velocity from turning my projects into rescue cases down the line.

Coasters: The Hidden Tax Every Team Is Paying

This is the archetype nobody wants to admit exists on their team. Coasters are engineers who were average or below before AI. With AI, they can produce code that looks complete: tests, types, comments, the whole package. But it breaks in production. It does not handle edge cases. It fails under load.

The Pragmatic Engineer survey found that coasters uplevel faster with AI than either builders or shippers. That sounds like a win until you read the fine print: they generate proportionally more slop while doing it. The tragedy of the commons is in full effect. Coasters dump code into shared repositories. Builders clean it up. Everyone pays for it except the person who wrote it.

I have inherited codebases from coasters. The pattern is always the same: the repo looks complete. The tests pass. The code compiles. But the integration layer is missing, the error handling is a try-catch that swallows everything and the state management makes assumptions that only work in a demo. The previous developer was fast. I was the one who had to make it work.

If you are currently sitting on a Next.js, React or Sanity project that a previous developer left in this exact state, that is the work I take on as a service. Hardcoded content where there should be a CMS, missing SSR, broken SEO, inconsistent UI, paid tools that were never integrated. I rescue it, ship it and hand it back working. If that sounds like your situation, book a free 30-minute project assessment and I will tell you what it would take to bring the codebase back.

The METR Paradox: Why You Cannot Trust Your Gut

The METR randomized controlled trial produced the most unsettling finding in this entire conversation. Experienced developers using AI were measurably 19% slower on complex tasks. But they believed they were 20% faster. That is not a small miscalibration. It is a complete inversion.

The Anthropic study from January 2026 found the same pattern in a different way: developers using AI scored 17% lower on mastery tests. The biggest gap was in debugging, the skill that matters most when things go wrong at 2 AM on a production server.

Why does this happen? AI handles the easy parts instantly. You type a prompt, you get back working code for the happy path. That feels productive. But the hard parts (edge cases, integration issues, performance problems) get harder because you spent less time building the mental model of the system. You outsourced the learning and paid for it later.

I see this in client conversations about rescue projects. "My previous developer told me AI made them 3x faster." And then I find the code. The easy parts are there. The hard parts are missing entirely.

What Nobody Is Adding to the Cost

The conversation about AI in software engineering focuses almost entirely on speed. The cost side of the ledger gets ignored. Here is what actually gets spent:

Token costs. Claude Code Max is $100-200/month per developer. GitHub Copilot switched to consumption-based pricing on June 1, 2026. LeadDev reported that token costs are the new cloud bill: exploding, unpredictable and hard to control.
Review tax. 11.4 hours per week of senior developer time spent cleaning up AI-generated code. That is a quarter of a productive workweek.
Debugging burden. AI code introduces bugs at a higher rate (1.7x more defects). Those bugs get found in production, not in review.
Skill atrophy. The more you rely on AI for tasks you used to do yourself, the slower you become at doing them without AI. The Anthropic study quantified this at 17% lower mastery.
Trust erosion. The Stack Overflow survey found trust in AI accuracy dropped from 40% to 29% in a single year. But usage rose to 84%. The gap between adoption and trust is the danger zone.

The macro narrative is straightforward: shippers burn tokens, budgets explode, companies clamp down and everyone suffers. The hype cycle is still running, but the cost side is catching up.

My Personal Rules for Staying a Deliberate Shipper

I ship fast. But I have built non-negotiable practices to make sure I stay in the "shipper who adds value" category instead of drifting into "coaster who leaves messes."

Rewrite every AI-generated function signature by hand. Before I accept any AI output, I type the function signature myself. This forces me to understand what the function takes and returns before I care about the body. It takes 10 seconds and saves hours of debugging.
Never let AI write tests for its own code. AI-generated tests for AI-generated code is a closed loop. It passes because both sides share the same blind spots. I write the tests. The AI implements against them. The order matters.
Always review the full diff before commit. No blind accept. I read every changed line before it enters the codebase. This is not negotiable. The review is where learning happens.
Run lint before accepting AI output. I have a pre-acceptance hook that runs my full lint suite against any AI-generated block. If it fails, I read the errors before fixing them. This catches the patterns AI always gets wrong.
Pick the tool that respects your skill level. Not all AI tools are equal. The Pragmatic Engineer survey found Claude Code is the most-loved tool (46% net positive) specifically because senior developers trust its output more. Copilot is good for autocomplete. Cursor and Windsurf are good for inline editing. Claude Code is the only one that consistently produces output I do not need to rewrite entirely. The tool you choose determines the archetype you feed.

These rules share one thing: they preserve cognitive engagement with the code. The moment you stop reading AI output, you start coasting. The moment you stop understanding the code you commit, you stop being a developer and start being a prompt engineer with a GitHub account.

The Tool You Choose Is the Archetype You Feed

The Pragmatic Engineer survey data, the METR paradox, the Anthropic mastery study, the 404 Media reporting: they all converge on the same conclusion. AI is not making everyone faster. It is making everyone more of what they already were. A good engineer becomes faster. A careless engineer becomes dangerous faster.

The archetype split is not going away. Teams and clients will learn to recognize it. The market will price it in. If you are a builder, your review burden is a real cost that needs to be managed. If you are a shipper, your tech debt is real and it compounds. If you are hiring or commissioning work, the ability to tell the difference between shipping and slop is becoming a core skill.

Conclusion

AI does not make everyone faster. It amplifies who you already are. A good engineer with good habits becomes better. A careless engineer with no review discipline becomes a liability. The split between builders, shippers and coasters is real and it is only going to widen as the tools improve.

The five rules above are how I stay on the right side of that split. They are simple. They are not expensive. But they require the one thing AI cannot replace: the willingness to stay engaged with your own code.

If you want the full system, including the specific prompts I use in Claude Code, my daily review workflow and the practices I teach to teams that want to ship fast without accumulating slop, I break it all down inside the Agentic Architect Lab. That is where the deliberate shippers hang out. Join us.