The observation
The people who get the most out of an LLM, in my experience, are not the people who are newest to code. They are the people who wrote a great deal of it before the models existed. They read a generated diff the way an editor reads a draft: quickly, and with a clear sense of which sentence is wrong. They know what "good" code looks like, because they have written bad code and lived with it. They have built systems large enough to fail in interesting ways, and they know which parts of a system matter and which parts nobody will ever look at again.
That head start is real. It is also the thing most at risk.
Why the head start is real
An LLM produces plausible output at a speed no person can match. Plausible is not the same as good, and the gap between the two is exactly what experience measures. A senior programmer can look at a working function and see that it will be painful to change in six months. They can see that the abstraction is in the wrong place, that the error handling is decorative, that the test covers the happy path and nothing else.
None of this is in the prompt. It is in the person. The model can generate a hundred versions of a module; it takes someone who has maintained a module like it to know which one to keep. This is the same argument I made in the piece on the architect becoming the bottleneck: implementation is getting cheap, and judgment about implementation is getting more valuable, not less.
The danger is stopping entirely
The danger is not that senior programmers use the model too much. It is that they stop programming altogether, and the judgment that made them good at directing the model starts to decay.
Taste in code is not a fixed asset. It was built by writing, debugging and rewriting, and it is kept alive the same way. A programmer who only reviews, and never writes, is living off a balance that is no longer being topped up. For a while nothing looks different. The reviews still sound confident. The architecture calls still sound reasonable. Then the language changes, the framework changes, the failure modes change, and the reviewer is still checking for the problems of five years ago.
I have come to think of this as the quiet version of brain rot. It is not a dramatic loss of skill. It is a slow drift from knowing why something is right to remembering that it used to be right.
The principle, in one sentence
Experience is what makes the model useful, and experience only stays current if you keep doing the work it came from.
The practical version is simple. Hand the model the parts that are genuinely routine. Keep writing the parts that are hard, unfamiliar, or close to the core of the system, by hand, often enough that the hands still know how.
What I am not saying
I am not saying senior programmers should avoid LLMs. They are the group best placed to use them, and refusing the tool would waste the head start this piece is about.
I am not saying every line should be typed by a person. Most code is routine, and routine code is exactly what the model should write.
I am not saying juniors are doomed. The question for someone starting out is a different one: how to build the judgment in the first place, when the model will happily skip the struggle that builds it. That deserves its own piece.
The claim is narrower. The edge that experience gives you is perishable, and the model, used without care, is very good at letting it perish.
Where this connects
This is the counterweight to the new-literacy argument. There I wrote that the new literacy is conceptual: you do not need to write the Dockerfile, you need to know why the container exists. I still think that is the right direction for most people. This piece adds a condition for the people whose job is judgment: concepts held without practice go stale, and the practice is the part that is easiest to give away.
It also sharpens the 0→1 note. The model is strong at the first version and weak at the hundredth, because the hundredth depends on history. The person who carries that history has to keep touching the code, or the history stops being theirs.
And it is the same split as the dirty-work piece: the system does the routine, the person does the judgment. The addition here is that judgment is not something a person has. It is something a person keeps doing.
What the literature already says
Lisanne Bainbridge, Ironies of Automation (1983). Bainbridge's point, written about industrial control rooms, is that automating the routine work leaves the operator with only the hardest cases, while removing the daily practice that kept them able to handle those cases. The more reliable the automation, the less skilled the person who has to step in when it fails. Replace "operator" with "senior programmer" and the paper reads as if it were written last year.
Michael Polanyi, The Tacit Dimension. We know more than we can tell. The senior programmer's sense that a design is wrong is mostly tacit, and tacit knowledge lives in practice. Stop the practice and the knowing goes with it, quietly, without anyone noticing the moment it left.
A postscript
The test I would apply to myself is a plain one. When did I last write something hard without the model, and could I still do it today? If the honest answer is "a long time ago" and "not sure", the edge is already being spent.