Dave Farley, fondateur de la chaîne Modern Software Engineering et figure historique de la Continuous Delivery, défend ici que la conversation publique sur l'IA et le développement logiciel oublie une variable décisive : la continuous delivery. Sans elle, le développement assisté par IA n'est pas seulement risqué, c'est un piège — un complexity bomb with a delayed fuse.
Son argument central tient en quatre temps. Premièrement, le code n'a jamais été le bottleneck du software engineering. La difficulté a toujours été ailleurs : comprendre le problème, le concevoir, le tester, l'intégrer, le déployer. L'IA accélère précisément la partie qui n'était pas le problème.
Deuxièmement, le paradoxe de Jevons s'applique : quand produire du code devient cheap, on en produit plus. Plus de code = plus de complexité, plus de points d'intégration, plus de comportements à évaluer, plus de maintenance. Et probablement moins de temps pour comprendre le problème. Ce n'est pas un gain de productivité, c'est une bombe à retardement.
Troisièmement, l'IA tend aux grands sauts alors que le bon engineering exige des petits pas réversibles avec feedback rapide. Farley cite Bob Martin ("the only way to go fast is to go well") et raconte un projet où l'arrivée brutale de 200 consultants un lundi matin a détruit dix-huit mois de progrès.
Quatrièmement, la Continuous Delivery est définie comme "working so that our software is always in a releasable state". La mécanique : petits incréments, tests automatisés rapides, deployment pipeline qui arbitre la releasability. Le pipeline ne se soucie pas de qui a écrit le code — humain ou IA, c'est le même standard.
Farley illustre par son propre retour d'expérience : il enseigne désormais à son assistant IA l'Acceptance Test-Driven Development, spécifie au niveau acceptance, et progresse en heures sur ce qui prenait des semaines — avec la confiance que la direction est juste. Il raconte aussi comment son pipeline a détecté un schema mismatch silencieux : l'IA mettait à jour la base de test mais pas la base de production. Tous les tests passaient, l'app crashait en prod. Le pipeline a parlé, pas l'IA.
Sa phrase de chute synthétise : "AI doesn't replace the need for software engineering. It exposes teams that were never really doing engineering in the first place." Le sujet n'est pas de savoir si l'IA peut écrire du code, mais si vos pratiques d'ingénierie sont assez robustes pour absorber du code venant de n'importe quelle source — humaine ou machine — et livrer du logiciel qui marche.