Mon agent est un collègue amnésique
Matt Pocock propose d’écrire son code pour un agent qui oublie tout à chaque session. Les bases du génie logiciel servaient déjà à ça.
Un agent de code oublie tout d’une session à l’autre. Matt Pocock en tire une règle que je trouve juste : il faut écrire son code et son contexte pour un nouveau venu permanent, et les bonnes pratiques du génie logiciel cherchent à faire exactement ça depuis des décennies.
Le collègue de Memento
Matt Pocock est l’auteur du cours Total TypeScript et du skill grill-me, qui demande à l’agent de vous interroger sans relâche avant de construire quoi que ce soit. Invité du podcast The Pragmatic Engineer, il décrit ce qu’il appelle le « Memento-driven development » :
« Imaginez un humain qui se réveille chaque matin sans savoir qui il est, comme le type de Memento. […] Un humain peut contourner un mauvais codebase et s’en faire une mémoire, mais un agent ne peut pas : il repart de zéro à chaque session. »
L’image me parle parce que je la vis. Il m’arrive souvent de dire à un agent « mais tu étais au courant de ce détail pourtant ! ». Il ne l’était pas. Il l’avait appris dans une session précédente, puis la session s’est fermée. Ma frustration vient de là : je lui parle comme à un collègue qui a de la mémoire alors qu’il n’en a aucune.
Les bases n’ont pas changé de but
La suite de son raisonnement est la plus utile. Un code lisible, des noms clairs, des modules qu’on comprend sans lire tout le reste : on a toujours défendu ces principes pour que le nouvel arrivant s’en sorte. Pocock rappelle que ce nouvel arrivant est désormais là tous les jours, à chaque session. Les principes n’ont pas changé ; on en voit simplement le bénéfice tout de suite.
J’en tire une conséquence pratique. Quand un agent oublie un détail, le corriger dans la conversation ne sert à rien, puisqu’il l’aura oublié demain. Il faut l’écrire là où la prochaine session le lira : une règle du projet, un skill, un test, une note de décisions. J’en parlais déjà dans mon article sur 37signals : quand l’agent se trompe, on répare ce qui le guide.
Je vois la même chose en dehors du code. J’ai un assistant personnel construit sur des notes Markdown, avec un fichier de règles, une note d’état par projet et des skills pour les tâches qui reviennent. Tout ce système sert à une seule chose : permettre à un agent qui ne se souvient de rien de reprendre là où le précédent s’est arrêté.
Les mots directeurs
Pocock a remarqué un autre phénomène. Un agent a tendance à construire couche par couche (la base de données, puis l’API, puis l’interface) et les bugs apparaissent aux jointures. En lisant The Pragmatic Programmer, il est tombé sur la notion de « tracer bullet » : faire d’abord marcher un chemin complet de bout en bout, même grossier, puis l’étoffer. Quand il demande à l’agent de construire « par tracer bullets », le code est meilleur.
Il appelle ces termes des « leading words », des mots directeurs. Un seul terme connu du métier suffit à rappeler au modèle toute une méthode qu’il a vue des milliers de fois. Depuis, il relit les classiques pour en trouver d’autres.
Je ne connaissais pas l’idée. Je l’ai ajoutée au skill que mon agent suit pour implémenter une fonctionnalité : quand le travail traverse plusieurs couches, il doit d’abord faire passer le cas le plus simple de bout en bout, de la migration à la réponse de l’API, avec un test qui le prouve, puis seulement ajouter les cas limites. Je ne sais pas encore si l’effet tient aussi bien sur un vrai projet que dans ses exemples.
Ce qu’il dit des tests
Pocock a des sentiments mitigés sur le TDD avec les agents. Selon lui, un test qui échoue sert surtout à rappeler à un humain distrait ce qui reste à faire. Un agent garde le fil plus longtemps, donc il lui demande plutôt de prouver que son code marche, avec ou sans TDD.
Je fais déjà à peu près la même chose. Ma consigne habituelle tient en une phrase : « fais les checks qu’il faut et vérifie que ça marche ».
Il est aussi en train d’abandonner son environnement local pour des agents dans le cloud, qui continuent de tourner une fois le laptop fermé et sur lesquels on peut travailler à plusieurs. Local ou cloud, l’agent repart de zéro à chaque session : la règle du collègue amnésique s’applique de la même façon.
Sources : AI Skills with Matt Pocock, The Pragmatic Engineer, le skill grill-me. Texte rédigé avec l’aide d’une IA à partir de mes idées, puis relu par moi.