Which developer skills actually decay when a coding assistant is always available, and which do not?
answer
- Not everything in the loop decays
- Recognition outlives recall
- Losing a skill versus never building one
- The tool picks the step you stop doing
- Keep a practice, not a volume limit
basics
~10 sFluency at producing routine code decays first and returns quickly. Judgement decays only if you stop exercising it, which accepting makes easy. The costlier loss is a model of the system you never built.
solid answer
~50 sSeparate two different losses. **Atrophy** is losing something you had: producing routine constructs from memory goes first, and it comes back quickly, because the reference is right there whenever you need it — it is the least worrying loss and the one people worry about most. **Non-acquisition** is never building the skill in the first place, and it is the expensive one, because judging a change well needs a model of the system it lands in, built by working through problems rather than by accepting answers to them. Judgement sits between the two: exercised more when you genuinely evaluate what comes back, lost quickly once accepting becomes automatic, because accepting is cheaper in the moment. So the deliberate move is not "use the tool less", which names a volume rather than a practice. It is choosing which practice you keep, especially in the areas you will later be asked to judge.
go deeper
Notice which step you have stopped doing rather than how often you reach for the tool. If you could not have written the change you just accepted, that area is where your own time is worth spending.
Explain the difference between a skill you are losing and one you never built, and say why the second costs more when you are later asked to judge work in that area.
Name the practice you deliberately keep and why you chose it, and show that you treat "I cannot judge this" as something to say out loud rather than something to cover.
Own where the team's understanding may thin out and where it may not, and accept the cost of the slow path in the areas where being wrong is expensive.
## Atrophy is not the interesting risk The worry people voice is that they will forget how to write code. That loss is real, and it is the cheapest one on the list: recall of routine constructs fades when you stop producing them from memory, and it comes back quickly, because the reference is at hand the moment you need it again. Recognition survives long after recall does, which is why a developer who cannot produce something from memory can still read it perfectly well. The loss worth talking about is different, and it is not a loss at all in the strict sense. **It is a skill that never gets built.** A developer who has only ever accepted suggestions in some part of the system has a much thinner model of that part — the problem is not a decayed skill but one that was never built up — and a model is precisely what evaluating a change requires. Judging whether a change is right is hard without some sense of what else it could have been. ## What moves, in which direction, and why | the skill | what heavy assistance does to it | why | |---|---|---| | producing a routine construct from memory | fades first, returns quickly | recognition outlives recall, and the reference is usually to hand | | a working model of the part of the system you are changing | does not decay from tool use, but stops growing where you only ever delegate | models are built by working a problem, not by reading a solution to it | | judging whether a change is right | exercised more if you genuinely evaluate, lost quickly once accepting is automatic | evaluation is a practice, and skipping it is cheaper in the moment | | working on something nobody on the team wrote | harder | the usual first move, asking the person who wrote it what they meant, has no target | | deciding what is worth building | not sharpened by heavy use, though cheap building shifts what gets proposed | the tool performs the step below it, not this one | Two things in that table are worth saying out loud, because they are what a thoughtful answer contains and a reflexive one does not. First, **not everything decays** — some skills get more exercise than before, because there is more output to judge than there used to be. Second, the direction is conditional in every row: it depends on what the person kept doing, not on how heavily the tool was used. ## The tool quietly chooses which practice you drop Almost nobody decides to stop drafting. Drafting simply stops happening, because something else does it first and the result is usually good enough to work with. Whatever step the tool performs by default is the step that leaves your week, and it leaves without a decision being taken about it. That is why remedies phrased as volume do not work. *Use it less* names no practice, so it survives about as long as any resolution with no target, and it is quietly abandoned under the first deadline. A remedy has to name the thing you are keeping. ## What a team can do on purpose - **Choose the practice you keep, not the volume you allow.** Decide which step you will still do by hand, and where. - **Make the first pass through an unfamiliar area a human reading pass.** The part of the system you will later be asked to judge is the part you need a model of. - **Rotate ownership of the areas nobody wants**, so understanding does not concentrate in one person's head and leave with them. - **Make "I could not have written this, so I should not be the one approving it" a normal sentence.** Social pressure removes that sentence long before any skill decays, and it is the single most valuable habit on this list. - **Take the slow path deliberately where being wrong is expensive**, and budget for it rather than hoping it happens. - **Check the assumption rather than trusting it.** Whether the person who merged a change can explain its shape is observable, and tells you more than any theory about decay. ## What nobody actually knows How much skill decay happens, to whom, and how fast is not settled, and no single figure could settle it: it depends on what people were doing before, what they now delegate, and what their team asks them to defend out loud. Anyone quoting a number for it is describing their sample, not your team. What you can reason about is the mechanism, and the mechanism is not mysterious. **A practice you stop doing gets worse, and the tool decides which practice you stop unless you decide first.** An answer built on that holds up; an answer built on a remembered statistic does not, and the interviewer usually knows the statistic better than you do. ## What an interviewer is listening for Two answers fail in the same way. *There is no downside, the tool just removes work nobody needed* and *it makes everybody worse* are both unconditional, and the honest answer to this question is conditional in every part. Name which skill, in which direction, under what conditions, and say what you do about it in your own work.
- A developer says the tool made them faster but they can no longer work without it. Is that a problem?It depends where. In an area they will never be asked to judge unaided, it is the ordinary dependence everyone already has on their tools. In a system they review, sign off, or get called about at night, it is a problem, because judging what comes back rests on being able to produce something comparable yourself.
- How would you tell atrophy apart from never having acquired the skill?Ask what the person can explain, not what they can type. Someone who once had the fluency can usually reconstruct why a change is shaped the way it is and where it would break. Someone who never built the model can say what the code does but not what else it could have been.
- Does the same reasoning apply to a senior engineer entering an unfamiliar codebase?Yes, and that is the useful test of it. Seniority is not a model of this system; it is a faster route to building one. A senior who delegates every first encounter with an unfamiliar area ends up in the same position as a junior who never wrote in it, just with better instincts about when to be suspicious.
saying these in an interview costs you the question
- Nothing decays; the tool only removes work nobody needed
- A skill the tool has is one you no longer need, even to check its work
- Reading a suggestion builds the same understanding as producing one
- Skill loss only affects juniors
- Using the tool less often is the whole fix
- Every skill lost to the tool returns as soon as you need it again