Le goulot d'étranglement, c'est moi
Six mois à faire tourner trois à cinq agents de code par jour, sur des projets différents et sur des machines qui ne sont pas celle où je suis assis. Ce qui casse n'est jamais le modèle.
Presque tout ce qui s'écrit sur les agents de code suppose un développeur devant un agent. Et quand le sujet dépasse ce cadre, il saute directement aux flottes de centaines d'agents autonomes. Ni l'un ni l'autre ne décrit une journée de travail.
Ce que font réellement les gens autour de moi, et ce que je fais tous les jours, c'est trois ou quatre agents sur les projets qu'ils ont déjà. Pas mille. Trois. Et à trois, on découvre que les problèmes durs n'ont rien à voir avec la qualité du modèle.
l'attentionOn ne lit pas quatre panneaux, donc on n'en lit aucun
C'est la première chose qui cède, et elle cède vite. À deux agents, on suit. À trois, on commence à balayer. À quatre, on a arrêté de lire sans s'en rendre compte : on regarde défiler, on attrape un mot au passage, et on se dit qu'on relira plus tard. On ne relit jamais.
Le pire n'est même pas là. Le pire, c'est qu'on reste quand même collé à l'écran. Pas pour lire, pour surveiller. Parce qu'à tout moment l'un des quatre peut poser une question et rester bloqué dessus jusqu'à ce qu'on la voie. On a délégué l'exécution et on a gardé la garde.
On a délégué le travail. On a gardé la laisse.
Aucune amélioration de modèle ne touche à ça. Un modèle deux fois meilleur produit deux fois plus de sorties à ne pas lire.
les notificationsPrévenir sur tout revient à ne prévenir sur rien
Ma première réponse a été la mauvaise : notifier chaque événement. Agent démarré, agent a écrit un fichier, agent a terminé une étape, agent a posé une question. Tout.
J'ai tenu deux jours. Au bout de deux jours, on ne lit plus les notifications, exactement comme on ne lisait plus les panneaux. On a juste déplacé le problème d'un écran à l'autre, en y ajoutant du bruit.
Ce qui marche est beaucoup plus étroit, et beaucoup moins satisfaisant à construire : ne signaler que ce qui attend vraiment une réponse humaine. Un agent qui travaille n'est pas un événement. Un agent qui a fini n'en est presque pas un. Un agent bloqué sur une question, si.
la compactionLe contexte se compacte, la consigne disparaît, le travail continue
Celui-là m'a coûté le plus cher, parce qu'il est silencieux. Quand la fenêtre de contexte se compacte, ce qui survit est ce qui a été fait récemment. Ce qui saute est la demande initiale, formulée cinquante messages plus tôt.
L'agent continue donc d'éditer le code avec application, en ayant oublié ce qu'on lui avait demandé. Il ne s'arrête pas, il ne prévient pas, il n'a aucun moyen de savoir qu'il a perdu quelque chose. On s'en aperçoit une demi-heure plus tard, sur une modification qui n'a plus de rapport avec le sujet.
La parade que j'ai retenue n'est pas de répéter la consigne à chaque tour, ce qui consomme précisément la ressource qu'on essaie d'économiser. C'est de stocker la consigne hors de la fenêtre de contexte, et de la faire relire à la demande. La mémoire de ce qu'on veut ne doit pas vivre dans le même endroit que la mémoire de ce qu'on a fait.
le verrouUn verrou libéré par un flux qui peut se taire n'est jamais libéré
Un de mes panneaux est resté marqué « attend une réponse » pendant un traitement de fond entier. J'ai cherché longtemps du côté de l'agent. Le bogue était chez moi et il est instructif.
Le verrou qui marque un panneau comme bloquant n'était relâché que par l'arrivée d'une ligne de transcription ultérieure. Or un traitement de fond n'écrit aucune ligne de transcription. Le panneau réclamait donc mon attention en permanence, sans que rien n'attende quoi que ce soit.
La leçon dépasse largement mon cas : un verrou dont la seule libération vient d'un flux qui peut se taire n'est jamais libéré. Et dans un système dont le seul rôle est de dire ce qui mérite l'attention, un faux positif permanent est pire qu'une panne franche. Une panne, on la voit.
la coutureLocal et distant n'est pas une installation, c'est un état permanent
La machine qui exécute n'est presque jamais celle où je suis assis. C'est normal et c'est souhaitable : un VPS, un serveur du bureau, une machine de test. Mais l'agent, lui, écrit comme s'il parlait à quelqu'un assis devant lui.
Il affiche un chemin de fichier, et ce chemin n'existe pas chez moi. Il affiche une URL en localhost, et elle est morte de mon côté de l'écran. Il me dit d'ouvrir un rapport, et je ne peux pas l'ouvrir.
Ce qui rend ça pénible n'est pas la difficulté, c'est la fréquence. Ce n'est pas un problème de montage qu'on règle une fois : ça se reproduit à chaque sortie d'agent, toute la journée, et chaque fois c'est trois secondes de traduction mentale. Trois secondes, deux cents fois.
les fausses pistesPlus de contexte et plus d'agents ont empiré la situation
Les deux réponses intuitives sont mauvaises, et je les ai essayées toutes les deux.
Une fenêtre de contexte plus grande retarde la compaction, elle ne la supprime pas, et elle rend la perte plus brutale quand elle arrive parce qu'il y a davantage à perdre. Davantage d'agents ne fait qu'accélérer la saturation de la seule ressource qui n'a pas augmenté, c'est-à-dire moi.
Ce sont des problèmes d'ergonomie et d'état, pas de puissance. Ils ne se règlent pas en achetant plus de la chose qui marche déjà.
l'objectionLe contre-argument que je me fais à moi-même
Un VPS à trois euros, tmux, un agent : ça règle complètement le cas d'un seul projet. Complètement. Il n'y a rien à ajouter, et quiconque prétend le contraire vend quelque chose.
Ma conviction est que ça cède vers cinq projets, parce que c'est là que j'ai vu ça céder. Mais c'est une conviction, pas une mesure, et c'est exactement le point sur lequel j'aimerais me faire contredire par quelqu'un qui pratique autrement. Si vous tenez cinq projets à la main sans y laisser votre attention, je veux savoir comment.
Je construis un outil dans ce domaine, une tour de contrôle pour agents de code. Je le dis ici plutôt qu'en fin de texte, et je n'en dirai rien de plus : ce qui précède est vrai indépendamment de ce que j'en fais, et la plupart de ces pannes sont les miennes, pas celles d'un produit concurrent.
Je le dis d'autant plus volontiers que je m'y suis déjà mal pris. Le 8 août, j'ai publié dans une communauté francophone du logiciel libre un billet sur mon propre outil, le jour même où j'y avais créé mon compte. Le billet a été retiré le lendemain. Avec le recul, à juste titre : un compte dont l'unique contenu est l'annonce de son produit est indiscernable d'une publicité, quelle que soit la qualité du texte. Je préfère le raconter que le taire.
Ce qui m'intéresse dans ce texte, ce ne sont pas les points d'accord. Ce sont les endroits où ça ne tient pas : le cas où trois agents ne posent aucun problème d'attention, le montage où la compaction n'a jamais rien cassé, la raison pour laquelle mon histoire de verrou est un bogue de débutant. Écrivez-moi, l'adresse est steven@e2pz.app.