Learning to Code Without Handing Over the Thinking

A task completed quickly and a skill acquired well are different outcomes. Anthropic’s randomized study examines developers learning an unfamiliar Python library, then tests their understanding shortly afterward. Its results make the speed–mastery tradeoff concrete, but the short assessment and small, mostly junior sample limit what it can establish about long-term skill.

Anthropic’s workplace study offers a contrasting view: engineers describe learning unfamiliar parts of their codebase and broadening their work, alongside worries about losing practice in deeper skills. Those interviews and usage data illuminate work as it happens, not causal effects on learning. Read together, the pieces ask whether AI changes the pace of practice, the breadth of what people attempt, or both—and set up the question of how assistance might be designed to support learning rather than merely output.

If productive effort matters, should an assistant answer less, or answer differently? OpenAI’s Study Mode describes a product strategy built around guiding questions, scaffolded responses, and knowledge checks. It explains the design intent, while noting that the early version depends on system instructions and can behave inconsistently; it is not evidence that the mode improves programming skill.

JetBrains’ advice for novice programmers puts more weight on the learner’s own habits: plan before coding, notice when AI is doing the thinking, and sometimes turn off inline completions. That is practical guidance, not a controlled comparison of learning strategies. Together, the readings frame a design tension: can a tutor reliably preserve active effort, or does that depend on learners choosing when to accept help? The next session narrows this broad question to a concrete interface: the hint.

A hint can be a nudge toward the next step, a partial code change, or a solution in disguise. JetBrains describes an in-IDE system that combines LLM-generated suggestions with IDE analysis, code-quality checks, and controls over hint size. This is an engineering approach to making assistance more contextual and incremental—not proof that the resulting hints produce durable learning.

A later JetBrains study observes how students actually respond: some accept hints, while others adapt fragments, revise their code, or combine information from several attempts. These traces and interviews show varied interaction strategies, but they do not establish which strategy causes better learning. The contrast between intended scaffolding and observed use matters: a system’s “hint” may become material for independent reasoning—or a shortcut. That makes the learner’s next debugging move, not just the interface, the subject of the next session.

Debugging is both a route to working code and a way to learn how code behaves. Microsoft Research’s Debug-gym builds an environment for AI coding tools to seek information interactively while debugging, rather than immediately generating a fix. It studies how to train agents, not how human learners acquire debugging skill; its value here is as a technical account of the information-gathering and iteration that one-shot fixes can bypass.

GitHub’s advice for junior developers suggests keeping access to explanations and debugging help while temporarily turning off inline completion during new learning. That is a workflow recommendation, not an experimental result. Put beside Debug-gym, it raises a useful question: can tools preserve diagnostic steps for people, or do they mainly automate those steps for agents? Even a learner who debugs actively still needs to judge whether a proposed fix works—and whether “works” is enough.

Tests, automated review, and code reading can all help catch mistakes, but they answer different questions. OpenAI’s account of code verification at scale describes a reviewer designed to surface actionable issues while acknowledging evaluation limits and the danger of treating a clean review as a guarantee. It is an engineering account of oversight, not a study of learning.

JetBrains’ framework argues that reviewing AI-generated code is also a problem of trust calibration: reviewers need ways to allocate attention to the riskiest parts of large changes. That framework comes from practitioner design research, not a validated teaching method. Together, these readings sharpen the seminar’s final distinction: tools may help verify an artifact, but the learner’s understanding needs its own evidence—especially evidence that holds beyond the immediate task.