There’s a version of this conversation that reassures people. I’m not writing that version
Here’s what’s actually happening: AI is systematically absorbing the high volume, low-judgment layer of software engineering — boilerplate generation, test scaffolding, routine bug triage, documentation drafts, CRUD implementa tions that follow a pattern. This work was never your competitive advantage. It was just slow enough to require humans. Now it isn’t
What “mediocre work” means precisely
When people say “AI replaces mediocre work,” they usually leave it vague enough to feel like a compliment. Let’s be specific.
Mediocre work in engineering is implementation work that a procedurally-skilled person can execute without deep system context — writing the 40th variation of an authentication middleware, generating a data access layer from a schema, building the CRUD surface for a new entity type, writing unit tests that verify the obvious. This isn’t bad work. It’s necessary work. It just doesn’t require judgment about tradeoffs, failure modes, or organizational constraints.
AI is fast at exactly this tier. Not because it’s intelligent — because this work is structurally pattern-matchable, and AI is a very fast pattern matcher with a large training set.
What it cannot reliably do: reason about system boundaries under real oper ational constraints, make architecture decisions where the tradeoffs depend on team skill distribution, debug a distributed failure where the signal is in what’s missing from the logs, or translate a product requirement into a technical shape that will survive the next 18 months of business change.
That is judgment work. It requires domain context, organizational memory, and the ability to reason under incomplete information. No current AI system does this consistently without a human who already knows the answer steering it.
The pipeline problem nobody is talking about
Here’s where engineering leaders should slow down.
The implementation volume that AI now absorbs — the boilerplate, the scaf folding, the routine work — is the same volume that junior engineers used to 1 do to become senior engineers
You learned distributed systems by debugging a production incident, not by reading a textbook. You developed architecture intuition by making a bad call and living with the consequences for two years. You built judgment by spending three years in the messy, underdetermined middle of real systems.
If AI handles the bottom of the implementation stack, what work does a junior engineer do to build toward that judgment? This is not a rhetorical question. It’s an organizational design problem most teams have not solved
The teams that figure this out — that redesign the junior-to-senior progression for an AI-assisted environment — will build the engineers who can actually leverage AI at a senior level. The teams that don’t will find themselves with a generation of engineers who are prompt-fluent but judgment-shallow
What this means for how you build teams
A few operating principles that follow from this:
Redefine what senior means. Senior used to mean “fast at implementation + judgment.” That’s no longer the definition. Senior now means “can direct AI on implementation and own the judgment layer.” These are different skills. Your leveling rubrics probably don’t reflect this yet.
Protect deliberate judgment-building for junior engineers. Don’t let AI do all the hard parts for them before they understand why those parts are hard. Give them real ownership of systems, not just prompt execution. The goal is not to produce engineers who can generate code — it’s to produce engineers who know when the generated code is wrong
Stop measuring output volume. An engineer with good AI tooling will produce 5x the output of an engineer without it. If your performance metrics reward throughput, you’re measuring the wrong thing. Start measuring decision quality, system outcomes, and design clarity. These are the things AI cannot produce for you.
The real risk isn’t headcount. Engineering leaders who are focused on “how many engineers do I need now that AI is here” are asking the wrong question. The right question is: what is the ratio of judgment work to implementation work in my organization, and am I building the capability to execute on the judgment side?
The uncomfortable version
The uncomfortable truth in the “AI replaces mediocre work” framing is not that mediocre developers are at risk. It’s that most engineering organizations — most of the time — are running on a higher percentage of mediocre work than anyone wants to admit
That’s not an insult. It’s economics. Implementation work has always been cheaper to produce than judgment work. Systems get built by mixing both in ratios that get the product shipped.
What AI changed is the floor. The minimum viable output is now higher, faster, and cheaper to produce. What used to be “good enough” delivery is now table stakes. The differentiator is judgment, design quality, and the ability to operate in the ambiguous space where requirements are incomplete and the stakes are real.
The developers who thrive are not the ones who avoided mediocre work — everyone does mediocre work sometimes. They’re the ones who built judgment capabilities on top of it.
Engineering leaders who want to stay relevant are not asking “will AI replace myteam.” They’re asking: “Is my team building the judgment layer fast enough to stay ahead of what AI just made free?”
That’s the right question. Most teams aren’t asking it yet