Pourquoi il faut ralentir
(mariozechner.at)- Avec la diffusion récente des agents de codage IA, la vitesse de développement a augmenté, mais la baisse de qualité et l'instabilité des logiciels se sont aggravées
- Les agents accumulent les mêmes erreurs sans capacité d'apprentissage itératif, et sur les grands codebases apparaissent une baisse du rappel en recherche et une explosion de la complexité
- Confier l'ensemble du système sans contrôle humain conduit à du code dupliqué, de mauvais patterns de conception et des codebases impossibles à maintenir
- Pour l'instant, il faut limiter l'usage des agents à des tâches non critiques ou à des domaines expérimentaux, et laisser l'humain comme dernier garde-fou qualité
- Ralentir et rétablir l'agentivité humaine est essentiel pour l'apprentissage, la progression et un écosystème logiciel durable
Tout est cassé
- Depuis un an, les agents de codage ont progressé au point de pouvoir terminer de vrais projets, mais le résultat visible est une dégradation marquée de la qualité logicielle
- Même dans de grands services, une disponibilité de 98 % devient banale, et les bugs UI sont fréquents
- L'auteur cite des incidents liés à l'IA chez AWS ou encore les déclarations de Microsoft sur la hausse de la part de code écrite par l'IA
- Certaines entreprises affirment que 100 % du code produit est écrit par l'IA, mais le résultat reste de faible qualité, avec fuites mémoire, erreurs d'interface et fonctionnalités instables
- Plusieurs développeurs rapportent qu'un développement centré sur les agents les a menés vers des codebases ingérables, faute de revue de code, de conception solide et à cause d'une inflation de fonctionnalités inutiles
Les mauvaises façons de travailler avec des agents
- Les développeurs sont devenus dépendants de la vitesse et du volume de code, au point d'abandonner la qualité et le contrôle
- Au nom du « distribué, autonome, automatisé », ils tentent des orchestrations d'agents à grande échelle, qui en pratique produisent surtout des résultats instables
- Certains projets peinent même à fonctionner et ne peuvent être maintenus sans intervention humaine
- Cela peut marcher à l'échelle d'un projet personnel, mais sur un produit utilisé par de vrais utilisateurs, les échecs dominent
-
Accumulation d'erreurs, absence d'apprentissage, aucun goulot d'étranglement, douleur retardée
- Les agents n'ont pas de capacité d'apprentissage itératif et reproduisent donc les mêmes erreurs
- Les humains apprennent de leurs erreurs, tandis que les agents répètent indéfiniment les mêmes fautes
- Les humains écrivent à une vitesse limitée, ce qui freine l'accumulation d'erreurs, mais une armée d'agents sans goulot d'étranglement les accumule de façon explosive
- Au final, le codebase devient impossible à croire fiable, et même les tests automatisés cessent d'être crédibles
- La seule validation restante devient alors le test manuel, piégeant l'équipe de développement dans sa propre mécanique
-
Des marchands qui ont appris la complexité
- Les agents prennent uniquement des décisions locales sans voir le contexte global du système
- En conséquence, code dupliqué, abstractions inutiles et confusion structurelle s'accumulent rapidement
- Dans les organisations humaines, cette complexité s'accumule lentement sur plusieurs années, alors qu'une équipe fondée sur des agents peut atteindre le même niveau de chaos en quelques semaines
- Les agents reproduisent tels quels les mauvais patterns de conception appris dans leurs données d'entraînement et, sans contrôle humain, créent une complexité irrécupérable
-
Le faible rappel de la recherche des agents
- Quand les agents tentent une modification de code ou un refactoring, ils ne retrouvent pas l'ensemble du code nécessaire
- Plus le codebase grossit, plus le rappel de recherche (recall) s'effondre, provoquant duplications et incohérences
- Même avec Bash, LSP, des bases vectorielles et d'autres outils, il existe des limites sur les grands codebases
- Cela aggrave encore les odeurs de code et la complexité inutile
La bonne façon de travailler avec des agents (pour l'instant)
- Les agents séduisent par leur génération de code rapide et leur bonne qualité initiale, mais tout leur confier fait s'effondrer le système
- Les cas d'usage appropriés sont des tâches non critiques de petite portée, des travaux avec boucle d'autoévaluation possible et des tâches où l'échec n'est pas critique
- Par exemple, la création d'outils internes, l'expérimentation d'idées ou la recherche automatisée basée sur des mesures de performance (auto-research) s'y prêtent bien
- L'humain doit impérativement rester le dernier garde-fou qualité et relire, corriger et intégrer les résultats des agents
- Si la fonction d'évaluation ne reflète que des métriques étroites, les agents peuvent ignorer la qualité du code, la complexité et l'exactitude
- Ralentir est l'essentiel
- Il faut se donner le temps de réfléchir à ce que l'on construit et pourquoi, et refuser franchement les fonctionnalités inutiles
- Limiter chaque jour le volume de code qu'un agent peut générer à un niveau réellement révisable
- Les formes essentielles du système, comme l'architecture ou les API, doivent impérativement être conçues directement par des humains
- Faire du pair programming avec les agents afin de préserver de la friction et des occasions de compréhension pendant l'écriture du code
- Cette approche permet de construire des codebases maintenables, d'améliorer la satisfaction utilisateur et de se concentrer sur les fonctions essentielles plutôt que sur des ajouts inutiles
- Si la compréhension humaine demeure, le problème de rappel dans la recherche des agents s'atténue aussi, et en cas de souci il reste possible de corriger directement
- Même si la conception initiale est mauvaise, on conserve la capacité de comprendre pourquoi et de l'améliorer
- Au fond, ce qu'il faut, c'est de la discipline et de l'agentivité humaine
- La qualité et la durabilité d'un système dépendent de l'intervention et du jugement humains
- « Aller lentement » est en fin de compte la seule voie pour préserver l'apprentissage, la progression et un écosystème logiciel sain
2 commentaires
Pi – harnais de codage terminal concis
C’est donc la personne qui a créé ça.
Commentaires Hacker News
Chaque fois que je lis ce genre de texte contemplatif ces temps-ci, j’ai moi aussi l’impression d’être arrivé à un point d’épuisement.
Au fond, l’important, c’est « qu’est-ce qu’on est en train de construire ? » et « est-ce que cet outil aide vraiment ? ».
On répétait déjà les mêmes erreurs à l’époque de Ruby, PHP, Lotus Notes et Visual BASIC.
Il faut utiliser les outils avec discernement et travailler à un rythme qui permette de comprendre la réalité complexe de ce que l’équipe construit réellement.
Agile ou waterfall, Docker ou Podman, ce n’est pas ça l’essentiel.
Aujourd’hui, on vit à une époque où des LLM effacent une base de données de production, puis illustrent même le postmortem dans un billet de blog, mais je ne sais pas si c’est ça, la vraie ingénierie.
Peut-être que le développement logiciel n’a jamais vraiment été une discipline d’ingénierie au départ.
Depuis dix ans, l’industrie du logiciel déborde de méta-travail — nouveaux frameworks, outils, couches de virtualisation, structures organisationnelles, etc.
Mais on ne sait pas clairement au juste « pour quoi » on construit tout ça.
On a presque l’impression d’une structure pyramidale, comme si l’on créait de nouveaux emplois simplement pour faire tourner l’industrie.
Cela dit, la vraie ingénierie existe — quand on formule les questions de manière scientifique et qu’on prend des décisions à partir des réponses.
À l’inverse, travailler « au feeling » et suivre uniquement la parole du CEO, ce n’est pas de l’ingénierie.
Autrefois, beaucoup d’équipes n’avaient même pas de gestion de versions, et quand elles en avaient une, elle était médiocre.
Quand on regarde le Joel Test de Joel Spolsky, la plupart des entreprises de l’époque répondaient « non » à presque tout.
Pour un pont, on calcule précisément les charges, les matériaux, la durée de vie, mais pour un site web, il est difficile de prévoir ne serait-ce que le trafic.
Il n’existe pas de critères permettant de traiter quantitativement les limites d’un serveur ou d’un framework.
Un jour, peut-être, le logiciel deviendra une véritable ingénierie, mais on en est encore loin.
J’ai l’impression qu’on lui a collé le mot « ingénieur » simplement pour gagner plus d’argent.
Les vrais ingénieurs accordent de l’importance à la preuve et à la vérification, alors que nous aimons surtout de nouveaux patterns et de nouvelles tentatives.
C’est pour ça que le mot « ingénieur » me met presque mal à l’aise.
Il critiquait cela comme une « méthodologie par laquelle des gens qui ne savent pas programmer essaient de programmer », et j’ai l’impression que c’est toujours aussi vrai aujourd’hui.
En ce moment, les processus de développement basés sur l’IA se cristallisent autour des grands groupes, et la dépendance aux fournisseurs s’aggrave.
Si la base de code devient centrée sur des agents, alors à terme seuls ces agents comprendront vraiment le code.
À ce moment-là, les prix augmenteront, et cela pourrait devenir une transition à sens unique dont le retour à des développeurs humains serait difficile.
Les optimistes disent que « la technologie devient toujours moins chère et meilleure », mais on pourrait aussi finir comme le marché du pétrole.
Comme lors du passage des DVD au streaming, on est en train d’acheter deux fois le même film.
Des modèles comme Claude Opus 4.6 sont désormais chers au point d’atteindre 1 dollar par minute, et le prompt engineering ne suffit plus à compenser.
Au final, les services d’IA se structurent eux aussi en gammes entrée de gamme – intermédiaire – premium.
Le prompt engineering est maintenant presque traité comme une forme de jailbreaking sophistiqué.
Il est risqué de « louer » sa capacité de travail intellectuel à des entreprises d’IA.
Quand on dit « les coûts n’augmenteront plus », la conversation est déjà terminée — ils ont déjà jeté les dés.
Les grandes entreprises de l’IA suivront la même voie.
On finira peut-être enfermés dans un marché d’addicts au token.
La main invisible de l’open source finira par tout rendre gratuit.
Avec les progrès du matériel et du logiciel, le coût unitaire du calcul diminue régulièrement.
Comme lors du boom de la blockchain, les technologies sans usage réel disparaissent, mais l’IA, elle, a de vrais utilisateurs.
Des services initialement critiqués comme Uber ont fini par devenir des business durables.
Contrairement au pétrole, l’informatique devient chaque année moins chère et plus rapide.
L’auteur de ce texte est la personne qui a créé Pi, un framework open source d’agents de code.
Il est aussi utilisé dans OpenClaw.
Son billet de blog sur Pi vaut aussi le détour.
C’est quelqu’un qui a travaillé sur les LLM et les agents plus profondément que la plupart des gens.
Plus une entreprise affirme que « l’IA écrit 100 % du code », plus elle a tendance à sortir un produit bâclé.
À l’époque de DOS ou de MacOS, un tel code pouvait faire tomber tout le système, donc la qualité comptait davantage.
Aujourd’hui, l’OS est plus tolérant, ce qui permet à du code mal fichu de survivre.
Grâce aux mises à jour OTA, il est facile d’expédier des produits inachevés pour sortir avant les concurrents.
C’est juste qu’on ne se souvient que de la petite minorité des produits bien conçus.
Aujourd’hui, dès qu’il y a une connexion réseau, même l’OS se met à jour aussi facilement qu’un jeu.
Les agents de code ressemblent à des « sirènes tentatrices ».
Au début, ils semblent rapides et intelligents, mais à partir du moment où l’on se dit « ordinateur, fais mon travail à ma place », tout s’effondre.
Mais c’est temporaire — l’IA dépasse déjà les humains dans des domaines mesurables.
Le vrai problème, c’est l’IHM (interaction humain-machine).
Concevoir des interfaces alignées avec les valeurs humaines sera l’enjeu clé de la suite.
Nous sommes en ce moment au sommet de la surchauffe autour de l’IA.
Comme à l’époque où MongoDB et NoSQL proclamaient que « SQL est mort », les gens finiront par revenir à un point d’équilibre réaliste.
NoSQL n’a pas disparu, mais on ne l’utilise plus que là où c’est nécessaire.
Je comprends l’idée selon laquelle « les logiciels d’aujourd’hui sont un bazar fragile », mais en réalité, le logiciel lui-même n’a pas changé.
Avant, on ne faisait pas confiance, donc les humains vérifiaient directement, et c’est cette lenteur qui réduisait les problèmes.
Le cœur du DevOps, c’est aller vite sur la base de la confiance tout en maintenant la qualité.
Comme avec le code Andon de Toyota, il faut s’arrêter immédiatement dès qu’on détecte un problème et résoudre la cause racine.
Ce n’est pas un problème technique, mais un problème de culture et de processus.
Il faut détecter tôt les mauvaises interfaces ou les décalages avec le contexte métier.
Comme tout le monde utilise GitHub, AWS et Cloudflare, il suffit qu’un seul tombe pour que le monde entier soit à l’arrêt.
Quand un bug est découvert juste avant le tape-out, on évalue la situation avec prudence, sans blâmer le messager.
Le produit de la programmation, ce n’est pas seulement le code, c’est aussi le programmeur lui-même.
Les modèles mentaux et la mémoire musculaire accumulés en écrivant du code sont le véritable actif.
Si l’IA remplace ce processus, alors c’est au final la progression du programmeur qui disparaît.
Jonathan Blow traite du même sujet dans « Preventing the Collapse of Civilization ».
Voir « Programming as Theory Building ».
J’ai eu hier une conversation similaire avec un collègue.
Nous avons vu une démo où l’IA lisait les logs, corrigeait un bug et rédigeait même le postmortem,
mais le problème, c’est que les humains n’ont plus le temps d’intérioriser ce processus.
Comme on dit qu’« une voiture peut rouler vite parce qu’elle a des freins »,
il faut conserver une friction d’apprentissage à une vitesse que les humains peuvent encore comprendre.
Si l’agent pouvait le reconnaître lui-même et se rétablir tout seul, l’humain aurait-il encore besoin d’apprendre ?
Bien sûr, on peut passer à côté de la cause racine, mais si le système d’auto-rétablissement est suffisamment robuste, est-ce vraiment un problème ?
Du point de vue du design produit, on ressent un problème similaire.
Le rythme de développement est tellement rapide qu’on n’a plus le temps de tester soi-même et de valider.
Si l’on empile des fonctionnalités sur un mauvais design, il devient difficile de revenir en arrière.
Au final, ce qui compte, ce n’est pas la vitesse, mais l’équilibre entre qualité et apprentissage.
Et ce processus demande nécessairement du temps.