AI coding assistants for junior developers are rapidly becoming part of the default developer workflow. But a new controlled study makes the central trade-off harder to ignore: a tool that helps someone finish a task may not help them build the judgment needed for the next one.
A recent Two Minute Papers video highlighted research from Anthropic on AI and coding-skill formation. The takeaway is more useful than the usual “AI is making developers dumber” headline: AI assistance is not inherently harmful, but delegating unfamiliar work without engaging with it can weaken learning—especially debugging and conceptual understanding.
What the AI coding assistants study actually found
Anthropic’s randomized controlled trial examined 52 mostly junior software engineers who had Python experience but were learning an unfamiliar asynchronous programming library. One group could use an AI chat assistant during coding tasks; the control group could not. Both groups then completed a 14-question assessment without AI help.
The AI-assisted group finished about two minutes faster, roughly an 8% difference. However, that speed increase was not statistically significant, meaning the study could not confidently conclude that AI improved task completion time in this setting.
The learning result was clearer. Developers who had access to AI scored 50% on the follow-up quiz, compared with 67% for the unaided group—a statistically significant 17-point gap. The researchers found weaker results across conceptual understanding, code reading, and debugging, with debugging standing out as the most consequential weakness.
That distinction matters. Writing a plausible first draft of a function is only one part of engineering. Production work also means tracing failures, evaluating trade-offs, identifying faulty assumptions, reading existing systems, and knowing when generated code does not belong in the codebase.
The original video accurately frames this as an early but meaningful signal, not a final verdict. The experiment involved a small group, a short learning period, one unfamiliar library, and a chat-style assistant rather than a modern autonomous coding agent. Those limits make broad claims premature—but they do not make the learning gap irrelevant.
The real risk is cognitive delegation, not AI itself
The study’s most valuable insight is that “using AI” is too vague a category. The paper identified six interaction patterns, including several that preserved learning outcomes when developers stayed cognitively engaged.
In other words, the problem is not asking a model for help. The problem is turning an unfamiliar problem into a copy-paste transaction before doing the mental work required to understand it.
That explains why AI productivity research can appear to conflict. GitHub has reported substantial speed and satisfaction gains among Copilot users, including faster completion on certain coding tasks. Those findings can be true at the same time as Anthropic’s result: productivity studies often measure output on a task, while this experiment measured whether a developer learned an unfamiliar technical capability well enough to use and debug it independently later.
For founders and engineering leaders, that is the difference between output acceleration and capability building. A junior engineer can close more tickets this week while becoming less prepared to resolve the difficult incident six months from now. Teams should measure both.
A tutor-first workflow for junior developers
The practical answer is not banning AI coding tools. It is designing a workflow in which the developer remains responsible for the reasoning.
Use these rules to get the benefits of AI coding assistants for junior developers without turning every task into hidden skill debt:
- Automate work you already understand. Ask AI to draft boilerplate, generate test cases, translate known patterns between languages, write documentation, or scaffold repetitive integrations. You should be able to explain and verify the result.
- Ask for concepts before solutions. When working with an unfamiliar framework or library, ask the assistant to explain the architecture, execution model, APIs, constraints, and common failure modes. Request a small example, then implement a variation yourself.
- Debug alone before escalating. Reproduce the problem, read the error, inspect the relevant code path, form a hypothesis, and try a fix. Only then ask AI to critique your reasoning or explain what you missed.
- Require explanation with every accepted patch. Before committing generated code, summarize what it does, why it works, what assumptions it makes, and how it could fail. If the author cannot do that, the patch is not ready.
- Use AI as a reviewer, not the sole author. Ask it to find edge cases, challenge a design, suggest tests, or compare alternatives. This creates a more active loop than requesting a one-shot implementation.
A simple prompt change can make a difference. Instead of: “Fix this error,” try: “Do not provide a patch yet. Explain the likely root causes, give me a debugging plan, and ask what evidence would distinguish each cause.” The developer is still moving faster, but the tool is supporting diagnosis rather than replacing it.
Why debugging should be protected as a core skill
Debugging is where the study’s warning becomes most practical. AI can often propose a fix that passes a narrow test while missing the underlying cause: incorrect state management, an unsafe concurrency assumption, a flawed data contract, or a dependency mismatch.
Junior developers need repeated exposure to that uncomfortable process of narrowing possibilities. It develops causal reasoning—the ability to connect a symptom to a system behavior—and that skill transfers across languages, frameworks, and tools.
Teams can protect it with lightweight operating rules:
- Reserve occasional “no-AI” practice tasks for onboarding and training.
- Ask juniors to narrate their investigation in pull requests or pairing sessions.
- Review AI-generated diffs with the same rigor as any external contribution.
- Treat failing tests, logs, stack traces, and observability tools as the first debugging interface—not the chatbot.
- Build learning time into estimates when a task introduces a new technology.
This is consistent with responsible-use guidance from GitHub, which emphasizes human oversight and thorough review for AI-generated code. As agentic coding features become more capable, that oversight becomes more important, not less: the quantity of code a developer can generate may increase faster than their ability to evaluate it.
What engineering managers should change
The manager-level mistake is rewarding only throughput. If a team celebrates tickets closed, lines changed, or pull requests merged without measuring comprehension and ownership, AI can mask a widening skills gap.
A healthier approach is to separate work into two lanes. The delivery lane uses AI aggressively for familiar, low-risk, repeatable work. The learning lane gives developers room to reason through new systems, write small pieces manually, explain design choices, and debug with coaching.
Code review should also test understanding. Ask questions such as: What invariant does this change preserve? Which failure cases did you test? Why is this API safe under concurrent load? What would make this implementation fail in production? These questions are not gatekeeping; they are how organizations turn AI output into durable engineering capability.
AI coding assistants for junior developers need guardrails, not panic
The study featured in the Two Minute Papers video does not prove that every AI-assisted developer will lose skills, nor does it justify treating coding copilots as inherently bad. It does show that speed and learning are different outcomes, and that heavy delegation on unfamiliar tasks can buy a small amount of short-term convenience at a substantial cost to mastery.
The winning habit is straightforward: let AI remove repetitive friction, but do not outsource the moment where you need to form a mental model. Use it to explain, challenge, test, and review your thinking. When something breaks, investigate first and ask the model to become a teacher—not an emergency replacement for your own judgment.