Avec les agents, on livre plus de code et on casse plus souvent
Plus de code, plus d’incidents, pas plus de fonctionnalités. Pourquoi c’est mécanique, et ce que je vérifie avant de faire confiance au code d’un agent.
Depuis que je code avec des agents, je vois passer beaucoup plus de bugs et de régressions. Ce n’est pas un hasard : plus on livre de changements, plus on casse, et le vrai travail se déplace vers la vérification.
Ce qu’on observe ailleurs
Titus Winters, auteur principal de Software Engineering at Google et aujourd’hui chez Adobe, le dit dans le podcast de Gergely Orosz. Quand il parle avec des ingénieurs d’autres entreprises, il entend la même chose partout : la quantité de code produite a énormément augmenté en un an, les incidents ont augmenté d’environ 30 %, et le nombre de fonctionnalités livrées n’a pas bougé. Pour lui, on fait du surplace.
Un calcul simple
Dans son dossier sur les outils d’astreinte assistés par IA, Gergely Orosz rappelle une formule de fiabilité : le taux d’incidents est égal au nombre de changements multiplié par la probabilité qu’un changement casse quelque chose. Dans beaucoup d’entreprises, les agents ont doublé le premier facteur. Si le second ne baisse pas, les incidents montent. Chez Rootly, qui vend ce type d’outil, les alertes reçues en dehors des heures de bureau ont presque doublé en un an.
Pour faire baisser cette probabilité, il n’y a que deux moyens : mieux vérifier avant de déployer, ou apprendre plus vite des incidents pour rendre le système plus solide.
Construit ne veut pas dire que ça marche
Un texte publié sur le site de Martin Fowler explique pourquoi les bons développeurs restent méfiants envers le développement par agents : ils savent qu’un logiciel construit n’est pas forcément un logiciel qui fonctionne en production. Dans une expérience où des agents écrivaient tout le code, l’application tournait, mais le build était souvent rouge. Le texte conseille de ne pas juger le succès au volume de code produit. Je suis d’accord : le nombre de PR ne dit rien de ce qui arrive aux clients.
Ce que je fais
Quand l’agent annonce que c’est fini, je ne le crois pas sur parole. Avant de committer, je lance un skill de vérification : l’agent doit montrer que la modification marche dans le vrai projet, avec des preuves.
Je teste d’abord dans une sandbox, jamais directement en production. Je demande au code de lever une erreur quand quelque chose ne va pas, plutôt que de continuer en silence : un script qui avale une exception a l’air de marcher et laisse des données fausses derrière lui.
Et quand l’agent fait tourner un script sur un serveur, je lui demande de revérifier ensuite l’état réel du serveur. Un script peut se terminer sans erreur sans avoir fait ce qu’on attendait.
Tout dépend de ce qui est en jeu
Titus Winters dit aussi que « la peur n’est pas une base acceptable pour l’ingénierie » : si on ne peut pas modifier une base de code sans avoir peur, elle n’est pas durable. Pour moi, le niveau de contrôle dépend du projet.
Sur un MVP ou un petit outil, je laisse l’agent faire et je ne regarde que le résultat. Sur une application en production utilisée par des centaines de clients, je regarde ce qu’il fait : « la confiance n’exclut pas le contrôle ».
Sources : Software engineering at Google & CS education with Titus Winters, The Pragmatic Engineer, AI SRE: what is it, how could it change on-call, and does it work?, The Pragmatic Engineer, Why are good developers so wary of agentic development?, martinfowler.com.