Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Angle
A contained bug, a simple endpoint, a script, a standard test, a modest refactor: these tasks did not merely keep a team's junior developers busy, they manufactured them — and they are exactly the ones a coding assistant produces best. The acceleration therefore does not first remove positions, it removes three mechanisms by which a software team reproduced its own competence: the cost of code, which forced you to understand before moving on; the small size of the system, which kept errors analysable and therefore instructive; the first rung, which exposed a beginner to the resistance of the real without endangering the product. None of the three was a deliberate practice — they were the side effects of a slowness nobody ever had reason to defend — and that is why nothing replaces them on its own when it falls away. What replaces them has to be decided and written down: never merge code nobody can explain, tie tests to functional behaviour, keep a catalogue of approved patterns, treat a failed assistant output as a missing directive, and judge the system on what you could rebuild of it rather than on what it shows on screen.
Synthesis
The first thing these notes contribute taken together is to separate what the usual discussion conflates: the degradation of code and the degradation of competence. The first is old and the assistant changes only its throughput; the second is new, and it is the one with no known remedy.
The three lost mechanisms are not three examples of the same fact, they form a chain. The cost of code produced understanding at the moment of producing; the modest size of the system made an error traceable to a decision, and therefore usable afterwards; the entry-level tasks supplied the occasions for error themselves. Remove the first, and the system grows faster than the learning loop, and the second falls with it. Remove the third, and there is nothing left to analyse at all. The acceleration therefore strikes the chain at all three links at once, and by the same gesture.
To this is added a pressure that is not technical. Learning time has not changed in duration, but everything around it has sped up: its relative price has jumped, and every local trade-off now favours the fast route without any decision having abolished training. That is what makes the loss invisible — it is nowhere observable, it accumulates.
The last piece is forward-looking and it moves the stakes outside the team: a profession's practices are not deduced by rereading previous ones, they are born from ground that resists. Idempotency, retries, circuit breakers, observability came out of outages and migrations lived through, not out of a catalogue reread. A generation no longer directly facing that resistance inherits the existing patterns without the means to invent others.
There remains what these notes propose in return, and it has a coherence: each counter-measure explicitly reinstalls one of the fallen mechanisms. Reconstructibility makes verifiable the understanding that the cost of code used to guarantee along the way. Refusing to merge unexplained code puts an immediate price on what understanding debt would charge later. The pattern catalogue restores the constraint of homogeneity that slowness imposed through sheer fatigue at reinventing everything. Analysing failed outputs turns failure into learning instead of a throwaway correction. And deliberately reintroduced difficulty — dojos without an assistant, reviews where you explain the code yourself — takes on what the others do not cover: a competence that daily use no longer needs dies out if nothing calls on it.
Tensions / contradictions
These notes do not agree on whether the loss is inevitable. Those describing the broken chain assume learning went through producing; those that qualify it point out that an assistant used as a tutor — explaining, comparing, making you verbalize, simulating a review — teaches part of what the first rung taught. If that substitution really works, the chain is not broken, it is displaced. Nothing here settles it, and the disagreement bears on the share of learning that requires having been responsible for the result.
Second disagreement, economic: the acceleration also funds what it threatens, since the time saved on production could pay for the learning. The thesis says that time redistributes by default towards more production; it does not say it cannot be allocated elsewhere.
Third point of friction, this one internal: the short loop these notes defend has a flaw of its own. It teaches the local gesture and never exposes anyone to system effects, which appear only at scale and late. A team that protected only small analysable errors would train developers blind to what actually breaks in production.
Questions
- Which of these counter-measures actually produce competence, and which produce only its documentary trace? Writing an architecture decision and knowing how to take one are not the same thing.
- What indirect exposure to the resistance of the ground — a post-mortem of an outage you did not live through, an operations trace, another company's public incident — is enough to bring out a new pattern, and what only transmits the pattern already found?
- How does a team recognize it has crossed the threshold where nobody can explain the system it maintains any more, other than by waiting for the outage that will teach it?
- In an organization that recruits already-trained profiles, at what level — the company, the industry, the school — should the cost of the first rung be borne, given that no player can recruit from outside the whole it belongs to?