Note de la rédaction : Alors que l'IA générative s'intègre de plus en plus rapidement dans l'ingénierie logicielle, l'état d'esprit du secteur passe de « l'émerveillement des capacités » à « l'anxiété de l'efficacité ». Ne pas écrire assez vite, ne pas utiliser, ne pas automatiser suffisamment semblent générer une pression de se faire remplacer. Mais lorsque les Agents de codage entrent réellement en environnement de production, des problèmes plus concrets émergent : les erreurs sont amplifiées, la complexité devient incontrôlable, les systèmes deviennent progressivement incompréhensibles, et les gains d'efficacité ne se traduisent pas proportionnellement par des gains de qualité.

Cet article, basé sur une pratique de première ligne, offre une réflexion lucide sur cette frénésie récente du « codage agentique ». L'auteur souligne que les Agents n'apprennent pas de leurs erreurs comme les humains ; en l'absence de goulots d'étranglement et de mécanismes de feedback, les petits problèmes sont rapidement amplifiés. Dans des bases de code complexes, leur perspective locale et leur capacité de rappel limitée exacerbent encore la confusion structurelle du système. La nature de ces problèmes ne réside pas dans la technologie elle-même, mais dans le fait que les humains, poussés par l'anxiété, abandonnent prématurément leur jugement et leur contrôle.

Par conséquent, plutôt que de sombrer dans l'anxiété de « faut-il absolument adopter l'IA pleinement », il vaut mieux recalibrer la relation entre l'homme et l'outil : laisser l'Agent assumer des tâches locales et contrôlables, tout en gardant fermement entre ses mains la conception du système, le contrôle qualité et les décisions clés. Dans ce processus, « ralentir » devient une compétence, signifiant que vous comprenez encore le système, que vous capable de faire des arbitrages, et que vous gardez le contrôle sur votre travail.

À une époque où les outils évoluent constamment, ce qui est vraiment rare, ce n'est peut-être pas une capacité de génération plus rapide, mais le jugement face à la complexité, et la détermination à faire des choix entre efficacité et qualité.

Voici l'article original :

Il y a environ un an, les premiers Agents de codage capables de vous aider à « réaliser un projet complet du début à la fin » ont commencé à apparaître. Il existait auparavant des outils comme Aider ou les premières versions de Cursor, mais ils ressemblaient plus à des assistants qu'à des « agents ». Les nouveaux outils sont extrêmement attrayants, et beaucoup ont passé beaucoup de temps libre à réaliser tous ces projets qu'ils voulaient faire mais n'avaient jamais le temps de faire.

Je pense que cela n'a en soi rien de mal. Faire des choses pendant son temps libre est amusant, et la plupart du temps, on ne se soucie pas vraiment de la qualité et de la maintenabilité du code. Cela offre aussi un chemin pour apprendre de nouvelles stacks technologiques.

Pendant les vacances de Noël, Anthropic et OpenAI ont même distribué des « crédits gratuits », attirant les gens comme des machines à sous. Pour beaucoup, c'était la première vraie expérience de la magie d'« un Agent qui écrit du code ». De plus en plus de gens ont participé.

Aujourd'hui, les Agents de codage commencent aussi à entrer dans les bases de code de production. Douze mois plus tard, nous commençons à voir les conséquences de ce « progrès ». Voici mon point de vue actuel.

Tout est cassé

Bien que ce soit surtout anecdotique, les logiciels donnent désormais une sensation de « fragilité permanente ». Une disponibilité de 98% devient la norme plutôt que l'exception, même pour les grands services. Les interfaces utilisateur sont remplies de bugs absurdes, du genre que les équipes QA auraient dû repérer immédiatement.

J'admets que cette situation existait déjà avant l'arrivée des Agents. Mais maintenant, le problème s'accélère clairement.

Nous ne voyons pas ce qui se passe réellement à l'intérieur des entreprises, mais des informations fuient occasionnellement, comme cette panne présumée d'AWS causée par l'IA. Amazon Web Services a immédiatement « corrigé » cette affirmation, mais a ensuite lancé en interne un plan de restructuration de 90 jours.

Satya Nadella (PDG de Microsoft) a également récemment souligné que de plus en plus de code dans l'entreprise est écrit par l'IA. Bien qu'il n'y ait pas de preuve directe, on a vraiment l'impression que la qualité de Windows se dégrade. Même d'après certains billets de blog publiés par Microsoft eux-mêmes, ils semblent l'admettre tacitement.

Les entreprises qui prétendent que « 100% du code de leur produit est généré par l'IA » produisent presque toujours les pires produits que vous puissiez imaginer. Sans vouloir citer personne, mais des fuites de mémoire de plusieurs Go, des interfaces utilisateur chaotiques, des fonctionnalités incomplètes, des plantages fréquents... Ce n'est absolument pas la « garantie de qualité » qu'ils pensent offrir, encore moins une démonstration positive de « laisser l'Agent tout faire pour vous ».

En privé, on entend de plus en plus, que ce soit dans les grandes entreprises ou les petites équipes, une même chose : ils se sont enfermés dans une impasse à cause du « codage par Agent ». Pas de revue de code, délégation des décisions de conception à l'Agent, empilement de fonctionnalités dont personne n'a besoin — la fin ne peut être que mauvaise.

Pourquoi nous ne devrions pas utiliser les Agents de cette façon

Nous avons presque abandonné toute discipline d'ingénierie et tout jugement subjectif, pour sombrer dans un mode de travail « addictif » : l'objectif unique est de générer le plus de code possible dans le temps le plus court, sans aucun égard pour les conséquences.

Vous construisez une couche d'orchestration pour commander une armée d'Agents automatisés. Vous installez Beads, sans savoir que c'est essentiellement un « logiciel malveillant » quasi impossible à désinstaller. Juste parce qu'Internet dit que « tout le monde fait comme ça ». Si vous ne le faites pas, vous « êtes foutu » (ngmi).

Vous vous consumez dans des « cycles d'emboîtement » sans fin.

Regardez — Anthropic a utilisé un groupe d'Agents pour créer un compilateur C, bien qu'il ait encore des problèmes, la prochaine génération de modèles les corrigera, n'est-ce pas ?

Regardez — Cursor a utilisé une grande foule d'Agents pour créer un navigateur, bien qu'il soit actuellement quasi inutilisable et nécessite des interventions manuelles ponctuelles, la prochaine génération de modèles s'en chargera, n'est-ce pas ?

« Distribué », « diviser pour régner », « système autonome », « usine sans lumière », « résoudre les problèmes logiciels en six mois », « le SaaS est mort, ma grand-mère vient de créer un Shopify avec Claw »...

Ces récits sont agréables à entendre.

Bien sûr, cette approche peut « fonctionner » pour vos projets secondaires que presque personne n'utilise (y compris vous). Peut-être existe-t-il un génie capable de créer ainsi un produit logiciel non médiocre, vraiment utilisé. Si vous êtes cette personne, alors chapeau.

Mais au moins dans mon cercle de développeurs, je n'ai encore vu aucun cas où cette méthode fonctionne vraiment. Bien sûr, peut-être sommes-nous simplement tous nuls.

Les erreurs s'accumulent sans apprentissage, sans goulot d'étranglement, avec une explosion retardée

Le problème des Agents est qu'ils font des erreurs. Cela n'a rien de grave en soi, les humains aussi font des erreurs. Peut-être juste des erreurs de correction, faciles à identifier et à corriger, et encore plus stables avec un test de régression ajouté. Ou bien des mauvaises odeurs de code que les linters ne capturent pas : ici une méthode inutile, là un type不合理, du code dupliqué, etc. Isolément, tout cela est anodin, les développeurs humains font aussi ce genre de petites erreurs.

Mais la « machine » n'est pas humaine. Après avoir répété plusieurs fois la même erreur, un humain apprend généralement à ne plus la commettre — soit parce qu'il se fait réprimander, soit en apprenant véritablement.

L'Agent n'a pas cette capacité d'apprentissage, du moins pas par défaut. Il répétera la même erreur encore et encore, et pourrait même « créer » de merveilleuses combinaisons de différentes erreurs basées sur les données d'entraînement.

Vous pouvez bien sûr essayer de « l'entraîner » : écrire des règles dans AGENTS.md pour qu'il ne fasse plus cette erreur ; concevoir un système complexe de mémoire pour qu'il interroge les erreurs passées et les meilleures pratiques. Cela fonctionne effectivement pour certains types de problèmes spécifiques. Mais à une condition — vous devez d'abord observer qu'il a commis cette erreur.

La différence cruciale est : l'humain est un goulot d'étranglement, l'Agent ne l'est pas.

Un humain ne peut pas cracher vingt mille lignes de code en quelques heures. Même avec une fréquence d'erreurs non négligeable, seul un nombre limité d'erreurs peut être introduit en une journée, leur accumulation est lente. Généralement, lorsque « la douleur causée par les erreurs » atteint un certain niveau, l'humain (par aversion instinctive à la douleur) s'arrête pour réparer. Ou la personne est remplacée, et quelqu'un d'autre répare. Bref, le problème est traité.

Mais lorsque vous utilisez toute une armée d'Agents orchestrés, il n'y a plus de goulot d'étranglement, plus de « sensation de douleur ». Ces petites erreurs auparavant insignifiantes s'accumulent à un rythme insoutenable. Vous avez été retiré de la boucle, vous ne savez même pas que ces petits problèmes apparemment inoffensifs sont devenus un monstre. Lorsque vous ressentez enfin la douleur, il est souvent trop tard.

Jusqu'au jour où vous voulez ajouter une nouvelle fonctionnalité et vous rendez compte que l'architecture actuelle du système (essentiellement un empilement d'erreurs) ne supporte pas la modification ; ou les utilisateurs se plaignent massivement parce que la dernière version a des problèmes, voire a perdu des données.

C'est alors que vous réalisez : vous ne pouvez plus faire confiance à ce code.

Pire encore, les milliers de tests unitaires, tests snapshot, tests end-to-end que vous avez fait générer par l'Agent ne sont plus fiables non plus. La seule façon de juger si « le système fonctionne correctement » reste les tests manuels.

Félicitations, vous vous êtes mis (ainsi que l'entreprise) dans une sacrée situation.

Vendeurs de complexité

Vous n'avez plus aucune idée de ce qui se passe dans le système, car vous avez cédé le contrôle à l'Agent. Et l'Agent, par essence, « vend de la complexité ». Ils ont vu beaucoup de mauvaises décisions architecturales dans les données d'entraînement, et renforcent continuellement ces modèles pendant le processus d'apprentissage par renforcement. Si vous le laissez concevoir le système, le résultat est prévisible.

Vous obtenez finalement : un système extrêmement complexe, un méli-mélo de mauvaises imitations des « meilleures pratiques de l'industrie », que vous n'avez pas contraint avant que les problèmes ne deviennent incontrôlables.

Mais le problème ne s'arrête pas là. Vos Agents ne partagent pas entre eux le processus d'exécution, ne voient pas la base de code complète, ne comprennent pas les décisions que vous ou d'autres Agents avez prises auparavant. Leurs décisions sont donc toujours « locales ».

Cela conduit directement aux problèmes mentionnés précédemment : beaucoup de code dupliqué, des structures abstraites pour le plaisir d'abstraire, diverses incohérences. Ces problèmes s'accumulent, finissant par former un système complexe et irrécupérable.

Cela ressemble beaucoup aux bases de code d'entreprise écrites par des humains. Sauf que cette complexité est généralement le résultat d'une accumulation sur plusieurs années : la douleur est répartie sur un grand nombre de personnes, chacune n'atteint pas le point critique du « il faut réparer », la tolérance de l'organisation elle-même est élevée, ainsi la complexité et l'organisation « co-évoluent ».

Mais dans une combinaison humain + Agent, ce processus est grandement accéléré. Deux personnes, avec une poignée d'Agents, peuvent atteindre cette complexité en quelques semaines.

Le rappel (recall) de la recherche agentique est faible

Vous pourriez espérer que l'Agent « nettoie le gâchis », vous aide à refactoriser, optimiser, rendre le système propre. Mais le problème est : ils n'en sont plus capables.

Parce que la base de code est trop grande, trop complexe, et qu'ils ne peuvent toujours voir que localement. Ce n'est pas seulement une question de fenêtre de contexte trop petite, ou de mécanismes de contexte long qui échouent face à des millions de lignes de code. Le problème est plus insidieux.

Avant que l'Agent n'essaie de réparer le système, il doit d'abord trouver tout le code à modifier, ainsi que les implémentations existantes pouvant être réutilisées. Cette étape, nous l'appelons la recherche agentique (agentic search).

Comment l'Agent fait cela dépend des outils que vous lui donnez : cela peut être Bash + ripgrep, un index de code interrogeable, un service LSP, une base de données vectorielle...

Mais quel que soit l'outil, l'essence est la même : plus la base de code est grande, plus le rappel (recall) est faible. Et un faible rappel signifie : l'Agent ne peut pas trouver tout le code pertinent, et ne peut donc pas faire les modifications correctes.

C'est aussi pourquoi ces petites erreurs de « mauvaises odeurs » de code apparaissent dès le début : il ne trouve pas l'implémentation existante, réinvente donc la roue, introduit des incohérences. Finalement, ces problèmes se propagent, s'accumulent, fleurissant en une « fleur pourrie » extrêmement complexe.

Alors, comment éviter tout cela ?

Comment devrions-nous collaborer avec les Agents (au moins pour l'instant)

Les Agents de codage sont comme des sirènes, vous attirant avec leur vitesse de génération de code ultra-rapide et cette intelligence « saccadée mais parfois impressionnante ». Ils peuvent souvent accomplir des tâches simples avec une vitesse et une qualité惊人. Les vrais problèmes commencent quand vous avez cette pensée — « Cette chose est trop forte, ordinateur, travaille pour moi ! »

Déléguer des tâches à l'Agent n'est bien sûr pas un problème en soi. Les bonnes tâches pour Agent ont généralement plusieurs caractéristiques : leur portée peut être bien délimitée, ne nécessite pas de comprendre tout le système ; la tâche est en boucle fermée, c'est-à-dire que l'Agent peut évaluer le résultat par lui-même ; la sortie n'est pas sur le chemin critique, ce ne sont que des outils temporaires ou des logiciels à usage interne, n'affectant pas les utilisateurs réels ou les revenus ; ou vous avez juste besoin d'un « canard en caoutchouc » pour aider à réfléchir — essentiellement, faire collisionner vos idées avec les connaissances compressées d'Internet et des données synthétiques.

Si ces conditions sont remplies, alors c'est une tâche adaptée à confier à l'Agent, à condition que vous, en tant qu'humain, restiez le garant final de la qualité.

Par exemple, utiliser la méthode auto-research proposée par Andrej Karpathy pour optimiser le temps de démarrage d'une application ? Très bien. Mais à condition de savoir que le code qu'il sort n'est absolument pas prêt pour la production. L'auto-research fonctionne parce que vous lui donnez une fonction d'évaluation, lui permettant d'optimiser autour d'une métrique (comme le temps de démarrage ou la perte). Mais cette fonction d'évaluation ne couvre qu'une dimension très étroite. L'Agent ignorera effrontément toutes les métriques absentes de la fonction d'évaluation, comme la qualité du code, la complexité du système, et même dans certains cas la correction — si votre fonction d'évaluation elle-même est problématique.

L'idée centrale est en fait simple : laissez l'Agent faire les choses ennuyeuses, celles qui ne vous apprennent rien de nouveau, ou ces travaux que vous n'auriez pas eu le temps d'essayer. Puis évaluez vous-même les résultats, sélectionnez les parties vraiment raisonnables et correctes, et finalisez l'implémentation. Bien sûr, vous pouvez aussi utiliser l'Agent pour cette dernière étape.

Mais ce que je veux surtout souligner, c'est : vraiment, il faut ralentir un peu.

Donnez-vous le temps de réfléchir à ce que vous faites vraiment, et pourquoi vous le faites. Donnez-vous une chance de dire « non », « non, nous n'avons pas besoin de cela ». Fixez une limite claire à l'Agent : la quantité de code qu'il est autorisé à générer par jour, qui doit correspondre à votre capacité réelle de revue. Toutes les parties qui déterminent la « forme globale » du système, comme l'architecture, les API, etc., doivent être écrites par vous. Vous pouvez utiliser l'auto-complétion pour retrouver une « sensation de code écrit à la main », ou faire du pair programming avec l'Agent, mais l'essentiel est : vous devez être dans le code.

Parce qu'écrire le code soi-même, ou le voir se construire étape par étape, ce processus apporte une sensation de « friction ». C'est précisément cette friction qui vous rend plus conscient de ce que vous voulez faire, de comment le système fonctionne, de sa « sensation » globale. C'est là que l'expérience et le « goût » entrent en jeu, et c'est justement ce que les modèles les plus avancés actuels ne peuvent encore remplacer. Ralentir, subir un peu de friction, est précisément votre façon d'apprendre et de grandir.

Finalement, vous obtiendrez un système toujours maintenable — au moins pas pire qu'avant l'arrivée des Agents. Oui, les systèmes passés n'étaient pas parfaits non plus. Mais vos utilisateurs vous remercieront, car votre produit est « utilisable », et non un tas de déchets bâclés.

Vous ferez moins de fonctionnalités, mais plus correctes. Apprendre à dire « non » est en soi une compétence. Vous pourrez aussi dormir tranquille, car vous savez au moins ce qui se passe dans le système, vous gardez l'initiative. C'est cette compréhension qui vous permet de compenser les problèmes de rappel de la recherche agentique, de rendre la sortie de l'Agent plus fiable, nécessitant moins de corrections.

Lorsque le système a un problème, vous pouvez intervenir pour le réparer ; lorsque la conception n'était pas bonne dès le départ, vous pouvez comprendre le problème et le refactoriser en une meilleure forme. Qu'il y ait un Agent ou non, ce n'est finalement pas si important.

Tout cela nécessite de la discipline. Tout cela ne peut se faire sans l'humain.