You're Not Getting Stuck Anymore. That's the Problem.
A randomized trial found the developers who hit fewer errors understood 17 points less — and lost the most ground exactly where it matters.
Fifty-two developers learned Trio, a Python async library none of them had used. Half used documentation and web search. Half had an AI assistant that could read their code and write correct solutions on demand.
Both groups shipped working code. Then both took a quiz on what they had just done.
Hand-coding group: 67%. AI group: 50%.
That 17-point gap comes from Anthropic's January 2026 study on skill formation, and it is not the most interesting number in it. This one is: the AI group hit a median of one error during the task. The hand-coding group hit a median of three.
Fewer errors. Less understanding. Those travel together for a reason.
Errors are the mechanism, not the friction
In the control group, someone forgot to await a coroutine and got a RuntimeWarning. Someone passed a coroutine object where an async function was expected and got a TypeError. Clearing those messages required building a working model of how Trio handles concurrency.
That is how programming knowledge forms. You predict what the machine will do, the machine disagrees, you revise. The gap between expectation and reality is the training signal. Remove the gap and you remove the signal.
The AI group did not get a weaker version of that loop. They largely skipped it. The generated code already awaited the coroutine, so the wrong belief was never surfaced and never corrected.
The errors were not in the way of the learning. They were the learning.
The damage was not evenly distributed either. The widest gap between groups was on debugging questions — looking at broken code and working out why it breaks. Code reading and conceptual understanding also declined, but debugging declined most.
The sign flips depending on what you already know
This is not the "AI makes developers lazy" argument, which is both moralizing and wrong.
The same research group previously found that AI assistance can speed up work by close to 80% when people already have the relevant skill. That gain is real. Put the two findings side by side and you get a rule rather than a warning.
AI is a multiplier on skills you already have and a divider on skills you are still building. Same tool, opposite sign.
So the useful question is never "how much AI should I use." It is per task, and it takes two seconds:
Am I executing a skill I own, or acquiring one I do not?
Generating boilerplate for an API you have written forty times is executing. Delegate it. Wiring up your first async runtime or your first message queue is acquiring. That is where the divider operates.
Worth noting: in the study the AI group's speed advantage did not reach statistical significance. They were not meaningfully faster. They understood meaningfully less.
Why this is a career problem, not just a learning problem
Every visible signal of your work stays healthy. PRs merge, tickets close, velocity holds. No dashboard anywhere tracks "understood what shipped."
So competence and the appearance of competence diverge quietly, for months, with no corrective feedback — then surface all at once during an incident, a design review, or a migration. Each of those requires a mental model of the system that was never built.
You cannot verify what you never had to understand.
And here is the trap. The skill that degrades most under AI assistance is debugging. The skill every AI-era job description says the human provides is catching what the AI got wrong. The productivity is borrowed directly against the thing that keeps you employable.
The error quota
Backend teams use error budgets: accept that perfection is impossible, define an allowed failure rate, spend it deliberately, stay under the ceiling.
While you are learning, that inverts. You do not need a ceiling. You need a floor.
A senior stays under an error budget. A learner has to meet an error quota.
A week in which nothing confused you is not a productive week. It is a week that taught you nothing — and it is the only metric that falls while your dashboards rise.
Rule three matters more than it looks. The study's qualitative analysis found participants scoring below 40% clustered into three habits: full delegation from the start, gradual offloading as the task progressed, and reaching for the AI the moment anything turned red. None of those is a conscious decision. All three are drift.
What the high scorers did differently
They did not abstain. This is the most practically useful finding in the paper and the part the headline loses.
They asked conceptual questions rather than requesting solutions.
They asked for explanations alongside generated code, not code alone.
They used the assistant to check a model they had already formed, rather than to supply one they had not.
That last habit is the whole discipline. Form the guess, then test it. Used that way, the AI corrects a wrong mental model — which is mechanically the same event as hitting an error, except you triggered it deliberately.
One caveat on the research: the trial used a chat-based assistant, not an agentic tool operating across a repo. The researchers expect agentic tools to make the skill-formation effect more pronounced, not less. It is also a single study on unfamiliar material, close to a worst case. Treat the direction as solid, the exact figures as one data point.
If you mentor juniors
Senior engineers reading this are mostly fine. Twenty years of banked errors is exactly what lets them separate good AI output from confident nonsense.
The pipeline is what breaks. Judgment was never taught in a module; it accumulated as a by-product of juniors doing unglamorous work badly and then repairing it. Automate that work and the by-product stops being produced — silently.
The fix is not "make juniors code by hand." It is narrower:
Assign bugs in code they did not write.
Ask for reasoning before the diff.
In review, ask "what would break this?" more often than "does this work?"
Make it safe to say I generated this and I do not fully understand line 40 yet. The alternative is not juniors who understand line 40 — it is juniors who learn not to mention it.
Key Takeaways
In a randomized trial, developers using AI assistance scored 50% on a comprehension quiz versus 67% for those coding by hand — a 17-point gap, roughly two letter grades.
The AI group encountered a median of 1 error versus 3 for the control group. Fewer errors correlated with less understanding.
Debugging showed the widest gap, which is the same skill AI-era roles depend on for oversight.
AI assistance behaves as a multiplier on existing skills (prior research: up to ~80% faster) and a divider on skills being acquired.
The speed advantage in the study did not reach statistical significance.
Highest-scoring participants used AI for explanations and verification of their own reasoning, not for solutions.
FAQ
Do AI coding assistants actually reduce developer skill?
In one randomized controlled trial with 52 developers learning an unfamiliar Python library, yes: the AI-assisted group scored 17 points lower on a comprehension quiz (50% versus 67%). The effect applies to skills being acquired. The same body of research found large productivity gains when people already have the relevant skill, so the effect is conditional, not universal.
Why does using AI hurt debugging skills the most?
Debugging is learned by encountering errors and resolving them. AI assistance removes most of those errors before they reach you — the AI group hit a median of one error versus three for the control group. Fewer encounters means fewer repetitions of the diagnose-and-repair loop that builds the skill.
Should junior developers avoid AI coding tools entirely?
No. The participants who scored highest in the study used AI — they used it for conceptual questions, explanations alongside code, and verification of their own reasoning. Abstention is not the variable. Whether you form and test your own model before delegating is.
How can I use AI without losing skills?
Decide per task whether you are executing a skill you own or acquiring one you do not. On unfamiliar material: attempt it yourself first, read your own stack traces, ask why before you ask what, request explanations with any generated code, and keep at least one area you build entirely by hand.
How do I know if I really understand AI-generated code?
Try to explain how it fails, not what it does. If you can describe two plausible ways the code breaks and what each error would look like, you understand it. If you can only narrate its behaviour, you have read it.
Is AI replacing junior developer roles?
The more precise concern in the research is not role replacement but apprenticeship replacement. The routine work that used to build judgment is now automated, while the visible output metrics — velocity, merged PRs, closed tickets — stay identical. The skill gap accumulates without appearing in any dashboard until an incident, design review, or migration exposes it.
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
The unsettling part of the study is not that the AI group scored badly. It is that nothing during the task told them they were. The code worked. The task finished. The feedback loop that would have flagged the problem is the exact loop the assistant had removed.
That is why "just be careful" is useless advice here. Careful is a feeling, and the feeling is unreliable when the failure mode is invisible. You need a rule that fires before the prompt, not a reaction after it.
The day you stop getting stuck is not the day you got good. It is the day you stopped getting the feedback that made you good.
This week, count something other than what you shipped. Count the times you were genuinely confused and worked your way out. If that number is zero, you had a fast week and an empty one.
Adam Jaber is a software engineer who writes Simply Explained — complex topics, made simple. No jargon, no hype.
