L’auteur de gonzo_ML : dans son équipe, seuls les modèles écrivent le code, les humains font les revues

D’ordinaire, les récits du type « nous sommes passés aux agents » se terminent par une belle présentation. Ici, on trouve une chronologie, des chiffres et une description honnête de ce qui n’a pas fonctionné. L’auteur de la chaîne gonzo_ML raconte comment, entre 2024 et 2026, il est passé de « les modèles complètent parfois le code » à « plus personne dans l’équipe ne code à la main ».

Le seuil franchi par les modèles

Les premiers projets achevés par l’auteur ont vu le jour à la charnière de 2024 et 2025. Selon lui, ce sont les modèles qui ont franchi un seuil, et non lui qui est devenu plus audacieux. En janvier 2025, Gemini et Claude lui ont produit le code d’un transformeur, d’interventions et d’une visualisation des activations pour un projet universitaire sur l’interprétabilité.

Au printemps, il a écrit un serveur MCP de traduction sans, par principe, saisir lui-même la moindre ligne. En décembre, il l’avait remanié pour utiliser Streamable HTTP et amené jusqu’en production. Comme souvent, la partie production s’est révélée plus volumineuse que la fonctionnalité elle-même : la journalisation, la supervision, la sécurité, la charge, la gestion des erreurs et le déploiement ont ajouté davantage de code que le nouveau transport.

La méthode de travail qui s’est imposée est la suivante : des spécifications décomposées, des tests avant l’implémentation et des ADR pour les décisions adoptées. Tout a commencé avec speckit ; aujourd’hui, toute l’équipe applique ces pratiques dans Claude Code, et non plus seulement l’auteur.

Pourquoi le brownfield ne fonctionnait pas, avant de finir par fonctionner

En 2025, l’auteur a tenté de confier aux modèles le code d’une plateforme vieille de dix ans. Les corrections de bugs et les petites fonctionnalités ne correspondaient pas aux attentes. Il a mis cela sur le compte du brownfield. Il a découvert plus tard que le problème était ailleurs : le contexte se trouvait dans la tête des humains, pas là où un agent pouvait le récupérer.

L’équipe s’est donc attaquée aux fondations. Elle a ouvert aux modèles la documentation présente dans les dépôts et, via MCP, celle de Confluence, ainsi que les normes et ADR, les tâches — d’abord dans Jira, puis dans Linear —, les journaux de production via MCP et, si nécessaire, les échanges dans Slack. Autrement dit, tout ce dont une nouvelle recrue aurait besoin pour travailler sur le projet. Désormais, les humains attribuent les tâches et effectuent les revues, tandis que les agents prennent aussi en charge la première revue, la documentation, les documents de livraison et les tests. L’humain intervient aux quality gates pour donner son approbation.

Le goulot d’étranglement s’est déplacé. Écrire le code ne prend plus beaucoup de temps, mais la lecture humaine finale est sous pression. Chacun maintient plusieurs sessions d’agents : pendant qu’un agent écrit, il est possible de lire dans une autre session les nouveaux et interminables diffs.

Choisir son langage et passer à Rust

Un effet inattendu est apparu : le langage peut être choisi en fonction de la tâche, et non des compétences de l’équipe. Le premier candidat fut un service émulant de véritables API avec tous leurs défauts, sur lequel butaient les tests de performance. Il a été réécrit en Rust, mais aussi en Go et en Node, avec un test de parité couvrant les quatre implémentations.

Dans le même pod de 100 Mo, Rust maintient environ 8 900 connexions ouvertes, contre quelque 3 400 pour l’original en Python. Au repos, il occupe 1 MiB au lieu de 33. Go avec fasthttp n’a fait que 11 % de mieux que Python, tandis qu’avec la bibliothèque standard net/http, il s’est révélé deux fois moins performant. L’auteur apporte une réserve : ces chiffres proviennent d’un banc de test local, et, dans un paradigme manuel, personne n’aurait consacré ne serait-ce qu’une semaine à une telle réécriture pour un service auxiliaire.

Pas seulement du code

Autre exemple : une déclaration comptable. Auparavant, l’auteur revérifiait chaque année le travail des comptables et y trouvait des erreurs. Cette année, Claude l’a fait en une soirée. Il a relevé des erreurs que l’auteur n’aurait pas pensé à contester, en citant les lois et leurs interprétations — l’auteur a vérifié, tout concordait. Il a également détecté un calcul erroné de l’année précédente, qui avait augmenté l’impôt, ainsi qu’un remboursement oublié pour l’année en cours. Le quality gate s’est déplacé : le modèle contrôle désormais les comptables comme l’auteur lui-même.

Limites et conclusion

Il s’agit d’une expérience personnelle unique, sans mesures indépendantes. Le benchmark Rust est local et le cas fiscal est isolé, même si l’auteur a vérifié manuellement les références. Les conditions sont elles aussi particulières : l’entreprise se réorganise délibérément selon une approche AI-first.

La conclusion pratique pour les équipes est la suivante : si un agent produit « quelque chose qui ne va pas », commencez par vérifier où se trouve le contexte. Placez dans le dépôt et dans MCP la documentation, les ADR, les tâches et les journaux ; rédigez les spécifications et les tests avant l’implémentation. Préparez aussi à l’avance le processus de revue, car c’est précisément lui qui deviendra le goulot d’étranglement.