L’extension du codage autonome sur de longues durées

• Cursor a expérimenté la possibilité d’exécuter en parallèle pendant plusieurs semaines des agents de codage autonomes afin d’achever des projets de grande ampleur
• Au départ, l’équipe a utilisé une structure de collaboration dynamique, mais des conflits de verrous (lock) et des doublons de travail ont créé des goulots d’étranglement
• Elle a ensuite séparé les rôles entre planificateurs (Planner) et exécutants (Worker), améliorant fortement le parallélisme et l’efficacité
• Avec cette structure, elle a implémenté un navigateur web à partir de zéro, des centaines d’agents écrivant plus d’un million de lignes de code
• Les résultats montrent qu’une structure simple et une conception appropriée des prompts sont la clé du passage à l’échelle du codage autonome de long terme

---

Les limites d’un agent unique

• Les agents de codage uniques actuels sont efficaces pour les tâches simples, mais lents sur les projets complexes
  • Exécuter plusieurs agents en parallèle est une voie naturelle de passage à l’échelle, mais la coordination des tâches est difficile
• Au début, une méthode de collaboration dynamique a été testée sans plan préalable
  • Une structure dans laquelle chaque agent observe l’état des autres agents et décide lui-même de la tâche suivante

Le processus d’apprentissage de la collaboration

• Une structure a été introduite dans laquelle tous les agents disposent de droits égaux et coordonnent le travail via des fichiers partagés
  • Chaque agent vérifie l’état des autres, se voit attribuer une tâche, puis met à jour son état
  • Un mécanisme de verrouillage (lock) a été utilisé pour éviter les doublons
• Problèmes rencontrés
  1. Certains agents gardaient les verrous trop longtemps ou ne les libéraient pas, ce qui ramenait la vitesse globale à l’équivalent de 2 ou 3 agents sur 20
  2. Des instabilités système apparaissaient lorsqu’un agent échouait en conservant un verrou, ou modifiait des fichiers sans verrou
• Passage au contrôle de concurrence optimiste (optimistic concurrency control)
  • La lecture était libre, tandis que l’écriture échouait en cas de changement d’état
  • La méthode était simple et stable, mais dans une structure sans hiérarchie, les agents adoptaient un comportement d’évitement du risque
  • Ils évitaient les problèmes difficiles et répétaient de petites corrections, créant un cycle de travail sans progrès

L’architecture planificateurs–exécutants

• Passage à un pipeline hiérarchique avec séparation des rôles
  • Planificateurs (Planners) : explorent la base de code, créent des tâches et peuvent engendrer des planificateurs subordonnés si nécessaire
  • Exécutants (Workers) : réalisent uniquement la tâche assignée puis poussent leurs modifications une fois terminées
• À chaque cycle, un agent juge (judge) décide s’il faut passer à l’étape suivante
  • Cette structure a résolu la plupart des problèmes de collaboration, assurant la scalabilité des projets de grande taille

Expériences d’exécution longue durée

• Objectif de l’expérience : implémenter un navigateur web à partir de zéro
  • Environ une semaine d’exécution, avec plus d’un million de lignes de code écrites dans 1 000 fichiers
  • Des centaines d’exécutants ont poussé simultanément sur la même branche, avec un minimum de conflits
  • Le code obtenu a été publié sur GitHub
• Expériences supplémentaires
  • Migration Solid → React : sur 3 semaines, +266K/-193K de modifications, confirmant la possibilité de fusion
  • Amélioration du rendu vidéo : la version Rust a apporté un gain de vitesse de 25x et ajouté les fonctions zoom, pan et motion blur
  • Ce code doit bientôt être déployé en production

Principaux enseignements

• Après avoir mobilisé des dizaines de milliards de tokens, les résultats montrent des performances supérieures aux attentes, même si le système n’est pas parfaitement efficace
• Le choix du modèle est essentiel pour le travail autonome de longue durée
  • GPT-5.2 excelle dans le maintien de l’attention, le respect des consignes et l’implémentation précise
  • Opus 4.5 a tendance à s’arrêter rapidement
  • GPT-5.2 est mieux adapté au rôle de planificateur que GPT-5.1-codex
  • Le modèle optimal est choisi selon chaque rôle
• La réduction de la complexité a contribué à améliorer les performances
  • Le rôle d’intégrateur qualité (integrator) créait au contraire un goulot d’étranglement
  • Les exécutants pouvaient résoudre eux-mêmes les conflits
• Une structure simple s’est révélée la plus efficace
  • Les théories des systèmes distribués ou les modèles de conception organisationnelle ne se sont avérés utiles qu’en partie
  • Trop peu de structure entraîne conflits et doublons, trop de structure augmente la fragilité
• La conception des prompts a une influence décisive sur le comportement du système
  • Elle joue un rôle clé pour maintenir l’attention sur la durée, prévenir les comportements pathologiques et favoriser la collaboration

Défis à venir

• La coordination multi-agents reste un problème difficile
  • Il faut améliorer le système pour que le planificateur planifie automatiquement l’étape suivante lorsqu’une tâche est terminée
  • Certains agents s’exécutent beaucoup trop longtemps et nécessitent des redémarrages périodiques
• Cependant, à la question centrale — « augmenter le nombre d’agents permet-il de faire passer à l’échelle le codage autonome ? »
  • Il a été confirmé que des centaines d’agents peuvent collaborer pendant plusieurs semaines et produire de véritables avancées
• Cette technologie devrait être intégrée à l’avenir dans les fonctions d’agent de Cursor

[GN⁺]

Réactions sur Hacker News

• J’ai trouvé ça intéressant, car je travaille sur un sujet lié au billet de Steve Yegge, Welcome to Gas Town

• Dans mes prédictions sur les LLM partagées récemment, je disais qu’autour de 2029, créer un navigateur avec du code assisté par IA ne sera plus surprenant. Le projet actuel de Cursor en est une deuxième tentative
  On peut voir un autre exemple dans ce post Reddit

  • Si c’est une implémentation intelligente, elle ne va-t-elle pas simplement reprendre le code source de Chromium sur GitHub, retirer les fonctionnalités inutiles et ne changer que l’apparence ?
  • Vers 2029, on devrait déjà relever le niveau d’exigence, au point de plaisanter sur le fait que l’IA fabrique un navigateur pour pélicans
  • J’ai regardé le code de l’exemple Reddit pendant environ cinq minutes, et la gestion de la mise en page du texte et du bidi (texte bidirectionnel) était catastrophique. Un « navigateur » qui ne tient pas compte des standards mérite difficilement ce nom
  • C’est impressionnant, mais je me demande si du code de navigateurs open source ne faisait pas déjà partie des données d’entraînement du modèle
  • Je me demande aussi pourquoi, après avoir dit que sa prédiction était fausse, il est revenu dans le même podcast une semaine plus tard pour en faire une nouvelle

• J’ai exécuté moi-même les tests du dépôt : il y avait des erreurs et des avertissements partout, et la CI échoue depuis longtemps. Je ne suis pas sûr qu’on puisse appeler ça un « exemple réussi ». Une approche centrée sur l’assistance à l’humain me paraît plus réaliste que du codage entièrement autonome

  • La base de code était éclatée en des centaines ou des milliers de petits fichiers, ce qui rendait la structure presque impossible à comprendre. Le README était bâclé et il n’y avait aucune explication sur les dépendances. C’est du code généré par IA, mais sa maintenance relèverait du cauchemar
  • L’auteur semble lui aussi voir le codage entièrement autonome moins comme un vrai produit que comme une expérience sur les limites des LLM. Pour l’instant, on n’en est qu’au stade où ils peuvent produire « seuls du code correct » seulement sur de petits projets
  • Le fait d’avoir fusionné un PR dont la CI échouait donne presque envie de plaisanter en disant que le système a atteint une qualité de niveau humain
  • Le terme « lent » reste flou. Lent en quoi ? Vitesse GPU ? Plus lent qu’un humain ? Au final, ça m’a surtout donné l’impression d’un article qui gonfle la bulle de l’IA

• Je me demande pourquoi ce PR n’a toujours pas été fusionné. L’idée d’un futur où des essaims d’agents IA finalisent à long terme des logiciels complexes est fascinante, mais l’exemple actuel est trop faible. Le point de collaboration avec l’humain est plus important

  • D’après mon expérience, les agents ne convergent pas : ils produisent au contraire des monstres de code de plus en plus chaotiques
  • Le fait de ne même pas publier un petit projet simple qui fonctionne ressemble à un appât destiné aux investisseurs. Le boom de l’IA rappelle la bulle internet, sauf que cette fois-ci l’aspect monétisation paraît encore plus central
  • Des exemples comme un navigateur, Excel ou Windows 7 ont sans doute été partiellement présents dans les données d’entraînement, mais cela ne suffit pas pour une reproduction complète
  • Le code est tellement volumineux et bourré de problèmes qu’il est impossible à relire. Au final, il ne reste qu’un merge façon YOLO
  • Ce qui m’intéresse, ce sont les conditions de convergence. Que le code grossisse ou rétrécisse, l’essentiel est qu’il se stabilise dans un état optimal

• C’est dommage de ne pas avoir expérimenté en augmentant progressivement la difficulté. En passant de React CRUD → clone de Paint → gestionnaire de fichiers → navigateur, on aurait pu voir beaucoup plus clairement les étapes de progression

• J’ai moi aussi créé tjs avec une approche similaire. C’est le validateur JSON Schema le plus rapide et le plus précis au monde, et le pattern planner/delegate basé sur git subtree s’est révélé efficace. Quand les standards et les tests sont bien définis, des agents IA peuvent réécrire et optimiser rapidement un logiciel
  Les commandes associées sont visibles dans spawn-perf-agents.md

• Construire un navigateur from scratch est extrêmement difficile, mais ce que présente le billet manquait d’analyse détaillée. Si l’on en reste simplement à « ça compile », l’intérêt est limité. Le vrai test, c’est de savoir si la modification suivante peut être fusionnée de manière stable

  • Le niveau minimum pour le codage par agent suit la séquence « compilation réussie » → « exécution normale » → « gestion des cas limites ». Il faut qu’un système tourne de manière stable pendant plus d’un an avec moins de bugs qu’un humain pour qu’on puisse lui faire confiance
  • En pratique, la CI échoue déjà, donc même l’affirmation « ça compile » est douteuse

• D’après le blog, des billions de tokens ont été utilisés. Au tarif de l’API OpenAI, cela représenterait des dizaines de millions de dollars. À ce niveau-là, il aurait peut-être mieux valu faire un don à une équipe qui développe un navigateur

• J’ai essayé de le compiler moi-même, et j’ai obtenu plus de 100 erreurs de compilation. La plupart des commits avaient une CI en échec et, en réalité, il s’agissait d’un assemblage de plusieurs bibliothèques open source.
  quickjs, wgpu, winit, egui, html parser et d’autres composants existants ont été repris tels quels, mais le CEO parle d’une « custom JS VM », ce qui induit en erreur
  Cela dit, le fait qu’une IA ait réussi à intégrer tout cela de manière autonome reste impressionnant

  • Les composants utilisés ressemblent beaucoup à blitz, un navigateur en Rust, donc il est possible qu’ils aient été présents dans les données d’entraînement
  • Il y a aussi eu une blague très startup du genre : « Peu importe si ça fonctionne, prenez une capture d’écran et montrez-la aux investisseurs »
  • Une statistique mentionne qu’un peu plus d’un millier de workflows seulement ont réussi sur environ 60 000. Cela ressemble, au fond, à un amas de code non validé
  • La conclusion se faisait sur l’humour : « Créons tous notre propre Cursor custom »

• Le code semblait très fragile et instable. Par exemple, la fonction render_placeholder ressemble à un simple code temporaire qui remplit le frame buffer.
  Je me demande quel rôle joue réellement ce code, et quel est le coût en tokens/temps pour chaque test

  • La façon d’extraire les attributs des balises, comme dans cette partie, paraissait aussi assez étrange
  • Mais si Cursor peut corriger cela automatiquement, alors ce genre de fragilité peut aussi devenir à long terme une stratégie pour renforcer la dépendance