If AI does the junior work, how do we develop tomorrow’s seniors?

AI can generate an implementation, explain unfamiliar code and suggest a fix. For someone starting a career in software development, that creates opportunities.

For employers, it also raises an uncomfortable question.

If an experienced developer with AI can handle work previously assigned to a junior, will companies still hire people at the beginning of their careers? And what value can those people bring while they are learning?

At HumanInTech, we believe there is a strong case for continuing to hire and develop juniors. But that case needs to be practical. Companies need people who contribute today, alongside building the expertise they will need tomorrow.

Recent research helps explain both the opportunity and the risk.

Producing more software, understanding that software and developing professional judgment are different outcomes. We need to make room for all three.

The pressure on entry-level employment deserves attention

Stanford researchers analysed US payroll data through June 2026. They reported that employment among workers aged 22–25 in AI-exposed occupations stood 19% below the level implied by keeping pace with less-exposed peers. The divergence operated mainly through reduced hiring.

The authors describe this as observational evidence, not a causal estimate. They also found no widespread, economy-wide displacement. These are US findings across occupations, not a measurement of Belgian junior developer hiring. Source: Stanford Digital Economy Lab, revised August 2026.

The employment graph reconstructs the reported comparison as an index: 100 for the comparison benchmark and 81 for the reported relative employment level. It does not show that 19% of junior developers lost their jobs.

For employers, this raises a question beyond redundancies: what happens when the first opportunity never opens?

A company might retain its experienced developers while deciding against its next junior vacancy. That choice may be understandable within a particular budget. Repeated across organisations, it could narrow the route through which people enter the profession.

We cannot promise that junior hiring will remain unchanged. We can decide whether our own organisations offer a meaningful path into the work.

AI can also make less experienced developers more productive

There is evidence for opportunity as well.

Three randomised field experiments involving 4,867 developers at Microsoft, Accenture and a Fortune 100 company found an estimated 26.08% increase in completed tasks with an AI coding assistant. Less experienced developers showed higher adoption and greater productivity gains. The pooled estimate had substantial uncertainty, shown in the graph. Source: Cui and colleagues, June 2025.

Completed tasks measure output. They do not establish equivalent gains in learning, reliability or commercial value.

The implication for hiring is worth considering. Employers can use AI to help a junior become useful sooner, with appropriate supervision.

That does not establish a universal return on hiring juniors. It does challenge the assumption that AI’s productivity benefits belong exclusively to experienced developers.

The practical question becomes: which useful responsibilities can a junior handle with these tools and the right support?

What value can a junior bring today?

A credible answer needs to go beyond enthusiasm, fresh perspectives or a lower salary. A junior can contribute through concrete work whose scope matches their developing ability.

• Investigating problems: reproduce an intermittent failure and document the conditions that trigger it, giving the team actionable evidence.
• Delivering bounded improvements: improve validation, accessibility or error handling with review, resolving real user problems.
• Verifying behaviour: turn a customer-reported defect into a regression test to help prevent the same failure returning.
• Clarifying knowledge: test onboarding instructions and document missing steps, making the team less dependent on informal explanations.
• Following up with users: check whether a delivered change addresses the original difficulty, connecting technical delivery to its intended outcome.
• Building domain understanding: learn the rules and exceptions behind a business workflow, developing the ability to make increasingly informed decisions.

These are examples of how we would structure work, rather than findings measured by the studies.

Consider a customer who reports that an order sometimes disappears from a screen. A junior can investigate which users are affected, reproduce the sequence and determine whether the information is missing, delayed or displayed incorrectly.

A senior may need to help interpret the evidence or choose the fix. But the investigation itself moves the work forward. The learning happens through useful contribution.

Faster completion does not guarantee deeper understanding

A separate experiment illustrates why output alone is an incomplete measure.

Researchers recruited 52 mostly junior engineers to work with an unfamiliar Python library. The AI-assisted group averaged 50% on an immediate comprehension quiz, compared with 67% without AI: a difference of 17 percentage points. The time advantage was not statistically significant.

This was a small, short-term experiment. It does not establish long-term skill loss. Exploratory analysis associated explanation-seeking and conceptual questions with stronger learning, but did not prove those behaviours caused it. Source: Shen and Tamkin, January 2026.

This experiment studied learning a new library. It should not be directly compared with the workplace productivity experiment as if both measured the same outcome.

Our interpretation is that companies should assess understanding alongside delivery. A completed ticket does not tell us whether its author can explain the solution or investigate its failure.

Juniors still need to learn programming

AI does not remove the need to understand control flow, data, permissions, concurrency, testing and failure handling.

Imagine an assistant generates code that retries a payment request after a timeout.

The code compiles. The happy-path test passes. But the payment provider might have processed the transaction before the connection failed. Retrying could charge the customer twice.

To recognise that danger, a developer needs to reason about uncertainty: what happened remotely, what the local application knows and which actions are safe to repeat.

Typing every line personally is not a prerequisite for that understanding. Practising reasoning about code is.

That practice should sometimes include working without AI. Can the junior trace execution, explain a failure or implement a small piece of logic independently?

It should also include working with AI. Can they question its suggestion, identify an untested assumption and verify the result? Both exercises reveal something useful.

Shared code review can connect delivery and learning

Reviewing code together with a senior is a practical way to develop judgment.

The senior can make their reasoning visible:

• What attracted their attention?
• Which assumption might fail?
• What would the consequences be?
• What evidence would make them comfortable accepting the change?

The junior should participate before receiving the answer.

For the payment example, the senior might ask: “If the request times out, do we know whether the payment happened?”

Let the junior follow that question through the system. Then ask them to reproduce the dangerous situation in a test and investigate a solution.

The result is a reviewed change, a concrete demonstration of the risk and a principle they can apply elsewhere.

Review alone is not enough

There is a limitation to learning through explanations: recognising a problem after someone identifies it is easier than finding it yourself.

Juniors need opportunities to form hypotheses, make decisions and discover where their reasoning breaks down.

A small feature can provide that experience from beginning to end. With support, a junior can clarify the requirement, propose an approach, implement it, respond to review and follow its behaviour after deployment.

The responsibility should grow as their competence grows.

We should also avoid assigning juniors endless verification work while reserving every design decision and interesting investigation for seniors. That may help clear today’s backlog, but it offers a narrow path towards independence.

Mentoring needs a business case—and time

Employers are entitled to ask what this approach costs.

A junior needs feedback. Reviews take time. Some tasks require rework. AI does not make those costs disappear.

The useful comparison is the contribution of the whole team over time: delivered improvements, mentoring effort, defects, growing independence and knowledge shared across people.

A practical approach could include:

• A named mentor with protected time.
• An initial set of useful tasks with manageable consequences.
• Shared reviews that examine reasoning as well as correctness.
• Regular opportunities to debug and explain code independently.
• Gradually broader responsibility as understanding improves.

Progress should become visible. Is the junior identifying risks earlier? Do they need less help with familiar work? Can they explain what they tested and what remains uncertain? Are they becoming dependable in part of the application?

There is no universal timetable. There should be an intentional progression.

If everyone hires only seniors, where does experience come from?

An organisation may reasonably need an experienced hire for a demanding project. It may also lack mentoring capacity at a particular moment.

But a lasting strategy of hiring only experienced people depends on other employers continuing to develop them.

Seniority grows through opportunities to make decisions, encounter consequences and receive feedback. Removing those opportunities while expecting an unlimited supply of experienced engineers is a fragile assumption.

Developing juniors also gives a company the chance to build product knowledge and distribute responsibility within its own team. Retention is never guaranteed, but recruiting experienced people carries uncertainty too.

The decision should account for both immediate delivery needs and the capabilities the organisation wants to have in several years.

The opportunity is to improve how we develop people

At HumanInTech, we believe companies should embrace AI while being deliberate about how developers learn.

Juniors can bring value through implementation, investigation, verification and an increasing understanding of the business. Experienced colleagues can help that contribution grow by explaining their judgment and creating opportunities to practise it.

The research gives us reasons to take both productivity and learning seriously. Our responsibility is to translate that into the way we organise work.

If we want tomorrow’s seniors to exercise sound judgment, we need to give today’s juniors opportunities to develop it.