I sat there half the night, and that half-night was the entire lesson.
In January 2024, AI started hitting my ears again through articles about code debugging and probable solutions. That hit home. I had been a developer for a short period earlier in my career, and I knew the feeling of sleepless nights with a deadline approaching and a bug I could not find.
Those nights cost real time. The cursor blinking. The stack trace pointing one way, the behavior pointing another. Every wrong turn felt like waste. But somewhere in that loop I was building something I could not see yet: a picture of how the system moved. Not the architecture diagram. The live, conditional reality of how data flowed between functions. That picture did not come from documentation. It came from being wrong, many times, in a row.
This is what junior developers using AI coding tools are quietly skipping. Not the bugs. The picture.
If the machine absorbs every dead end, what does the developer never build?
The productivity case for AI is documented and I am not here to argue against it. Junior developers are shipping more, faster. Ticket counts are up. Sprint dashboards look good.
But a sprint dashboard measures output, not comprehension. When AI resolves a dead end before a junior developer has to sit with it, the mechanism that would have built their mental model of the system does not fire. This is not laziness. It is not poor work ethic. The developer is working. They are just not doing the particular kind of work that builds system intuition. It is a question of a mechanism that only forms under pressure, and AI relieves the pressure.
The result is skill atrophy that looks, from the outside, like a productivity gain.
You can complete every journey on time without ever learning to steer in a skid.
Think about a new driver who always had someone more experienced take the wheel in difficult conditions. Every trip completed on time. Journey metrics clean. But the driver never felt what happens when the car loses traction. They never learned the reflex of steering into a skid rather than away from it.
The first time they encounter a real skid alone, there is no muscle memory to draw on.
A junior developer who has shipped twenty features with AI assistance has an equally clean completion record. What they lose is not the ability to produce output. It is the ability to reason about what the output is doing when it stops working correctly. The delivery record is real. The invisible deficit is also real. And the deficit does not show up until a production incident surfaces it.
The productivity data looks good until you read what it does not measure.
Before calling this a problem with AI, name what AI does for junior developers. An NBER paper tracking how AI coding tools change developer outcomes found a range of effects, including a 34% improvement for novice and low-skilled workers but with minimal impact on experienced and highly skilled workers. That 34% figure is not contested. The productivity gain is real and documented.
The question is what the gain does not include.
A study on code comprehension in AI generated code, tracking students who completed programming tasks with an AI coding assistant, found that their comprehension scores did not improve correspondingly. Output went up. Understanding of the code did not follow. The researchers called this a comprehension-performance decoupling.
A separate paper observing programmers using AI found something harder to fix than low scores: struggling students often expressed cognitive dissonance about their problem solving ability, thought they performed better than they did, and finished with an illusion of competence. They did not know they did not understand. Low scores can be corrected with feedback. A developer who cannot assess their own knowledge gaps is invisible to every standard measure the team uses.
One participant in a study of professional developers gave that gap a voice after shipping a working feature: "It has my name on it, but I have no idea why it works" (J8). That sentence is the sprint dashboard's blind spot made audible.
Senior developers use AI every day and most of them are not losing their edge.
Does AI coding make junior developers worse at their jobs? The honest answer depends on sequence, not the tool.
Senior developers use AI constantly. They are faster. They are not showing the same comprehension decoupling the research documents for juniors. That is not a contradiction of the argument above. It is the explanation for it.
When a senior developer accepts a Copilot suggestion, they read it against a mental model built through years of debugging, failure, and system investigation before AI was available. They know the language of the codebase. They know what a wrong suggestion looks like, even when it compiles. Those debugging skills, built before AI arrived, are the reference map they check every suggestion against.
The junior developer who starts using AI before that map is built has nothing to check the suggestion against. They have the suggestion and a green test. The difference is not the tool. It is the order in which things happened.
The fix is a sequence, not a ban.
I stay behind the wheel. I ask generalised queries. I never paste sensitive customer data, IRB submission IDs, or other regulated material into the cloud. That rule is non-negotiable in pharma IT. I have built a Context Generator utility on my site that walks users through the Role / Objective / Background / Data prompt shape.
The "behind the wheel" principle maps onto the junior developer problem with one adjustment. For me, it means keeping judgment and accountability with the consultant, not the tool. For a junior developer learning the system, it means writing the attempt before asking the tool.
The junior writes the function first. Even if it is slow. Even if it is wrong. The act of writing forces a position on what the function needs to do, what edge cases could arrive, what the failure state looks like. Then AI critiques the attempt.
That is a different cognitive position from handing AI a requirement and accepting what comes back. AI should audit the junior's attempt, not replace the attempt. That gap does not form in the first model. It forms in the second one.
Speed is the only signal that gets reported, and that is exactly the trap.
The specific failure mode is not a junior developer making a bad choice. It is a team that mandates AI use for velocity without redesigning how junior competence is measured.
When AI-driven velocity signals team fragility, the signal looks identical to when it signals health: the sprint dashboard is green. The distinction is not in the output. It is in whether the developer who built the output understands what would need to change if the requirements changed.
AI tools surface one number. Junior developer debugging skills do not appear in that number at all. The comprehension deficit can accumulate for months before a production incident makes it visible. That is not a junior developer problem. It is a metric design problem. The organization creates the structure in which the gap is invisible by design.
The question worth sitting with does not appear in a sprint report.
When a junior developer who has shipped cleanly for six months hits a production incident they cannot read, there is one question worth asking. Not "how did this happen?" That will have an answer. The harder question is whether this was the first sign, or the last.
The sprint report will not tell you which one it is.
