The apprenticeship has to be rebuilt on purpose
Junior engineers became senior ones as a byproduct of work that was too expensive to do any other way. That work is now cheap, the byproduct is gone, and byproducts do not come back on their own. If you want seniors in five years you have to fund the path as a line item.
Nobody designed the engineering apprenticeship. It emerged.
Juniors got the small tickets, the bug fixes, the test writing and the unglamorous migrations, not because anyone believed those tasks were pedagogically optimal but because seniors did not want to do them and somebody had to. Over two or three years of that, a person accumulated a working model of the system, a feel for what breaks, and enough scar tissue to have opinions. Then they became a senior, and the cycle continued.
Entry-level developer postings are down around forty percent, and the usual explanation is that AI replaced junior work. The more precise statement is that the economic accident which produced seniors has stopped running. The tasks were never the point. They were the delivery mechanism.
My position: the apprenticeship will not re-emerge, because the conditions that produced it were incidental and those conditions are gone. If you want senior engineers in 2031 you have to design and fund the path deliberately, as a cost you have chosen, and the design looks almost nothing like the one that ran by itself.
Two fixes that do not work
Before the design, the two things organisations reach for first, both of which fail for the same underlying reason.
Give juniors the small tickets anyway. The instinct is to preserve the old shape by carving out work an agent could do and reserving it for humans. It fails in two ways. The work is now visibly makework, and juniors know it, which corrodes exactly the motivation you are relying on. And it trains for a job that no longer exists: producing small units of code by hand is not what anyone will be paid for by the time they are senior.
Put them on documentation and testing. Slightly better disguised, same problem. These are now generation tasks. A junior asked to spend a year writing tests an agent produces in seconds is being trained in the operation of a machine they will never operate.
The failure in both cases is that they preserve the task rather than the learning. The learning was never in producing the code. It was in the loop: form a model of how the system behaves, act on it, discover the model was wrong, update it. Producing code was just the cheapest available way to run that loop several hundred times.
Preserving the old tasks
- Junior hand-writes work an agent does in minutes
- Visibly makework, which juniors detect immediately
- Trains a skill with a declining market
- Feedback loop runs once per ticket, slowly
- Senior time spent reviewing output nobody needed
Preserving the loop
- Junior judges, verifies and rejects agent output
- Real work with real consequences, on the critical path
- Trains the skill that is becoming scarce
- Loop runs many times a day
- Senior time spent on the junior's judgement, not their typing
Put them on the verification side
The work that is genuinely scarce now is judging whether produced work is correct, safe and appropriate. That is where the constraint sits, it is unambiguously real work, and it is the fastest available way to build the model of a system that used to take three years.
A junior who spends six months reading agent-authored changes against stated criteria, in one subsystem, with a senior checking their conclusions, learns that subsystem faster than a junior who spent six months writing small features in it. They see more of it, they see it from more angles, and every judgement they make gets corrected within a day rather than within a sprint.
This is genuinely counterintuitive, because review has always been positioned as the senior activity and generation as the junior one. That ordering existed because generation was the bottleneck and you put your cheapest labour on the bottleneck. Once verification became the constraint, the ordering became wrong, and nobody sent a memo.
The version that works is not “juniors approve pull requests”. It is graduated authority, with an explicit scope that widens as their judgement proves out.
The part that costs money, said plainly
None of this is free, and pretending otherwise is how these programmes die in month five.
A junior on the verification path consumes senior attention: someone has to compare their judgement against a correct one, often enough for the correction to be useful. That is a real reduction in senior throughput, at exactly the moment when senior judgement is the constraint on delivery. You are spending your scarcest resource on people who will not repay it for two years.
That is the whole problem, and it is why this will not happen by accident. Every individual quarter, the rational move is to skip it. The cost is immediate and local, the benefit is delayed and partly captured by whoever employs that person in 2029.
Which is the definition of a collective action problem, and collective action problems are not solved by everyone independently recognising them. They are solved by someone deciding to absorb the cost, or by the market repricing until absorbing it is obviously correct.
There is a counter-signal worth watching here, and it is not nothing. While startups have cut junior hiring hard, some large enterprises have gone the other way and increased it. Read that as a bet: organisations with long time horizons and internal labour markets can capture enough of the return to justify the spend. If they are right, the arbitrage is substantial, because they will be hiring from a cohort nobody else trained.
What a senior needs that this still does not teach
I want to be careful not to oversell the design, because there is a gap in it.
Verification teaches you what correct looks like in a system that exists. It does not teach you to build a system that does not exist yet: to choose between three architectures with incomplete information, to decide what to leave out, to hold a design in your head over months. That is a generative skill and the verification path does not exercise it.
The honest answer is that this needs its own deliberate provision, and the only thing I have seen work is giving people ownership of something small and genuinely theirs, early, with the authority to make bad decisions in it and the obligation to live with them. Small internal tools, one contained service, something with real users and low blast radius. It is inefficient. It is also the only mechanism I know for producing judgement about design, and it was another thing the old system provided by accident, through the simple fact that small projects were sometimes handed to whoever was free.
Where this breaks down
Putting juniors on verification puts inexperienced judgement on the critical path. The whole argument for verification as training is that it is real work with consequences, and consequences are exactly what a junior’s judgement is not yet ready for. Graduated authority mitigates this, but the first six months are genuinely a period where you have added risk to your review process in exchange for a return in 2029.
Trust in AI output is falling, and that changes the calculus. The Stack Overflow 2025 survey put developer trust in AI output down from around forty percent to twenty-nine percent. If that trend continues and organisations pull back toward human-written code, a cohort trained primarily to verify rather than to build may be badly positioned. I am designing for a future I am reasonably but not overwhelmingly confident in.
The economics may simply not work at small scale. For a thirty-person company, the honest answer might be that training juniors is somebody else’s job and hiring seniors is the correct strategy. That is a defensible position, it is what most of the market has concluded, and my argument is really addressed to organisations large enough to internalise some of the return.
“Verification is the scarce skill” could be a temporary state. If tooling gets substantially better at verifying agent output, the constraint moves again, and a training programme built entirely around human judgement of diffs will have trained for the previous bottleneck. That is the same mistake as training juniors to hand-write small features, one iteration later.
And I have a commercial interest here. We sell tooling in the verification layer, so an argument that verification is where the value and the learning both sit is an argument that suits us. Discount accordingly. The graduated authority ladder is a management practice, costs nothing, and needs no product.
The takeaway
The apprenticeship was a byproduct of expensive work, not a designed programme, and the work got cheap. Byproducts do not return when the process that produced them stops. If you want seniors in five years, someone has to decide to pay for them now, in the currency that actually matters, which is senior attention.
The path that works puts juniors on the verification side with graduated authority, gets them to real ownership and a pager as fast as is responsible, and separately provides something small they can design badly and live with.
If you take one thing into next week: work out who in your organisation is currently accountable for producing your 2031 senior engineers. If the answer is nobody, that is not an oversight, it is the default, and the default is what everyone else is also doing.