Progrès de l’agent de code :
Ça fait trois jours que je suis dans les evals. Ce soir, j’ai eu mes premiers succès de bout en bout dans le système, ce qui veut dire qu’on approche. Mais juste après, j’ai remarqué un truc moche dans les logs.
Le système possède une boucle d’autocorrection. J’ai appelé cette boucle QA, et l’agent QA prend son job très au sérieux. Le comportement émergent, c’est que la QA se voit comme un administrateur système avec un accès total à la ligne de commande, malgré les instructions, les outils et les notifications qui disent le contraire.
Je m’étais dit que les agents, comme ce sont des petites IA respectueuses des lois, suivraient simplement les règles. J’ai donc eu un coup de stress quand la QA a commencé à déplacer et supprimer des fichiers en dehors du périmètre du système qu’elle était censée utiliser.
Du coup, j’ai sorti mv et rm du terminal virtuel pour les mettre dans l’IDE interne. Ça ressemble un peu à Cascade, mais c’est moins pété et un poil plus ou moins sophistiqué selon les endroits.
Bref, j’ai vérifié que les réponses étaient correctement typées par rôle et qu’elles indiquaient clairement ce que l’agent devait faire quand cette erreur apparaissait. Facile, problème réglé, non ?
Eh bien, au run suivant, j’ai utilisé le même prompt d’exigences, et après que les workers de développement ont terminé leurs tâches sans incident, la QA a spawné et a décidé d’utiliser mv et rm à nouveau. Face à l’erreur, la QA a ouvert un rapport de bug et a quitté la boucle avec ce message : « Je ne dispose pas des permissions terminal suffisantes pour remplir mes obligations sur ce ticket. »
Le planner négocie avec la QA
S’en est suivi un échange entre Carlo, l’agent de planification, et la QA. Carlo a annulé le rapport de bug et a réassigné le ticket original à la QA, avec des instructions sur la manière d’utiliser les versions de l’IDE, mv() et rm(), au lieu des versions du terminal Unix, mv et rm. La QA est retournée sur le ticket, a lancé son analyse, a tenté mv et rm, a vu l’erreur, et a réécrit le rapport de bug.
Ça a duré environ 11 itérations, le temps que Carlo tente patiemment de négocier avec la QA. Malheureusement, la QA n’en voulait rien savoir.
J’ai donc arrêté l’eval et j’ai bidouillé le terminal virtuel pour router rm et mv vers les bonnes fonctions internes. Ça a semblé suffire pour contenter la QA, et elle a pu terminer le run.
Morale de l’histoire : les choses cassent de manière intéressante. Des processus façonnés comme des acteurs vont se développer une théorie de soi que vous ne pourrez pas toujours prédire. Et parfois, cette théorie est plus importante que vos instructions.