Nous avons chargé Claude Opus 4.6 d'utiliser des équipes d'agents pour construire un compilateur C, ce que cela nous a appris sur l'avenir du développement logiciel autonome

Construire un compilateur C avec une équipe de Claudes parallèles : Nous avons chargé Opus 4.6, à l'aide d'équipes d'agents, de créer un compilateur C, par Nicholas Carlini

Nous avons chargé Opus 4.6 d'utiliser des équipes d'agents pour construire un compilateur C, puis nous nous sommes (presque) retirés du projet. Voici ce que cela nous a appris sur l'avenir du développement logiciel autonome.

J'ai expérimenté une nouvelle approche de supervision des modèles de langage que nous appelons « équipes d'agents ».

Avec les équipes d'agents, plusieurs instances de Claude travaillent en parallèle sur une base de code partagée sans intervention humaine active. Cette approche élargit considérablement le champ des possibilités offertes par les agents LLM.

Pour la tester, j'ai chargé 16 agents d'écrire à partir de zéro un compilateur C basé sur Rust, capable de compiler le noyau Linux. Après près de 2 000 sessions Claude Code et 20 000 dollars de frais d'API, l'équipe d'agents a produit un compilateur de 100 000 lignes capable de construire Linux 6.9 sur x86, ARM et RISC-V.


Le compilateur est un artefact intéressant en soi, mais je me concentre ici sur ce que j'ai appris au sujet de la conception de harnais pour les équipes d'agents autonomes à long terme : comment écrire des tests qui maintiennent les agents sur la bonne voie sans supervision humaine, comment structurer le travail afin que plusieurs agents puissent progresser en parallèle, et où cette approche atteint ses limites.

Permettre le fonctionnement prolongé de Claude

Les structures d'agents existantes telles que Claude Code nécessitent qu'un opérateur soit en ligne et disponible pour travailler conjointement. Si vous demandez une solution à un problème long et complexe, le modèle peut en résoudre une partie, mais il finira par s'arrêter et attendre une nouvelle entrée : une question, une mise à jour de statut ou une demande de clarification.

Pour obtenir des progrès autonomes et soutenus, j'ai construit un harnais qui maintient Claude dans une boucle simple (si vous avez déjà vu Ralph-loop, cela devrait vous sembler familier). Lorsqu'il termine une tâche, il passe immédiatement à la suivante. (Exécutez cela dans un conteneur, pas sur votre machine réelle).



Dans l'instruction générative de l'agent, j'indique à Claude le problème à résoudre et je lui demande d'aborder le problème en le décomposant en petites parties, en suivant ce sur quoi il travaille, en déterminant ce sur quoi il doit travailler ensuite et en continuant efficacement jusqu'à ce que ce soit parfait. (Sur ce dernier point, Claude n'a pas le choix. La boucle s'exécute indéfiniment, même si, dans un cas, j'ai vu Claude [c]pkill -9 bash[c] par accident, se tuant ainsi lui-même et mettant fin à la boucle. Oups !).

Exécution parallèle de Claude

L'exécution parallèle de plusieurs instances permet de pallier deux faiblesses d'un harnais à agent unique :

- Une session Claude Code ne peut effectuer qu'une seule tâche à la fois. À mesure que la portée d'un projet s'étend, il est beaucoup plus efficace de déboguer plusieurs problèmes en parallèle.

- L'exécution de plusieurs agents Claude permet une spécialisation. Alors que quelques agents sont chargés de résoudre le problème concret, d'autres agents spécialisés peuvent être invoqués pour (par exemple) maintenir la documentation, surveiller la qualité du code ou résoudre des sous-tâches spécialisées.

Mon implémentation de Claude en parallèle est très basique. Un nouveau dépôt git vide est créé, et pour chaque agent, un conteneur Docker est lancé avec le dépôt monté sur /upstream. Chaque agent clone une copie locale dans /workspace, et une fois cela fait, effectue un push depuis son propre conteneur local vers upstream.

Pour éviter que deux agents n'essaient de résoudre le même problème en même temps, le harnais utilise un algorithme de synchronisation simple :

1. Claude « verrouille » une tâche en écrivant un fichier texte dans current_tasks/ (par exemple, un agent peut verrouiller current_tasks/parse_if_statement.txt, tandis qu'un autre verrouille current_tasks/codegen_function_definition.txt). Si deux agents tentent de revendiquer la même tâche, la synchronisation de git oblige le second agent à en choisir une autre.

2. Claude travaille sur la tâche, puis extrait les données en amont, fusionne les modifications apportées par les autres agents, pousse ses modifications et supprime le verrou. Les conflits de fusion sont fréquents, mais Claude est suffisamment intelligent pour les résoudre.

3. La boucle infinie de génération d'agents génère une nouvelle session Claude Code dans un nouveau conteneur, et le cycle se répète.

Il s'agit d'un prototype de recherche très précoce. Je n'ai pas encore mis en œuvre d'autre méthode de communication entre les agents, ni imposé de processus pour gérer les objectifs de haut niveau. Je n'utilise pas d'agent d'orchestration.

Au lieu de cela, je laisse à chaque agent Claude le soin de décider comment agir. Dans la plupart des cas, Claude choisit le problème « le plus évident » suivant. Lorsqu'il est bloqué sur un bug, Claude conserve souvent un document répertoriant les approches qui ont échoué et les tâches restantes. Dans le dépôt git du projet, vous pouvez consulter l'historique et voir comment il supprime les verrous sur diverses tâches.

Leçons tirées de la programmation avec les équipes d'agents Claude

Le scaffolding exécute Claude en boucle, mais cette boucle n'est utile que si Claude sait comment progresser. J'ai consacré l'essentiel de mes efforts à la conception de l'environnement autour de Claude (les tests, l'environnement, le retour d'information) afin qu'il puisse s'orienter sans moi. Voici les approches que j'ai trouvées les plus utiles pour orchestrer plusieurs instances Claude.

Rédiger des tests de très haute qualité

Claude travaille de manière autonome pour résoudre tous les problèmes que je lui soumets. Il est donc important que le vérificateur de tâches soit presque parfait, sinon Claude résoudra le mauvais problème. Pour améliorer le harnais de test, il a fallu trouver des suites de tests de compilateurs de haute qualité, rédiger des vérificateurs et des scripts de compilation pour les paquets logiciels open source, surveiller les erreurs commises par Claude, puis concevoir de nouveaux tests à mesure que j'identifiais ces modes de défaillance.

Par exemple, vers la fin du projet, Claude a commencé à perturber fréquemment les fonctionnalités existantes chaque fois qu'il implémentait une nouvelle fonctionnalité. Pour remédier à cela, j'ai construit un pipeline d'intégration continue et mis en place une application plus stricte qui a permis à Claude de mieux tester son travail afin que les nouveaux commits ne puissent pas perturber le code existant.

Mettez-vous à la place de Claude

Je devais constamment me rappeler que j'écrivais ce harnais de test pour Claude et non pour moi-même, ce qui m'obligeait à repenser bon nombre de mes hypothèses sur la manière dont les tests devaient communiquer les résultats.

Par exemple, chaque agent est placé dans un nouveau conteneur sans contexte et passe beaucoup de temps à s'orienter, en particulier sur les grands projets. Avant même d'arriver aux tests, afin d'aider Claude à s'aider lui-même, j'ai inclus des instructions pour maintenir des fichiers README et des fichiers de progression détaillés qui doivent être mis à jour fréquemment avec l'état actuel.

J'ai également gardé à l'esprit le fait que les modèles linguistiques ont des limites inhérentes, qui, dans ce cas, devaient être prises en compte lors de la conception. Il s'agit notamment des suivantes :

- Pollution de la fenêtre contextuelle : le harnais de test ne doit pas imprimer des milliers d'octets inutiles. Il doit au maximum imprimer quelques lignes de sortie et consigner toutes les informations importantes dans un fichier afin que Claude puisse les trouver en cas de besoin. Les fichiers journaux doivent être faciles à traiter automatiquement : en cas d'erreur, Claude doit écrire ERROR et indiquer la raison sur la même ligne afin que grep puisse la trouver. Il est utile de précalculer les statistiques récapitulatives agrégées afin que Claude n'ait pas à les recalculer.

- Cécité temporelle : Claude ne sait pas lire l'heure et, laissé à lui-même, il passera volontiers des heures à exécuter des tests au lieu de progresser. Le harnais affiche rarement la progression incrémentielle (pour éviter de polluer le contexte) et inclut une option --fast par défaut qui exécute un échantillon aléatoire de 1 % ou 10 %. Ce sous-échantillon est déterministe par agent mais aléatoire entre les machines virtuelles, de sorte que Claude couvre toujours tous les fichiers, mais chaque agent peut parfaitement identifier les régressions.

Faciliter le parallélisme

Lorsqu'il existe de nombreux tests distincts qui échouent, le parallélisme est trivial : chaque agent choisit un test différent qui échoue pour travailler dessus. Une fois que la suite de tests a atteint un taux de réussite de 99 %, chaque agent s'est attelé à la compilation d'un petit projet open source différent (par exemple, SQlite, Redis, libjpeg, MQuickJS, Lua).

Mais lorsque les agents ont commencé à compiler le noyau Linux, ils se sont retrouvés bloqués. Contrairement à une suite de tests comprenant des centaines de tests indépendants, la compilation du noyau Linux est une tâche gigantesque. Chaque agent rencontrait le même bug, le corrigeait, puis écrasait les modifications apportées par les autres. Le fait d'avoir 16 agents en fonctionnement n'aidait pas, car chacun était bloqué sur la même tâche.

La solution consistait à utiliser GCC comme compilateur en ligne fiable à des fins de comparaison. J'ai écrit un nouveau harnais de test qui compilait aléatoirement la majeure partie du noyau à l'aide de GCC, et uniquement les fichiers restants avec le compilateur C de Claude. Si le noyau fonctionnait, cela signifiait que le problème ne se trouvait pas dans le sous-ensemble de fichiers de Claude. S'il ne fonctionnait pas, il était possible de l'affiner en recompilant certains de ces fichiers avec GCC. Cela a permis à chaque agent de travailler en parallèle, en corrigeant différents bogues dans différents fichiers, jusqu'à ce que le compilateur de Claude puisse finalement compiler tous les fichiers. (Une fois que cela a fonctionné, il a encore fallu appliquer des techniques de débogage delta pour trouver les paires de fichiers qui échouaient ensemble mais fonctionnaient indépendamment).

Rôles multiples des agents

Le parallélisme permet également la spécialisation. Le code écrit par LLM réimplémente fréquemment des fonctionnalités existantes, j'ai donc chargé un agent de fusionner tout code dupliqué qu'il trouvait. J'ai chargé un autre agent d'améliorer les performances du compilateur lui-même, et un troisième de produire un code compilé efficace. J'ai demandé à un autre agent de critiquer la conception du projet du point de vue d'un développeur Rust et d'apporter des modifications structurelles au projet afin d'améliorer la qualité globale du code, et à un autre de travailler sur la documentation.

Tester les limites des équipes d'agents

Ce projet a été conçu comme un benchmark de capacités. Je souhaite tester les limites de ce que les LLM peuvent à peine réaliser aujourd'hui afin de nous aider à nous préparer à ce que les modèles pourront réaliser de manière fiable à l'avenir.

J'ai utilisé le projet C Compiler comme benchmark pour toute la série de modèles Claude 4. Comme pour les projets précédents, j'ai commencé par rédiger une ébauche de ce que je voulais : un compilateur optimisé à partir de zéro, sans dépendances, compatible avec GCC, capable de compiler le noyau Linux et conçu pour prendre en charge plusieurs backends. Bien que j'aie spécifié certains aspects de la conception (par exemple, qu'il devait disposer d'un SSA IR pour permettre plusieurs passes d'optimisation), je ne suis pas entré dans les détails sur la manière de procéder.

Les modèles Opus 4 précédents étaient à peine capables de produire un compilateur fonctionnel. Opus 4.5 a été le premier à franchir un seuil qui lui a permis de produire un compilateur fonctionnel capable de passer de grandes suites de tests, mais il était encore incapable de compiler de véritables projets de grande envergure. Mon objectif avec Opus 4.6 était de tester à nouveau les limites.

Évaluation

Au cours de près de 2 000 sessions Claude Code réparties sur deux semaines, Opus 4.6 a consommé 2 milliards de jetons d'entrée et généré 140 millions de jetons de sortie, pour un coût total d'un peu moins de 20 000 dollars. Même comparé aux plans Claude Max les plus chers, ce projet était extrêmement coûteux. Mais ce total ne représente qu'une fraction de ce qu'il m'aurait coûté de le produire moi-même, sans parler d'une équipe entière.

Il s'agissait d'une implémentation en salle blanche (Claude n'a eu aucun accès à Internet pendant son développement) ; elle dépend uniquement de la bibliothèque standard Rust. Le compilateur de 100 000 lignes peut construire un Linux 6.9 bootable sur x86, ARM et RISC-V. Il peut également compiler QEMU, FFmpeg, SQlite, postgres, redis, et affiche un taux de réussite de 99 % sur la plupart des suites de tests de compilateurs, y compris la suite de tests de torture GCC. Il passe également le test décisif ultime des développeurs : il peut compiler et exécuter Doom.

Le compilateur n'est toutefois pas sans limites. Parmi celles-ci, on peut citer :

- Il ne dispose pas du compilateur x86 16 bits nécessaire pour démarrer Linux hors du mode réel. Pour cela, il fait appel à GCC (les compilateurs x86_32 et x86_64 sont les siens).

- Il ne dispose pas de son propre assembleur et de son propre éditeur de liens ; ce sont les derniers éléments que Claude a commencé à automatiser et qui sont encore quelque peu bogués. La vidéo de démonstration a été produite avec un assembleur et un éditeur de liens GCC.

- Le compilateur permet de compiler avec succès de nombreux projets, mais pas tous. Il ne remplace pas encore complètement un véritable compilateur.
Le code généré n'est pas très efficace. Même avec toutes les optimisations activées, il produit un code moins efficace que GCC avec toutes les optimisations désactivées.

- La qualité du code Rust est raisonnable, mais elle est loin d'égaler celle qu'un programmeur Rust expert pourrait produire.

Le compilateur obtenu a presque atteint les limites des capacités d'Opus. J'ai essayé (avec acharnement !) de corriger plusieurs des limitations ci-dessus, mais sans succès. Les nouvelles fonctionnalités et les corrections de bogues ont souvent perturbé les fonctionnalités existantes.

Un exemple particulièrement difficile est celui où Opus n'a pas pu implémenter un générateur de code x86 16 bits nécessaire pour démarrer en mode réel 16 bits. Bien que le compilateur puisse produire un code x86 16 bits correct via les préfixes d'opcode 66/67, le résultat compilé dépasse 60 ko, ce qui est bien supérieur à la limite de 32 ko imposée par Linux. Au lieu de cela, Claude triche simplement ici et fait appel à GCC pour cette phase (ceci n'est le cas que pour x86. Pour ARM ou RISC-V, le compilateur de Claude peut compiler entièrement par lui-même).

Le code source du compilateur est disponible. Téléchargez-le, lisez le code et essayez-le sur vos projets C préférés. J'ai toujours trouvé que la meilleure façon de comprendre ce que les modèles linguistiques peuvent faire est de les pousser à leurs limites, puis d'étudier où ils commencent à échouer. Au cours des prochains jours, je continuerai à demander à Claude d'apporter de nouvelles modifications si vous souhaitez suivre ses tentatives continues pour remédier à ces limites.

Perspectives d'avenir

Chaque génération de modèles linguistiques ouvre de nouvelles façons de travailler avec eux. Les premiers modèles étaient utiles pour la complétion automatique dans les IDE. Peu de temps après, les modèles ont pu compléter le corps d'une fonction à partir de sa chaîne de documentation. Le lancement de Claude Code a permis aux agents de se démocratiser et aux développeurs de programmer en binôme avec Claude. Mais chacun de ces produits fonctionne en partant du principe que l'utilisateur définit une tâche, qu'un LLM s'exécute pendant quelques secondes ou minutes et renvoie une réponse, puis que l'utilisateur fournit un suivi.

Les équipes d'agents montrent qu'il est possible de mettre en œuvre des projets complexes dans leur intégralité de manière autonome. Cela nous permet, en tant qu'utilisateurs de ces outils, d'être plus ambitieux dans nos objectifs.

Nous n'en sommes encore qu'au début, et le développement entièrement autonome comporte des risques réels. Lorsqu'un humain travaille avec Claude pendant le développement, il peut garantir une qualité constante et détecter les erreurs en temps réel. Avec les systèmes autonomes, il est facile de voir que les tests sont réussis et de supposer que le travail est terminé, alors que c'est rarement le cas. J'ai travaillé dans le domaine des tests de pénétration, exploitant les vulnérabilités des produits fabriqués par de grandes entreprises, et l'idée que des programmeurs déploient des logiciels qu'ils n'ont jamais vérifiés personnellement est une réelle préoccupation.

Ainsi, même si cette expérience m'enthousiasme, elle me laisse également un sentiment de malaise. La création de ce compilateur a été l'une des expériences les plus amusantes que j'ai vécues récemment, mais je ne m'attendais pas à ce que cela soit possible aussi tôt en 2026. Les progrès rapides réalisés à la fois dans les modèles linguistiques et dans les structures que nous utilisons pour interagir avec eux ouvrent la voie à l'écriture d'une quantité énorme de nouveau code. Je pense que les applications positives l'emporteront sur les négatives, mais nous entrons dans un nouveau monde qui nécessitera de nouvelles stratégies pour naviguer en toute sécurité.

Source : Building a C compiler with a team of parallel Claudes

Et vous ?

Pensez-vous que ce rapport est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Comment j'utilise les agents IA pour écrire du code avec Claude Code, par Nolan Lawson

Laissez l'agent de codage Copilot se charger des tâches fastidieuses : analyser votre référentiel, planifier des tâches en plusieurs étapes, créer des tickets et des pull requests, par Bruno Capuano

Description technique détaillée du fonctionnement interne de l'agent de codage d'OpenAI Codex CLI, un outil de codage IA qui écrit du code, exécute des tests et corrige des bogues