The Case for Still Hiring Juniors When AI Does Junior Work

What the entry-level data actually says

That entry-level hiring in AI-exposed work has contracted, and that nobody has shown AI caused it. Using ADP payroll records covering a monthly panel of 3.5 to 5 million employees from January 2021 through June 2026, Brynjolfsson, Chandar and Chen find employment of 22 to 25 year olds in AI-exposed occupations sitting 19% below where it would be had it kept pace with less-exposed peers, with no comparable gap for experienced workers ¹.

Four details change how that number should be used, and all four come from the same paper. The authors call these descriptive indicators and say explicitly they are not causal estimates of AI. The 19% is a kept-pace shortfall against less-exposed occupations rather than a 19% fall in young workers' jobs; in levels, employment of 22 to 25 year olds in the two most exposed quintiles fell about 11% between November 2022 and June 2026 while the same age group in the three least-exposed quintiles grew about 10%. The gap opens through reduced hiring, not through people being let go. And the declines concentrate where AI substitutes for human tasks, with employment flat or rising where it complements them ¹.

So the strongest available evidence describes a market, not a business case. It says other employers slowed down. It does not say they were right, it does not price your role, and it certainly does not say what a team looks like in three years if the class is cut to zero.

That gap matters because the decision in the room is a forecast, and the data on the table is a rear-view measurement of other people's forecasts.

Why AI gains land hardest on the least experienced

Because the measured productivity gains concentrate in less experienced workers, which is the part of the argument most often dropped. Access to a generative AI assistant raised issues resolved per hour by 14% on average across 5,179 customer support agents at one software firm, a 34% improvement for novice and low-skilled agents and almost nothing for the experienced ones ².

The developer evidence points the same way. Pooling three company-run randomized trials at Microsoft, Accenture and an anonymous Fortune 100 firm across 4,867 developers, access to an AI coding assistant raised completed tasks by 26.08%, and less experienced developers both adopted it more and gained more ³. The standard error is 10.3%, so the interval around that headline is wide, and the outcome is weekly completed pull requests: a volume measure that says nothing about defect rates or about who ends up reviewing the extra work.

This cuts in two directions at once, which is why both slogans can quote it. A junior with an assistant closes more of the gap to a mid-level than a junior without one, so the marginal output case for hiring them is stronger than it was. And the tasks that used to be a junior's first year of learning are exactly the tasks the assistant handles, so the learning case is weaker than it was.

Both are true. The decision turns on which of the two applies to the specific tasks in front of you, which is a question about the work and not about the labor market.

Test each entry-level task for a verification ladder

Take the tasks that made up the entry-level role and ask, for each one, whether a person doing it produces something another person reads and grades. That is the ladder. A task with a reader is how somebody learns what good looks like. A task whose output nobody opens teaches nothing, regardless of who or what produced it.

Sort every task into three piles:

• Keep. The output is read by a named person against a known standard, and being wrong is visible. First-draft analysis that a senior marks up, tickets that go through review, reconciliations that either balance or do not.
• Automate. The output is mechanical, correct-or-incorrect, and nobody learns anything from doing it by hand. Formatting, extraction, routine lookup.
• Kill. The output existed because somebody had to produce it and nobody reads it. These were never training either; they were just cheap when a person was cheap.

If the keep pile is thin, the honest conclusion is not that juniors are obsolete. It is that the role was already a bad training post and AI made that visible. Rebuild the role around the keep pile before deciding whether to fill it, and be direct with candidates about what the first year now consists of, because a cohort that learned the craft alongside a model needs scaffolding built for how they already work (new grads who never learned to work without AI).

Where to keep hiring, and where to stop

Keep hiring into work that produces reviewable artifacts against a known answer, and stop hiring into work whose only remaining output is a draft nobody opens. Everything else is a judgment call about how fast the remaining tasks are moving, and the honest way to make it is one req at a time with a stated review date, never a policy announced for the year.

Price the three-year version explicitly, because the one-year version always favours cutting. Three inputs are enough. What the junior costs while unproductive, which is a real number your finance team already has. What a mid-level hire costs in three years in a market where a lot of employers stopped growing them. And what the senior time spent teaching would otherwise have produced, which is the input most planning models leave out and the one most likely to be the largest.

The shape of the entry-level commitment is a separate decision from whether to make one. An apprenticeship, a fixed internship and a rotational programme each answer a different problem, and picking the wrong one is how a defensible decision produces an indefensible year (apprenticeship, internship or rotation).

One last discipline. Whichever way this goes, write down what the role produces that a person is accountable for, because a req approved on a vague scope gets re-argued as a tooling question within six months: decide whether the work needs a person or a model.

See the benchmarks >