Does AI Actually Slow Down Junior Developer Learning?

AI access reduced immediate test performance in one unfamiliar-library experiment. The experiment did not show that delegating reasoning caused the gap: that idea comes from exploratory clusters of two to seven people and remains a hypothesis to test. It is not evidence that every junior who uses AI learns less, nor that the effect lasts for months.

What the study actually found#

Shen and Tamkin’s 2026 preprint randomized 52 people into AI-assisted and no-AI groups. Each learned the unfamiliar Python Trio library by completing two tasks in at most 35 minutes, then took a 14-question, 27-point quiz without AI. The quiz tested conceptual understanding, code reading and debugging immediately after the work.

The primary paper reports a difference of 4.15 points on a 27-point quiz. Expressed against the available score, that is 15.4 percentage points. The authors describe it as a “17% score difference”; later coverage often rounded the group scores to 67% and 50% and called that a 17-point gap. Those phrasings are not interchangeable. The defensible result is the paper’s raw gap, and it was statistically significant (p = 0.01). Task completion time did not improve significantly on average.

This was not, despite some coverage, a study made up mostly of junior engineers. Only four of the 52 participants reported 1–3 years of coding experience; 29 reported seven or more. What made them novices was Trio: everyone had more than a year of Python experience, used Python at least weekly and had never used this library. The result applies most directly to experienced programmers learning an unfamiliar tool, not to junior developers as a class.

The quiz followed the tasks immediately. The experiment did not measure retention months later, performance across a job, or whether a habit changes with sustained use. Even “learning” needs care here: the measured outcome was immediate understanding and test performance after one short new-library exercise.

The useful clue lies in the paper’s exploratory review of tiny behaviour clusters, not in a second randomized comparison. Three high-scoring patterns averaged at least 65% and kept the participant cognitively engaged: asking conceptual questions, asking for code and explanation together, or generating code and then questioning it. Three low-scoring patterns averaged below 40% and handed over code generation or debugging. Each cluster contained only two to seven people, so treat the pattern as a mechanism to test, not a universal threshold.

METR measured a different question#

METR’s 2025 randomized trial involved 16 experienced open-source developers completing 246 real issues in repositories they already knew. With early-2025 AI tools allowed, they took 19% longer. That is a productivity result, not a learning result, in almost the inverse setting: experienced maintainers, familiar codebases, real issues, and elapsed time as the main outcome.

Putting the numbers beside each other does not produce a law that AI slows developers by some blended amount. It produces a better question: what is the task asking the human to acquire? If the answer is “nothing new,” assistance may simply remove work. If the answer is “the mental model needed to diagnose this system next time,” completion and learning are separate outputs. The site’s guide to measuring a factory honestly covers METR’s productivity result in its proper context.

Check what you delegated#

Tool choice is a weak proxy for learning. The sharper distinction is whether the tool removed typing or removed the decision you needed to practise. Classify five real prompts, not five prompts you wish you had written.

This is a reflection aid, not a validated assessment; its result is a prompt for reviewing your own transcript, not a skill score.

A practical rule follows. Before asking AI, write one prediction: what is failing, where, and what evidence would change your mind. Ask for the smallest answer that lets you test it. After the fix, close the transcript and explain the mechanism. That is the learning version of keeping deterministic steps separate from AI steps: you decide which part must remain reproducible in your own head.

The same bug, two conversations#

Suppose a new Trio user has this 6-line function. It raises a TypeError, and even after that is fixed it still returns an empty list.

async def fetch_all(ids):
    results = []
    async with trio.open_nursery() as nursery:
        for user_id in ids:
            nursery.start_soon(fetch_one(user_id))
    return results

Both routes can end at the same implementation. The nested store function gives each child task an explicit place to put its value, while start_soon receives a callable and an argument rather than the coroutine produced by calling it early.

import trio


async def fetch_one(user_id):
    await trio.sleep(0)
    return f"user-{user_id}"


async def fetch_all(ids):
    results = {}

    async def store(user_id):
        results[user_id] = await fetch_one(user_id)

    async with trio.open_nursery() as nursery:
        for user_id in ids:
            nursery.start_soon(store, user_id)

    return results

The test uses three IDs, waits for the nursery to close, and checks all three returned values rather than merely checking that no exception was raised.

import trio

from final import fetch_all


async def test_fetch_all():
    result = await fetch_all([7, 11, 42])
    assert result == {7: "user-7", 11: "user-11", 42: "user-42"}
    print(f"{len(result)} users: {', '.join(str(key) for key in sorted(result))}")


if __name__ == "__main__":
    trio.run(test_fetch_all)

The questioning route forces three retrievals: a coroutine is not an async function; start_soon receives the function and its arguments separately; concurrently started tasks need an explicit place to put results. The learner makes the edit and can later reproduce why it works. The delegation route optimizes the current ticket. The questioning route also leaves something behind.

A harder market raises the stakes#

SignalFire’s June 2026 talent report says entry-level tech hiring continued to contract while employers favored experienced individual contributors. It also says engineering hiring remained slightly below its 2019 pace and describes an unusually large supply of experienced candidates per opening. Its proprietary dataset tracks 650 million-plus people and 80 million-plus organizations, but the published report does not isolate AI as the cause of fewer junior hires.

That market context changes the cost of the habit, not the evidence about cognition. A junior developer needs shipped work and the judgement to defend it. AI can help produce the first while quietly withholding the second. The distinction matters because the move from junior toward senior is not measured in code volume; it is measured in the decisions you can make while the answer is still open, as the seniority guide shows.