Créer un compilateur C avec une équipe Claude en parallèle

• 16 agents Claude ont collaboré en parallèle pour achever un compilateur C basé sur Rust, atteignant un niveau suffisant pour compiler le noyau Linux 6.9
• Environ 2 000 sessions pour un coût de 20 000 dollars ont permis de générer une base de code d’environ 100 000 lignes, avec prise en charge des architectures x86, ARM et RISC-V
• Les agents ont travaillé en continu sans intervention humaine grâce à un harness de boucle automatique, et ont gagné en efficacité via une structure de tests, parallélisation et répartition des rôles
• Le résultat a montré une compatibilité avec GCC et un taux élevé de réussite aux tests, mais des éléments comme la génération de code x86 16 bits, l’éditeur de liens et la qualité des optimisations restent inachevés
• Cette expérience constitue un cas concret de validation des limites et possibilités d’une équipe autonome de LLM, tandis que la sécurité et le contrôle qualité d’un environnement de développement entièrement autonome émergent comme enjeux majeurs

---

Vue d’ensemble du projet de compilateur C basé sur une équipe d’agents

• Une expérimentation dans laquelle plusieurs instances de Claude collaborent en parallèle pour développer une même base de code
  • Sans intervention humaine en temps réel, elles écrivent, testent et corrigent le code de manière autonome en boucle
• L’objectif était d’achever un compilateur C écrit en Rust afin de compiler directement le noyau Linux
• Au total, 16 agents, environ 2 000 sessions, et 200 millions de tokens en entrée, 140 millions en sortie ont été utilisés
• Le résultat est un compilateur d’environ 100 000 lignes, capable de compiler le noyau Linux 6.9 et de grands projets open source (QEMU, FFmpeg, SQLite, Redis, etc.)

Conception du harness Claude pour une exécution de longue durée

• Claude Code nécessitait auparavant une saisie humaine, mais un harness d’exécution automatique en boucle infinie a permis une progression autonome
  • Une structure de répétition automatique qui enchaîne immédiatement sur la tâche suivante après l’achèvement de la précédente
  • Pendant le travail, un Claude a même accidentellement exécuté pkill -9 bash et mis fin à son propre processus
• La structure d’exécution parallèle repose sur des conteneurs Docker et une synchronisation Git
  • Chaque agent travaille dans /workspace puis pousse vers /upstream
  • Des verrous (locks) basés sur des fichiers texte empêchent les conflits de travail
  • Les conflits de fusion sont résolus directement par Claude

Mode de fonctionnement de Claude en parallèle

• L’avantage de l’exécution parallèle réside dans le débogage simultané et la différenciation des rôles
  • Certains agents écrivent du code, d’autres se chargent de la documentation, du contrôle qualité et de l’optimisation des performances
• Il n’existe ni communication directe ni coordinateur central, chaque agent choisit de manière autonome la tâche suivante
• L’historique Git conserve les traces des verrous de travail et les documents de suivi de chaque agent

Enseignements tirés de la programmation en équipe avec Claude

L’importance de tests de haute qualité

• Claude travaillant de manière autonome à partir des tests fournis, la précision du validateur est essentielle
  • En cas de faux positifs, le développement peut partir dans la mauvaise direction
• Une pipeline d’intégration continue (CI) a été mise en place pour vérifier de force que les fonctionnalités existantes ne cassent pas
• La qualité a été assurée à l’aide de scripts de build open source et de suites de tests de compilateur

Concevoir l’environnement du point de vue de Claude

• Chaque agent démarre dans un nouveau conteneur sans contexte, d’où la nécessité de documenter l’avancement
  • Il leur était demandé de mettre à jour en continu le README et les fichiers de suivi
• Prévention de la pollution de contexte : journaux minimaux, et erreurs consignées de manière à être identifiables avec le mot-clé ERROR
• Pour compenser l’absence de perception du temps, des tests d’échantillonnage de 1 à 10 % étaient exécutés avec l’option --fast

Limites de la parallélisation et solutions apportées

• La parallélisation est simple lorsqu’il existe de nombreux tests indépendants, mais la compilation du noyau Linux constitue une tâche monolithique unique générant des conflits
• La solution a consisté à utiliser GCC comme compilateur oracle de référence
  • Certains fichiers étaient compilés avec GCC, les autres avec le compilateur de Claude
  • En cas d’échec, cela permettait de réduire progressivement le périmètre jusqu’au fichier problématique et de déboguer en parallèle
  • Ensuite, un delta debugging permettait de détecter les erreurs interdépendantes

Répartition des rôles entre agents

• Répartition spécialisée des tâches : suppression de code redondant, amélioration des performances, génération de code plus efficace, amélioration de la structure Rust, documentation, etc.
• La combinaison de la parallélisation et de la spécialisation a amélioré l’efficacité de gestion d’une base de code de grande taille

Évaluation des performances du modèle Opus 4.6

• Jusqu’à Opus 4.5, la compilation de grands projets n’était pas possible ; Opus 4.6 a atteint pour la première fois un niveau réellement exploitable
• Il s’agit d’une implémentation clean room utilisant uniquement la bibliothèque standard Rust, sans accès à Internet
• 99 % de réussite sur la GCC torture test suite, et Doom peut être exécuté
• Limites :
  • Impossible de générer du code x86 16 bits, ce qui impose de faire appel à GCC au stade du boot
  • Assembleur et éditeur de liens inachevés, avec quelques bugs persistants
  • Efficacité du code généré faible, plus inefficace qu’un GCC sans optimisations
  • Qualité du code Rust correcte, mais en deçà du niveau d’un expert

Limites et possibilités d’une équipe d’agents autonomes

• Le projet sert de benchmark pour mesurer les limites de la collaboration autonome des LLM
• Un développement entièrement autonome s’accompagne de risques en matière d’assurance qualité et de sécurité
  • Réussir les tests seuls peut conduire à croire à tort qu’un projet est achevé
• Des inquiétudes sont exprimées quant au déploiement de code sans validation humaine
• Cependant, l’expérience démontre qu’une équipe d’agents autonomes peut mener à bien un projet complexe
• À mesure que les modèles progressent, des stratégies de développement autonome sûres deviennent un enjeu indispensable

Perspectives

• Les progrès des modèles de langage évoluent de l’autocomplétion dans l’IDE → la complétion de fonctions → le pair programming → l’exécution autonome de projets
• Les agent teams montrent le potentiel d’un développement entièrement autonome
• Face à la rapidité des avancées techniques, le besoin de nouveaux cadres éthiques et de sécurité est souligné
• On espère que les usages positifs compenseront les risques, mais il faut se préparer à un nouveau paradigme de développement

[mammal]

Comme il s’agit d’un projet construit uniquement avec la bibliothèque standard de Rust, et non d’un compilateur écrit en C, j’ai l’impression que la critique selon laquelle le code C de gcc/clang ferait partie des données d’entraînement relève un peu d’un déplacement des buts. Quoi qu’il en soit, c’est impressionnant.

[GN⁺]

Commentaires sur Hacker News

• J’ai travaillé pendant près de 10 ans chez Google sur la compilation du noyau Linux avec Clang. Ce projet (clangbuiltlinux.github.io) affirme qu’un LLM a accompli la même chose avec 2 000 sessions et 20 000 dollars de coûts d’API. Le fait qu’il arrive réellement à booter est impressionnant. En revanche, l’efficacité du code généré est faible, et il serait même moins efficace qu’une version de GCC sans optimisations. Cela reste malgré tout un projet vraiment remarquable

  • C’est impressionnant, mais il est aussi possible que le résultat revienne à copier les devoirs de quelqu’un d’autre
  • Apparemment, comme Opus n’a pas réussi à implémenter un générateur de code x86 16 bits, ils ont utilisé une astuce consistant à appeler GCC à l’étape du boot. On peut donc se demander si ça a vraiment booté
  • Cela donne l’impression d’un retour à l’époque du « Trusting Trust » de Ken Thompson. L’IA pourrait bientôt s’implanter elle-même à l’intérieur des compilateurs
  • Si cela a coûté 20 000 dollars, on aurait aussi pu embaucher 8 développeurs seniors pour une courte période avec cette somme. On a l’impression qu’il y a eu trop de dépenses marketing, et le modèle économique réel reste flou

• C’est une approche bien plus réaliste que le projet de navigateur de Cursor. Ils parlent d’une implémentation en clean room, réalisée sans accès à Internet et en n’utilisant que la bibliothèque standard de Rust. Un compilateur de 100 000 lignes serait capable de compiler Linux 6.9, QEMU, FFmpeg, SQLite, Postgres et Redis.
  Opus 4.5 aurait été le premier à réussir ce type de gros tests, et ce résultat semble presque en exploiter toute la limite.
  Malgré les nombreuses contraintes, je trouve que c’est une expérience impressionnante

  • L’expression « implémentation en clean room » semble exagérée. Le modèle a déjà été entraîné sur l’ensemble des compilateurs C d’Internet, donc il n’est pas nécessaire d’utiliser ce terme
  • C’est dommage d’évaluer ce genre de résultat uniquement à l’aune de l’état actuel. Vu la vitesse des progrès de ces derniers mois, dans un an ce sera probablement au-delà de ce qu’on imagine
  • En pratique, cela ressemble moins à une clean room qu’au résultat d’un LLM qui décompresse un savoir compressé pendant l’entraînement en s’appuyant sur des tests
  • Le modèle a de toute façon probablement été entraîné sur du code GCC ou Clang, donc je me demande à quel point il ressemble réellement au code source original
  • Personnellement, c’est impressionnant, mais du point de vue de l’utilisateur réel, c’est moins intéressant. Ajouter une nouvelle ISA à LLVM ou créer un compilateur pour un nouveau langage me semblerait plus pertinent

• Au début, ma réaction a été « wow, incroyable », puis j’ai changé d’avis. Un compilateur C est un logiciel aux spécifications très strictes, donc relativement facile à traiter pour un LLM.
  En revanche, la plupart de nos tâches se déroulent dans des environnements où les exigences sont floues et les objectifs changent en permanence. Je me demande si cela fonctionnerait aussi bien dans ce type de domaine

  • L’idée que « le compilateur C est clair » me fait rire. Vu le nombre de « unspecified behavior » qu’il y a
  • Le fait d’ajuster la génération de code aux tests ressemble à un fitting de modèle de ML. Les humains doivent toujours concevoir les tests et les valider

• Je trouve étrange qu’on attende un résultat parfait. Le simple fait que ce soit possible est déjà surprenant. Ce genre d’essai pourrait être intégré à l’entraînement des prochains Opus ou Sonnet, et peut-être qu’un jour un modèle produira lui-même un compilateur efficace

  • Je pense la même chose. « Ce qui est étonnant, ce n’est pas à quel point le chien danse bien, mais le fait qu’il danse »
  • Il y a en ce moment un fort rejet de l’IA générative, donc au moindre défaut on crie immédiatement à l’“ordure IA”, et c’est regrettable. Ce n’est pourtant qu’une démo, une preuve de concept

• Ce projet serait capable de compiler le noyau Linux, QEMU, FFmpeg, Redis et même Doom. C’est vraiment impressionnant.
  Mais ce type de système agentique fonctionne bien dans les domaines testables, alors qu’il montre ses limites dans des domaines qui demandent du contexte, comme la prise de décision métier

  • Je me demande déjà si la notion même d’« implémentation en clean room » a encore un sens pour un modèle entraîné sur l’ensemble d’Internet
  • L’étape suivante, c’est que l’IA comprenne et opère réellement dans un contexte métier. Par exemple, si l’on regarde un benchmark comme Vending-Bench, le jour où un chef de produit IA mènera automatiquement des entretiens utilisateurs, des expérimentations et des propositions de roadmap ne semble plus très loin

• C’est un beau projet, mais il aurait mieux valu éviter la mention « clean room ». Avec un modèle entraîné sur du code soumis au droit d’auteur, on est plutôt à l’opposé

  • Mais les humains aussi apprennent à partir de code existant, puis réalisent parfois une implémentation en clean room sur cette base
  • De la même manière qu’un humain réutilise ailleurs ce qu’il a appris dans une entreprise, un LLM reconstruit de manière transformatrice les données sur lesquelles il a été entraîné. Tant qu’il ne copie pas directement, la nature du problème est différente

• D’après une issue GitHub, le problème vient d’un chemin d’include manquant. Le compilateur lui-même fonctionne normalement

  • Il manque peut-être simplement un paquet comme glibc-devel
  • Le texte était trop long et manquait d’éléments probants. J’ai eu l’impression qu’il passait à côté de l’essentiel
  • L’IA, c’est l’avenir
  • C’est un résultat vraiment étonnant

• J’aimerais qu’ils publient tous les prompts et l’architecture des agents. Ce serait excellent pour l’apprentissage, mais dépenser soi-même 20 000 dollars pour reproduire cela est difficile à justifier

  • C’est dommage qu’aujourd’hui on regarde seulement le résultat final sans se soucier du processus

• C’est comme une version qui fonctionne réellement du billet de blog de Cursor. Les preuves qu’ils ont effectivement compilé le noyau Linux sont bien plus convaincantes

  • Au départ, je voulais créer un petit langage léger pour le 1er avril, mais voir maintenant des résultats de ce niveau est surprenant. Je compte quand même continuer à essayer

• C’est une approche du type « on peut construire des pyramides, mais pas des cathédrales » (article lié).
  En gros, ils ont injecté une énorme quantité de ressources de calcul pour forcer l’implémentation à fonctionner, au point qu’on pourrait dire que 20 000 dollars sont partis en fumée.
  Obtenir un résultat linéaire avec un calcul exponentiel a un certain sens, mais à long terme cela semble être une direction inefficace

  • 20 000 dollars, c’est selon le tarif API ; avec des abonnements, cela représenterait probablement 5 à 6 forfaits Max
  • Malgré tout, cela ne représente que deux semaines de coût salarial d’un ingénieur FAANG. Un humain ne peut pas créer un compilateur en deux semaines, donc comme démonstration, cela a largement sa valeur