Every developer has felt it. You hit a gnarly bug, reach for an AI agent, and watch it write a fix in seconds. The effort vanished. The problem is solved. And you learned almost nothing from the exchange.
That gap, between the output you get and the skill you build, is the central tension of building software with AI. It is not about whether the code is correct. It is about whether you will be able to write the next one without the machine.
The strain is the mechanism
London cab drivers spend three to four years learning 25,000 streets from memory, a process called the Knowledge. Neuroscientists found that their posterior hippocampus, the part of the brain that holds spatial maps, was measurably larger than in other people, and larger the longer they had driven. There was a trade-off: the same drivers had a smaller anterior hippocampus and did worse at taking on new spatial layouts. The brain had specialised, hard, to the load the years demanded.
When GPS replaced that effort, the capacity atrophied. Researchers found that habitual GPS users had the worst spatial memory when navigating unaided, and the more they used it over time, the steeper their decline. The skill was handed to a machine and quietly wasted away.
The same thing happens when an AI writes your code. The effort of debugging, of tracing through the call stack, of holding the architecture in your head, that effort is the repetition that builds system-level understanding. Remove it and you keep the output. You lose the adaptation the doing leaves in you.
What testing yourself from memory proves
Psychologists have measured this directly. Give one group a passage to study by rereading it and another by testing themselves on it from memory. The rereaders feel more confident. On the exam a week later, the group that had to pull it back out of memory, the one that felt less certain, remembers far more.
The comfortable method felt like progress and delivered little. The uncomfortable one felt like failure and did the work.
When you let an AI agent fix every bug, you are the rereader. You feel productive. You are not building the mental model you will need when the AI is not there or when the problem is genuinely novel.
The irony of automation for developers
Engineers named this forty years ago: hand a task to a machine and the person's remaining job is to watch the machine and catch its failures, except that handing the task over is what wastes the skill the watching requires. Most of the time, checking a thing is cheaper than making it. You can offload arithmetic and keep enough number sense to know when a total is absurd.
The dangerous capacities are the ones that are their own only check. Whether an architecture is sound, whether a code review is thorough, whether a design handles the edge cases, those are judgements you feel only with the part of you that would have built it. Hand one of those over and you have kept nothing cheaper to catch the failure with. You need the very thing you are losing to know whether losing it is safe.
A personal example: I built a panel of AI judges to score my writing because I did not fully trust what the first model produced. They were good. They caught what I missed. But when I set their verdict beside a room of real readers, the machines had scored the work almost a full point higher than the people did. I had believed the higher number. The judgement I had handed over was certain the work was better than it was, and it had no way to know otherwise. I only found out because I asked.
Not all difficulty is sacred
Plenty of difficulty builds nothing. The twenty minutes lost to a broken interface, the boilerplate, the config file that refuses to validate. That kind is pure waste, and giving it to a machine is one of the real gifts of this era. Take the gift.
The other kind builds. It takes real effort and leaves a changed you, a capacity that stays after the task is gone. The two wear the same face, and from the inside they feel identical, both just resistance. One test does most of the sorting: when the task is done, look at what is left behind. If the only thing left is the finished task, that difficulty was only taking from you. If something in you is different, it was building you, and that is the one to protect.
Which difficulty will you keep doing the hard way?
The cabbies were made by a difficulty they were handed. They did not choose it, the city made it compulsory. No institution will impose ours. What ends, in a world where everything can be automated, is formation by default: nothing outside you will build you any more unless you choose to keep it.
For a developer, the question becomes concrete. Do you let the agent write the architecture and review it, or do you sketch it yourself and use the agent to surface the gaps? Do you paste the error into a chat or spend ten minutes tracing it? Do you ask the machine to perform the exact act you are trying to keep?
The answer determines not just what you ship today, but what you will be able to ship in five years.
This piece is adapted from "The Difficulty You're Escaping Was Making You." The full version, with all references and footnotes, is on Substack.
Top comments (0)