Contexte Technique
J'adore l'AI automation dans le développement, mais j'ai approuvé un peu trop vite l'article de Mario Zechner du 25 mars. Il y décrit un phénomène que j'observe moi-même dans les pipelines agentiques : le code est généré si rapidement que la maintenance est dépassée dès le départ.
En bref, les agents peuvent produire des dizaines de milliers de lignes en quelques heures, puis le vrai plaisir commence : logique dupliquée, pans de code existant ignorés, désynchronisation des interfaces, solutions de contournement étranges par-dessus d'anciens bugs. Ce n'est pas la "dette technique habituelle". C'est une nouvelle forme de dette où la complexité croît plus vite que les LLM actuels ne peuvent la démêler.
Son idée sur l'absence de frein humain me parle particulièrement. Un humain se fatigue, bute sur un problème, relit, ressent la douleur d'une mauvaise architecture et ralentit généralement. Un agent ne ressent aucune douleur. Il ne se dit pas : "Attends, sommes-nous sûrs d'avoir besoin d'un autre service, d'une autre couche d'abstraction, d'un autre helper ?"
Et c'est là que l'approche naïve du "générer d'abord, refactoriser ensuite" s'effondre. Elle peut fonctionner pour de petites tâches. Mais sur le long terme, le codage agentique transforme rapidement un projet en un code legacy qu'un bon LLM ne peut plus appréhender dans son ensemble, se contentant de le corriger par fragments, au risque de casser des parties adjacentes.
Essentiellement, Mario dit une chose simple : l'architecture, les API et la conception globale du système ne peuvent pas être laissées en pilote automatique total sans réfléchir. J'irais même plus loin : si vous n'avez pas de frontières de modules claires, de cycles de revue courts et de limites sur le volume des changements générés par les agents, vous n'accélérez pas le développement. Vous ne faites qu'accélérer le chaos.
Impact sur l'Entreprise et l'Automatisation
Pour les entreprises, la conclusion est très pragmatique. Les gagnants seront les équipes qui utilisent les agents comme des amplificateurs dans un cadre strict : génération de tests, couches CRUD, migrations, utilitaires internes, documentation. Les perdants seront ceux qui essaient de "faire grandir un produit" directement via des agents sans une architecture IA rigoureuse.
Je vois un deuxième effet sur le coût de possession. La génération de code bon marché d'aujourd'hui se transforme facilement en une maintenance coûteuse un mois plus tard, lorsque chaque modification commence à faire tomber des parties adjacentes du système.
Par conséquent, une intégration correcte de l'intelligence artificielle dans le développement semble maintenant plus ennuyeuse, mais plus mature : de petits changements, un contrôle humain sur l'architecture, des limites de vitesse et des portails de qualité obligatoires. Chez Nahornyi AI Lab, c'est exactement le problème que nous résolvons pour nos clients : pas seulement connecter un agent, mais construire le développement de solutions IA de manière à ce que l'automatisation ne crée pas une nouvelle classe de problèmes.
Si vous avez déjà une équipe qui a "accéléré" avec des agents, je vous conseille de regarder dès maintenant le volume des changements, la qualité des frontières modulaires et le coût de chaque modification ultérieure. Si vous sentez que la base de code commence à vous échapper, nous pouvons l'analyser sereinement ensemble chez Nahornyi AI Lab et configurer votre AI automation pour qu'elle vous fasse réellement gagner du temps, au lieu de convertir votre budget en futures réparations.