Discussion :

[Nicholas Carlini]

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).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#!/bin/bash
 
while true; do
    COMMIT=$(git rev-parse --short=6 HEAD)
    LOGFILE="agent_logs/agent_${COMMIT}.log"
 
    claude --dangerously-skip-permissions \
           -p "$(cat AGENT_PROMPT.md)" \
           --model claude-opus-X-Y &> "$LOGFILE"
done

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

[Serguei_TARASSOV]

Y a t il d’intérêt générer le code en Rust à la place de C/C++ ?

[la.lune]

Quand j'ai trouvé que l'article est ecrit pas un ingénieur d'Anthropic et publié dans un blog d'Anthropic, je trouve ça a une vocation publicitaire. Mais intéressant sur comment dépasser les limites d'une simple session Claude, et orchestrer plusieurs agents claude, même s'il expose une manière d'exploser les dépenses.
L'article serait neutre s'il était ecrit par un ingénieur indépendant. Mais là c'est plutôt une exposition de comment ils font pour evaluer les limites de Claude.

[Mathis Lucas]

Des tests révèlent les lacunes profondes du compilateur C créé par l'IA Claude d'Anthropic pour 20 000 dollars : l'outil est nettement moins efficace que GCC et peine à réaliser des optimisations de base

Anthropic a annoncé qu'une équipe de 16 agents Claude Opus 4.6 ont écrit, en deux semaines et sans accès à Internet, un compilateur C en Rust de 100 000 lignes. Le compilateur est capable de compiler Linux et même le jeu Doom, ce qui a été présenté comme une démonstration spectaculaire des capacités de l'IA dans le développement logiciel. Cependant, lorsque l'on examine de plus près les performances réelles, l'utilité et la qualité du code, le discours passe de « percée révolutionnaire » à « expérience très coûteuse ». Avec un coût d'environ 20 000 $ en utilisation de jetons, le compilateur créé par Claude produit des binaires moins efficaces que GCC.

Le langage C a 53 ans. L'écosystème C dispose de suites de tests qui encodent les subtilités du langage. Il existe des compilateurs de référence, tels que GCC et Clang, qui servent de référence à chaque étape. De plus, il est probable que tous les nombreux compilateurs et outils C open source soient incorporés dans les données d'entraînement des grands modèles de langage (LLM) d'Antrhopic. Alors, le compilateur écrit par Claude est-il un réel exploit ?

Les développeurs n'en sont pas convaincus. Prétendre que les 16 agents Claude Opus 4.6 n'avaient pas accès à Internet est considéré comme trompeur par les critiques, car il faut tenir compte des données d'entraînement du modèle. Ils jugent que le coût de l'opération, environ 20 000 dollars, est « très peu efficace ». Les étudiants en informatique écrivent des compilateurs C tous les semestres dans leurs cours, avec des budgets beaucoup moins élevés.

À première vue, les gros titres semblent impressionnants. Le logiciel créé par les agents Claude peut compiler le noyau Linux 6.9 (couvrant les architectures x86, ARM et RISC-V) et exécuter le jeu classique Doom. Pour Anthropic, ce compilateur C est une démonstration du potentiel de Claude Code en matière d'ingénierie logicielle. Mais si l'on examine les détails et les tests effectués par la communauté, l'histoire est beaucoup moins impressionnante.

Comparaison du compilateur C d'Anthropic avec GCC et Clang

Les rapports des utilisateurs et les premiers benchmarks indiquent de sérieux goulots d'étranglement en matière de performances. Lorsque l'on compare les binaires produits par la solution de Claude à ceux de GCC, la différence est flagrante. Même avec ses « optimisations » internes activées, le compilateur généré par l'IA d'Anthropic produit un code qui s'exécute beaucoup plus lentement que GCC avec toutes les optimisations désactivées.

Dans le monde de la programmation système, il s'agit d'un défaut rédhibitoire. Plus précisément, un compilateur qui ne parvient pas à surpasser les performances de base non optimisées d'un outil vieux de trente ans n'offre aucune valeur pratique pour les environnements de production. Selon certains critiques, la qualité du code Rust généré par l'IA d'Anthropic est raisonnable, mais elle est encore loin d'égaler celle d'un programmeur Rust expert.

Le problème ne concerne pas seulement la vitesse, mais aussi l'exhaustivité de l'architecture. Le compilateur C généré par Claude ne dispose pas de son propre assembleur et éditeur de liens. Il effectue la traduction de haut niveau du C vers des représentations intermédiaires, mais confie finalement les tâches les plus lourdes (assemblage du code machine et liaison des bibliothèques) à l'installation GCC existante du système de l'utilisateur.

En outre, le compilateur C généré par Claude ne peut pas non plus gérer la compilation x86 16 bits. Cela signifie qu'il ne parvient pas à traiter le code de démarrage en mode réel requis pendant la séquence de démarrage de Linux, ce qui nécessite de recourir encore à GCC pour ces fichiers spécifiques.

Pourquoi l'IA générative peine à optimiser le backend

Les retours suggèrent que les modèles excellent pour les parties « faciles » de la conception des compilateurs, mais échouent dans la logique algorithmique complexe requise pour l'optimisation. Les compilateurs se composent de deux parties : le frontend (analyse du texte) et le backend (optimisation de la logique). L'IA excelle dans l'analyse, qui est une tâche linguistique. Claude Opus semble bien maîtriser la traduction de la syntaxe C en structures Rust.

Cependant, le backend implique des concepts mathématiques rigoureux : coloration de graphes pour l'allocation de registres, ordonnancement d'instructions, déplacement de code invariant de boucle et analyse du flux de contrôle. Il ne s'agit pas de modèles linguistiques, mais de casse-têtes logiques qui nécessitent un respect strict de la théorie des graphes et des contraintes matérielles. C'est à ce stade que Claude échoue lamentablement.

Le compilateur C d'Anthropic imite la structure de l'optimisation sans comprendre les mathématiques sous-jacentes. Il produit un code Rust qui ressemble à un compilateur, mais les algorithmes qu'il contient ne réduisent pas efficacement les cycles d'instructions et ne gèrent pas efficacement l'accès à la mémoire.

Cela prouve que si l'IA peut reproduire les éléments standard d'un système complexe, elle ne peut pas encore « raisonner » pour résoudre des problèmes d'ingénierie de haute performance. Les critiques craignent que les entreprises trop enthousiastes remplacent précipitamment les programmeurs humains par l'IA. Les conséquences sur le long terme pourraient être désastreuses, car l'IA n'est pas encore douée pour la logique et les mathématiques.

Le code généré par l'IA demeure difficile à maintenir

L'un des risques majeurs liés aux bases de code générées par l'IA est « l'impossibilité de les maintenir ». Lorsque les humains écrivent du code, ils construisent une carte mentale de la logique du système. Lorsqu'une IA génère 100 000 lignes de code, aucun être humain ne possède cette carte mentale. Ce qui représente un frein majeur à la maintenance du code. Pour corriger un bogue, il faut procéder à une ingénierie inverse de la logique de l'IA.

Si le « créateur » original (l'agent IA) n'est pas en ligne pour le corriger, le code devient « slop » : fonctionnel pendant un moment, mais devenu inutile dès que les exigences changent. Selon les critiques, les entreprises ayant remplacé leurs programmeurs par l'IA pourraient bientôt être confrontées à ce problème.

« Ma véritable inquiétude reste que les entreprises folles d'IA licencient les développeurs sans discernement et les remplacent par l'IA pour améliorer leurs résultats financiers. L'IA n'est tout simplement pas encore prête à prendre le relais des emplois de programmation, même si de nombreux PDG affirment qu'elle change déjà la donne. Non, c'est juste un outil utile qui nécessite une utilisation prudente et experte pour être efficace », rappelle un critique.

Analyse du coût de développement de 20 000 dollars

Dépenser 20 000 dollars pour reproduire un outil qui existe déjà gratuitement (GCC/Clang), et le reproduire de manière médiocre, soulève des questions. Pour le même montant, une entreprise pourrait embaucher un développeur junior pendant quelques mois. Ce développeur junior apprendrait, s'améliorerait et contribuerait à terme à la santé à long terme du code source. Les crédits consommés par l'IA lors de l'exécution sont un coût irrécupérable.

Le modèle n'apprend pas du projet d'une manière qui profite directement au projet suivant, et il ne reste pas pour corriger les bogues. Cependant, considéré comme de la recherche et du développement, le coût est justifiable. Selon certains analystes, l'expérience d'Anthropic prouve qu'il est possible de gérer la fenêtre contextuelle et la coordination de 16 agents parallèles. La valeur n'était pas le compilateur, mais les données du flux de travail.

Conclusion

Le compilateur généré par l'IA Claude d'Anthropic est une démo de laboratoire intéressante, mais rien de plus. Les développeurs ont mis en évidence des problèmes concrets. Il est incapable de compiler un simple « Hello World » sans que l'utilisateur spécifie manuellement les chemins vers les bibliothèques système. Il ne dispose pas de son propre assembleur ni de son éditeur de liens, et la démonstration a été réalisée en s'appuyant sur ceux de GCC.

Le code généré est moins efficace que GCC et certains projets ne compilent tout simplement pas. La vraie inquiétude est que des entreprises, aveuglées par le battage médiatique, licencient des développeurs pour les remplacer par une IA inefficace. L'IA reste un outil utile, mais elle exige une expertise humaine pour être efficace. Dans le cas contraire, ses lacunes pourraient augmenter la charge de travail plutôt que de la réduire.

Sources : Anthropic, rapports de la communauté (1, 2)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du compilateur C généré par l'IA Claude d'Anthropic ?
Selon vous, s'agit-il d'une prouesse de l'IA ou d'un simple effet de communication ?
Que pensez-vous des nombreuses lacunes du compilateur C généré par l'IA Claude d'Anthropic ?
Pensez-vous que l'IA générative sera en mesure de créer un meilleur compilateur C à l'avenir ? Pourquoi ?
La logique et les mathématiques restent le talon d'Achille de l'IA générative. Qu'en pensez-vous ?

Voir aussi

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

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

[Ryu2000]

Le compilateur généré par l'IA Claude d'Anthropic est une démo de laboratoire intéressante, mais rien de plus.

C'est déjà pas mal

Pensez-vous que l'IA générative sera en mesure de créer un meilleur compilateur C à l'avenir ? Pourquoi ?

Meilleur que celui ci, oui.
Meilleur que GCC, non.

[kmedghaith]

Ce qui n'est pas assez souligné c'est que ce n'est pas vraiment "from scratch" et que les vibe codeurs ont utilisé les datasets de gcc qui contient tous les corners cases possibles (construits sur 37 ans ...) et qu'ils utilisent gcc comme référence.
Du coup c'est un peu plus facile.
Essayer de développer vraiment un nouveau produit est plus ambitieux.

[kain_tn]

Ce qui n'est pas assez souligné c'est que ce n'est pas vraiment "from scratch" et que les vibe codeurs ont utilisé les datasets de gcc qui contient tous les corners cases possibles (construits sur 37 ans ...) et qu'ils utilisent gcc comme référence.
Du coup c'est un peu plus facile.
Essayer de développer vraiment un nouveau produit est plus ambitieux.

C'est exactement ça.

Et même avec ça, le truc n'est pas foutu de fonctionner correctement.

[floyer]

Ce qui aurait été intéressant aurait été de faire quelque chose de franchement nouveau et utile. On peut imaginer des éléments de preuve formelle pour des sous ensemble de Linux (c'est un coup à trouver des bugs car pour prouver la conformité, il faut au préalable corriger des bugs). Et le faire humainement coute très cher : on ne le fait que pour des développements critiques (automatisation de la ligne de métro Meteor par exemple). Ou inversement, porter des logiciels sur le noyau SeL4 qui offre un niveau de sécurité prouvé formellement.

Dans les deux approches, impossible de considérer que l'IA a beaucoup pompé ailleurs.

[Ryu2000]

Ce qui aurait été intéressant aurait été de faire quelque chose de franchement nouveau et utile.

Il faut apprendre à marcher avant de courir.
Il faut y aller mollo sur les objectifs qu'on donne à l'IA, ça ne sert à rien d'être trop ambitieux trop tôt.
Il y a un paquet d'étapes à passer avant que l'IA produise quelque chose de bien.

[fodger75]

"Mettez-vous à la place de Claude", carton rouge.

C'est un programme, pas un être humain.