00:00:00Anthropic vient de réaliser un exploit : ils ont lâché 16 agents Claude dans la nature pour concevoir
00:00:05un compilateur C. Après deux semaines de travail non-stop, ils en ont produit un capable de compiler
00:00:11le noyau Linux et même de faire tourner Doom. C'est impressionnant, et c'était impossible
00:00:16avec les anciennes versions d'Opus 4. Pourtant, certains crient au « putaclic » et à
00:00:22la demi-vérité, à cause des techniques douteuses qu'Anthropic a utilisées pour y arriver.
00:00:28Alors, Anthropic a-t-il triché ? Abonnez-vous et découvrons-le ensemble.
00:00:31Cette vidéo se divise en trois parties. D'abord, nous verrons comment l'expérience a été mise en place,
00:00:37puis nous analyserons les conclusions clés (indispensables pour tout développeur),
00:00:42et enfin, nous verrons si les résultats sont valables, car j'ai un avis bien tranché
00:00:47sur la méthode employée. L'expérience a été menée par Nicholas Carlini, un esprit
00:00:52brillant selon moi. Regardons de plus près la configuration qu'il a imaginée.
00:00:58Le projet se trouvait dans un répertoire nommé « Upstream », qui était monté
00:01:03sur 16 conteneurs Docker différents. On n'en voit que quatre ici, mais imaginez qu'il y en a 16.
00:01:08Chaque conteneur faisait tourner Claude Code avec Opus 4.6, clonait
00:01:15le dépôt Upstream dans un espace de travail, y effectuait ses modifications, puis
00:01:21les poussait vers Upstream. C'était malin car chaque agent travaillait isolément sans
00:01:27gêner les autres. En cas de conflit de fusion, Claude était assez
00:01:32intelligent pour le résoudre avant de renvoyer le code. Chaque agent piochait des tâches.
00:01:38J'ignore si elles étaient créées par un humain ou par l'IA suite à des tests,
00:01:44mais ces tâches avaient des noms précis et chaque agent s'en voyait attribuer une,
00:01:50ce qui ouvrait une nouvelle session. Pour faire tourner ces agents sur la durée, une boucle Ralph
00:01:56était utilisée : l'agent travaillait, finissait, poussait son code, puis
00:02:02reprenait une nouvelle tâche avec une session toute neuve, indéfiniment.
00:02:08Si vous avez vu notre vidéo sur Ralph, vous savez que le secret des agents longue durée,
00:02:13ce sont des tâches bien définies. Mais avec 16 agents en simultané,
00:02:19comment éviter qu'ils choisissent la même ? Grâce au verrouillage de tâche.
00:02:24L'auteur ne détaille pas tout, mais il existe une liste de tâches : un agent en choisit une,
00:02:30crée un fichier texte au nom de la tâche et fait un commit pour la verrouiller à son nom
00:02:36avant de pousser le tout. Si un autre agent tente de prendre la même tâche
00:02:42et crée le même fichier, Git rejettera son push en signalant que
00:02:48le fichier existe déjà. Il doit alors changer de tâche. C'est ainsi que Carlini
00:02:53a testé l'endurance des agents sous Opus 4.6, et les résultats sont bluffants.
00:03:00Mais cette expérience a révélé des points cruciaux pour n'importe quel
00:03:07développeur. D'abord, l'importance de créer un harnais de test (ou un script) qui
00:03:12lance différents types de tests. Car quand Nick (on est intimes maintenant)
00:03:17menait l'expérience, Claude cassait souvent des fonctions existantes en en créant de nouvelles.
00:03:23Il a donc bâti un harnais avec des tests de haute qualité issus de projets comme
00:03:29SQLite, libjpg et Redis. Pour éviter de polluer le contexte, ce harnais
00:03:35ne transmettait à l'agent que les logs utiles (les erreurs principalement), tout en
00:03:41stockant le reste dans un fichier consultable au besoin. Mais avec des milliers
00:03:47de tests, les agents passeraient des heures à tout valider au lieu de produire du code.
00:03:52Nick a donc eu une idée brillante : il a ajouté une option « rapide » à son harnais.
00:03:58Chaque agent ne lançait que 1 % ou 10 % des tests au hasard. Si chaque
00:04:05agent en lançait 10 %, on couvrait 160 % des tests au total, ce qui est excellent.
00:04:13Et voici l'astuce : pour que cela fonctionne,
00:04:19le choix des tests était aléatoire mais basé sur une graine (seed) identique,
00:04:25ce qui rendait le processus déterministe. Les agents parcouraient ainsi toute
00:04:31la suite de tests bien plus vite qu'en travaillant seuls.
00:04:36Le point suivant est tout aussi malin, mais plus controversé : s'appuyer sur l'existant.
00:04:41Jusque-là, chaque agent gérait des tests unitaires de projets open source,
00:04:46ce qui marchait bien par petits blocs. Mais pour compiler le
00:04:53noyau Linux, ce n'est plus une question de tests isolés. C'est devenu
00:04:58difficile : chaque agent essayait de tout compiler, tombait sur la même erreur,
00:05:04tentait de la corriger et écrasait le travail des autres. Nick a donc décidé
00:05:09de confier un pourcentage de la compilation à chaque agent et de laisser GCC,
00:05:15le compilateur GNU, faire le reste. Il a appelé GCC « l'oracle », car le noyau Linux
00:05:22doit compiler parfaitement avec lui. Si un agent compilait sa propre section
00:05:27du noyau et que le reste était géré par GCC, toute erreur venait forcément de
00:05:34l'agent. Il n'avait alors qu'à corriger son propre code sans interférer avec les autres.
00:05:40C'est controversé car on utilise un compilateur existant pour aider Claude
00:05:46à en créer un de toutes pièces. On en reparlera à la fin.
00:05:51Passons au point suivant : donner une mémoire à vos agents.
00:05:57Comme les nouvelles sessions de Claude démarrent sans aucun souvenir du travail passé,
00:06:03Nick mettait à jour le fichier Readme et créait des fichiers de suivi
00:06:09indiquant où l'on en était. Ainsi, les nouvelles sessions avaient une base solide
00:06:13et ne réintroduisaient pas de bugs déjà corrigés. Enfin, point plus
00:06:18évident : attribuer des rôles différents aux agents. L'avantage du travail
00:06:23parallèle, c'est que plusieurs tâches peuvent être menées sur le même code en simultané.
00:06:29Quand il n'y avait pas de nouveau code à écrire, Nick donnait des rôles uniques :
00:06:35l'un traquait le code dupliqué, l'autre optimisait les performances,
00:06:40et un autre critiquait le design du point de vue d'un développeur Rust (en espérant
00:06:45qu'il ne s'en soit pas vanté auprès des autres). Mais malgré le succès du projet,
00:06:51la question demeure : Anthropic a-t-il triché pour obtenir ce résultat ?
00:06:57Eh bien, un peu. La mission était de créer un compilateur C de zéro sans
00:07:03accès à Internet. L'agent a donc généré tout le code lui-même. Vraiment ?
00:07:10Il avait accès aux suites de tests et à la version compilée de GCC.
00:07:16Il a donc pu « sonder » GCC en observant ses sorties pour orienter
00:07:24la conception de son propre compilateur en Rust. Pour être honnête, si je devais
00:07:31créer un compilateur C, je ferais pareil : j'analyserais l'existant pour
00:07:36m'en inspirer. S'il s'était agi d'inventer un compilateur pour
00:07:41un tout nouveau langage, ce serait une autre paire de manches. Ce serait d'ailleurs
00:07:47un excellent test pour voir si Claude est capable de créer ex nihilo.
00:07:53C'est une idée pour Nick. Parlons maintenant de l'aspect autonome de l'expérience.
00:07:57Certes, Claude a écrit tout le code, mais il a été très encadré par l'humain.
00:08:04C'est un humain qui a choisi les tests, lancé la boucle Ralph,
00:08:11conçu le harnais de test et attribué les rôles. On est donc loin
00:08:16d'une IA à qui l'on dirait simplement « fais-moi un compilateur » avant de la laisser tourner.
00:08:22On ne peut pas parler d'autonomie à 100 %, car qu'aurait
00:08:28produit l'agent sans cette supervision humaine constante ?
00:08:33Même avec cet encadrement, le compilateur Claude a ses limites.
00:08:39Par exemple, il utilise l'assembleur et l'éditeur de liens de GCC, les siens étant
00:08:46trop buggés. Il a aussi eu besoin du compilateur x86 16 bits de GCC pour booter Linux.
00:08:54Enfin, le code n'est pas très efficace : sa version la plus optimisée est
00:09:00moins performante que la version la moins optimisée de GCC. Bref, les développeurs
00:09:05ont encore de beaux jours devant eux... pour l'instant.