290 sessions, 13 leçons : ce que les agents d'IA ont appris par eux-mêmes

La plupart des matins, une leçon s'affiche en haut de mon terminal. Elle dit : exécutez les tests que vous avez écrits et indiquez s'ils ont réussi ou échoué avant de déclarer le travail terminé.

Personne dans notre équipe n'a écrit cette phrase. Un agent l'a fait, la nuit, après avoir relu une journée de son propre travail et remarqué qu'il écrivait régulièrement des tests sans ensuite les exécuter.

On appelle cela l'auto-amélioration récursive (RSI). On dirait le sujet d'un article sur la fin du monde. En pratique, cela ressemble plutôt à un musicien qui réécoute l'enregistrement après le concert. Vous entendez le passage que vous avez joué trop vite. Vous le notez. Le lendemain, vous vous précipitez un peu moins.

Cette boucle tourne sur nos propres machines depuis la mi-septembre. La plupart des textes que je lis sur la RSI des agents d'IA parlent de ce qu'elle pourrait faire un jour. Ici, je parle de ce que la nôtre a fait jusqu'à présent.

Comment fonctionne la boucle

Sno Station la lance une fois par jour. Les étapes sont simples.

Elle rassemble les sessions de la journée issues de Claude Code et de Codex. Chaque session reçoit deux indications rapides : à conserver ou non, réussie ou échouée. Celles qui sont conservées passent à un modèle chargé de les examiner, qui cherche un moment où quelque chose a été appris. Il s'agit généralement d'une personne qui corrige l'agent, mais parfois l'agent se reprend lui-même, et parfois l'environnement lui joue simplement un mauvais tour.

Pour chaque moment, ce modèle rédige une leçon en quatre parties. La situation qui la déclenche. Le conseil. La raison. Et la preuve, citée mot pour mot depuis la session, avec le numéro de la ligne d'origine.

Ensuite, la leçon doit franchir deux contrôles.

Le premier est mécanique. Chaque citation utilisée par la leçon doit figurer, caractère pour caractère, dans la session dont elle prétend provenir. Une leçon fondée sur une citation introuvable est écartée. Le second contrôle est confié à un autre modèle dont la seule tâche est de douter. Il compare chaque phrase de la leçon aux preuves et rejette celles qui affirment plus que ce que les preuves permettent.

Après cela, une personne intervient. Je lis ce qui reste et décide de garder ou non.

Les leçons retenues sont présentées aux agents au début de sessions ultérieures, à raison d'une ligne chacune, les plus utiles en premier. Si une leçon semble pertinente, l'agent peut l'ouvrir en entier.

Ce qui en est sorti

Voici les chiffres tirés des propres relevés de la boucle sur notre machine de compilation.

Elle a recueilli 1 879 sessions. Parmi elles, 290 ont été envoyées au modèle chargé de les examiner. 13 leçons ont franchi les deux contrôles. J'en ai gardé 6. Les 7 autres attendent encore ma décision.

290 sessions, 13 leçons. Ce rapport m'a d'abord surpris. Puis j'y ai réfléchi. Combien de journées de votre propre travail contiennent une idée que vous écririez pour l'accrocher au mur ? La plupart des journées sont simplement des journées.

Et les leçons elles-mêmes sont modestes. Pour dire vrai, je m'attendais à quelque chose de plus grand. En voici trois, citées telles que les agents les ont écrites.

Après un renommage de package ou de répertoire avec git mv dans un espace de travail npm, avant d'exécuter la vérification, contrôlez explicitement dans chaque package les répertoires de sortie de compilation ignorés par git (dist/, build/, out/) pour repérer d'anciens artefacts. Déplacez-les ou supprimez-les.

Avant de construire chaque bloc d'un correctif, lisez la plage exacte de lignes à modifier pour disposer du contexte mot pour mot. Ne réutilisez jamais des identifiants ou une syntaxe provenant d'une lecture antérieure tronquée du même fichier.

Indiquez que la fonctionnalité n'est « pas documentée dans les sources consultées » jusqu'à ce qu'un contrat explicite ou un test ciblé établisse son absence.

La première nous a coûté un après-midi le jour où le problème s'est produit. Un package avait été renommé, tout était correct dans le code source, mais l'installation échouait toujours parce qu'un ancien fichier compilé traînait dans un dossier que git ne regarde pas. La deuxième décrit ce qu'un agent fait quarante fois par semaine : il se souvient approximativement du contenu d'un fichier et prépare un correctif d'après son souvenir plutôt que d'après le fichier.

La troisième est ma préférée. Un agent comparait des produits, n'a pas trouvé une fonctionnalité dans la documentation d'un concurrent et a conclu que ce concurrent ne l'avait pas. L'absence de mention ne prouve pas l'absence. C'est une leçon que j'ai déjà dû enseigner à des humains.

C'est le genre de choses qu'un ingénieur expérimenté porte en lui sans le savoir. Les traces des erreurs passées. La différence, c'est qu'un agent commence chaque session sans aucune de ces traces.

Ce que cela vaut

Je ne peux pas encore dire dans quelle mesure tout cela aide.

Les leçons ont été montrées au début de 5 595 sessions. Un agent en a ouvert une en entier 135 fois. Soit environ 2 pour cent du temps. La version en une ligne fait l'essentiel du travail, ou rien ne le fait. Je ne sais pas toujours lequel des deux.

La boucle vérifie aussi ses propres résultats. Après avoir montré une leçon, elle cherche à savoir si l'agent l'a suivie et si cela l'a aidé. Pour l'instant, elle a obtenu deux réponses claires : « suivie, et utile ». Les deux concernent la même leçon. Sept autres réponses restent incertaines.

Et la leçon qui s'affiche en haut de mon terminal, celle qui dit d'exécuter vos tests ? Après sa mise en service, les agents ont encore parfois omis les tests. 4 échecs sur 12 sessions. Avant cette leçon, il y en avait 22 sur 119. L'échantillon est trop petit pour dire que la situation a empiré. Il est certainement trop petit pour dire qu'elle s'est améliorée.

Donc je ne sais pas encore. Je le dis sans détour. Si vous m'obligiez à lui attribuer une valeur aujourd'hui, je dirais que chaque leçon conservée évite une erreur qui coûte entre dix minutes et un après-midi, et que ces six mêmes erreurs reviennent assez souvent pour que cela compte. Une nuit d'examen de 193 sessions a coûté environ cinquante centimes. Le coût d'une erreur d'estimation sur leur valeur est faible.

Ce à quoi je me fie est plus modeste qu'une mesure. Je reconnais ces leçons. Je les lis et je me dis : oui, c'est arrivé, et oui, c'est ce que je lui aurais dit.

Ce qui a mal tourné

La boucle elle-même avait besoin du traitement qu'elle applique aux agents.

Au début, un défaut permettait à des brouillons de leçons de passer le second contrôle sans aucune vérification. Nous les avons tous écartés. Les chiffres ci-dessus ne comprennent que les leçons ayant suivi le processus complet.

Nous avions aussi construit la boucle avec trop de précautions. Un canari, un contrôle par empreinte, une récupération après plantage. Un soir, nous en avons retiré 724 lignes, et elle a mieux fonctionné. Un système conçu pour apprendre des erreurs avait été entouré de protections contre des erreurs qu'il n'avait jamais commises.

Puis, à la fin de septembre, la boucle s'est tue. Un fichier de paramètres avait disparu ; chaque nuit, elle se réveillait, ne trouvait rien qu'elle avait le droit d'envoyer et se rendormait. Cela a duré une semaine avant que quelqu'un le remarque. Difficile d'aimer quelque chose qui échoue en silence à trois heures du matin.

C'est maintenant sur la liste. Cela devrait probablement devenir une leçon.

Et maintenant

Treize leçons, ce n'est pas un agent qui se réécrit lui-même. C'est un carnet. Il y a un mois, nos agents commettaient le mardi la même erreur que le lundi, sans souvenir de l'un ni de l'autre.

Certains matins, le rappel est là et les tests ne sont toujours pas exécutés.

Sno Station est open source, et la revue nocturne en fait partie. Vous le trouverez sur sno.ai.