Ralentissez, c'est la réponse à l'ère de l'agent

Titre original : Réflexions sur le ralentissement
Auteur original : Mario Zechner
Traduction : Peggy, BlockBeats

Note de l'éditeur : Alors que l'IA générative s'accélère dans l'ingénierie logicielle, le sentiment dans l'industrie passe de "l'émerveillement face aux capacités" à "l'anxiété de l'efficacité." Ne pas écrire assez vite, ne pas utiliser suffisamment, ne pas automatiser suffisamment — tout cela semble créer une pression d'obsolescence. Cependant, à mesure que les agents de codage entrent véritablement dans l'environnement de production, certains problèmes plus pratiques commencent à émerger : les erreurs sont amplifiées, la complexité devient ingérable, les systèmes deviennent de plus en plus opaques, et les gains d'efficacité ne se traduisent pas proportionnellement en améliorations de qualité.

Basé sur la pratique de première ligne, cet article offre une réflexion sobre sur la tendance actuelle du "codage agentique." L'auteur souligne que les agents n'apprennent pas de leurs erreurs comme le font les humains ; en l'absence de goulets d'étranglement et de mécanismes de retour d'information, les petits problèmes sont rapidement amplifiés. Au sein de bases de code complexes, leur perspective locale et leur capacité de rappel limitée aggravent encore le désordre de la structure du système. L'essence de ces problèmes ne réside pas dans la technologie elle-même mais dans le fait que les humains abandonnent prématurément leur jugement et leur contrôle sous l'effet de l'anxiété.

Par conséquent, au lieu de tomber dans l'anxiété de "si nous devons pleinement adopter l'IA," il est préférable de recalibrer la relation entre les humains et les outils : laisser les agents s'occuper de tâches locales et contrôlables tout en gardant la conception du système, l'assurance qualité et les décisions clés fermement entre nos mains. Dans ce processus, "ralentir" devient une capacité ; cela signifie que vous comprenez toujours le système, pouvez faire des compromis et maintenez un certain contrôle sur votre travail.

À une époque d'outils en évolution, ce qui est vraiment rare n'est peut-être pas des capacités génératives plus rapides mais le jugement de la complexité et la fermeté pour faire des choix entre efficacité et qualité.

Ci-dessous se trouve le texte original :

L'expression sur le visage de la tortue est celle que j'adopte face à cette industrie.

Il y a environ un an, un véritable agent de codage capable de vous "aider à réaliser un projet complet de A à Z" a commencé à émerger. Il y avait des outils antérieurs comme Aider et le premier Cursor, mais ils ressemblaient davantage à des assistants qu'à des "agents". La nouvelle génération d'outils est très attrayante, et de nombreuses personnes ont passé beaucoup de leur temps libre à réaliser tous les projets qu'elles ont toujours voulu faire mais pour lesquels elles n'avaient jamais eu le temps.

Je ne pense pas que ce soit un problème en soi. Il est intrinsèquement joyeux de faire quelque chose pendant son temps libre, et la plupart du temps, vous n'avez pas vraiment besoin de vous soucier de la qualité du code et de sa maintenabilité. Cela vous donne également un chemin pour apprendre une nouvelle pile technologique.

Pendant la période des fêtes de Noël, Anthropic et OpenAI ont également publié des "crédits gratuits", attirant les gens comme une machine à sous. Pour beaucoup, c'était leur première véritable expérience de la magie du "codage avec un agent". La participation est en croissance.

De nos jours, le codage avec un agent commence également à s'intégrer dans les bases de code de production. Douze mois se sont écoulés, et nous commençons à voir les conséquences de ce "progrès". Voici mes réflexions actuelles.

Tout s'effondre.

Bien que la plupart de cela soit anecdotique, le logiciel actuel donne effectivement un sentiment d'être "sur le point de se briser" à tout moment. 98 % de disponibilité passe d'une exception à la norme, même pour les grands services. L'interface utilisateur est remplie de toutes sortes de bugs absurdes qui auraient dû être détectés d'un coup d'œil par l'équipe QA.

J'admets que cette situation existait avant l'apparition de l'agent. Mais maintenant, le problème s'accélère clairement.

Nous ne pouvons pas voir l'état réel à l'intérieur des entreprises, mais il y a des fuites d'informations occasionnelles, comme la rumeur de la "panne d'AWS induite par l'IA." Amazon Web Services a rapidement "corrigé" la déclaration, mais a ensuite immédiatement lancé un plan de réorganisation interne de 90 jours.

Satya Nadella (PDG de Microsoft) a également souligné récemment que de plus en plus de code dans l'entreprise est écrit par l'IA. Bien qu'il n'y ait pas de preuves directes, il y a en effet un sentiment : la qualité de Windows est en déclin. Même dans certains blogs publiés par Microsoft eux-mêmes, ils semblent avoir tacitement reconnu cela.

Les entreprises qui affirment que "100 % du produit est généré par l'IA" finissent presque toujours par produire les pires produits que l'on puisse imaginer. Sans vouloir accuser qui que ce soit, des problèmes comme des fuites de mémoire par gigaoctet, le chaos de l'interface utilisateur, des fonctionnalités manquantes, des plantages fréquents... aucun de ces éléments n'est ce qu'ils considéraient comme un "soutien à la qualité," sans parler d'une démonstration positive de "laissez l'Agent tout faire pour vous."

En privé, vous entendrez de plus en plus, tant de grandes entreprises que de petites équipes, dire une chose : elles ont été poussées dans un coin par le "codage par Agent." Sans revues de code, en confiant les décisions de conception à l'Agent, et en ajoutant ensuite une multitude de fonctionnalités inutiles—évidemment, cela ne va pas bien se terminer.

Pourquoi nous ne devrions pas utiliser l'Agent de cette manière

Nous avons presque abandonné toute discipline d'ingénierie et jugement subjectif, tombant plutôt dans une manière de travailler "addictive" : il n'y a qu'un seul objectif—générer le plus de code dans le temps le plus court possible, sans aucune considération pour les conséquences.

Vous construisez une couche d'échafaudage pour commander une armée d'Agents automatisés. Vous avez installé Beads, mais vous n'êtes pas du tout conscient qu'il s'agit essentiellement d'un "maliciel" désinstallable. Vous ne le faites que parce que des sources en ligne disent que "tout le monde le fait." Si vous ne le faites pas de cette manière, vous êtes "ngmi" (vous n'allez pas y arriver).

Vous vous consommez continuellement dans une "boucle de poupée gigogne."

Regardez—Anthropic a créé un compilateur C en utilisant un groupe d'Agents, bien qu'il ait encore des problèmes maintenant, le modèle de prochaine génération pourra sûrement le corriger, n'est-ce pas ?

Maintenant regardez—Cursor a construit un navigateur en utilisant un grand groupe d'Agents, bien qu'il soit pratiquement inutilisable maintenant et nécessite encore une intervention manuelle occasionnelle, le modèle de prochaine génération pourra sûrement le gérer, n'est-ce pas ?

"Distribué," "Diviser et Conquérir," "Systèmes Autonomes," "Usine de Lumière Noire," "Six Mois pour Résoudre un Problème Logiciel," "Le SaaS est mort, ma grand-mère vient de créer une boutique Shopify avec Claw"...

Ces récits semblent passionnants.

Bien sûr, cette approche peut en effet "fonctionner encore" pour votre projet secondaire presque inutilisé (y compris par vous-même). Peut-être qu'il y a vraiment un génie qui peut utiliser cette méthode pour créer un produit logiciel non-poubelle, véritablement utilisable. Si vous êtes cette personne, alors je vous admire vraiment.

Cependant, du moins dans mes cercles de développeurs, je n'ai pas encore vu de cas véritablement efficace de cette méthode. Bien sûr, peut-être que nous sommes tous simplement trop inexpérimentés.

L'accumulation d'erreurs dans l'absence d'apprentissage, sans goulets d'étranglement, et des explosions retardées

Le problème avec les Agents est : ils font des erreurs. Ce n'est pas un gros problème en soi ; les humains font aussi des erreurs. Cela pourrait être juste quelques erreurs de précision, faciles à identifier et à corriger, et ajouter un test de régression le rend encore plus stable. Cela pourrait aussi être des mauvaises pratiques de code que les linters ne peuvent pas détecter : une méthode inutilisée ici, un type déraisonnable là, du code dupliqué, et ainsi de suite. Individuellement, ce ne sont pas de gros problèmes, et les développeurs humains font également ce genre de petites erreurs.

Mais les "machines" ne sont pas des humains. Après avoir répété la même erreur plusieurs fois, les humains apprennent généralement à ne pas la répéter—soit ils sont réprimandés par quelqu'un, soit ils changent dans un véritable processus d'apprentissage.

Les Agents n'ont pas cette capacité d'apprentissage, du moins pas par défaut. Ils répéteront la même erreur encore et encore, et peuvent même "créer" de merveilleuses combinaisons d'erreurs différentes basées sur les données d'entraînement.

Bien sûr, vous pouvez essayer de les "former" : écrire des règles dans AGENTS.md pour qu'ils ne répètent pas de telles erreurs ; concevoir un système de mémoire complexe pour qu'ils interrogent les erreurs historiques et les meilleures pratiques. Cela est en effet efficace dans certains types de problèmes. Mais le prérequis est—vous devez d'abord observer qu'il a fait cette erreur.

La différence clé est la suivante : Les humains sont le goulet d'étranglement ; les Agents ne le sont pas.

Un humain ne peut pas vomir vingt mille lignes de code en quelques heures. Même avec un taux d'erreur pas si bas, seul un nombre fini d'erreurs peut être introduit en une journée, leur accumulation étant lente. Typiquement, lorsque la "douleur causée par les erreurs" atteint un certain niveau, les humains (par aversion instinctive à la douleur) feront une pause pour corriger les choses. Ou ils sont remplacés, et quelqu'un d'autre les corrige. Dans tous les cas, le problème est traité.

Cependant, lorsque vous déployez toute une armée d'Agents bien orchestrés, il n'y a pas de goulet d'étranglement et pas de "sensation de douleur." Ces petites erreurs initialement sans conséquence s'accumulent à un rythme insoutenable. Vous avez été sorti du circuit, inconscient que ces glitches apparemment inoffensifs se sont transformés en un monstre. Au moment où vous ressentez vraiment la douleur, il est généralement trop tard.

C'est seulement lorsque, un jour, vous essayez d'ajouter une nouvelle fonctionnalité et que vous constatez que l'architecture actuelle du système (essentiellement une pile d'erreurs) ne peut pas accueillir le changement, ou que les utilisateurs commencent à se plaindre furieusement parce que la dernière version a des problèmes, ou pire, des données perdues.

C'est à ce moment-là que vous réalisez : Vous ne pouvez plus faire confiance à cette base de code.

Pire encore, les milliers et milliers de tests unitaires, de tests de snapshot, de tests de bout en bout générés par les Agents sont tout aussi peu fiables. Le seul moyen d'évaluer si le "système fonctionne correctement" est par des tests manuels.

Félicitations, vous vous êtes enfoncé (vous et votre entreprise) dans un trou.

Le Marchand de Complexité

Vous avez complètement perdu de vue ce qui se passe dans le système parce que vous avez remis le contrôle aux Agents. Et fondamentalement, les Agents sont dans le métier de "vendre de la complexité." Ils ont vu de nombreuses décisions architecturales terribles dans leurs données d'entraînement et ont continuellement renforcé ces schémas dans le processus d'apprentissage par renforcement. Vous les avez laissés concevoir le système, et le résultat est conforme à vos attentes.

Ce que vous obtenez est un système hautement convolué, mélangeant diverses imitations médiocres des "meilleures pratiques de l'industrie", et vous n'avez imposé aucune contrainte avant que les problèmes ne deviennent incontrôlables.

Mais les problèmes ne s'arrêtent pas là. Vos Agents ne partagent pas les processus d'exécution entre eux, ne peuvent pas voir l'ensemble du code, et n'ont aucune connaissance des décisions que vous ou d'autres Agents avez prises précédemment. Ainsi, leurs décisions sont toujours "locales".

Cela conduit directement aux problèmes mentionnés précédemment : un code dupliqué en abondance, des structures trop abstraites pour le simple plaisir de l'abstraction, toutes sortes d'incohérences. Ces problèmes s'accumulent, résultant finalement en un système irrémédiablement complexe.

C'est en fait assez similaire à une base de code d'entreprise écrite par des humains. La seule différence est que ce type de complexité est généralement le résultat d'années d'accumulation : la douleur est répartie sur un grand nombre de personnes, chacune d'entre elles n'ayant pas atteint le seuil de "doit être corrigé", l'organisation elle-même ayant une grande tolérance, donc la complexité et l'organisation "coévoluent".

Cependant, dans le cas d'une combinaison humain + Agent, ce processus sera considérablement accéléré. Deux personnes, plus un groupe d'Agents, peuvent atteindre ce niveau de complexité en quelques semaines.

Le taux de rappel de la recherche agentique est faible.

Vous pouvez espérer que les Agents "nettoient le désordre" pour vous, vous aident à refactoriser, optimiser et rendre le système plus propre. Mais le problème est : ils ne peuvent plus le faire.

Parce que la base de code est trop grande et que la complexité est trop élevée, et ils ne peuvent voir qu'une partie de celle-ci. Ce n'est pas seulement une question de fenêtre de contexte qui n'est pas assez grande, ou de mécanisme de long contexte échouant face à des millions de lignes de code. Le problème est plus insidieux.

Avant qu'un Agent n'essaie de corriger le système, il doit d'abord trouver tout le code qui doit être modifié, ainsi que les implémentations existantes qui peuvent être réutilisées. Cette étape, nous l'appelons recherche agentique.

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

Mais peu importe les outils utilisés, l'essence est la même : plus la base de code est grande, plus le taux de rappel est faible. Et un faible taux de rappel signifie que l'Agent ne peut pas trouver tout le code pertinent et, naturellement, ne peut pas effectuer les modifications correctes.

C'est aussi pourquoi, au départ, ces petites erreurs de "code smell" apparaissent, il n'a pas trouvé d'implémentation existante, donc il réinvente la roue, introduisant de l'incohérence. Finalement, ces problèmes continueront à se propager, à se chevaucher et à se transformer en une "fleur pourrie" extrêmement complexe.

Alors, comment pouvons-nous éviter tout cela ?

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

Coder avec des Agents, c'est comme traiter avec un monstre marin, avec sa vitesse de génération de code extrêmement rapide et ce genre d'intelligence "intermittente mais parfois époustouflante" qui vous attire. Ils peuvent souvent accomplir des tâches simples à une vitesse et une qualité étonnantes. Le véritable problème commence lorsque vous avez l'idée - "Cette chose est trop puissante, ordinateur, fais le travail pour moi !"

Confier des tâches à l'Agent lui-même n'est bien sûr pas un problème. De bonnes tâches pour l'Agent ont généralement plusieurs caractéristiques : le périmètre peut être bien défini, il n'est pas nécessaire de comprendre l'ensemble du système ; la tâche est en boucle fermée, ce qui signifie que l'Agent peut évaluer les résultats par lui-même ; la sortie n'est pas sur le chemin critique, juste quelques outils ou logiciels temporaires pour un usage interne, cela n'affectera pas les utilisateurs réels ou les revenus ; ou vous avez juste besoin d'un "canard en caoutchouc" pour vous aider à réfléchir - essentiellement en prenant vos idées et en ayant une collision avec des connaissances compressées provenant d'internet et de 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 contrôle qualité ultime.

Par exemple, utiliser la méthode de recherche automatique d'Andrej Karpathy pour optimiser le temps de démarrage de l'application ? Super. Mais il est essentiel que vous compreniez que le code qu'il génère n'est en aucun cas prêt pour la production. La recherche automatique est efficace parce que vous lui avez donné une fonction de fitness à optimiser autour d'un métrique spécifique (comme le temps de démarrage ou la perte). Cependant, cette fonction de fitness ne couvre qu'une dimension très étroite. L'Agent ignorera audacieusement toutes les métriques non incluses dans la fonction de fitness, telles que la qualité du code, la complexité du système, et dans certains cas, même la correction - si votre fonction de fitness elle-même est défectueuse.

L'idée principale est en réalité assez simple : laissez l'Agent s'occuper des tâches ennuyeuses et non éducatives, ou du travail exploratoire que vous n'avez jamais eu le temps d'essayer. Ensuite, évaluez les résultats, sélectionnez les parties vraiment raisonnables et correctes, et complétez l'implémentation finale. Bien sûr, vous pouvez également utiliser l'Agent pour vous aider dans cette étape finale.

Mais ce que je veux vraiment souligner, c'est : ralentissez un peu.

Accordez-vous du temps pour réfléchir à ce que vous faites et pourquoi vous le faites. Donnez-vous une chance de dire "non, nous n'avons pas besoin de cela." Fixez une limite claire pour l'Agent : combien de code il peut générer par jour, une quantité qui doit correspondre à votre capacité réelle de révision. Toutes les parties qui déterminent la "forme générale" du système, telles que l'architecture et les API, doivent être écrites par vous. Vous pouvez utiliser l'autocomplétion pour ressentir le "fait d'écrire du code à la main," ou faire du pair programming avec l'Agent, mais la clé est : vous devez être dans le code.

Car écrire du code vous-même, ou le voir construit étape par étape, apporte une sorte de "friction." C'est cette friction qui vous rend plus clair sur ce que vous voulez faire, comment le système fonctionne et quel est le "ressenti" général. C'est là que l'expérience et le "goût" entrent en jeu, et c'est précisément ce que les modèles les plus avancés ne peuvent pas encore remplacer. Ralentissez, supportez un peu de friction – c'est précisément ainsi que vous apprenez et grandissez.

Au final, ce que vous aurez est toujours un système maintenable—du moins pas pire qu'avant l'apparition de l'Agent. Oui, les systèmes passés n'étaient pas parfaits non plus. Mais vos utilisateurs vous remercieront parce que votre produit est "utilisable," et non un tas de déchets assemblés à la hâte.

Vous aurez moins de fonctionnalités, mais elles seront plus correctes. Apprendre à dire "non" est en soi une compétence. Vous pouvez également dormir paisiblement car vous savez toujours ce qui se passe dans le système, vous avez toujours le contrôle. C'est cette compréhension qui vous permet de traiter le problème de rappel de la recherche agentique, rendant la sortie de l'Agent plus fiable et nécessitant moins de corrections.

Lorsque le système se trompe, vous pouvez vous salir les mains pour le réparer ; lorsque la conception était défectueuse dès le départ, vous pouvez comprendre le problème et le refactoriser en une meilleure forme. Que l'Agent soit présent ou non n'est pas si important, en réalité.

Tout cela nécessite de la discipline. Tout cela est indissociable des humains.

[Article Original]