The story going around is simple and mostly wrong. AI can write code now, the story goes, so the junior developer is finished. There is a number people point to: entry-level engineering postings are down roughly forty percent from their peak, and a widely-cited Harvard study found that when a company adopts generative AI, its junior headcount falls around nine to ten percent within six quarters while senior headcount barely moves. The conclusion writes itself. The bottom rung is being sawn off.
The numbers are real. The conclusion drawn from them is not. A shrinking number of job postings tells you a job is being bought less. It does not tell you a person is worth less, and it certainly does not tell you which job stopped being bought. When you look at that second question closely, the panic reorganises into something more precise, and more useful to anyone actually running a team.
AI did not replace the junior engineer. It replaced the part of the junior engineer's day that was already the least valuable: turning an unambiguous specification into syntactically correct code. That was never the hard part. It was just the visible part.
The job that actually died
For twenty years the entry-level engineering job had a stable shape. A senior broke a problem into tickets small and clear enough that a junior could implement them without needing to hold the whole system in their head. "Add this field to that endpoint." "Wire this button to that handler." The junior's job was to take a well-defined spec and produce working code, and in doing so, slowly, to absorb how the system fit together.
That specific transaction, clear spec in, working code out, is exactly what a coding agent now does in minutes for a few cents. It is the single most automatable slice of the entire profession, because it was the slice we had already spent two decades making automatable: we wrote the tickets to be unambiguous precisely so a less experienced person could execute them without judgement. We optimised that job into a form a machine could eat, and then acted surprised when a machine ate it.
The market data agrees, if you read past the headline. The roles collapsing are the ones that centred on implementing well-defined specifications. The roles growing are the ones that require judgement and oversight: security postings up around a hundred and twenty percent year over year, AI and ML roles up nearly ninety. The market is not shrinking. It is recomposing, away from execution and toward judgement, and it is doing it fast enough to look like collapse if you only count the jobs that are leaving.
The numbers, and what they hide
It is worth sitting with the figures, because they cut in two directions at once.
The first number is the one that scares people. The third is the one that explains it. If half of committed code is now machine-assisted, the constraint on a team is no longer how much code it can produce; it is how much of that code someone can responsibly vouch for. We made this argument from the inside in our piece on what an AI-native team actually looks like: generation got cheap, and verification became the job. A market that suddenly needs far more verification and far less raw production will, of course, stop advertising for raw producers. That is not the end of the entry level. It is a demand shock in the middle of it.
What the numbers hide is the timing problem underneath. The judgement the market now wants was, until very recently, built by doing the exact job the market has stopped offering. You learned to spot a plausible-but-wrong design by writing a few hundred plausible-but-wrong designs yourself and feeling them break. Remove the rung where that happened and the judgement does not appear somewhere else. It just does not get built.
The seed-corn problem
This is the part almost nobody selling the efficiency story wants to discuss, and it is the part that will actually bite. Every senior engineer alive was once a junior who did a great deal of unglamorous, automatable work, and got their judgement as a byproduct of it. The first seventy percent of the work was never the point. The point was the engineer that doing it produced.
A company that stops hiring juniors because a model is cheaper at the visible task is making a decision that looks free this year and is enormously expensive in five. It is eating its seed corn. The pipeline that turns a graduate into the senior who can catch a confident, subtly wrong diff is not a market you can buy from on demand; it is a thing you grow, slowly, and only if you are willing to pay for the slow years. When every company defers that cost at once, the industry quietly stops manufacturing the one role everyone agrees is now the most valuable.
You cannot buy a senior engineer who was never allowed to be a junior. If the whole industry stops training the entry level, it is collectively short-selling the exact skill it is bidding up.
The enterprises that depend on long-lived systems, finance, healthcare, infrastructure, have quietly worked this out and kept hiring juniors, because they know their future seniors have to come from somewhere. The teams most at risk are the ones young enough and cost-pressured enough to treat the training pipeline as a line item they can cut this quarter. It is the same short-horizon mistake we catalogued in the three decisions that kill technically sound startups: optimising a number that is easy to measure at the expense of one that is not.
How we still train a junior
We are a small studio, and we still bring people in early. But the shape of that first year changed, because the old shape, hand you narrow tickets until you osmose the system, no longer works when the narrow tickets are the first thing we hand to a machine. Here is what we do instead.
We start them on review, not production, but backwards from how it sounds. A junior's first serious work is reading generated diffs against a spec and finding what is wrong with them. This is the actual job now, and it turns out to be a faster teacher than writing the code was, because a junior sees ten approaches a day instead of writing one. The catch is that you cannot judge code you could not have written, so we pair every review block with the second thing.
We make them build things the slow way, on purpose. Regularly, and without the agent, a junior implements something end to end by hand, not because it is efficient, it is not, but because the judgement that makes the review valuable was only ever built by once doing the thing yourself and feeling it break. We treat this as training cost, the way a gym treats lifting heavy as the point rather than an inefficiency. It is the deliberate counterweight to the vibe-coding reflex of letting the model carry everything.
We give them ownership of something small but real. Not a ticket, a surface: a feature, an endpoint, a corner of the product they are accountable for when it breaks at 2am. Accountability is the thing that converts activity into judgement, and it is the one input a model cannot supply, because a model is never on the hook. The junior who has been paged is a different engineer three months later than the one who has only ever closed tickets.
What we hire for now
The interview changed to match. We used to ask, in effect, "can you build this." That question is nearly free to answer now, so it tells us almost nothing. The question we ask instead is closer to: here is a confident, plausible, fluent piece of work with something quietly wrong buried in it, will you catch it, and can you say precisely why.
That reframing is kinder to the right juniors than the old one was, not crueller. It stops rewarding the narrow speed-of-typing that the model just commoditised, and starts rewarding the thing that was always the actual job: taste, skepticism, the instinct that something reads correct but is not. Plenty of graduates have that instinct on arrival and were never asked for it. A market obsessed with implementation speed was, it turns out, screening for the wrong trait all along, and the same forces we described for the small business adopting these tools apply to the small team hiring for them: the scarce input was never production, it was judgement.
The bet
So the honest picture is not the one on either side of the panic. The junior developer is not obsolete, and the "AI changes nothing" reassurance is just as wrong. What happened is narrower and more consequential than either: one specific job, spec-to-code, stopped being scarce, and it happened to be the rung the whole profession used to climb from. The role did not vanish. Its entrance moved, and a lot of companies have not noticed the door is somewhere new.
Our bet, and it is a bet, is that the teams which keep training juniors through this awkward window will own the next decade, because they will have the one thing the market is already pricing as scarce and will price higher still: people who can look at a confident machine and know, precisely, when it is wrong. Everyone can generate now. Almost nobody is still manufacturing the judgement to check the generation. We would rather be short on output this year than short on seniors in five. If you want the other half of this argument, how the day-to-day of a team actually reorganises around that scarcity, it is in our piece on the AI-native small team.