Main idea

A skill that everyday work no longer calls on doesn't maintain itself. A developer who asks an assistant to read, explain and fix on their behalf keeps the dexterity of steering the tool and gradually loses the ability to read unfamiliar code, sustain a diagnosis or simplify an architecture.

The remedy isn't to give up the tool, it is to create situations where it isn't available: AI-free dojos, exercises with a deliberately limited assistant, reviews where you have to explain the code yourself, moments taken on purpose to read, understand and simplify. The same logic is accepted elsewhere without argument — a calculator is useful, but never working a sum out yourself creates dependence; in sport, you add weight and resistance because resistance is what builds muscle.

This isn't nostalgia for the developer who must suffer to earn their craft, and the goal isn't to slow everything down. It is to slow down in the right place: producing very fast part of the time, and ring-fencing long stretches — a day of continuous improvement, architecture reviews, ADRs, slow refactors, post-mortems on botched generations — to understand what was produced.

Why it matters

This addresses a gap no production rule covers: the counter-measures that protect the quality of the system don't protect the aptitude of the people who hold it. A team can apply impeccable merge discipline and let the very skill that would let it judge what it merges die out.

It also gives a reading of a problem that predates the tooling: many developers were already heads-down, producing without taking the step back that grows skill. The acceleration makes that worse if it fills all the freed-up space with more production, and corrects it if it serves to separate the time for doing from the time for understanding.

Nuances and limits

The difficulty added has to resemble the real craft. An artificial exercise maintains ease at the exercise, not the skill you were after — and a badly chosen constraint costs time and trains nothing.

And some skills rendered unnecessary deserve to disappear: nobody practises writing assembly to stay lucid about their code. Telling what must be maintained from what can be given up is an open judgment call this idea doesn't settle.

Open questions

• By what sign does a team notice that a skill has died out, when its daily production hadn't called on it for a long time and looked perfectly normal?