Two Developers, Same AI. Only One Is Getting Better.
A randomized trial found AI-assisted learners scored two letter grades lower — yet some of them beat the developers who used no AI at all. The variable wasn't the tool.
Two developers, same team, same stack, same model subscription. Eighteen months pass. One has become the person everyone pings when production is on fire. The other ships more code than ever and can no longer debug an unfamiliar stack trace without opening a chat window first.
Their commit counts look the same. Their velocity looks the same. If anything, the second developer looks more productive.
The popular explanation — AI is making developers worse — doesn't survive contact with the research. Something narrower is happening, and it's far more fixable than the doom takes suggest.
The trial that deserved more attention
In January 2026, Anthropic published a randomized controlled trial on skill formation. Fifty-two developers, mostly early-career, learned Trio, an unfamiliar Python async library. Half had an AI assistant that could produce correct code on demand. Half worked it out themselves.
Both groups then took the same comprehension quiz, without AI.
Hand-coding group: 67%
AI-assisted group: 50%
That's roughly two letter grades, and the gap was statistically significant. The AI group also didn't finish meaningfully faster. They paid for the assistance and didn't receive what they were paying for.
They finished at about the same time. They just knew less at the end.
That headline circulated for a week under titles about AI rotting your brain. Then almost nobody read the next section.
The average hides the entire story
The researchers also coded how people used the assistant. Six distinct interaction patterns fell out of the transcripts. Three scored under 40%. Three scored between 65% and the mid-80s.
The worst performers delegated: describe the problem, take the generated code, confirm it runs, move on. Fastest to finish, least understanding at the end.
The best performers asked conceptual questions — "why does this need to be awaited here," not "write me an async function." They typed their own code and used the model to interrogate what they were building. Developers with those high-engagement patterns matched or beat the people who used no AI at all.
The tool didn't decide the outcome. The shape of the loop did.
One study, 52 people, one library, one quiz taken immediately afterwards. It doesn't establish a career theory on its own. It does describe a mechanism you can test against your own last six months.
Why the loop beats the tool
You don't learn from the answer. You learn from the distance between your guess and the answer.
Committing to a prediction — even a wrong one — builds a specific expectation about how something works. The correction lands on that expectation and reshapes it. That reshaping is the learning. Without a guess, the correct answer arrives with nothing to attach to. It slides past, and it feels excellent on the way down.
This is why reading a good solution is so deceptive. Following an explanation you couldn't have produced yourself generates a powerful sensation of understanding, because fluency and comprehension feel identical from the inside. You discover the difference later, when the explanation isn't available and you have to generate it.
Fluency is what understanding feels like from the inside. It isn't the same thing.
Every senior engineer you admire carries an internal library of "when this breaks, it's usually that." Nobody handed them that library. They built it by guessing wrong about a hundred outages and letting reality correct them, one specific wrong guess at a time.
The ladder used to force this on you
Junior work was never economically valuable. The small bug fix, the boilerplate, the flaky test — none of it justified the salary. What justified it was that those tasks were a machine for producing guesses with consequences attached. You committed to a theory about the bug, you were wrong in a pull request, and somebody senior enough to see your reasoning corrected it.
The grunt work was never the curriculum. Being wrong on the record was.
That machine is being switched off. Stanford's Digital Economy Lab, working from payroll data, reports that employment for 22-to-25-year-olds in AI-exposed occupations now sits roughly 19% below where it would be had it tracked their less-exposed peers. There's no evidence of broad economy-wide displacement. The effect runs almost entirely through reduced hiring rather than layoffs, and it concentrates in occupations where AI is used to automate work rather than to assist it.
The authors call these descriptive indicators, not causal estimates. Fair. The practical lesson holds anyway: the rung that used to manufacture your reps is thinner than it was, and waiting for it to return is not a plan.
The rung was never where the learning lived. The loop was — and the loop is portable.
What it costs you
Not unemployment. Plateau, which is quieter and takes far longer to notice.
Run the delegation loop for three years and you produce three years of shipped work and roughly one year of capability. Nothing flags it. Tickets close, reviews pass. It surfaces the first time you're somewhere the model can't answer for you: a 2am incident, a system design conversation, an interview asking why you chose that approach, a codebase written by people who left.
There's a nastier version. The role is shifting toward reviewing, verifying and judging AI output — a job that runs entirely on the pattern library described above. Delegating to gain speed spends exactly the capacity the next version of the job demands.
The uncomfortable test: take the last non-trivial thing you shipped with AI help. Could you rebuild it tomorrow, unaided, and explain each decision? If not, that wasn't a rep. It was a delivery.
Putting the gap back in
The usual advice is "code by hand for six months." That loses to reality by Wednesday. Nobody is giving up the speed, and nobody should have to. You only need to reinstate one step.
1. Guess first. Before you ask, write one line: what you think the answer is and why. It doesn't need to be right. It needs to be committed. Cost: about fifteen seconds.
2. Ask how, not what. "Explain why this deadlocks" builds the library. "Fix this deadlock" empties it. That distinction is what the transcripts picked out, and it separates a mid-80s score from a sub-40 one.
3. Name the gap. When the answer arrives, say where your guess was wrong. Not that it was wrong — where. That sentence is the learning. Everything before it was setup.
4. Rebuild it tomorrow. Take one thing from today and redo it from memory, no assistant. If you can't, you watched someone else understand something.
Total cost: roughly ninety seconds on an unfamiliar problem. You keep the speed and stop paying for it with your ceiling.
When delegating is correct
Not everything deserves a rep, and pretending otherwise is how good advice gets abandoned.
The config you've written forty times, the throwaway migration script, the regex you'll never revisit, the thing that must ship before midnight — delegate all of it, guilt-free. That's what the tool is for. The mistake isn't delegating. It's delegating by default, including on the problems that were about to teach you something.
Delegate what you already understand. Predict on everything you don't.
A rule of thumb: if it lives in the part of the system you want to own in two years, it gets the loop. If it doesn't, ship it and move on.
Key Takeaways
AI-assisted developers scored 50% versus 67% for hand-coders on an unaided comprehension quiz — about two letter grades — with no meaningful speed gain.
The average hides the real finding: six usage patterns, three scoring under 40% and three scoring 65% to the mid-80s.
Developers with high-engagement patterns (conceptual questions, own code) matched or beat those using no AI at all.
Skill forms in the gap between a committed guess and a correction. Delegation removes the gap; prediction preserves it.
Entry-level hiring in AI-exposed occupations is roughly 19% below trend for 22-to-25-year-olds, driven by reduced hiring rather than layoffs.
The risk to most working developers isn't unemployment. It's three years of output and one year of capability.
Fix: guess before you ask, ask how rather than what, name where you were wrong, rebuild it unaided the next day.
FAQ
Does using AI to code make you a worse developer?
Not by itself. In Anthropic's skill-formation trial the AI-assisted group averaged 17 points lower on an unaided comprehension quiz, but that average concealed a wide spread: developers who asked conceptual questions and wrote their own code matched or exceeded the group using no AI. The variable is the interaction pattern, not the presence of the tool.
What is the difference between AI delegation and AI-assisted learning?
Delegation means describing a problem, accepting generated code, confirming it runs, and moving on — fastest to finish, lowest comprehension afterwards. AI-assisted learning means committing to your own answer first, asking the model how something works rather than what to type, and then comparing. Same tool, opposite outcomes.
How do I keep learning while using AI coding assistants?
Reinstate one step: write a one-line prediction before you ask. Then ask "how" and "why" questions instead of requesting code, say explicitly where your guess was wrong, and rebuild the same thing unaided the next day. It adds about ninety seconds per unfamiliar problem.
Is AI responsible for the drop in junior developer hiring?
The Stanford Digital Economy Lab finds employment for 22-to-25-year-olds in AI-exposed occupations sits roughly 19% below where it would be had it tracked less-exposed peers, with no evidence of widespread displacement and the effect running through reduced hiring rather than layoffs. The authors describe these as early indicators rather than causal estimates.
Why does reading a correct solution feel like learning when it isn't?
Because fluency and comprehension feel identical from the inside. Following an explanation you couldn't have produced yourself creates a strong sensation of understanding, but nothing gets updated unless you had a prior expectation for the correction to land on. You find out later, when the explanation isn't there.
Should juniors write code by hand to learn in the AI era?
Only where the difficulty is doing the teaching. Writing by hand is a proxy for the real ingredient — a committed prediction before feedback — and you can preserve that ingredient while still using the tool. Blanket "no AI for six months" rules tend to be abandoned within a week.
Related reading
AI Won't Take Your Coding Job. It Will Change It. — the role this article describes from the other direction: verification as the core of the work.
AI Writes Code That Looks Right — what you are actually verifying against.
How to Let AI Think for You Without It Thinking for You — the cognitive-offloading line, drawn deliberately.
The AI Productivity Paradox — why the time saved often is not time gained.
Start Here — the full Simply Explained map.
The bottom line
Two developers, same team, same tools, same eighteen months, wildly different positions. It wasn't talent and it wasn't the job market. One kept guessing before asking. The other stopped.
The apprenticeship a ticket queue used to hand you can be run deliberately, with faster feedback than the old ladder ever offered. It simply no longer happens by accident.
Delegate what you already understand. Predict on everything you don't.
Adam Jaber is a software engineer who writes Simply Explained: complex topics, made simple, with no jargon and no hype.
