If the AI does the junior work, where do senior engineers come from in 2036?

The argument as usually conducted: does AI-assisted coding reduce the need for junior engineers? Both camps have their talking points, neither has data anybody trusts, and the discussion resets every four months.

It’s the wrong timeframe. Ask instead: an engineer who is senior in 2036 is, today, roughly two years out of school. What produces that person?

How seniority is actually made

Not by reading. Not by courses. By a specific and fairly grim process:

You get handed a bug in code you didn’t write. You spend two days on it. You form four wrong theories and discard them. You learn to read a stack trace properly, then to distrust it. You ship a fix, it breaks something else, and somebody more senior explains — with varying patience — what you missed and why.

Repeat several hundred times over four years and you have an engineer with judgment. Not knowledge; judgment. The thing that lets someone look at a design and say “that’ll be fine for eighteen months and then the retry logic will kill you,” without being able to fully articulate how they know.

That’s pattern matching built from a large corpus of personal failure. There is no shortcut, and the corpus is assembled almost entirely from the exact work that gets described as “tasks AI handles now”: small bugs, test coverage, boilerplate, the tedious refactor, the CRUD endpoint, the log-reading.

The tedium was never the point. The tedium was the curriculum.

The uncomfortable middle

I don’t think the strong version of the pessimist case holds. “AI eliminates junior work, pipeline collapses” assumes the work is a fixed quantity, and it isn’t — a team that ships faster generates more systems, more integration surface, more operational complexity, and therefore more of everything that needs a person.

But something more specific is happening, and it’s worth naming precisely: the difficulty distribution of the remaining work is shifting.

The easy tasks that used to be a junior’s entry point get generated. What’s left is reviewing generated code, integrating it, and debugging its failures — all of which are harder than writing it was, and all of which require the judgment that the easy tasks used to build.

That’s an inverted ladder. The first rung is now above head height, and you need the thing you were supposed to acquire by climbing.

Where I’ve changed my mind

My first take was that this would sort itself out, because it always has. Compilers didn’t destroy programmers; they moved the abstraction level. Every generation has this panic and every generation is wrong.

I’m less confident in that analogy now, for one reason: previous abstraction jumps removed a category of work entirely. Nobody needed to learn register allocation to be a productive programmer after optimising compilers, and nobody was diminished by that, because register allocation wasn’t teaching them anything else.

This is different. The work being automated isn’t a category being eliminated — it’s the practice ground for work that still exists. You still need people who can debug a distributed system at 3am. The path that used to produce them ran directly through the tasks a model now does in four seconds.

I could still be wrong. New practice grounds may emerge that I can’t see, and I’d note that people said similar things about high-level languages and were mistaken. But the mechanism is different enough that “it worked out before” isn’t the argument people think it is.

What organisations should actually do

The good news is that the fix is unglamorous and known, because other professions solved this centuries ago. It’s apprenticeship, and it costs money.

Give juniors problems, not tickets. A ticket with a defined solution can be generated. “This endpoint gets slow under load and we don’t know why” cannot, and it is the actual curriculum. Let them flounder for a day before helping.

Make review the teaching surface. If a junior’s job is reviewing generated code, then reviewing their review is where the learning happens. That’s senior time, deliberately spent, on something with no output this sprint. It will lose every prioritisation argument it’s ever in unless someone protects it.

Require them to be able to explain it. Not to justify the code — to explain the system. “Why is it structured this way” is a question a model can answer plausibly and a junior must be able to answer correctly. Those diverge, and the divergence is where the learning is.

Accept the cost honestly. A junior is a net negative for a while. That was always true; AI-assisted output makes the comparison look worse in the short run and identical in the long run. An organisation that optimises this quarter’s velocity will not hire them, and in 2036 will be bidding against everyone else for a smaller pool of senior engineers than the industry needs.

That’s a tragedy of the commons, and no individual company is wrong to defect. Which is precisely why it’s likely to happen.