You have been shipping for a year, maybe two. Claude Code is open in a second window more often than not. It writes the boilerplate, drafts the tests, and some days gets the whole function right before you have finished reading the ticket. Code review comes back clean. Your velocity, if anyone bothered to measure it, has gone up. And somewhere underneath the speed sits a question you have not said out loud, not even to yourself in so many words: if the tool disappeared tomorrow, could you still do this?
Everyone arguing about that question is arguing about the wrong variable. The public fight keeps treating AI-assisted learning as a referendum on willpower: strong engineers resist the crutch, weak ones lean on it. But a randomized controlled trial that measured exactly this found something more specific and more useful than a verdict on character. It was not whether people used AI. It was how.
What the study actually found
In early 2026, Anthropic's own research team ran the experiment directly: 52 working software engineers, split into two groups, learning the same unfamiliar Python library. Half coded with an AI assistant. Half coded by hand. Both groups then sat a quiz on the code they had just written, while it was still fresh.
The AI group finished about two minutes faster, a gap too small to call significant. The AI group also scored 50% on the quiz, against 67% for the hand-coding group. The paper calls that "the equivalent of nearly two letter grades," and the gap was largest on the debugging questions: the exact skill you need to know when the AI is wrong. Speed barely moved. Understanding did.
That is a real finding, and it is worth sitting with rather than explaining away. It is also not the finding everyone reaches for. The study's own next sentence is the one that gets skipped: using AI did not guarantee the lower score. How someone used it did.
Two ways to run the same tool
Some participants pasted the spec in, took the code back, and moved on. They finished fast, with few or no errors, and their cluster averaged under 40% on the quiz, the bottom of the study. Others used the exact same assistant to ask why the code worked, to request an explanation, to pose a conceptual question before accepting an answer. They were not the fastest in the study. They scored higher. The study's high-scoring patterns all used AI to build comprehension, not just to produce code.
Same model. Same task. Same sitting. The variable that decided who kept the skill was never the AI. It was whether the person treated it as a typist or a tutor.
You do not protect a junior by taking the AI away. You protect them by giving them AI that argues back.
The instinct to solve this by restricting the tool gets the mechanism backwards. The tutor-mode engineers in the study were not using less AI. They were using an AI that made them justify themselves before it moved on.
The missing piece is a loop, not willpower
If the fix were willpower, the study would have found that some people just try harder. It did not find that. It found a repeatable interaction pattern: predict before you see the answer, get pushed back on when your reasoning has a gap, build the thing, and then have someone tell you, specifically, what you demonstrated. Take any one step out and the loop collapses back into typing.
That loop is not a personality trait. It is a sequence, and a sequence is something you can run on purpose, on the actual work in front of you, without waiting to feel more disciplined first.
A second, quieter study says the same thing
A separate, qualitative study at CHI 2026 studied ten junior and ten senior engineers working with agentic AI on the job. It carries no effect size and no controlled comparison, and the authors are careful to say so. But the pattern it describes matches the RCT's own split: the senior engineers kept control of AI-assisted work by arriving with a plan and delegating only the parts that fit it, while the junior engineers working on unfamiliar code swung between leaning on the assistant entirely and refusing to trust it at all. Arriving with a plan, in other words, is not a senior personality quirk. It is the mechanism, described from the other side of the career ladder.
What that loop looks like on a Tuesday afternoon
Scaffold, a free Claude Code plugin, is that sequence wired into your own repo. Run /scaffold in a project and it engages the loop on whatever you are actually building that day.
Say the bug is a queue that double-sends a confirmation email on retry. Before Scaffold writes anything, it asks what you think is wrong and why. You answer. Then it shows its own plan as a diff against your prediction: what you got right, banked as evidence, and what it would change, each item tagged with the concept behind it. If you disagree with a real shipping decision in that diff, it will not proceed until you argue it out. Then, and only after you approve, you build together.
After the commit, you get a report: what the change taught about the codebase, and what you personally demonstrated. That second half goes into a ledger Scaffold keeps separate from everything it knows itself, so it never credits you with understanding you have not actually shown.
Concepts move through three levels, mechanically earned: learning, then understanding once you have predicted correctly twice unaided, then internalizing once you have applied the idea somewhere new or caught a miss in Scaffold's own plan.
A level never gets revoked. It can get flagged for review after two misses in six weeks, and the flag comes with the page to reread and the task that clears it, but it never drops you back down. The whole wiki lives in your own repo, gitignored, sent nowhere; sharing any of it with a mentor is a command you type, never a default.
That last part matters more than it sounds.
If I cannot explain why it works, I do not control it. I rent it.
The ledger is not a scoreboard. It is a running answer to that exact question, with dates and receipts attached, so "I think I understand this" stops being a feeling and starts being something you can point to.
Install it: run /plugin marketplace add kayashaolu/systemthinkinglab, then /plugin install scaffold@systemthinkinglab.
The speed objection
It is a fair worry, and the answer is not "no," it is "not by much, and on purpose." Scaffold runs a size gate: a typo-level fix skips the ritual entirely, and the full loop charges one bounded "struggle toll" per task, capped at minutes. If you tell it to just fix the thing, it pushes back once, then does it. It never holds work hostage.
That is the right way to think about the cost.
Spend your struggle budget where the understanding lives. Let AI have the rest.
You are not spending more effort. You are spending the same effort somewhere it compounds instead of somewhere it evaporates.
None of this is a verdict on the work you have already done
If you are the engineer in the opening paragraph, nothing here says your last year of commits was fake, or that using AI to write them was a shortcut you owe anyone an apology for. The study's low-scoring group still shipped working code. The question was never whether the code worked. It was whether the understanding came with it, and that is a property of the process you ran, not a property of you.
The loop is the fix, and the loop is available today, on the actual ticket you are about to open, not on some hypothetical rewrite of the last two years. Say what you think should happen before the AI answers. Make it defend the parts where you disagree. Build it together. Ask it to tell you, afterward, exactly what you demonstrated. And the question from the top stops being a feeling: the loop is what gives you an answer you can point to. You do not learn less by using AI. You learn less by using it in a loop that never asks you to predict, never pushes back, and never tells you what you actually showed.
Scaffold is free and it runs on real work today, no course required. If the loop above is one you want to run with more structure than a plugin alone gives you, that is what Course 0 is for. Scaffold is the tool. Course 0 is the method. The free path stays exactly that, free, whether or not you ever take the course.