The Bench Doesn't Fill Itself

That missing line matters if the plan still assumes you’ll need more experienced engineers later. Remove the place they’ll learn without replacing it and you’ve taken a loan against that capacity. Someone else will have to fund the learning, or you’ll have to rebuild it.

Shipping and Learning Can Part Company

A February 2025 analysis of randomized field experiments pooled results from 4,867 developers at Microsoft, Accenture, and an unnamed Fortune 100 company. Its preferred estimate was roughly 26% more completed tasks, measured as weekly pull requests, among developers using GitHub Copilot. At Microsoft, where the researchers had seniority data, the estimates pointed toward larger gains for junior developers and recent hires. Those subgroup estimates weren’t statistically conclusive.

These were code-completion tools in real workplaces, and the authors describe the individual experiments as noisy. The result gives a serious reason to equip less experienced engineers. It doesn’t tell you whether to remove their roles.

Judy Hanwen Shen and Alex Tamkin’s January 2026 experiment asked what participants understood after they put the tool away. They randomly assigned 52 regular Python users to learn an unfamiliar library, Trio, with or without a GPT-4o chat assistant. On the follow-up quiz, taken without AI, Anthropic reported average scores of 50% for the AI group and 67% for the group without it. The AI group showed no statistically significant improvement in completion time.

That experiment measured immediate comprehension of one library, including debugging and code reading. Participants had prior Python experience; they were learning something new within their trade. It can’t tell us how they would develop over a career, or how newer tools would affect them.

The studies used different tools and tasks. They don’t establish a productivity-for-learning exchange rate. Our inference is narrower: completed code is an inadequate receipt for learning. A staffing plan that counts output alone can miss the difference.

The Senior-Only Plan Has a Supplier

A company can skip junior hiring and recruit experienced engineers when it needs them. That can work for the company. But the experience it buys had to be acquired somewhere, whether in another employer’s paid work or through somebody’s own projects.

The collective risk follows from that dependency. If enough employers reduce the work through which newcomers learn, while still wanting experienced system owners, they become more dependent on a supply they’re doing less to replenish. A successful senior hire solves your vacancy. It leaves open the question of who is developing the next candidate.

Neither study establishes that an industry shortage will follow. Other routes into engineering could expand, or better AI-supported teaching could make a smaller intake sufficient. The risk depends on how much useful experience those alternatives produce, against how much employers still need.

Better automation could also reduce the demand itself. If a system can reliably handle diagnosis and recovery, a company might need fewer people with those skills. The learning experiment can’t rule that future out. The assumption becomes questionable when a plan retains human review and incident response, cuts the route into those responsibilities, and treats faster code generation as proof that everything is covered.

For that plan, the remaining human work is the place to start. Which decisions must an engineer still make? Which failures must they still diagnose? Those responsibilities define the experience the organization needs to develop or buy. Old job titles and ticket counts won’t answer the question.

The next owner may already be on the team, learning an unfamiliar part of the system. That route still needs room for learning and review. A new junior hire is one way to develop capacity; shifting real responsibility to an existing engineer can be another.

Give the Learner Something to Own

Preserving that experience doesn’t require keeping boilerplate busywork. The same skill-formation study found AI users who scored well, including people who asked conceptual questions or requested explanations alongside generated code. Those were small, self-selected behavior groups within the experiment. Their results support trying those approaches, without establishing that a particular prompting style causes better learning.

The practical change is to give the learner responsibility for an explanation that can be tested. Reading an AI-generated patch and accepting its explanation leaves the understanding untested. Ask the engineer to predict its behavior, then show what happens.

For a retry handler, suppose a server records an order but its response never reaches the caller. A timeout tells the caller that no reply arrived. It leaves the order’s status unknown. If each attempt creates a fresh order, retrying creates a duplicate even though the retry code compiles.

Have the learner reproduce that condition in a test system: record the order, drop the reply, then allow the retry to complete. Ask them to predict the stored result before inspecting it.

Move the initial failure to before the order is recorded and ask for a fresh diagnosis without an AI-supplied answer. The caller still sees a timeout, but now a successful retry creates the missing order. You’re looking for someone who can demonstrate this compiles, and it’s wrong, and explain why, rather than somebody who can get another patch generated.

That exercise makes the understanding inspectable. It doesn’t establish that the learner will reach seniority faster. The study didn’t compare AI assistance with human mentoring either, so it can’t settle which teaching approach works best. Normal work can still use AI; the unaided diagnosis checks what the engineer can verify independently.

Expand their responsibility when they can handle unfamiliar cases, with an experienced engineer checking the reasoning as well as the code. The mentor’s time belongs in the same headcount calculation; otherwise the apprenticeship is still unfunded. Name the work that moves off the mentor’s plate to make room for supervision, and who will cover it.

Then compare the whole plan with hiring experience: recruiting costs, learning this system, and who covers the responsibility until the new owner can take it. Training someone can cost more than expected, and the person may leave before taking on the work you funded. An experienced hire can leave too. Use your own costs and keep retention uncertain; neither route comes with a guaranteed return.

A team without safe work to delegate or capacity to supervise it may reasonably pause junior hiring or hire an experienced engineer first. Keeping a junior title on the roster alone buys little. The meaningful commitment is to the work and feedback through which someone can become responsible for more of the system.

The salary saving is recorded when the hire is removed. A later training bill or difficult senior search can land under another leader, disconnected from the choice that created the dependency. Before the line comes off the plan, record where the next system owner is expected to come from. If the answer is better automation, name the human responsibility it must take over. Leave that assumption where the next leader can find it.