Titre original : Réflexions sur le fait de ralentir, putain
Auteur original : Mario Zechner
Traduction : Peggy，BlockBeats

Note de l’éditeur : À l’heure où l’IA générative accélère son entrée dans l’ingénierie logicielle, les émotions du secteur glissent de la « stupéfaction face aux capacités » vers une « angoisse de l’efficacité ». Ne pas aller assez vite, ne pas en faire assez, et ne pas automatiser assez en profondeur semble, chez beaucoup, provoquer une pression : celle d’être dépassé. Mais quand les agents d’encodage entrent vraiment en environnement de production, certains problèmes plus réalistes commencent à apparaître : les erreurs sont amplifiées, la complexité devient incontrôlable, le système finit par devenir incompréhensible, et l’amélioration de l’efficacité ne se traduit pas, de façon proportionnelle, en amélioration de la qualité.

Cet article s’appuie sur des pratiques de terrain pour une réflexion calme sur la vague actuelle de « agentic coding ». L’auteur souligne que les agents n’apprennent pas, comme les humains, au travers de leurs erreurs. En l’absence de goulots d’étranglement et de mécanismes de feedback, de petits problèmes sont rapidement amplifiés ; et, dans des bases de code complexes, leur perspective locale et leurs capacités de rappel limitées aggravent encore la confusion de la structure du système. La nature profonde de ces problèmes n’est donc pas dans la technologie elle-même, mais dans le fait que l’être humain, mû par l’anxiété, abandonne trop tôt le jugement et le contrôle.

Par conséquent, plutôt que de sombrer dans l’angoisse de « faut-il embrasser l’IA à fond ou non », il vaut mieux recalibrer la relation entre l’être humain et les outils : laisser les agents prendre en charge des tâches locales et contrôlables, tandis que la conception du système, le contrôle qualité et les décisions clés restent fermement entre vos mains. Dans ce processus, « ralentir » devient au contraire une capacité : cela signifie que vous comprenez encore le système, que vous êtes capable de faire des choix, et que vous conservez toujours un sentiment de maîtrise sur votre travail.

À l’ère où les outils évoluent sans cesse, la vraie ressource rare n’est peut-être pas une capacité de génération plus rapide, mais le jugement sur la complexité, et la détermination de choisir entre l’efficacité et la qualité.

Voici le texte original :

Le visage de la tortue, c’est l’expression que j’ai quand je regarde ce secteur

Il y a environ un an, les agents d’encodage qui pouvaient vraiment vous aider à « réaliser un projet complet de bout en bout » ont commencé à apparaître. Avant cela, il existait aussi des outils comme Aider, ou des Cursor de première génération, mais ils ressemblaient davantage à des assistants qu’à des « agents ». La nouvelle génération d’outils est extrêmement séduisante, et beaucoup de gens ont consacré énormément de temps libre à faire, enfin, ces projets qu’ils voulaient faire depuis longtemps mais pour lesquels ils n’avaient jamais eu le temps.

Je pense que ce n’est pas forcément un problème. Faire des choses pendant son temps libre, c’est déjà quelque chose de très plaisant, et dans la plupart des cas, on n’a pas vraiment besoin de se soucier de la qualité du code et de la maintenabilité. Cela vous donne aussi un chemin pour apprendre de nouvelles stacks technologiques.

Pendant les vacances de Noël, Anthropic et OpenAI ont aussi publié « des crédits gratuits », aspirant les gens comme dans une machine à sous. Pour beaucoup, c’était la première fois qu’ils pouvaient vraiment ressentir la « magie : les agents écrivent du code ». De plus en plus de personnes y participent.

Aujourd’hui, les agents d’encodage commencent également à entrer dans des bases de code de production. Après 12 mois, nous commençons à voir les conséquences de cette « progression ». Voici ce que je pense, à l’heure actuelle.

Tout est en train de se casser

Même si la plupart de ce qui suit ne sont que des retours d’expérience, les logiciels donnent effectivement aujourd’hui l’impression qu’ils peuvent « se rompre à tout moment ». Une disponibilité de 98 %, qui autrefois relevait de l’exception, devient la norme : même les grands services n’y échappent pas. Les interfaces utilisateur sont remplies d’un tas de bugs totalement absurdes, des bugs que l’équipe QA aurait dû repérer du premier coup.

J’admets que cette situation existait déjà avant l’apparition des agents. Mais maintenant, on voit clairement que le problème s’accélère.

On ne voit pas la réalité à l’intérieur des entreprises, mais il arrive que certaines informations fuient. Par exemple, cette fois où l’on parlait d’un « incident AWS causé par l’IA ». Amazon Web Services a ensuite « corrigé » la version rapidement, mais juste après, l’entreprise a lancé en interne un plan de restructuration de 90 jours.

Satya Nadella (PDG de Microsoft) a aussi insisté récemment sur le fait que de plus en plus de code dans l’entreprise est écrit par l’IA. Il n’y a pas de preuves directes, mais on a vraiment cette impression : la qualité de Windows est en baisse. Et même, en regardant certains billets publiés par Microsoft lui-même, on dirait qu’ils l’ont en quelque sorte déjà admis.

Les entreprises qui prétendent que « 100 % du code du produit est généré par l’IA » sortent presque toujours les produits les pires que vous puissiez imaginer. Pas forcément “contre” qui que ce soit, mais à grande échelle : des fuites de mémoire en dizaines de GB, une UI chaotique, des fonctionnalités incomplètes, des crashs fréquents… Tout cela ne ressemble en rien à ce qu’ils appelleraient une « preuve de qualité », encore moins à un « bon exemple » pour « laisser l’agent s’occuper de tout ».

En privé, vous entendrez de plus en plus souvent une même chose, que ce soit dans de grandes entreprises ou dans de petites équipes : ils ont été poussés dans une impasse par l’« agent qui écrit du code ». Sans revue de code, en confiant les décisions de conception à l’agent, puis en empilant une montagne de fonctionnalités dont personne n’a besoin—le résultat ne peut pas être bon.

Pourquoi ne pas utiliser les agents de cette façon

On a presque abandonné toutes les disciplines d’ingénierie et tout jugement subjectif, pour tomber dans une manière de travailler « addictive » : un seul objectif—générer le plus de code possible dans le temps le plus court. Quant aux conséquences, on ne les prend pas en compte du tout.

Vous mettez en place une couche d’orchestration pour commander une « armée » d’agents automatisés. Vous installez Beads, mais vous ne savez même pas qu’au fond, ce n’est presque rien d’autre qu’un « malware » impossible à désinstaller. Simplement parce que, d’après ce qu’on dit en ligne, « tout le monde fait ça ». Sinon, vous « êtes foutus » (ngmi).

Vous vous épuisez dans des cycles en boucle, comme des poupées russes.

Voyez—Anthropic a utilisé une série d’agents pour faire un compilateur C. Même s’il reste des problèmes aujourd’hui, la prochaine génération de modèles va sûrement les corriger, non ?

Regardez—Cursor a utilisé une grande foule d’agents pour faire un navigateur. Même si, à l’heure actuelle, il est presque inutilisable et qu’il faut parfois une intervention manuelle, la prochaine génération de modèles va sûrement s’en charger, non ?

« Distribué », « diviser pour régner », « systèmes autonomes », « usines en mode noir », « résoudre un problème logiciel en six mois », « SaaS est mort, ma grand-mère vient d’utiliser Claw pour monter un Shopify »…

Ces récits donnent l’impression de tout ce qu’il y a de plus satisfaisant.

Bien sûr, pour ce qui ressemble à vos side projects à peu près personne n’utilise (y compris vous-même), cette approche peut peut-être « encore fonctionner ». Peut-être existe-t-il bien un génie qui, avec ce type de méthode, produit un produit logiciel non médiocre, réellement utilisé par des gens. Si vous êtes cette personne, alors je vous admire vraiment.

Mais, au moins dans mon cercle de développeurs, je n’ai pas encore vu de véritables exemples qui prouvent que cette méthode marche vraiment. Bien sûr, peut-être que nous sommes simplement tous trop nuls.

Les erreurs s’empilent sans apprentissage, sans goulots d’étranglement, avec une explosion du délai

Le problème des agents, c’est qu’ils font des erreurs. En soi, ce n’est pas grave : les humains font aussi des erreurs. Peut-être s’agit-il d’erreurs de validité/correction faciles à repérer et à corriger, puis en ajoutant juste un peu de tests de non-régression, on rend le tout plus solide. Ou peut-être s’agit-il d’odeurs de code que le linter n’arrive pas à capter : par-ci une méthode inutile, par-là un type injustifié, et aussi du code dupliqué. Pris isolément, ça ne ferait pas de mal—les développeurs humains commettent aussi ce genre de petites erreurs.

Mais « la machine » n’est pas un humain. Après avoir répété plusieurs fois les mêmes erreurs, un humain finit généralement par apprendre à ne plus les faire—soit parce qu’il s’est fait reprendre, soit parce qu’il corrige pendant le vrai processus d’apprentissage.

Et un agent n’a pas cette capacité d’apprentissage, au moins par défaut. Il répète les mêmes erreurs encore et encore, et peut même, sur la base des données d’entraînement, « créer » de merveilleuses combinaisons d’erreurs différentes.

Bien sûr, vous pouvez essayer de le « former » : écrire des règles dans AGENTS.md pour qu’il ne refasse plus ce type d’erreur ; concevoir un système de mémoire complexe, afin qu’il interroge les erreurs passées et les meilleures pratiques. Sur certains types de problèmes, ça marche effectivement. Mais la condition, c’est que—vous devez d’abord observer qu’il commet ce genre d’erreur.

La différence la plus importante, toutefois, est la suivante : l’humain a des goulots d’étranglement, pas l’agent.

Un humain ne peut pas produire, en quelques heures, 20 000 lignes de code. Même si le taux d’erreurs n’est pas faible, sur une journée, vous n’introduisez qu’un nombre limité d’erreurs, et leur accumulation est lente. En général, lorsque la « douleur causée par les erreurs » s’accumule à un certain niveau, l’humain s’arrête pour réparer (par aversion instinctive de la douleur). Ou bien l’humain est remplacé, et quelqu’un d’autre vient corriger. Dans tous les cas, le problème finit par être traité.

Mais lorsque vous utilisez toute une série d’agents orchestrés comme une « armée », il n’y a ni goulot d’étranglement, ni « sensation de douleur ». Ces petites erreurs, qui étaient à l’origine insignifiantes, s’empilent à une vitesse non soutenable. Vous avez été retiré de la boucle, et même vous ne savez pas que ces petits problèmes apparemment inoffensifs ont déjà grossi jusqu’à devenir une masse énorme. Quand vous ressentez enfin la douleur, il est souvent déjà trop tard.

Jusqu’au jour où vous voulez ajouter une nouvelle fonctionnalité, mais que vous découvrez que l’architecture actuelle du système (en essence, une accumulation d’erreurs) ne peut tout simplement pas supporter la modification ; ou bien les utilisateurs commencent à se plaindre furieusement, parce qu’une publication récente a causé des problèmes—voire a fait perdre des données.

À ce moment-là seulement, vous vous rendez compte d’une chose : vous ne pouvez plus faire confiance à ce code.

Pire encore, vous ne pouvez plus non plus faire confiance aux milliers de tests unitaires, de snapshot tests, de tests bout-en-bout que génèrent les agents. La seule façon de juger si « le système fonctionne correctement » ne laisse plus que les tests manuels.

Félicitations : vous avez mis vous-même (et votre entreprise) dans une sacrée galère.

Le commerce de la complexité

Vous ne savez plus ce qui se passe dans le système, parce que vous avez donné le contrôle à l’agent. Et l’agent, fondamentalement, « vend de la complexité ». Il a vu, dans ses données d’entraînement, énormément de décisions d’architecture mauvaises, et il renforce aussi continuellement ces schémas dans le cadre de l’apprentissage par renforcement. Vous lui confiez la conception du système, alors le résultat n’est pas surprenant.

Au final, vous obtenez : un ensemble entier de systèmes extrêmement complexes, mélangeant des imitations médiocres de « meilleures pratiques de l’industrie », sans aucune contrainte appliquée avant que le problème ne parte en vrille.

Mais le problème ne s’arrête pas là. Les agents ne partagent pas entre eux le processus d’exécution, ne voient pas l’ensemble de la base de code, et ne comprennent pas les décisions que vous (ou d’autres agents) ont prises avant. Par conséquent, leurs décisions restent toujours « locales ».

Cela entraîne directement les problèmes mentionnés plus haut : beaucoup de code répété, des structures abstraites sans raison d’être, toutes sortes d’incohérences. Ces problèmes s’accumulent, puis finissent par former un système de complexité irréparable.

En réalité, cela ressemble beaucoup à une base de code d’entreprise écrite par des humains. La différence, c’est que la complexité chez les humains s’accumule généralement sur des années : la douleur est répartie sur un grand nombre de personnes, chacune n’atteint pas le seuil où « il faut vraiment corriger », et l’organisation a une tolérance élevée ; alors la complexité évolue « en symbiose » avec l’organisation.

Mais avec la combinaison humains + agents, ce processus est énormément accéléré. Deux personnes, plus une ribambelle d’agents : en quelques semaines, vous atteignez déjà cette complexité.

Le rappel de la recherche agentique est faible

Vous pourriez espérer que les agents puissent « arranger les choses », vous aider à refactoriser, optimiser, rendre le système propre. Mais le problème, c’est qu’ils n’y arrivent plus.

Parce que la base de code est trop grande, la complexité trop élevée, et eux ne voient toujours que localement. Ce n’est pas seulement parce que la fenêtre de contexte est insuffisante, ou que le mécanisme de long contexte échoue devant des millions de lignes de code. Le problème est plus subtil.

Avant qu’un agent 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 agentic search (recherche par agent).

Comment l’agent réalise cela dépend des outils que vous lui fournissez : Bash + ripgrep, ou un index de code interrogeable, des services LSP, une base de données vectorielle…

Mais quels que soient les outils, le fond est le même : plus la base de code est grande, plus le taux de rappel est faible. Un faible rappel signifie que l’agent ne peut pas trouver tout le code pertinent, et donc ne peut pas faire des modifications correctes.

C’est aussi la raison pour laquelle, dès le début, ces petits « bugs d’odeur de code » apparaissent : il n’a pas trouvé d’implémentation existante, alors il recommence à faire ses propres roues, introduisant des incohérences. Au final, ces problèmes continuent de se propager, de s’accumuler, et donnent naissance à une « tache » extrêmement complexe.

Alors, comment éviter tout ça ?

Comment collaborer avec les agents (au moins pour l’instant)

Coder avec un agent, c’est comme des sirènes : la vitesse de génération de code est extrêmement rapide, et ce type d’intelligence « par à-coups mais parfois vraiment époustouflante » vous attire. Ils parviennent souvent, à une vitesse impressionnante, à accomplir des tâches simples avec une grande qualité. Le vrai problème commence quand vous vous mettez à penser quelque chose comme : « C’est trop puissant : ordinateur, fais-le pour moi ! »

Confier des tâches à un agent, en soi, ce n’est pas forcément un problème. De bonnes tâches pour des agents ont généralement quelques caractéristiques : leur périmètre peut être très bien limité, sans besoin de comprendre l’ensemble du 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 la voie critique : c’est juste quelques outils temporaires ou des logiciels utilisés en interne, qui n’affectent pas les utilisateurs réels ni les revenus ; ou bien vous avez simplement besoin d’un « canard en caoutchouc » pour vous aider à penser—en substance, vous faites entrer vos idées dans une collision avec la connaissance compressée d’Internet et des données synthétiques.

Si ces conditions sont réunies, alors ce sont des tâches adaptées à confier à l’agent. À condition que, en tant qu’humain, vous restiez le garant final de la qualité.

Par exemple, optimiser le temps de démarrage d’une application avec la méthode auto-research proposée par Andrej Karpathy ? Très bien. Mais à condition que vous sachiez une chose : le code qu’il produit n’a absolument aucune aptitude à être utilisable en production. Si auto-research fonctionne, c’est parce que vous lui fournissez une fonction d’évaluation, lui permettant d’optimiser autour d’un indicateur (par exemple le temps de démarrage ou le loss). Mais cette fonction d’évaluation ne couvre qu’un ensemble de dimensions très étroit. L’agent peut alors, sans se gêner, ignorer tous les indicateurs qui ne sont pas dans la fonction d’évaluation—comme la qualité du code, la complexité du système, et même, dans certains cas, la correction. Si la fonction d’évaluation est elle-même problématique, alors tout le reste l’est aussi.

L’idée centrale est en réalité très simple : faire en sorte que l’agent s’occupe de tâches ennuyeuses qui ne vous feront pas apprendre de nouvelles choses, ou de tâches exploratoires que vous n’avez de toute façon pas le temps d’essayer. Ensuite, c’est à vous d’évaluer les résultats, de sélectionner les parties réellement raisonnables et correctes, puis de terminer l’implémentation finale. Bien sûr, vous pouvez aussi utiliser l’agent pour cette dernière étape.

Mais je veux surtout insister sur ceci : oui, il faut vraiment ralentir un peu.

Donnez-vous du temps pour réfléchir à ce que vous faites, et surtout pourquoi vous le faites. Donnez-vous la possibilité de dire « non » : « Non, on n’en a pas besoin. » Fixez à l’agent une limite claire : combien de lignes de code il est autorisé à générer par jour, et ce volume doit correspondre à votre capacité réelle à le revoir. Toutes les parties qui déterminent la « forme globale » du système, comme l’architecture, les API, etc., doivent être écrites par vos soins. Vous pouvez utiliser l’auto-complétion pour retrouver un peu la sensation du « code écrit à la main », ou vous pouvez programmer en binôme avec l’agent—mais le point clé, c’est : vous devez mettre la main dans le code.

Parce que, qu’il s’agisse d’écrire vous-même le code, ou de le voir se construire étape par étape sous vos yeux, ce processus crée une sorte de « frottement ». C’est précisément ce frottement qui vous rend plus clair sur ce que vous voulez vraiment faire, sur la manière dont le système fonctionne, et sur la sensation globale (« hand-feel »). C’est là que l’expérience et le « goût » entrent en jeu ; et c’est précisément quelque chose que, pour le moment, les modèles les plus avancés ne peuvent pas remplacer. Ralentir, accepter un peu de frottement : c’est une manière d’apprendre et de grandir.

Au final, vous obtiendrez un système qui reste maintenable—au moins pas pire que ce qu’il aurait été avant l’apparition des agents. Oui, les anciens systèmes n’étaient pas parfaits. Mais vos utilisateurs vous remercieront, parce que votre produit est « utile », et non une simple pile de déchets recollés.

Vous ferez moins de fonctionnalités, mais plus justes. Apprendre à dire « non » est en soi une compétence. Vous pouvez aussi dormir tranquille : au moins vous savez encore ce qui se passe dans le système, et vous gardez la main. C’est précisément cette compréhension qui vous permet de compenser le problème du faible rappel d’agentic search, rendant la sortie de l’agent plus fiable et nécessitant moins de retouches.

Quand le système tombe en panne, vous pouvez intervenir vous-même pour réparer. Quand, dès le départ, la conception est déraisonnable, vous pouvez comprendre où est le problème et le refactoriser en une meilleure forme. Quant à savoir s’il y a des agents ou non, ce n’est finalement pas si important.

Tout cela exige de la discipline. Et tout cela ne peut pas se passer des humains.

[Lien vers l’original]

Cliquez pour en savoir plus sur le recrutement chez律动 BlockBeats

Bienvenue à rejoindre la communauté officielle de律动 BlockBeats :

Groupe Telegram (abonnement) : https://t.me/theblockbeats

Groupe Telegram : https://t.me/BlockBeats_App

Compte Twitter officiel : https://twitter.com/BlockBeatsAsia