She asks the model how to do the thing, a correct answer arrives inside a minute, and she uses it. What she does not do, because there is no longer any occasion to, is sit with the problem long enough to know why the answer is correct. The code works. It goes in. She has solved the task and skipped the understanding, and nothing in her day marks the second thing as missing.
This is the third and last Sunday of a series that began at provenance and passed through sovereignty. The first two were about the thing depended upon, the code one did not write and the model one cannot fork. This one is about the person doing the depending, because last Sunday closed on her: the engineer who no longer needs to understand the thing she leans on. The earlier questions were about a licence and a weight. This one is about a muscle, which is a good deal harder to legislate for.
The Muscle That Atrophies
Understanding was never a possession you acquired once and kept on a shelf. It is a practice, and like any practice it is kept up only by use. The first Sunday of this series said as much in passing; it turns out to be the whole of the third. What a working engineer understands, they understand because they spent years doing the understanding by hand, poorly at first, and the doing is itself the knowledge, there being no shorter road to the same place.
The point is not new, only newly urgent. In 1983, in a paper on the ironies of automation that has aged with some dignity, Lisanne Bainbridge observed that when you automate most of a task the operator stops practising the parts the machine now covers, and the skill wastes for want of use; the present generation, she added, rides on the competence of the manual operators it replaced, which the next generation will not have. The description was meant for power stations and aircraft, and it fits an engineer with a model open in the adjacent pane rather better than either.
There is a modern measurement of the mechanism. A 2025 study from Microsoft Research and Carnegie Mellon, covering three hundred and nineteen knowledge workers and nine hundred and thirty-six recorded uses of these tools, found that the more a worker trusted the tool the less critical thinking they brought to its output; confidence in the machine and effort of one's own ran in opposite directions. Which is a roundabout way of saying that we scrutinise the machine least exactly where we have trusted it most.
The skill does not depart with a bang. It goes in the small moments where the question of why a thing is correct once got asked and now does not, a plausible answer being already on the screen and the schedule being what it has always been. What wastes is the particular faculty this section has spent a year admiring: the habit of thinking a whole machine through. It is the thing behind a Unix tool that does one small job and composes without fuss, and behind a demo that folds a world of wonders into sixty-four kilobytes. None of that comes of accepting a plausible answer; all of it comes of the sitting-with that a plausible answer removes the occasion for. You do not lose it by deciding to. You lose it by never again needing it.
The Reviewer Who Cannot Review
Which would be a private loss, a matter of personal craft, were it not for the first Sunday of this series, where the law was quietly waiting. The revised Product Liability Directive brings software and AI systems inside the definition of a product from December of this year, and a Californian statute, AB 316, has already shut the exit marked the machine did it; between them the principle is settled, that the entity shipping the code owns the code, whatever first wrote it. Review, once a courtesy the schedule tended to skip, is becoming a duty the law assumes you performed.
Set the two beside each other and the bind is plain. You are answerable for the code you accept; you can review only what you understand; and the understanding is the very thing the accepting was letting you skip. Bainbridge saw this sharp end too. Manual takeover is called for exactly when the process has gone abnormal, so what is wanted at that moment is more skill rather than less, arriving just when the operator has practised least. The reviewer who has waved through a thousand correct answers without following one of them is, on the day the thousand-and-first is wrong, the least equipped person in the room to catch it. The liability stays with the name on the commit. The competence to discharge it has quietly gone.
We make poor witnesses to our own standing here, which is the awkward part. In a controlled trial published in 2025, METR found that experienced developers working on code they knew well were nineteen per cent slower with AI assistance than without, and came away convinced they had been some twenty per cent faster.
The confidence that licenses one to skip the understanding turns out to be the confidence with the least behind it, which is the Microsoft finding a second time, arriving by another road.
The Limit
It would be easy, and wrong, to read this as a brief for doing everything by hand. Abstraction has been retiring skills since programming began, and the retirements were mostly progress. Almost no one counts machine cycles by hand any more, the compiler having turned out to be better at it than we are; garbage collection saw off the manual sweeping of memory a generation ago, and nobody has written in asking for it back. Mourning the assembler is nostalgia, not argument, and a discipline that cannot tell a lost convenience from a lost capacity is merely sentimental.
Two honest concessions, then. The gains are real, and this series has said so twice: the tools cross the blank page, and they put a competent first draft within reach of people who had none of one before. And the evidence is softer than a headline would prefer; the authors of that slower-with-AI trial now file their own result under history, the tools having moved on beneath it, and it was a thin slice of seasoned engineers on code they already owned. This is not the claim that the machine makes you slower.
The claim is narrower, and it outlives the concessions. Some skills are conveniences, and the tool may keep them for you, and welcome. One is not. The capacity to understand the thing you depend on well enough to check it is the ground judgement stands on, and it is the single skill an answer machine is built not to return to you, since it works precisely by removing the occasion to practise it. The question was never whether to use the tool. It is whether you are still keeping up the one practice that lets you notice when it is wrong.
The Point
Three Sundays, and three things you can import: the code you did not write, the model you cannot fork, and now the answer you did not have to understand. What does not come down the wire is the judgement that only the understanding confers, and judgement was the whole of what sovereignty, at this layer, ever amounted to. The ability to read the thing you lean on, and to check what you carry.
The weight you cannot read was never only the model's. It becomes yours on the day you can no longer read it either, and no notice is sent when that day comes. It is felt, if it is felt at all, as the absence of a question you used to ask.
Understanding is a practice, not a possession. You do not lose it by deciding to; you lose it by never again needing it.