Ralentir les agents exprès

Des agents plus rapides ne construisent pas un meilleur logiciel - des agents disciplinés le font. Le régulateur qui garde RakuAI cohérent est la même discipline que nous pensons que toute équipe sérieuse pilotée par agents doit avoir.

Plan différent ce samedi par rapport aux derniers week-ends. Les derniers ont été des week-ends de débit. Quatre-vingts commits, soixante-dix commits, deux cent quatre-vingt-deux avant ça. La tendance était à la hausse. Je chevauchais la file d’agents grand ouverte et regardais les lignes de code s’empiler.

Ce week-end je l’ai régulée à trente-sept commits, exprès. La tendance sur ce graphique est maintenant à la baisse, et elle est à la baisse exprès, et je veux écrire pourquoi parce que je ne pense pas que ce soit la tendance que la plupart des gens qui construisent avec des agents IA attendraient.

Ce qui est vrai sur le flux de travail

Les agents ne se fatiguent pas. Le débit de la couche d’implémentation est borné par le coût en tokens et par le nombre d’issues ouvertes dans la file. Si je dépose cent issues à six heures du matin, la file se vide et se remplit toute la journée et j’obtiens cent PR en retour. C’est ce que fait le flux de travail quand on le laisse tourner grand ouvert.

Ce qu’il ne fait pas, quand il tourne grand ouvert, c’est produire une base de code cohérente. Chaque PR atterrit proprement isolément. L’intersection de quarante PR atterrissant en une journée commence à dériver. Les conventions de nommage divergent. Les frontières de sous-systèmes deviennent floues. L’agent qui a travaillé sur une issue a supposé quelque chose sur la couche runtime que l’agent sur une issue parallèle n’a pas supposé. D’ici samedi soir, les deux hypothèses sont entrées en collision dans une troisième PR qui doit les réconcilier, et la réconciliation est de la bouillie.

Le goulot d’étranglement dans ce flux de travail n’est pas l’agent. C’est l’humain qui lit ce que les agents produisent et garde l’architecture cohérente.

Ce que j’ai changé

Deux choses, toutes deux visibles dans le schéma de commits de ce week-end.

J’ai réduit la profondeur de la file. Au lieu de quinze issues d’agent-queue ouvertes en permanence, je l’ai fait descendre à six. Les agents ne tournent plus grand ouvert. Ils tournent à un rythme qui me permet de réellement lire leur production avant que le prochain lot n’atterrisse.

J’ai déplacé la revue plus tôt. Au lieu de laisser les PR d’agents s’accumuler jusqu’à ce que j’aie un lot à traiter, je suis passé à revoir chacune à son ouverture. Cela paraît plus lent, et ça l’est. Cela attrape aussi la dérive avant qu’elle ne se propage. Une mauvaise hypothèse corrigée tôt le samedi n’a pas besoin d’être défaite d’ici samedi soir à travers six PR.

L’effet combiné de ces deux changements est le week-end à trente-sept commits au lieu d’un week-end à quatre-vingts commits. L’effet combiné est aussi une base de code en meilleure forme qu’elle ne l’était samedi dernier, ce qui est le but.

Ce qui a quand même atterri

Une discipline multi-dépôts s’est affermie ce week-end. Le runtime, le SDK, et le dépôt de documentation ont tous avancé ensemble. Le runtime a eu l’aperçu du répertoire de documentation dans le README. Le SDK a eu les références croisées correspondantes. La documentation a grandi. Aucun des trois dépôts n’a pris de l’avance sur les autres.

Cela compte parce que dans un flux de travail piloté par agents, la documentation n’est pas juste de la documentation. La documentation est l’entrée que l’agent lit quand il reprend la prochaine issue. Si la documentation ment sur ce que le runtime supporte, l’agent écrira fidèlement du code pour la version mensongère du runtime, et ce code ne compilera pas contre la réalité. Le remède est de garder les trois dépôts honnêtes, en permanence, même quand l’un d’eux est celui sur lequel vous travailleriez naturellement.

L’autre chose discrètement importante de ce week-end était le nettoyage de la surface API. Quelques API qui avaient été ajoutées dans la précipitation de septembre se sont avérées ne pas avoir leur place sur la surface publique. Elles ont été rétrogradées en interne. Les agents ont géré la rétrogradation à travers le SDK en une seule PR. C’est le genre de refactorisation qui, faite par un seul humain, prend une journée entière. Faite dans ce flux de travail, elle prend une issue, une PR, et une revue attentive.

Ce que « bonnes pratiques » signifie dans ce flux de travail

Une courte liste, affinée ce week-end par l’expérience de réduire le rythme.

La documentation est une entrée de développement, pas une sortie de développement. Si la documentation est mauvaise, le travail est mauvais. Maintenez-la comme vous maintenez le code. Revoyez-la comme vous revoyez le code. Refusez de fusionner une fonctionnalité dont la documentation a été sautée.

Les frontières entre sous-systèmes sont sacrées. L’agent n’inventera pas de frontières que la base de code n’avait pas déjà. Si vous voulez une frontière, vous devez la dessiner, l’étiqueter, et refuser les PR qui la violent.

La synchronisation inter-dépôts est une tâche de premier ordre. Quand le runtime et le SDK doivent avancer ensemble, la description de la PR doit le dire, et la fusion de l’un est conditionnée à la fusion de l’autre. La divergence d’état entre deux dépôts est l’un des modes de défaillance les plus faciles à éviter et l’un des plus douloureux dont on récupère.

Ralentissez exprès. L’agent ne le fait pas. Vous devez le faire. Le week-end où l’agent livre cent PR n’est pas le même week-end où la base de code s’améliore de cent PR de valeur. Le week-end où l’agent livre trente-sept PR bien revues pourrait l’être.

Ce que les partenaires pourraient trouver utile

Si vous construisez quoi que ce soit avec des agents de codage autonomes et que vous tombez dans la version « les agents travaillent vite et la base de code est un désordre » de ce flux de travail, la réponse n’est pas de meilleurs agents. La réponse est une file plus petite, un passage de revue plus tôt, et une documentation que les agents lisent en entrée.

Si vous êtes un laboratoire IA qui règle un agent de codage pour des flux de travail autonomes-par-PR comme celui-ci, la métrique que je trouve la plus utile en pratique n’est pas les lignes de code livrées par jour. C’est la fréquence à laquelle une PR atterrie tôt dans une semaine doit être réécrite plus tard le même week-end parce que la base de code a bougé en dessous d’elle. Plus ce chiffre est bas, meilleur est l’agent au travail réel.

Trente-sept commits. Une meilleure base de code que je n’avais samedi dernier. Samedi après-midi et je vais aller faire une promenade.