Mise à jour du projet d’agents de code :
Une observation.
Les solveurs à horizon long sont en fait assez faciles à écrire.
On bosse sa structure. On peaufine son système. On bâtit l’architecture avec soin dès le premier jour. Et si on a bien fait ça, il y a de fortes chances qu’on puisse faire tourner ses agents aussi longtemps que nécessaire.
En fait, si on maîtrise l’isolation du contexte et qu’on arrive à gérer une sorte de mémoire orientée tâche entre les processus, on peut même faire fonctionner la résolution à horizon long sur certains modèles de la classe 27B à 35B, ce qui aurait été presque impensable il y a encore un an.
Enfin... jusqu’à ce qu’on essaie de généraliser ce processus entre plusieurs modèles.
C’est là que, je pense, les gens se plantent.
Les modèles sont chaotiques. Les outils, du moins tels que l’industrie les conçoit aujourd’hui, demandent encore un effort de raisonnement. J’ai pas mal de griefs à ce sujet, mais je vais les garder pour plus tard et partir du principe qu’on parle tous d’outils cloud-first, ou interchangeables via le cloud de manière significative.
Là où la généralisation devient le benchmark
Parce que c’est le raisonnement sur les outils, ou parfois son absence, qui crée le goulot d’étranglement.
Imaginez : vous avez bâti le runtime d’agents le plus propre de votre carrière, vous êtes ravie de sa perfection logique. Ça brille. Mais trois modèles arrivent à boucler le workflow, alors que le quatrième n’y arrive pas.
Vous réparez ça pour le quatrième, et sans savoir comment, vous avez cassé la même pièce pour les deux premiers. Vous voilà dans la grotte aux gobelins avec une lampe torche et un bloc-notes, à essayer de comprendre s’il vous faut des invariants plus stricts, des processus plus simples, de meilleures limites de rôles, ou un sitar et un feu cérémoniel.
La réponse est : oui.
C’est pour ça que la généralisation devient un benchmark.
Même dans des systèmes moins sophistiqués, on voit parfois des avertissements du genre : « On ne sait pas ce qui va se passer si vous utilisez ce modèle. Vous êtes prévenus ! »
C’est aussi l’une des raisons pour lesquelles les agents de code sont un espace de problèmes si intéressant.
Il y a plein d’autres raisons, évidemment.
On ne peut pas vraiment faire tourner un business avec des agents tant qu’on n’a pas réglé le problème des agents de code. Mais ce que je trouve le plus intéressant, c’est qu’avec le code, contrairement aux autres catégories de travail d’agents... on n’a qu’une idée vague de ce qu’est la tâche.
On ne connaît pas la quantité de choses. On ne connaît pas toujours les conséquences d’un changement avant de l’appliquer. On n’a qu’une idée approximative de la complexité d’un projet donné, en supposant que l’utilisateur ne parte pas dans une spirale de « ne serait-ce pas sympa si... ».
Ce qu’ils feront, si vous les laissez trop bavarder.
L’autocorrection cohérente à grande échelle
Alors, quand on construit des agents capables de coder pendant des heures, des jours ou des semaines sans s’arrêter, tout l’enjeu est de maximiser la certitude tout en gardant des boucles d’autocorrection cohérentes.
Ensuite, on généralise.
Ensuite, on teste sur les douze modèles les plus populaires du moment.
Ensuite, on mesure le succès au nombre de projets terminés, à la stabilité des passages de relais, à la cohérence du comportement de récupération et, avec un peu de chance, au plus petit nombre possible de crises de nerfs de l’IA.
Si vous arrivez là sans que la complexité ne fonde et ne bouffe tout votre temps, mon ami, vous tenez un business.
C’est beaucoup plus dur que ça en a l’air.
Je pense que c’est la vraie raison pour laquelle la plupart des systèmes n’essaient pas encore de le faire.
Ça vous plombe la vélocité comme rien d’autre.
C’est risqué d’admettre ça en ce moment : il existe des contextes de développement où même des systèmes entièrement automatisés peuvent réduire votre vitesse à un pas de tortue.
Mais c’est là que se trouve le vrai boulot.
On patauge dans la boue. On se coltine des évals lentes et on reste attentive, parce que c’est un travail de précision. On observe, on documente, on resserre les boucles. On simplifie le processus. On rend le système moins malin là où l’astuce nuit, et plus explicite là où l’ambiguïté continue de s’infiltrer.
Et une fois que c’est fini, on peut enfin utiliser l’outil, et là, on doit retrouver sa vélocité.
Le build actuel
Voilà où j’en suis aujourd’hui.
On est au dernier tour du projet d’agent de code. Je viens d’ajouter de la télémétrie interne pour faciliter l’audit et le débogage. Moins d’étapes. Meilleure visibilité. Plus facile à auditer et à surveiller sur toute la ligne.
La suite, c’est un serveur MCP compatible avec l’orchestration, optimisé pour Paperclip. Ça devrait aussi marcher avec Pillowfort quand il sortira. Même principe général.
On a survécu aux périodes fastes et aux moments de crash total.
Et je me sens plutôt confiante à l’idée de passer le bébé à mon groupe bêta bientôt.
Ça va être sympa.