Aller au contenu

Garder un essaim de code orienté sur des projets longs

Test de l’essaim d’agents de code.

J’en suis à mon troisième jour de tests à horizon long, et la session actuelle tourne depuis un peu plus de 3 heures, pratiquement seule.

Vous ne pouvez pas encore le voir, car le test est automatisé via Codex pour le moment, mais c’est la distance la plus longue jamais parcourue.

À cet instant, la machine a déjà généré plus de 6 000 lignes de code selon le cahier des charges. La planification et la décomposition se sont bien passées cette fois.

L’objectif est de réaliser un portage Go en « white-room » d’un système d’orchestration open-source très utilisé, écrit en Python, à partir d’un seul document de spécifications, sans aucune baby-sitting d’agent.

La cible du test est assez large pour mettre les agents à l’épreuve, assez petite pour rester raisonnable, et assez disciplinée pour que l’architecture soit lisible.

C’est une session fantastique jusqu’ici. J’ai débusqué des bugs de processus, dont quelques-uns bien vicieux.

Mais la fonction /babysitter marche. La fonction /rawcontext est fonctionnelle. Et ça narre son propre statut comme une folle.

Le système a une transparence programmatique totale, et tout ça avance.

C’est ça qui compte.

À ce stade, je m’inquiète moins d’écrire un runtime d’agents cohérent capable de coder, que de savoir si un système d’agents peut rester orienté, s’auto-inspecter, se remettre de ses erreurs, exposer son propre état et continuer de progresser sur un projet trop gros pour être résolu d’un seul trait.

C’est ça, la mission.

Un agent de code capable de tourner pendant des heures, ou des jours tout seul, de rester cohérent et de boucler des projets monstrueux de manière fiable.

On y est presque, les bébés.
Je vous aime fort.