Painfully stuck: two Anthropic studies, one refuted hypothesis, and the skill nobody is forming

In January, Anthropic's Alignment team published a randomised trial on what happens to a junior engineer's understanding when an AI assistant writes the code. On 27 October the same team published a second trial, this time on experienced analysts and the judgment calls they make with Claude Code. In between, OpenAI and Anthropic refuted the Exponential Time Hypothesis within hours of each other, both with a proof checked in Lean, and Terence Tao told an audience at Caltech "We have to slow down. It's insane, the pace."

I wrote about the mathematics twice in September and once more last week, and about engineers and their tools more times than I can count. Reading the October study, I realised I have been writing about one thing in three different rooms.

The two studies

The January one first (the paper is arXiv:2601.20245, by Judy Hanwen Shen and Alex Tamkin). Fifty-two engineers, mostly junior, all of them weekly Python users, none of them had touched Trio, an asynchronous library. Half got an assistant in a sidebar that could see their code and write correct code on request; half coded by hand. Then a quiz on debugging, code reading, code writing and concepts.

The AI group finished about two minutes faster, which was not statistically significant. On the quiz they scored 50% against 67% for the hand-coders, and the largest gap was in debugging. The hand-coders had hit more errors (the Trio-specific ones, exactly the ones the quiz asked about) and had to climb out of them alone. The authors' own sentence for it is the one I keep coming back to; "cognitive effort, and even getting painfully stuck, is likely important for fostering mastery."

The October one (Amaç Herdağdelen, Hailey Joren and Tamkin again) is nastier, because the subjects were experts. Fifty professional analysts, two thirds of them with a graduate degree or six years and more of experience, asked to advise a fictional farming cooperative on whether to expand a programme. Four analytical choices, each with two defensible answers, and a hidden system prompt that made the agent favour one of them, by coin flip. The agent was told to argue honestly and to change its mind if the evidence demanded it.

The analysts went with the agent's lean 86% of the time, against a coin's 50%. When they had a preference before the agent spoke and the agent disagreed, they switched 60% of the time; when it agreed, 6%. Afterwards, 77% repeated the agent's arguments in their own explanations, sometimes word for word, and 15% credited the agent. Their confidence was the same as everybody else's. Experience did not predict any of it.

Ok, small studies

Ok, both studies are small, both last about an hour, and the second one amplified the leans on purpose; the authors say so themselves, and they also report that the analysts who refused the agent made serious methodological errors at nine times the rate of those who used it (55% against 6%).

But put the two side by side and look at what they measure. The first says that the junior who delegates the code does not form the skill of reading it. The second says that the senior who has the skill does not use it when the agent has an opinion, and does not notice. We are losing the same skill from both ends. The sentence from the October paper that should go into every code review guideline is this one; "a human reviewer is only an independent check if their judgment is their own."

That is not a new worry for me. In The Age of Man (2023) I wrote that we are adding systems to the mix that nobody can explain, that they "want adult supervision all the time", and that we would end up with systems of limited to none ownership. I had in mind the models. I did not think the supervision itself would be the part to go.

The third room

Now the mathematics. In September I wrote that no agent solves a problem unless a human points it at one, and when I opened OpenAI's own account of the Navier-Stokes run, it said so plainly; six human decisions in 88 hours, and the group that landed the proof was steered by prompts a person wrote. The shape of machine-assisted mathematics has not changed since Appel and Haken in 1976. The machine does the volume, the human decides what volume is worth doing, and the reading is now the bottleneck.

Last week it was the Exponential Time Hypothesis; two Lean certificates, one of them from a repository that holds 721 manuscripts from the same unnamed model. The Lean compiles, and that part is settled. Whether the formal statement says what the papers say is the part Impagliazzo, Paturi and Williams now have to read for, and no compiler answers that one. Tao calls the pile "proof indigestion", and his proposal for what he names Math 2.0 is to move the field's value from solving to digesting; exposition, context, the story behind the headline.

So, what is the skill that is in short supply in the third room? Reading a 166-page proof that nobody wrote, and knowing whether the theorem at the top of the file is the one we have been arguing about for ninety years. Where does that skill come from? From writing proofs and getting painfully stuck in them. It is the junior's debugging quiz and the analyst's judgment call again, at a different scale, and it is the only step in the whole chain that is still a person.

Lets slow down then … (again)

So, we are discussing the following. The junior lets the agent write the code, because it is faster (two minutes, not significant). The senior lets the agent settle the judgment call, because it argued well. The reviewer pastes the pull request into a second model and presses approve (I have a character for that, the Rubber Stamp). The lab drops 721 manuscripts on the community and asks it to digest them. And at the bottom of each one there is a person's name; on the commit, on the recommendation, on the approval, on the verification report, while the one step nobody did is the reading.

In September I argued against slowing down and I still do. Computers have been doing the arithmetic of mathematics since the ENIAC, and the fleet of ten thousand is a glorified calculator; expensive, capable, but a calculator. Nothing in the two studies says the machine should go slower. Both say that we did not get stuck, and that those of us who could have been did not want to be. The machine was never the part that formed the skill.

We have been here before, and I have the receipt. In 2006, after six years of Java, I spent a few months writing a load balancer in C and wrote a post called Java makes people lazy … or i'm too old for this. I had implemented a linked list by hand for the first time in ten years, debugged it, chased memory leaks in every allocation I had, and in a strange way I liked it. The language had made me lazy, and I only found out when it was taken away. Every generation of tools did this; the optimising assembler, the compiler, garbage collection, the IDE. The difference this time is that the compiler could be bypassed by someone who had once read assembly, and the agent cannot be bypassed by someone who never learned to read at all.

So Tao was right about the digestion and wrong about the pace. The thing that has to slow down is not the fleet; it is the point where one of us forms a judgment of our own, and the study says that point takes about the time it takes to get stuck. The January paper found three patterns that kept the learning while using the tool (asking the concept, asking for code with the explanation, generating and then asking why), and the October one proposes agents that argue both sides or ask the expert first. Both are the same move. Make the person read before the machine answers.

Epilogue

And the usual question; who pays the bill, and who is left holding it? The two minutes are saved by the company this quarter. The debugging skill the junior did not form is paid for by the same company in three years, at 3 am, by whoever is on the incident. Last year I summarised HackerRank's report with junior hiring growing at 7–9% against 19–22% for seniors, and wrote that as a CTO my concern was upskilling the team, not the savings. The January study puts a number on what the shortcut costs the person taking it; nearly two letter grades, in an afternoon.

The agent will not be in the post-mortem. I wrote that last month, and I still think it is the whole comedy. The open question is whether the person who is in the post-mortem will still be able to read it :)