A Bad Hire Now Ships 100,000 Lines Before You Notice

James Phoenix
James Phoenix

Florian Herrengt argues that AI is removing the middle class of software engineering. I think he is right, and I think the mechanism is narrower and nastier than skill polarisation. The cost of a bad hire used to be bounded by how fast they could type. It is not bounded by anything now.

Author: James Phoenix | Date: August 2026 | Riffs on: Florian Herrengt, “AI is removing the middle class of software engineering”


The Scene That Made This Concrete

Two engineers pairing on a feature one of them shipped the week before. Neither can explain why it works the way it does. So they do the obvious thing, which is to ask Claude. Claude reads the code, explains it back to them confidently and mostly correctly, and they nod and carry on.

Nothing in that room looks broken. The feature works, the tests are green, the explanation was probably accurate. But something structural happened: the codebase acquired a section whose only remaining author is a model, and the two people nominally responsible for it are now downstream consumers of an explanation neither of them can check.

I have written about where that ratchet ends in Cognitive Surrender. What I want to price here is different. Not what it does to the code, what it does to hiring.

What a Bad Hire Used to Cost

A weak engineer was always expensive, and the expense was always survivable, because it was bounded. The bound was throughput. They could only introduce so much wrongness per week, because introducing wrongness required typing it. A bad abstraction arrived one file at a time, and the slowness gave the organisation time to reject it. Someone hit it in review, someone else hit it in an adjacent ticket, and the correction landed while the blast radius was still three files wide.

That bound was doing far more work than anyone gave it credit for. Nobody designed it. It was a side effect of implementation being expensive, and it functioned as a rate limiter on damage. It is the same loop I described in Which Code Is Allowed to Be Understood by Nobody: the system could not get much bigger, or much more wrong, than someone was keeping up with.

That rate limiter is gone and nothing replaced it. A single person with a decent harness can put twenty to a hundred thousand lines into a repository between two standups. Whether that is a gift or a catastrophe depends entirely on the quality of the decisions underneath it, and the decisions are the part nobody can see in the diff.

The Two Kinds of Wrong, and Only One Got Cheaper

The useful split is between implementation-wrong and architecture-wrong.

Implementation-wrong got dramatically cheaper to fix. A generated function that misses an edge case is a free diagnostic. You delete it, tighten the spec, and regenerate. That is the move I argued for in Seniority Was a Proxy for Typing Speed, and it holds: a wrong output is the cheapest possible evidence that a specification was ambiguous.

Architecture-wrong did not get cheaper. It got worse, and the reason is arithmetic. The cost of reversing a structural decision scales with the volume of code resting on it, and that volume is now growing twenty times faster. Pick the wrong framework, the wrong data model, the wrong service boundary, and every file written afterwards is another vote for keeping it. A senior used to have three weeks to notice a bad boundary before it became load-bearing. Now they have a long weekend.

A Bad Hire Now Ships 100,000 Lines Before You Notice

This is the asymmetry that makes the current moment genuinely different rather than just faster. The reversible mistakes became free. The irreversible ones became irreversible sooner.

Why the Middle Specifically

The market never priced engineers by skill. It priced them by scarcity, and for most of the industry’s history the scarce input was competent implementation. That made the middle of the market an easy trade. Someone who knew the framework, moved quickly, and produced working code was straightforwardly worth their salary, and nobody looked too hard at their architectural judgment, because the judgment was not the thing being bought.

Now the thing on the invoice is free. Juniors are not exposed in the same way, because nobody was ever paying a junior for output. They were paying for an option on who that person becomes. The top is not exposed, because judgment was already what they were being paid for and it just got scarcer. The exposed group is the people who sold execution and were never evaluated on judgment, and who are now being evaluated on it retroactively. That is what “middle class” means here, and it is not a claim about ability. It is a claim about which skill happened to be on the invoice.

The Arithmetic That Makes People Stop Hiring

Say I bring someone onto a feature. There are two paths.

Path one, they hold the architecture. They choose the boundary, the framework, the data model, and the agents fill in the rest. If their judgment is good this is enormous leverage and easily the best money I can spend. If it is not, I inherit sixty thousand lines resting on a decision I would never have made, discovered at the point where reversing it is no longer rational, so I live with it for years.

Leanpub Book

Read The Meta-Engineer

A practical book on building autonomous AI systems with Claude Code, context engineering, verification loops, and production harnesses.

Continuously updated
Claude Code + agentic systems
View Book

Path two, I hold the architecture. I write the spec tightly enough that the structural decisions are mine and the generated code cannot drift away from them. This is safe. It is also self-defeating, because if I am writing a spec at that resolution, the hire’s marginal contribution is running the agent, and I can run the agent.

A Bad Hire Now Ships 100,000 Lines Before You Notice

That is the squeeze, and it has almost nothing to do with salary. Whatever the person’s execution is worth now nets against the option value of a structural decision I cannot cheaply reverse. Every hire became a bet on judgment, at a stake set by how much code the person can generate before anyone checks. Run that calculation honestly and the answer is uncomfortably often to not hire.

Where I Get Off The Bus

That logic is locally correct and globally self-terminating, and I do not think Florian’s piece sits with the second half long enough.

Judgment about architecture is not taught in a bootcamp and cannot be read off a model. It is produced by making structural decisions, living inside them, and paying to reverse them. The bound that used to rate-limit damage was the same mechanism that manufactured seniors, because a mistake small enough to survive is a mistake you learn from. Every firm running the “do not hire the middle” arithmetic is depending on some other firm to have paid for the judgment it now demands as an entry requirement. That works until enough firms run it.

I am not going to pretend this resolves into “hire anyway.” It resolves into the interview measuring the wrong thing.

What I Would Interview For Instead

Not throughput, and not framework recall, because both of those are now free and both are what most loops still measure. What I want is a reversal story. Tell me about a structural decision you made, how you found out it was wrong, what it cost to undo, and what you would look for earlier next time. Someone who cannot produce one has either never held a boundary or never noticed losing it, and both answers cost the same.

The employer side of the same move is to stop leaving structural decisions implicit. Write down which subsystems are allowed to be generated freely and which require a human theory-holder, and make that line an artefact rather than a vibe. A new hire cannot violate a boundary they can read, and holding that line for a team is the senior job that does not scale with reading speed.

One Sentence

Implementation-wrong got cheap to undo and architecture-wrong got expensive, so hiring stopped being a bet on execution and became a bet on judgment, priced at the volume of code the person can generate before anyone checks.

Related

Topics
Ai AgentsCareerCoding AgentsDeveloper ExperienceSoftware Architecture

Newsletter

Become a better AI engineer

Weekly deep dives on production AI systems, context engineering, and the patterns that compound. No fluff, no tutorials. Just what works.

Join 306K+ developers. No spam. Unsubscribe anytime.


More Insights

Cover Image for What Is Cognitive Surrender?

What Is Cognitive Surrender?

Cognitive surrender is the point where a team can no longer independently check what its tooling tells it, because nobody holds a working model of the system anymore.

James Phoenix
James Phoenix
Cover Image for Read Less Code, Not No Code

Read Less Code, Not No Code

The capacity math on human review broke years before AI arrived. That is an argument for spending the review budget deliberately, not for zeroing it.

James Phoenix
James Phoenix