Everyone is offloading the hard parts. The pipeline is clogged. And the generation that was supposed to learn — didn’t.

There is a new dynamic spreading through engineering teams, and almost nobody is naming it clearly. It isn’t about productivity. It’s about offloading. Specifically, it’s about who can use AI to generate work that forces someone else to do the hardest part.

Junior developers can now produce an extraordinary volume of code. Pull requests come in at a pace that would have been unthinkable two years ago. The problem is that generating a PR and writing correct, reviewable code are not the same thing. Seniors are being buried under a growing mountain of AI-generated output that looks plausible on the surface but requires genuine expertise to evaluate. The pipeline isn’t moving faster — it’s clogging.

It Runs Both Ways⌗

But let’s not pretend this is only a junior problem. Senior engineers who want to ship fast are doing the same thing in the other direction — using AI to crank out features and, when something inevitably breaks, deferring the investigation and cleanup to junior teammates. Meanwhile, managers can now generate entire sprint backlogs from a single brainstorm session. Tickets appear at volume, each one requiring someone lower in the chain to actually determine whether the idea is technically coherent. Nobody is accountable for the mess they’ve created upstream, because generating the mess required almost no effort.

This is the tug of war: every role has found a way to use AI to pass the genuinely difficult work to someone else. The result isn’t more velocity. It’s more noise at every layer of the organization, with the same or worse actual delivery — and, when something ships, the quality often suffers visibly.

The Same Disease in Your Feed⌗

This pattern isn’t limited to code. Look at any professional content feed right now. The volume of long-form posts has exploded because turning a half-baked idea into a thousand words takes about ninety seconds with the right prompt. The posts look considered. They use all the right frameworks. But scroll through enough of them and something becomes clear: almost nothing new is actually being said. It’s the same ideas, recirculated, reworded, re-packaged. The marginal cost of producing content has collapsed to near zero, and so the feed has become a landfill of well-formatted emptiness.

Fake Productivity⌗

Funny how there’s so much productivity, but no product.

We are now at the point where it is becoming possible to see clearly what the AI productivity boom actually was — at least in part. A lot of it was fake. Not fake in the sense that nothing got built. Things got built. But the output wasn’t meaningfully better, the code wasn’t meaningfully more correct, and the ideas weren’t meaningfully more original. What grew was volume. Volume of PRs, volume of tickets, volume of posts, volume of job applications. Noise, not signal.

The tools for filtering that noise have not kept pace. Code review cannot be fully automated in any way that provides real safety guarantees. Human judgment is still the bottleneck, and human reviewers are being asked to process an order of magnitude more input than they were before, with roughly the same number of hours in the day. Something has to give — and what gives is either quality or people’s sanity.

The Generation That Didn’t Learn⌗

There is a longer-horizon problem that deserves more attention than it’s getting. Engineering skill is built through friction. You learn a technology by fighting with it — by hitting the wall, reading the stack trace, understanding why the abstraction leaked, internalizing the behavior. That process is slow and sometimes painful, and it is also irreplaceable.

A significant portion of the junior developers entering the field right now are not going through that process. They are going through a different one: write a prompt, get code, debug it with another prompt, ship it. This can produce results fast enough to pass code review in many organizations. It does not produce engineers who understand what they built.

The consequences of that are deferred, not avoided. Systems will break. Incidents will happen. When they do, you need engineers who can reason about what the system is actually doing — not just engineers who can prompt their way toward a solution in ideal conditions. The bill for skipping the hard work of learning is coming. It is just not due today.

Where This Leaves Us⌗

The organizations that figure this out fastest will be the ones that raise the bar on what counts as a reviewable contribution — not to be obstructionist, but because high standards are genuinely the only defense against a pipeline flooded with plausible-looking slop. That means investing in tooling, yes, but more fundamentally, it means rebuilding a culture that takes correctness seriously as a shared responsibility rather than something to be deferred upstream or downstream.

Individually, the question is simpler but harder to answer honestly: where do you actually stand? Are you the one generating the noise, or the one with the judgment to evaluate it? Because in a world where content and code can be produced at near-zero cost, the scarce thing — the actually valuable thing — is the judgment to know what is good.

That judgment doesn’t come from prompts. It still comes from doing the work.