Jetable vs Durable : Quand la qualité du code compte encore avec les agents IA
Les agents de codage IA ont changé le volume de code que les équipes peuvent produire. Ils n’ont pas supprimé le besoin de jugement sur quel code mérite un investissement.
La récente keynote de Max Kanat-Alexander à AI Engineer NYC 2026 donne une règle de décision claire : la qualité du code a toujours existé pour deux raisons — comprendre un système et le modifier en toute sécurité. Tout le reste (structure, tests, lisibilité, revue) est au service de ces deux objectifs.
Quand ces deux objectifs cessent d’avoir de l’importance, la qualité cesse d’en avoir.
Le logiciel jetable est maintenant le volume par défaut
Kanat-Alexander décrit une catégorie qui a toujours existé mais qui est sur le point de devenir bien plus courante : le logiciel jetable.
Il a :
- Des conséquences minimales ou nulles en cas d’échec
- Peu (ou aucun) dépendants humains ou systèmes
- Un coût quasi nul pour le jeter et le régénérer
- Essentiellement aucune charge de maintenance à long terme
Dans ce monde, les risques cumulés que les pratiques de qualité étaient conçues pour prévenir disparaissent en grande partie. On peut traiter la sortie comme temporaire. Les agents rendent cette catégorie pratique à grande échelle parce que la régénération est bon marché.
Le logiciel durable est l’opposé : longue durée de vie, de nombreux dépendants, de vraies conséquences en production, coût élevé de la perte de compréhension. Pour ce logiciel, la qualité compte encore — et d’une certaine façon compte plus, parce que le coût de l’opacité se compose de façon non linéaire.
La question pratique pour les équipes n’est plus « la qualité compte-t-elle ? ». C’est « quelles parties de notre système sont jetables, et lesquelles sont durables ? »
Regardez la keynote : Does Code Quality Still Matter? — Max Kanat-Alexander
Les usines logicielles s’intègrent à la distinction
Les talks récents sur les workflows agentiques pointent dans la même direction.
Le cadrage de David Ondrej des usines logicielles (collections de boucles d’agents avec déclencheurs, skills, checks et portes humaines) est le plus utile quand l’usine est autorisée à produire beaucoup de travail intermédiaire jetable tout en protégeant le noyau durable. Les checks planifiés, le triage de bugs, les prototypes exploratoires et les analyses one-off peuvent tourner avec des standards plus légers. Les changements d’architecture, les bibliothèques partagées et les plans de contrôle de production ne le peuvent pas.
Kerim Satirli (HashiCorp) décrit le traitement des agents plus comme un pipeline CI/CD contraint que comme un junior engineer libre. Les règles de prompt sont des demandes ; les contraintes dures et les checks déterministes sont les vrais garde-fous — surtout sur l’infrastructure qui est durable par nature.
La règle de Carlos Kelkboom — jeter le code généré dès que tu ne le comprends pas — est une application directe de la scission jetable/durable. Si tu ne peux pas l’expliquer, il n’appartient pas à la surface durable.
Règles pratiques qui en découlent
- Classifie avant de générer. Pour tout travail non trivial, décide d’avance : durée de vie attendue, rayon d’explosion, nombre de dépendants, coût de remplacement. Écris-le.
- Garde un plancher de sécurité partout. Même le code jetable ne devrait pas fuiter des credentials, ouvrir des opérations destructrices sans confirmation, ou laisser des secrets dans les logs. La sécurité et la vie privée ne sont pas optionnelles juste parce que le code est temporaire.
- Concentre la rigueur sur la surface durable. Tests, propriété, observabilité, revue et structure claire appartiennent aux parties qui seront encore là dans un an et dont d’autres systèmes dépendent.
- Rends la rigueur bon marché. Le second levier de Kanat-Alexander est de réduire le coût de faire la bonne chose : standards, outils in-workflow, tests faciles et strictness maximale pour que le chemin de moindre résistance soit le chemin sûr. Cela empêche le travail durable de devenir un goulot.
- Conçois pour le jetable là où ça aide. Isole les expériences, garde le couplage bas, préfère la régénération à la maintenance héroïque de scripts jetables, et évite de promouvoir accidentellement du code jetable dans le noyau durable.
Comment cela s’inscrit à côté de la vue goulot
Un post précédent couvrait comment le goulot s’est déplacé de l’écriture de code vers la revue, la confiance et la vérification. Le cadre jetable/durable ajoute la classification manquante : pas chaque changement généré ne mérite le même budget de vérification. Les équipes qui traitent tout comme durable se noieront dans la revue. Les équipes qui traitent tout comme jetable accumuleront des systèmes opaques et à haut risque.
La compétence à fort levier est de trier correctement les deux, puis de faire tourner des usines d’agents qui génèrent librement côté jetable tout en protégeant la compréhension et la sécurité du changement côté durable.
Sources :