8 min read ·
Let the junior get stuck
Anthropic ran an experiment this year: junior engineers learned a new library, some with an AI assistant and some without. The AI group finished two minutes faster and scored 17 points lower on the quiz. The biggest gap was on debugging.
The people with the assistant built the same thing and understood less of it.
I've started to think the most useful thing a senior engineer can do for a junior right now is the thing that feels the least kind: leave them alone with a bug for an afternoon.
Here's the study, because the details matter.
Fifty-two engineers, mostly early in their careers, all comfortable with Python, none of whom had used Trio, a library for asynchronous code. (Asynchronous code can pause while it waits on something slow, like the network, and let other work run in the meantime. It is a famous source of confusing bugs.) They were randomly split. One group got an AI assistant in a sidebar that could write the correct code at any time if asked. The other got no AI at all. Both built two small features in about 35 minutes, then took a quiz.
The no-AI group averaged 67%. The AI group averaged 50%. The speed difference was too small to be statistically meaningful.
The people without AI also hit more errors, and fixed them alone. The authors' hypothesis, which the study can't prove, is that this is why they did better on the debugging questions. Their own line is the one I keep coming back to: "Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery."
The more interesting finding is that the AI group wasn't one group. The people who handed the whole task to the assistant, or slid into handing it over after a question or two, averaged under 40%. The people who asked the assistant only conceptual questions, things like "how does this work" and "why would I use this", and then fixed their own errors, scored about the same as the people with no AI at all. They were also among the fastest.
Same tool. Same task. The difference was whether they let the tool do the thinking.
A second paper, from researchers at Carnegie Mellon, Berkeley, Oxford, MIT and UCLA, ran three randomized trials with 1,222 people. No code this time: fraction problems and reading comprehension. One group practised with an AI sidebar that would hand over complete answers on demand. Then the AI was taken away, and everyone did three problems alone.
The AI group solved fewer of them in all three trials. In two of the three, they also gave up more often, skipping problems they could have tried. The authors' explanation is that the assistant trained people to expect an answer right away, so when no answer came, they had less patience to dig for one.
That second part worries me more than the scores. Debugging is mostly the patience to stay with a problem you don't understand yet.
Now the limits, because both teams are honest about them. The Anthropic study had 52 people learning one new library in a single session of about 75 minutes, with a quiz straight afterwards, and the groups within the AI group are two to seven people each. The other paper measured five to twelve practice problems' worth of AI exposure, tested people right away, and used an assistant that hands over full answers, the most corrosive kind. Neither study shows that a year of AI use makes you a worse engineer. Neither even tries to.
What they show is narrower and, I think, more useful: in the moment of learning, the shortcut costs you understanding, and you can't feel it happening.
That last bit isn't new. Robert Bjork's lab at UCLA has spent decades on "desirable difficulties", the finding that practice which feels harder produces learning that lasts, while smooth practice produces confidence. As Bjork puts it: "What we can observe is performance, but what we have to infer is learning."
A passing test, the green tick, is performance. Whether the person who made it green could do it again is learning. AI tools are very, very good at the first one.
Take a made-up afternoon. Nothing in it is unusual.
Say you're four months into your first job, at a company that sells concert tickets. A bug report comes in: a show sold one more seat than the venue has. It happens rarely. You can't make it happen on your laptop.
So you start digging. You read the purchase code. It checks how many seats are left, and if there's at least one, it writes the sale. Looks fine. You pull up the logs for the bad show and find two purchases of the last seat, a few milliseconds apart.
And you stare at that for a while, because the code is clearly correct, and yet.
Somewhere around four in the afternoon it clicks. Both requests ran the check before either ran the write. Both saw one seat left. Both sold it. You have just met your first race condition: a bug that only appears when two things happen in an unlucky order. You prove it by adding a one-second pause between the check and the write, then firing two requests from two terminals. Now you can oversell the show almost every time.
You fix it by making the database check the seat count and record the sale in one atomic step: an update that only goes through if a seat is still free. The second request finds zero seats and fails. You go home tired.
Here's what you actually got from that afternoon. You now know that anywhere code checks something and then acts on it, there's a gap, and someone else can walk through the gap. You will see that shape for the rest of your career, in caches, in file systems, in payments, and once in a while in a cloud outage. You know how to make a rare bug happen on purpose. You know the logs were telling you the truth before you believed them.
Now replay it with an assistant. You paste the function and the bug report. It says this looks like a race condition and wraps the code in a lock, so only one request at a time can run that part. The tests pass. They passed before, too. Twenty minutes, done. What did you learn? That the fix for weird bugs is "add a lock." And the next time, when two locks leave two requests waiting on each other forever, you'll paste that too.
The bugs you fix alone are the curriculum. Nobody else can sit them for you.
The obvious objection: we all copied from Stack Overflow, the question-and-answer site, and we turned out fine.
Sure. But think about what that copying involved. You found an answer to someone else's question, with their variable names, their version of the library, their slightly different bug. Then you had to work out which parts applied to you and bend the rest to fit. Half the time it didn't work and you were back to reading your own code.
That leftover gap was where the learning lived. An assistant closes it. It answers your exact question, in your codebase, with your names. Nothing is left over for you to figure out, unless you choose to leave it.
This matters more now because the old path into the job is narrowing. Employment for 22-to-25-year-olds in the most AI-exposed jobs is already falling while older workers in the same jobs hold steady (Who signs the diff has the numbers), and the juniors who do get hired are handed a tool that can skip the part that turned juniors into seniors. If we're going to hire fewer of them, we owe the ones we hire the struggle.
So what does a team do?
Ask for the guess before the answer. When a junior brings you a bug, ask what they think is happening before you say anything. A wrong guess is fine. No guess means they haven't started yet, and neither has the learning. The same rule works for the chat window: write down your guess before you paste the stack trace (the list of function calls the program was in when it crashed), then see whose guess was right. It works in code review too: ask "how did you find it?" If the answer is "the assistant suggested it," ask why the fix works. If they can't say, send it back with a question, not with the answer.
Use the tools in tutor mode. Claude Code has a Learning output style that explains its choices and leaves the real design decisions for you to write, marked with a TODO(human) comment. ChatGPT has a study mode that asks you questions instead of handing you answers. Turn them on for anyone in their first year.
Stop rescuing at minute five. The urge to lean over and point at the line is strong, and it feels generous. Give it an hour. Check in, ask a question, walk away. Being stuck for an hour on a real bug is not wasted time on a junior's calendar. It's the only time on that calendar that compounds.
None of this is anti-AI. Some of the best scores in that study came from people with the assistant open. They used it to understand, not to skip the understanding.
The fix was one line. The afternoon was the lesson.