The worry I keep hearing is that people will forget how to write code. That's the wrong thing to be afraid of, and it's the comfortable thing to be afraid of, because syntax was always cheap and Googleable. What actually decays is harder to see: the patience to sit with a confusing system long enough to build an accurate mental model of it, which is the thing you need to recognize a plausible wrong answer.
I watch this most clearly in data work, where the model will happily generate a query that runs, returns rows, and quietly means the wrong thing because it joined on a column that looks like a key and isn't. Catching that has never been about knowing SQL. It's about having lived in the schema enough to feel that the number is too clean. The model produces the answer in four seconds, and the four seconds you used to spend being confused, the confusion that was actually building the model in your head, is exactly what got skipped.
So the atrophy isn't in the fingers. It's in the part that knows when to distrust the fluent output. And that part only ever got built by doing the slow version enough times to develop a sense for wrongness.
The strongest reply, which I half-believe: this is what every abstraction does. ORMs meant fewer people understood query plans, compilers meant fewer understood the stack, and the field absorbed it and moved up a level, freeing attention for problems that mattered more. Maybe judgment about plausible-but-wrong output just becomes the new fundamental we teach directly. The difference I can't argue away is that the older abstractions were deterministic. A compiler that's confidently wrong is a bug you can find. A model that's confidently wrong is Tuesday, and the only defense is the exact judgment the tool discourages you from building.