L’agent de code que je build commence à devenir intéressant.
Il me semble sensiblement différent de la plupart des agents de code, et c’est en partie philosophique. J’ai bossé sur une nouvelle façon de concevoir les agents, et j’en suis maintenant au stade où le système peut gérer un peu plus de complexité.
Les projets d’aujourd’hui étaient sympas. Celui sur lequel j’ai passé le plus de temps, c’est ce prompt :
« Un blog écrit entièrement en Golang avec des templates, utilisant sqlite comme backend. Genre LessWrong, mais pour des tout-petits instruits. Il doit supporter les tags, les commentaires, l’inscription des utilisateurs et la publication. Rendez ça coloré, mais inutilement technique en même temps. Une sorte d’esthétique brutaliste de garderie pour geeks, soit maximalement minimale, soit minimalement maximale. »
Celui-là a étonnamment bien marché.
Honnêtement, ces prompts de test font la moitié du plaisir. C’est de l’évaluation, certes, mais c’est aussi de la provocation créative. Un bon prompt de test ne se contente pas de mesurer une capacité. Il expose une forme. Un goût. Des modes de défaillance. De petites hypothèses cachées et bizarres. Parfois, ça en dit plus sur l’architecture que n’importe quel benchmark.
Le système de tickets irréductible
Ce qui m’a vraiment fait réfléchir, par contre, c’est le système de tickets interne.
Pour l’instant, c’est encore basique. C’est spécifique au projet et lié à la mémoire et à la planification. Mais même à ce niveau, ça rend déjà une chose évidente : beaucoup de systèmes de tickets humains ne sont que du théâtre d’interface.
Ce n’est pas une insulte. Les systèmes humains ont besoin de cérémonie. Ils ont besoin de visibilité, d’être rassurés, de lisibilité sociale, de rituels de passation, de petits décors en carton pour que la coordination semble réelle et stable. Mais dès qu’on commence à décomposer ces mêmes systèmes pour des agents, le brouillard se dissipe vite.
Ce qu’il reste, c’est une question plus intéressante :
quelle est la structure minimale irréductible nécessaire au travail coordonné ?
Quelles parties sont réellement fonctionnelles ?
Quelles parties sont des costumes de conformité ?
Quelles parties n’existent que parce que les humains ont besoin de regarder la machine et de sentir que l’ordre règne ?
Quand on abstrait la gestion de projet en API compatibles avec les machines, certains éléments deviennent plus importants que jamais, et d’autres disparaissent comme des accessoires de scène après la dernière représentation.