Pourquoi il faut ralentir

• 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