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