16 agents Claude ont écrit en deux semaines un compilateur C de 100 000 lignes pour $20 000

Nicholas Carlini, chercheur dans l'équipe Safeguards d'Anthropic, a mené une expérience : 16 instances de Claude Opus 4.6 ont travaillé en parallèle sur un dépôt commun pour écrire en Rust un compilateur C à partir de zéro. L'intervention humaine est restée quasi nulle. En deux semaines et environ 2000 sessions Claude Code, les agents ont produit 100 000 lignes de code. Le compilateur construit un noyau Linux 6.9 amorçable sur x86, ARM et RISC-V. La facture d'API s'élève à un peu moins de $20 000.

Comment les agents sont orchestrés

Le principe est simple. Claude tourne dans une boucle infinie : une tâche terminée, il passe à la suivante. Chaque agent vit dans son propre conteneur Docker, clone un dépôt git bare partagé et y pousse ses modifications. Pour éviter que plusieurs agents traitent le même problème, le système repose sur des verrous : Claude crée un fichier texte du type current_tasks/parse_if_statement.txt, et git empêche un second agent de s'emparer de la même tâche. Les conflits de fusion sont fréquents, mais le modèle les résout lui-même.

Il n'y a pas d'orchestrateur, ni de canal de communication commun entre les agents. Chacun décide seul de la suite, et choisit généralement le problème « le plus évident » suivant. Une fois, un agent a exécuté par accident pkill -9 bash et a interrompu sa propre boucle.

L'essentiel de l'effort n'a pas porté sur les prompts, mais sur l'environnement : tests, logs, retours d'information. La sortie des tests est limitée à quelques lignes pour ne pas polluer le contexte. Les erreurs sont écrites sur une seule ligne, avec l'étiquette ERROR pour faciliter le grep. Pour pallier la « cécité temporelle » des agents, une option --fast a été ajoutée : elle exécute un échantillon de 1% ou de 10% des tests, déterministe pour chaque agent.

Là où le système a atteint son plafond

Tant que les tests sont indépendants, la parallélisation est facile : chaque agent prend son propre test en échec. Mais le noyau Linux constitue une seule et gigantesque tâche. Les 16 agents butaient sur la même erreur et écrasaient mutuellement leurs correctifs. La solution est venue de GCC, utilisé comme oracle de référence : GCC compilait une partie aléatoire des fichiers du noyau, Claude le reste. Les agents ont ainsi pu corriger des bugs différents dans des fichiers différents. Pour les paires de fichiers qui ne plantaient qu'ensemble, l'équipe a employé le delta debugging.

Les agents ont aussi reçu des rôles : l'un fusionnait le code dupliqué, un autre accélérait le compilateur lui-même, un troisième travaillait sur l'efficacité du code généré, un quatrième jouait le critique d'architecture du point de vue d'un développeur Rust, un cinquième tenait la documentation.

Chiffres et limites

• Volume : environ 100 000 lignes de Rust, sans dépendances autres que la bibliothèque standard.
• Ressources : 2 milliards de tokens en entrée et 140 millions en sortie, près de $20 000.
• Tests : 99% sur la plupart des suites, dont GCC torture.
• Compile : Linux 6.9 (x86, ARM, RISC-V), QEMU, FFmpeg, SQLite, Postgres, Redis, Doom.
• Développement en « clean room » : Claude n'avait pas accès à internet.
• Pas d'assembleur ni d'éditeur de liens propres : ces modules ont été automatisés en dernier et restent buggés.
• Le x86 16 bits pour le real mode n'est pas implémenté : la sortie dépasse 60 Ko alors que la limite du noyau est de 32 Ko, d'où le recours à GCC.
• Le code généré est moins efficace que celui de GCC, même avec les optimisations désactivées.

Carlini écrit sans détour que le compilateur a presque atteint la limite des capacités d'Opus : les nouvelles fonctionnalités et les correctifs cassaient régulièrement l'existant. Les progrès au sein de la gamme sont nets : les premiers Opus 4 parvenaient à peine à produire un compilateur fonctionnel, et Opus 4.5 a passé pour la première fois de grandes suites de tests, mais ne compilait pas de vrais projets.

Enseignements pratiques

La leçon principale pour ceux qui construisent des agents autonomes : la qualité du mécanisme de vérification compte plus que le modèle lui-même. Si le vérificateur est imprécis, l'agent résoudra avec assurance le mauvais problème. Les tests doivent donc être conçus pour le modèle : sortie courte, logs compatibles avec grep, sous-échantillons déterministes et rapides, CI qui empêche de casser les commits précédents.

Deuxième point : le parallélisme exige une décomposition. Si la tâche est monolithique, des agents supplémentaires ne font que gêner, et un étalon de référence qui fonctionne aide à la découper en parties indépendantes.

Troisième point : $20 000 pour un compilateur capable de compiler Linux coûtent bien moins cher qu'une équipe d'ingénieurs, mais nettement plus qu'un abonnement. Le code est publié, et chacun peut le tester sur ses propres projets C. L'auteur lui-même nuance : le développement entièrement autonome comporte de vrais risques, et l'on ne peut pas encore se passer d'un contrôle humain de la qualité et de la sécurité du code.