Somebody decided what a graduate does all day. A model has since overruled most of it, and nobody updated the document.
That is the actual sequence, and it runs in the opposite direction to the debate about it. A job posting for an entry-level analyst now requires stakeholder management and strategic judgment. PwC's 2026 Global AI Jobs Barometer, which analysed more than a billion job advertisements across 27 countries, found that entry-level roles in the most AI-exposed occupations are seven times more likely to demand traditionally senior skills that used to appear later in a worker's career (PwC, June 2026).
Read that finding the way a hiring manager would and it looks like the bar went up. Read it the way a delivery leader should and it says something narrower and more useful: the job description was rewritten because the work inside the job was rewritten first, and almost nobody did the rewriting on purpose.
Most of the conversation about AI and early-career talent is a conversation about headcount. Hire fewer graduates. Hire the same number and hope. Hire seniors instead and skip the problem. All three answers assume the junior role still contains the work it contained in 2023, and it does not. The research, the first drafts, the test scaffolding, the summarization, the data cleanup - the tasks that used to fill a graduate's first six months now come back from a model in minutes. Call it what it is: an empty work package, still being staffed as though it were full.
So the headcount question is premature. Decide what junior work is made of now, and the hiring number falls out of that decision rather than driving it. Get the order backwards and you are budgeting for a role you have not defined, and paying for the mistake in 2030 rather than this quarter.
Key takeaways
- AI absorbed the repeatable portion of junior work, not the role. What changed is task composition, and most organizations updated their tooling and their hiring plan without rewriting the work in between.
- Those absorbed tasks were the apprenticeship mechanism, not overhead. Removing them removes the feedback loop that built judgment.
- Entry-level job descriptions have been promoted. PwC calls it seniorization, and the openings for those redrawn roles grew 35% since 2019 while traditional entry-level openings fell 10%.
- The binding constraint on the new model is senior review time, not junior headcount. Almost nobody budgets for it, and that is how the redesign fails.
- Redesign the work first. The hiring number is an output of that decision, not an input to it.
What AI actually took off the junior's desk
The absorbed work is specific, and naming it is what turns this from a mood into a decision.
McKinsey's work on early-career talent in the agentic organization names the absorbed set precisely: research, documentation, data cleanup, basic coding, drafting, and preliminary analysis (McKinsey, May 2026). Add test generation and meeting summarization and you have close to a complete inventory of what a first-year hire in a delivery organization used to do.
Look at what those tasks have in common. Every one of them is repeatable, verifiable against a clear standard, and low-context. Those are the properties that make work delegable to a junior, and they are the properties that make work delegable to a model. The overlap is not a coincidence. It is the same overlap, discovered twice.
What follows is a composition change rather than a volume change . The role still exists. Requisitions still open. But the container now holds different work, and in most organizations nobody specified what. The tooling arrived through individual adoption, the hiring plan got revised in a budget cycle, and the thing in between - the actual definition of what a junior does all day - was never touched.
That gap is where the damage accumulates. A graduate arrives in week one with a work package written for a world where their value was throughput on well-specified tasks. The model already did those. So the junior gets handed either work they are not ready for or work that no longer teaches them anything, and both outcomes get read as a problem with the graduate.
Which raises the question the emptied package makes unavoidable. If those tasks are gone, what exactly were they doing for you?
Those tasks were the apprenticeship, not the overhead
They were the training budget. The line item nobody ever wrote down, funded by work that looked like the cheapest output in the building.
Nobody assigned a junior developer a naive implementation because the organization desperately needed a naive implementation. They assigned it because writing the slow version, watching it fall over at a hundred thousand rows, and working out why is how a person learns something about complexity that no textbook makes stick. The artefact was disposable. The loop was the point.
Loadsys put this well in June 2026: the turmoil was never the teacher, the feedback loop was. Decide, watch the decision meet reality, understand the failure, adjust. Repetition, supervised practice, error correction, and steadily increasing exposure to ambiguity are the mechanism by which judgment forms. Strip out the tasks and the loop goes with them.
This is why the popular prescription - make juniors hand-write code so they earn it the hard way - gets the diagnosis right and the cure wrong. It mistakes the pain for the lesson. Hand-writing code was the delivery mechanism for the feedback loop, not the source of the learning. Reinstating the mechanism without the loop just makes the work slower.
Compare the two versions concretely. In the old loop, a graduate wrote a query, shipped it, watched it time out in production, and traced the cause back to a missing index. Three days, one permanent lesson. In the new default, the same graduate describes the query, accepts a generated version that compiles and returns plausible rows, and ships it. Four minutes, no lesson, and a defect that surfaces later in someone else's sprint.
The organization got faster. The person did not get better. Run that pattern for two years and you have a team of people who can produce anything and evaluate nothing.
The entry-level job got promoted without telling anyone
The job description moved up the skills ladder. The ladder itself was never extended downward, and the numbers on that are firmer than most of the commentary around them.
PwC's 2026 Barometer is the clearest read. In the most AI-exposed occupations, 52% of the new skill requirements appearing in entry-level job postings were skills traditionally associated with experienced workers. In the least AI-exposed occupations, that figure was 7%. Job openings for these redrawn roles grew 35% since 2019, while traditional entry-level openings shrank 10% over the same period (PwC, June 2026). PwC's name for the effect is seniorization.
The labour-market backdrop fits. Unemployment among recent US college graduates sat at roughly 5.7% in the first quarter of 2026, with about four in ten underemployed (Federal Reserve Bank of New York, May 2026). Stanford's Digital Economy Lab found that workers aged 22 to 25 in the most AI-exposed occupations experienced a 16% relative decline in employment even after controlling for firm-level shocks (Brynjolfsson, Chandar and Chen, November 2025).
Now the part most articles leave out. How much of this is AI is contested. Economists at the New York Fed attribute much of the rise in young-graduate unemployment to remote work, which makes novices harder to train at a distance. Yale's Budget Lab finds no clear economy-wide AI fingerprint yet, while flagging the divergence between younger and older graduates as consistent with early-career effects (both June 2026).
That disagreement does not weaken the case for redesigning the work. It strengthens it. Whether the apprenticeship channel is eroding because of algorithms or because of distance, the implication for an employer is identical: the informal mechanisms that used to turn novices into practitioners can no longer be assumed to run on their own. If they are going to run, someone has to design them.
The judgment gap is the real risk, and it is measurable
The people leaning hardest on AI are the ones least equipped to catch it being wrong, and both halves of that sentence have numbers attached.
The 2025 Stack Overflow Developer Survey, covering more than 49,000 developers, found that 84% of developers use or plan to use AI tools, and that early-career developers lead daily use at 55.5%. Hold that next to the same survey's biggest complaint: 66% of developers say their top problem is code that is almost right but not quite, and 45% report that debugging AI-generated code costs more time than it saves. Trust in AI accuracy falls as experience rises. The most senior developers in the sample are the most sceptical.
The BairesDev Dev Barometer, a survey of 1,569 developers across 77 countries published in June 2026, found the same gap from the other side. 85% of junior developers say AI tools have improved their understanding of software development. Only 16% of senior developers believe juniors fully understand the AI-generated code they submit.
That failure mode is the most dangerous kind, because almost-right code compiles. It looks finished. It passes a quick glance. The only thing between almost-right and a production incident is a person who has met this failure mode before and knows where to look.
That person, by definition, is not the junior. So this is a work-design problem, and the design has to be written down. A course will not close it.
What goes in the new junior work package
Almost every source agrees juniors should review, validate, and direct AI output. Almost none of them say what that contains on a Monday morning. Here it is, as six items you can put in a work-package template and grade.
| What the task used to be | What replaces it | What the junior learns |
|---|---|---|
| Write the first implementation | Write the spec before the agent generates anything | Precision about requirements, and where ambiguity hides |
| Discover bugs by shipping | Predict failure modes in writing, then run and compare | Calibration - the difference between a guess and a judgment |
| Produce output for senior review | Review agent output against named criteria as a graded deliverable | What "wrong" looks like before it is obvious |
| Handle the straightforward cases | Own exception handling and the almost-right cases | Where the standard pattern stops applying |
| Complete one task at a time | Orchestrate multi-step work and verify each handoff | How failures propagate across a system |
| Explain the code they wrote | Trace and explain a generated artefact end to end, out loud | Whether their understanding is real or borrowed |
Three of those carry most of the learning.
Spec before generation. The junior writes what the output must do, what it must not do, and how it will be checked, before an agent produces anything. This single change restores the decision that AI otherwise makes invisible.
Predicted failure modes. Before running the generated artefact, the junior writes down where they expect it to break. Then they run it. The delta between prediction and reality is the feedback loop, rebuilt inside a workflow that takes minutes instead of days.
Review as a graded deliverable. Reviewing AI output is treated as a skill with a standard, not a formality. A junior who approves an almost-right artefact has produced a defect, and it is discussed as one.
Everything in that table is achievable inside normal delivery work . None of it requires a separate training programme, which matters, because a separate programme is the thing that gets cut when the quarter tightens.
There is a catch in this design, and it is the reason most versions of it quietly fail.
Somebody has to review the reviewer
Senior review time is the binding resource, not junior headcount. The junior reviews the agent. Someone reviews the junior. That someone is the most expensive person on the team and the one whose throughput the delivery plan already depends on .
Two Microsoft engineering leaders, Mark Russinovich and Scott Hanselman, described the dynamic in Communications of the ACM in April 2026: agentic coding assistants give senior engineers an AI boost that multiplies their throughput, while imposing an AI drag on early-career developers who lack the judgment to steer and verify output. The incentive that falls out of that - hire seniors, automate juniors - dismantles the bottom of the pyramid every senior role depends on. Their prescription is unusually candid. Keep hiring early-career people, accept that they initially reduce capacity, and make their growth an explicit organizational goal.
Accept that they initially reduce capacity. That sentence is the whole planning problem. A junior on a review-first package is a net capacity cost for a period measured in months, not weeks, and the cost lands on your senior engineers rather than showing up as a line item. When it is unbudgeted, one of two things happens. Either review becomes a rubber stamp, which reproduces the judgment gap at speed, or seniors absorb the load invisibly until delivery slips and the graduate programme gets blamed.
The practical move is to make the load explicit and small. Cap how many review-first juniors a single senior supervises at once, and treat that number as a real capacity commitment in the plan rather than a goodwill activity. Ratios that work in practice tend to be tighter than people expect in the first quarter and loosen as the junior's prediction accuracy improves. Treat any specific number as a hypothesis to measure in your own organization.
Some of the review burden can be moved off senior humans. Automated checks, structured review templates, and agent-assisted first-pass review all reduce what a senior has to read personally without removing their judgment from the decision. That is a design choice worth making deliberately, because it is the difference between a model that scales and one that consumes your most senior capacity.
If working out where AI is already absorbing work in your delivery organization is the blocker, that is exactly what an AI Readiness Snapshot is for. It is a free 30-minute call that maps which of your junior work packages have already emptied out and what the supervision load looks like once you refill them.
How to tell it is working
Output volume stopped being a useful signal the moment a model could produce output. Five things replace it, and all five are observable inside a sprint.
- Spec quality before generation. Does the junior's written spec anticipate the constraints a senior would have named? This improves fast and is easy to review.
- Prediction hit rate. How often do their predicted failure modes match what actually breaks? A rising hit rate is the clearest evidence that judgment is developing.
- Defects caught in review versus escaped. Track where problems are found. Movement from production to review is the outcome the whole model exists to produce.
- Escalation distance. How far into a problem does the junior get before escalating? Too early wastes senior time. Too late produces incidents. The healthy range narrows with experience.
- Unassisted explanation. Can they walk through a generated artefact and explain each decision without the model open? This is the check that separates real understanding from borrowed fluency.
The hiring side is shifting in the same direction. In the BairesDev survey, only 5% of junior developers said the ability to write code from scratch was critical to getting hired, while 70% of senior developers ranked real-world project experience as the strongest indicator of readiness and 72% named critical thinking as foundational for the next three years. McKinsey has reportedly moved to assessing how candidates use AI - how they prompt it, challenge it, and refine its output - rather than whether they avoided it.
None of these measures require new tooling. They require deciding in advance what improvement looks like, which is the part that usually gets skipped.
The cost of waiting, dated
The cost of doing nothing here is deferred and compounding, which is what makes it easy to postpone and expensive to have postponed.
Writing in The National in April 2026, José Parra Moyano set out the mechanism: AI-driven cuts to entry-level roles risk hollowing out the management pipeline, creating bottlenecks in middle management and eroding competitiveness over years rather than quarters. Short-term savings from reduced junior hiring do not price in weaker judgment development or the higher future wages commanded by scarce experienced talent.
Nacho De Marco of BairesDev framed the same point as a question worth putting to your own leadership team: where are the senior engineers, architects, and technical leaders of 2030 and 2035 going to come from? The seniors of the future are the juniors of today. A hiring freeze at the point of entry does not show up in delivery metrics for years, and by the time it does, the option to have trained those people has expired.
The consulting sector has read this earlier than most, and that matters precisely because those firms are the ones whose model most depends on a graduate pyramid. Deloitte's early-career research documents both the enthusiasm and the anxiety among workers with under five years of experience, and its internal academies have been rebuilt around AI capability. Bloomberg reported in April 2026 that the major strategy firms have changed how they assess entry-level candidates. These are organizations acting on a pipeline risk before it appears in their numbers.
The asymmetry is what makes this a decision rather than a debate. Redesigning junior work while you still have juniors is cheap and reversible. Rebuilding a talent pipeline after a three-year gap in it is neither.
Where to start
Redesign the work, then decide the headcount. That is the whole argument, and the order matters more than any specific number.
Three things worth doing in the next two weeks:
- Audit one junior work package. Take an actual onboarding plan or work description and mark every task a model now does faster than a graduate. The proportion is usually higher than expected, and the exercise makes the problem concrete for people who have been discussing it abstractly.
- Cost the senior review time. Pick one senior engineer and estimate the hours a review-first junior would take from them per week. Put that number in the delivery plan rather than in someone's goodwill.
- Run one team on the new package. Spec before generation, predicted failure modes, graded review. One team, one quarter, and measure prediction hit rate. That is enough to know whether the model works in your organization before you commit a whole intake to it.
