It's not atrophy, it's a mismatch

This week an article by Lars Faye, Agentic Coding is a Trap, made the rounds and stirred up some corners of the field. Its thesis: the workflow the industry is selling — the AI writes the code, the human stays on as orchestrator — is a trap. And among the costs it lists, one names the fear underneath all of them, a word that recurs through the piece and is worth looking at closely: atrophy. Skills atrophy, it says; and the cruel part is that the ones that atrophy are exactly the ones you need to supervise the machine. He calls it the paradox of supervision.

Let me start by granting what the article gets right, because it’s a lot and because I feel it too. There is a real cognitive debt when the prompt becomes the artifact you keep and the code becomes exhaust you never read: you can lose your grip on a system you nominally own. There is a real exhaustion in shipping more while feeling less sure of any of it. Those symptoms exist, I’ve lived them, and naming them isn’t Luddism: it’s describing a craft shifting under your feet. My disagreement isn’t with the symptoms. It’s with the diagnosis, and with what that diagnosis invites you to do.

The real trap

The real trap isn’t agentic coding. It’s folding distinct problems — the cognitive debt, the junior who never gets trained, the senior who fears for their job, the feeling of not being able to keep pace — into a single word, atrophy, and presenting them as one thing, unsolvable. Because once a phenomenon is framed as unsolvable, the only response left is to take a position against the tool that causes it. And that’s the catch: the harms are different, not one; several are solvable; and there are people — myself included — already at work mitigating them with some success. Calling every affected person to form one front against the machine, as if they shared a single wound, is the move that actually closes doors.

”Atrophy” is the wrong word

Atrophy means a precise thing: a capacity that grows smaller, that diminishes. A muscle that shrinks because it stopped being used. To claim the AI atrophies programmers, you’d need to show cognitive capacities measured and diminished, and that experimental basis doesn’t exist. What exists are people who code less and report feeling rusty, which is a different thing.

Take the case invoked most often, the junior developer. The story goes that they no longer devise algorithms, that they only read and review generated code, and so they never learn. Fair enough — but that isn’t atrophy. It’s truncated training, a distinct phenomenon with distinct causes. Atrophy takes away something you had; truncated training keeps you from acquiring something you never had. And it’s worth asking where that review-only junior is actually working: in a sandbox whose output never reaches the public? Because the argument rests on a premise we never say out loud — that the human programmer was infallible, that they didn’t make those mistakes. We built an entire discipline — code review, linters, postmortems — on the opposite premise. (I wrote about that in The immaculate programmer.)

There’s something in the word that gives away its function. Atrophy makes the harm feel intimate, like damage to your mind, your body. It reminds me of someone who claims to be sick because they can “feel” electromagnetic waves. The malaise is real, I don’t doubt it; what’s wrong is the cause assigned to it. And assigning the wrong cause isn’t a small thing: it’s what sends you off to fight the wrong antenna.

What actually happens: the mismatch

So what is it that you feel? Not a diminished capacity, but a new distance. The machine has accelerated, astonishingly, the speed at which code gets written. I’ve watched with my own eyes how work that took a team of twenty programmers ten months — grinding hours and countless “agile” meetings — gets finished by a few AI agents in a couple of weeks. The code is no longer the bottleneck. We are.

But being outrun by that speed is not atrophy. Imagine you’re asked to solve a problem in one hour, and the answer is spread across four hundred books you’d have to read first. You wouldn’t fail because your mind had shrunk. You’d fail for lack of time. Your capacity to read and understand is intact; what falls short is the bandwidth to match it to the pace being demanded. That’s what happens in front of an agent at its best: there is no atrophy, there is a mismatch between your cognitive speed and its own. And that mismatch, that failure to pair, is what shows up as vulnerability, helplessness, abandonment — a feeling that turns to dread when your salary, your livelihood, your job are also on the line.

It’s economics, not physiology

Because that’s the problem underneath, and it isn’t physiological. It isn’t that your brain shrinks. It’s that the work you did may stop needing you, or may never exist at all for those coming up behind you. That threat is real. But it isn’t the tool’s fault. It’s the fault of a mode of production that puts productivity above people, and that offloads the cost of every technical leap onto whoever works.

It isn’t the first time, not by a long way. We saw it with the arrival of machines — the steam engine, the sewing machine — and with new methods of producing — the assembly line, Fordism, Toyotism. And every time there was resistance and reaction against the machines that threatened to displace skilled labor: the craft guilds, and in their most violent form, the Luddites smashing looms. The novelty today isn’t the dread; that’s old. The novelty is the word we name it with. Calling it atrophy medicalizes what is really an economic conflict, and by making it intimate — a flaw in you, in your mind — it distracts us from where the dispute actually lies.

What the article senses correctly

And yet Faye senses something, and I’ll grant it: the work that will persist is the orchestrator’s, the one who decides and directs — the architect’s. I think he’s right about that. He just doesn’t get there by way of atrophy. He gets there because, once the machine carries the typing, what’s left on the human side is judgment, and judgment becomes the craft’s center of gravity.

Those who champion AI-augmented engineering propose to solve the role problem along that line: that every junior be trained no longer as a coder but as an architect, learning from the start to hold the baton and to solve from a bird’s-eye view. I find that a natural way out of the role problem, but it doesn’t solve the other one, the problem of numbers: there’s no room for everyone who used to be a programmer to now be an architect — not in the labor market, and not vocationally, because not everyone wants to direct or should. So we have distinct problems, in distinct roles, under common threats. The solutions now emerging will help some, but they won’t save everyone. And pretending one word covers them all is exactly what keeps us from tending to each.

Pair, don’t slow down

If the real problem is the mismatch, then the answer isn’t Faye’s — slow the machine, demote its role, type eighty percent of it by hand again so you don’t lose the muscle. That treats the wrong symptom. The answer is to pair: close the distance between your bandwidth and the machine’s, so you can stay in command at its speed without having to hold the whole system in your head.

That’s what I’m building in StrayMark, and I call it cognitive pairing. The idea is to put knowledge, not just information, in front of the person: not a data dump for a machine to query, but a map a human can stand inside — seeing what was decided and why, what’s in flight and where it’s headed — and make a call, fast. A map doesn’t slow you down; it’s how you move fast without getting lost. It isn’t about needing the machine less, or about it needing you less. It’s about a pairing where each runs at its own speed without the human left dumbstruck, watching work go by that they no longer understand. The mismatch isn’t cured by decelerating the machine. It’s cured by giving the human a better place to stand and look from.

You didn’t atrophy. You read four hundred books in an hour, and no one gave you the library map.

(This is a companion to I don’t want an AI that needs me less, where I made the case for keeping the human in the loop as the load-bearing element, not the inefficiency to remove.)