Shipping Fast With AI Is Not the Same Thing as Getting Better
The research says AI-assisted developers understand less. The fix is not using AI less — it is changing the order you use it in.
It is 2 a.m. and checkout is failing for about one order in forty. You wrote that service four months ago. You shipped it on time and the pull request was clean.
You open the file and it reads like something a stranger wrote.
You can follow it. You cannot predict it — you cannot look at the retry block and say out loud what happens when the payment provider returns a success after your client already timed out. So you paste it into a chat window and ask. It works. You go back to bed.
Nothing about that night tells you what just happened: you outsourced the exact moment that used to turn a four-month-old file into experience.
The risk with AI was never that it writes bad code. It is that you can ship for three years and come out with about six months of engineering judgment.
What the studies actually measured
In a randomized trial run by Anthropic researchers, 52 mostly-junior engineers learned Trio, an async Python library none of them knew. Half had an AI assistant. Everyone was quizzed on concepts they had been using minutes earlier. The assisted group averaged around 50 percent; the unassisted group around 67. The widest gap was on debugging, and the assisted group did not finish faster.
A separate trial of 16 experienced open-source developers, working in repositories they had maintained for years, found they expected to be about 24 percent faster with AI, reported feeling about 20 percent faster, and were measured 19 percent slower.
Small studies, narrow tasks, and neither one settles the argument. But notice what neither measured: the quality of the code. Both pointed the instrument at the human afterwards, and both found the artifact was fine and the person was unchanged.
The code shipped. The engineer didn't move.
Why "just use AI less" is the wrong fix
The usual reasoning: AI types for you, so you stop practising, so your skill decays. Therefore use it less, turn off autocomplete, do it the hard way.
Typing was never where the skill lived. The industry copy-pasted from Stack Overflow for fifteen years and still produced excellent senior engineers. Struggle is not magic either — six hours lost to a misconfigured environment variable teaches almost nothing. Pain does not automatically convert into ability.
What changed is not effort. It is latency. The answer now arrives before your guess does.
Experience is the residue of being wrong
Three findings from learning research explain the whole thing.
The generation effect: you remember what you produced far better than what you read. The testing effect: retrieval builds memory, review mostly does not. Prediction error: your mental model updates at the moment reality disagrees with it.
So experience is the residue of being wrong about something specific, in a way you noticed.
Reading a correct answer produces fluency instead — the smooth "yes, obviously" feeling, which is a convincing impersonation of competence. It is the illusion of explanatory depth: everyone is certain they could explain how a zip works until somebody asks.
You don't learn from the answer. You learn from the distance between the answer and what you expected.
One missing step, five symptoms
These get treated as five separate weaknesses. They are one habit repeating.
You cannot explain the PR you opened yesterday. You never formed a claim, so there is nothing to retrieve.
Debugging unfamiliar code feels like starting from zero. Debugging is prediction under pressure; you have not practised the prediction half.
Estimates are guesses, not memory. Good estimates come from having been wrong about similar work and remembering the shape of it.
Incidents become search sessions. You go wide because you cannot go narrow, and narrow requires a hypothesis you would bet on.
Interviews feel unfair. Debug unfamiliar code, review a PR, defend a design decision — these are the cheapest tests for whether shipping became judgment.
The 30-second prediction loop
The fix is not removing the tool. It is putting something of yours in front of it.
Before you read the output, guess. One line. Not analysis — a bet.
Before asking for a fix: "I think it is the retry. The provider is not idempotent and we are not keying on order ID."
Before generating a function: "This breaks on empty input, and timezone handling will bite."
Before opening unfamiliar code: "This class probably owns the connection, so closing it here starves the pool."
Then read at full speed. No abstinence, no performed struggle. Find the exact place your guess and the answer disagree. That disagreement is the lesson; the rest you already knew.
It has to be written down. An unwritten prediction gets silently revised — you read the answer, feel the click, and your memory rewrites what you thought thirty seconds ago into something much closer to the truth. Hindsight bias eats feedback loops for a living. A guess only counts if it can embarrass you.
Where this stops working
Prediction is not consequence. Some judgment only arrives by owning an outage, or living with a decision for eighteen months. No thirty-second habit replaces being on the hook.
In a domain where you have no model, your guess is noise. If you have never touched Kubernetes, "I predict the pod restarts" is not a bet. Read first, then predict the next one.
And none of this argues that AI is bad for engineers. In this order it is the fastest feedback instrument the profession has ever had.
We were handed the best feedback loop in the history of the craft, and we're using it as a vending machine.
Why it is a career problem, not a study-habits problem
The market already repriced it. Volume of shipped work used to be a decent proxy for skill, and hiring processes noticed it stopped being one faster than résumés did. Unfamiliar-code debugging is now standard in interviews because it is the one signal AI assistance does not inflate.
Inside a company it is quieter. When something is on fire, somebody decides who gets pulled in. It is never the person with the most merged tickets. It is the person who can look at a graph and say "I think it is the connection pool" and be usefully, narrowly wrong within ninety seconds.
You can build that while using AI all day. You cannot build it while reading answers you never guessed at.
Key Takeaways
AI-assisted developers in controlled studies scored lower on comprehension and debugging of code they had just written — the gap was largest on debugging.
The cause is not typing less. It is that the answer arrives before your prediction does.
Skill forms from prediction error: you encode the gap between what you expected and what turned out to be true.
Fluency (a correct answer feeling obvious) is not competence, and feels identical from the inside.
The fix is order, not abstinence: one written guess, then read at full speed, then keep only the delta.
Consequence and ownership still teach things prediction cannot.
FAQ
Does using AI actually make developers worse at coding?
It makes them worse at skills they stop exercising, particularly debugging and reasoning about unfamiliar code. Controlled studies found AI-assisted learners scored roughly 17 points lower on comprehension quizzes about code they had just written. The code itself was not worse — the learning was.
Why do I feel faster with AI but not more skilled?
Because reading a correct answer produces fluency, which feels like understanding. Fluency and competence are indistinguishable from the inside, which is why one study found developers reporting they were 20 percent faster while measurably being 19 percent slower.
How can junior developers use AI without skipping the learning?
Predict before reading. Write one line stating what you think the cause is, or what the generated code will do, then read the answer and find where you were wrong. A junior who is corrected twenty times a day is learning faster than anyone did before these tools existed.
Should I stop using AI coding assistants to protect my skills?
No, and almost nobody who tries this sticks with it. Abstinence targets the wrong variable. The variable that matters is whether you form a prediction before the answer appears, which costs about thirty seconds and none of the speed.
What is the generation effect in programming?
It is the finding that you remember information you produced far better than information you read. In practice it means an attempted solution you got wrong teaches you more than a correct solution you read, which is why passive acceptance of AI output leaves so little behind.
Why do technical interviews now focus on debugging unfamiliar code?
Because shipping volume stopped being a reliable signal of skill once AI could produce most of the volume. Debugging code you did not write, reviewing a PR, and defending a design decision are cheap to run and hard to fake, so they became the default filters.
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
If you cannot say what you expect before you look, you are not practising. You are watching. Watching is pleasant, productive, and invisible from the outside — your commit history looks identical either way — right up until the night something breaks and the file you wrote reads like a stranger's.
Being wrong on the record is the cheapest way to become senior that has ever existed.
Adam Jaber is a software engineer who writes about AI, backend systems, and careers — complex topics, made simple. No jargon, no hype.
