Maya is the best mid-level engineer on her team. Give her a ticket and she ships it: clean code, good tests, on time, every time. For six years, that reliability made her indispensable.
Then the two juniors on her team got Claude Code. Within a month, they were closing tickets at her pace.
I told Maya's story recently, and it traveled further than anything I have written. The reaction split into two camps. One camp argued the premise could never happen. The other camp recognized their own team in it. Both camps were reacting to the same uncomfortable idea, so it is worth laying out the full argument.
The conversation about AI and engineering careers keeps circling one prediction: the junior role disappears first. Why hire someone to write junior-level code when AI writes it faster? I think that prediction aims at the wrong rung of the ladder. The role AI eliminates is the mid-level one.
What each rung is actually for
To see why, ignore the years of experience attached to each title and look at what each rung is for.
A junior engineer is paid to learn. They execute with guidance, ask questions early, and build the foundation everything else sits on. That is not a weakness. That is the job.
The pinnacle of mid-level development is successful execution. Hand a mid-level engineer a clear spec and they return working, production-grade code without anyone watching over their shoulder. Reliable translation of a defined problem into a working solution: that is the rung's entire identity, and for a long time it was the most dependable value an engineer could offer.
The senior level is different in kind, not in degree. Seniors are expected to exercise judgment within ambiguity. Not judgment in general: judgment where the spec does not exist. What to build. What to cut. What breaks at 2 AM, and whether it is worth preventing. The problem arrives fuzzy, contradictory, and political, and the senior's job is to give it a shape before anyone writes a line.
Petar Ivanov, who teaches JavaScript developers to think like architects, draws this ladder as three questions. The junior asks: what should I build? The mid-level asks: how should I build it? The senior asks: should we build it at all?
Now look at the middle question. "How should I build it?" is precisely the question AI-assisted coding answers. Give a coding agent a clear spec, a well-organized codebase, and context about your team's practices, and it produces the implementation. Not perfectly, and not unsupervised. But the gap between an AI-assisted junior and a strong mid-level executor is closing by the month, because execution is the part AI is best at.
The middle question got automated. The questions on either side of it did not.
The distance shrinks
This is the part most analyses miss. It is not just that one rung folds. The whole ladder gets shorter.
If AI can get a junior close to mid-level execution quality, then the space between junior and senior is not as wide as it has been. The traverse that used to take years of grinding through tickets now runs more directly: from learning what to build, toward deciding whether to build it, without a long residency in how.
The mid-level rung was where engineers used to park while their execution matured. AI is removing the reason to park there.
The cruel twist: the proficient adopt last
A fair objection: in what world do the juniors get AI and the rest of the team does not?
No world. Everyone has access. The asymmetry is adoption, not access, and it cuts in an unexpected direction.
The tool feels slow when you are fast. A proficient engineer who can type the solution in twenty minutes experiences the AI loop as friction. They have speed to defend, and the tool loses the race on the tasks they already do well, so they wait. A junior has no speed to defend. They adopt on day one.
So AI usage divides by experience level organically, with no policy required. And the result is bitter: the engineers whose role depends most on execution speed are the slowest to pick up the tool that resets it. The proficiency that made the mid-level indispensable becomes adoption inertia. The squeezed rung adopts the leverage last, which compounds the squeeze.
But what about quality?
The second objection arrives quickly in every one of these conversations: clean code is still a differentiator. AI output is sloppy. Real engineers still matter.
Two things are true at once. First, a well-instrumented AI development pipeline, with context about your codebase and your team's best practices placed where the agent will use it, produces cleaner code than most skeptics expect. Quality of AI output is mostly a property of the pipeline around the model, not the model.
Second, and more uncomfortable: code quality is not an absolute. For much of business software, the business rules are what matter, and there is plenty of badly maintained code in the world quietly earning revenue. The senior skill was never "make everything clean." It is knowing where low quality disproportionately hurts the business and spending the effort there. That is not an execution decision. That is judgment within ambiguity, which is exactly the point.
Where will seniors come from?
The strongest objection deserves the most room. If juniors skip the execution years, where does judgment come from? Software engineer Virlla Devi Soothar put the worry as well as anyone: "The danger isn't that AI will write your code. The danger is that AI could replace the learning experiences that turn developers into engineers."
The worry is real. The conclusion usually drawn from it, that juniors must learn the way we learned, is not.
How a generation builds judgment has already changed medium twice. The engineers who started before the internet matured learned by pure trial and error. Then Stack Overflow and search engines arrived, and suddenly you could search your issue and find that someone had documented the answer. Engineers my age learned through that mediation, and nobody concluded we would never develop judgment because we did not suffer enough. Now every engineer has a personal assistant that can not only produce the right answer but explain it in the way that particular person understands.
Insisting that juniors learn through the previous generation's medium is not rigor. It is nostalgia.
What actually builds judgment in this era is using the new medium adversarially, in both directions. Ask the AI to explain its choices. Have it plan before it builds, and challenge the plan. And go the other way: tell the AI it is wrong and make it prove itself. The engineers who treat AI output as a conversation to interrogate, rather than an answer to accept, are doing the same thing my generation did in long debugging sessions. The back and forth is where judgment forms.
There is a social fact hiding here that makes the tool more valuable than it looks. Challenging people is expensive. You do not get many opportunities to challenge your team members, and as a junior it is not always wise to spend them: you are still learning, and you cannot tell yet which of your objections are insight and which are inexperience. But you can challenge the AI all day long. No meeting, no standing, no relationship to spend. Every round is a repetition of the exact skill the senior rung runs on. A junior who argues with their AI daily is doing judgment reps that previous generations had to wait years for permission to do.
Teams can build this into the system itself. Imagine a codebase that can explain itself. A bug fix that arrives with the root issue explained, not just the patch. Team knowledge distilled automatically into onboarding for the next junior, so the patterns and the reasons behind them are taught rather than excavated. One engineer's hard lesson, fed into the shared AI context, becoming every engineer's guardrail. None of this is speculative. All of it is possible now, with intentional structuring of how AI is used. The apprenticeship is not dying. It is changing substrate: from folklore passed across desks to context passed into the tools.
What happened to Maya
Maya spent her first month trying to out-type Claude Code. Longer hours, faster hands, cleaner diffs. It almost worked.
Then she stopped racing and changed questions. She stopped asking how fast she could close a ticket and started asking whether the ticket should exist. She wrote the specs the juniors' AI built from. She cut a feature that looked urgent and was not. She learned what breaks at 2 AM, and why.
Six months later her name was on fewer commits than anyone on the team, and nothing shipped without her. Then the title caught up.
Petar Ivanov has a line I keep coming back to: "Progression isn't about stress. It's about blast radius." Maya's commits shrank while her blast radius grew. That is what climbing actually looks like now.
The ladder is shorter, not harder
The mid-level rung is folding. I will not pretend otherwise, and if you are standing on it, the data says you will feel the squeeze before your slower-adopting peers believe it is happening.
But notice what is actually disappearing. The rung was never the job. The judgment was. Execution was a long apprenticeship we required before we let engineers near the real decisions, and the apprenticeship just got dramatically shorter. The decisions did not go anywhere. They are arriving earlier in careers, less announced, to people with less time parked in between.
And the mid-level engineer who fully embraces the tool may be the best positioned of all. Their expertise still buys solid execution, now with the tool doing the typing, and that frees the bandwidth for the hardest habit separating the middle of the ladder from the top: the pause. Stopping to ask why this is being built. Challenging whether it should be built at all. The pause is hard to practice on a delivery treadmill, and harder still to practice on colleagues. But a tool you can challenge gives you unlimited practice, and experience compounds: the mid-level who adopts this way builds senior judgment faster than the juniors ever could.
That is the opportunity hiding inside the squeeze. Judgment within ambiguity is learnable, and the path to it no longer requires six years of translating specs. It requires owning problems: understanding what systems are made of, what forces act on them, and what they have to survive. That vocabulary is what I teach, and it is the part of the job AI keeps making more valuable, not less.
You do not climb by writing more code. You climb by owning the problem the code is for.