Nous expérimentons l’exécution autonome d’agents de codage pendant plusieurs semaines.

Notre objectif est de comprendre jusqu’où nous pouvons repousser les limites du codage agentique pour des projets qui demandent généralement des mois de travail à des équipes humaines.

Cet article décrit ce que nous avons appris en exécutant des centaines d’agents simultanément sur un même projet, en coordonnant leur travail et en les regardant écrire plus d’un million de lignes de code et des milliers de milliards de tokens.

#Les limites d’un seul agent

Les agents actuels sont efficaces pour des tâches ciblées, mais ils sont lents sur des projets complexes. L’étape naturelle suivante consiste à exécuter plusieurs agents en parallèle, mais il est difficile de déterminer comment les coordonner.

Nous avons d’abord pensé qu’une planification en amont serait trop rigide. Le cheminement dans un projet de grande ampleur est ambigu, et la bonne répartition du travail n’est pas évidente dès le départ. Nous avons donc commencé par une coordination dynamique, où les agents décident quoi faire en fonction de ce que font les autres à un moment donné.

#Apprendre à se coordonner

Notre approche initiale plaçait tous les agents sur un pied d’égalité et les laissait se coordonner eux-mêmes via un fichier partagé. Chaque agent vérifiait ce que faisaient les autres, s’attribuait une tâche et mettait à jour son statut. Pour éviter que deux agents ne prennent la même tâche, nous utilisions un mécanisme de verrouillage.

Cette approche a échoué de manière intéressante :

1. Les agents conservaient les verrous trop longtemps, ou oubliaient complètement de les libérer. Même lorsque le verrouillage fonctionnait correctement, il devenait un goulot d’étranglement. Vingt agents finissaient avec le débit effectif de deux ou trois seulement, la majeure partie du temps étant passée à attendre.

2. Le système était fragile : les agents pouvaient tomber en panne tout en détenant des verrous, tenter d’acquérir des verrous qu’ils détenaient déjà, ou mettre à jour le fichier de coordination sans même acquérir le verrou.

Nous avons essayé de remplacer les verrous par un contrôle optimiste de la concurrence. Les agents pouvaient lire l’état librement, mais les écritures échouaient si l’état avait changé depuis leur dernière lecture. C’était plus simple et plus robuste, mais des problèmes plus profonds subsistaient.

Sans hiérarchie, les agents devenaient réticents à prendre des risques. Ils évitaient les tâches difficiles et se contentaient de petites modifications sans risque. Aucun agent ne prenait en charge les problèmes complexes ni l’implémentation de bout en bout. Résultat : le travail pouvait tourner en rond pendant de longues périodes, sans réel progrès.

#Planificateurs et exécutants

Notre approche suivante a consisté à séparer les rôles. Au lieu d’une structure plate où chaque agent fait tout, nous avons créé un pipeline avec des responsabilités distinctes.

• Planificateurs explorent en continu la base de code et créent des tâches. Ils peuvent lancer des sous-planificateurs pour des zones spécifiques, ce qui rend la planification elle-même parallèle et récursive.

• Exécutants prennent les tâches en charge et se concentrent entièrement sur leur exécution. Ils ne se coordonnent pas avec les autres exécutants et ne se préoccupent pas de la vue d’ensemble. Ils se contentent d’avancer sur la tâche qui leur est assignée jusqu’à ce qu’elle soit terminée, puis pushent leurs modifications.

À la fin de chaque cycle, un agent arbitre déterminait s’il fallait continuer, puis l’itération suivante repartait de zéro. Cela a résolu la plupart de nos problèmes de coordination et nous a permis de passer à l’échelle sur des projets très vastes sans qu’aucun agent ne développe une vision en tunnel.

#Pendant des semaines

Pour tester ce système, nous lui avons donné un objectif ambitieux : créer un navigateur web à partir de zéro. Les agents ont tourné pendant près d’une semaine, en écrivant plus d’un million de lignes de code dans 1 000 fichiers. Vous pouvez découvrir le code source sur GitHub.

Malgré la taille de la base de code, de nouveaux agents peuvent toujours la comprendre et accomplir des progrès significatifs. Des centaines de workers s’exécutent en parallèle et poussent vers la même branche avec un minimum de conflits.

Même si cela peut ressembler à une simple capture d’écran, créer un navigateur à partir de zéro est extrêmement difficile.

Une autre expérience consistait à effectuer une migration de Solid vers React directement dans la base de code de Cursor. Cela a pris plus de trois semaines, avec +266K/-193K modifications. Le résultat nécessite encore une relecture attentive, mais passait notre CI et les premières vérifications.

Une autre expérience consistait à améliorer un produit à venir. Un agent de longue durée a accéléré le rendu vidéo d’un facteur 25 grâce à une version Rust efficace. Il a également ajouté la prise en charge du zoom et du panoramique fluides, avec des transitions naturelles à effet de ressort et des flous de mouvement qui suivent le curseur. Ce code a été intégré et sera bientôt mis en production.

Nous avons quelques autres exemples intéressants toujours en cours d’exécution :

• Java LSP : 7.4K commits, 550K LoC
• émulateur Windows 7 : 14.6K commits, 1.2M LoC
• Excel : 12K commits, 1.6M LoC

#Ce que nous avons appris

Nous avons déployé des milliers de milliards de tokens sur ces agents au service d’un objectif unique. Le système n’est pas parfaitement efficient, mais il est bien plus efficace que nous l’avions anticipé.

Le choix du modèle est déterminant pour les tâches de très longue durée. Nous avons constaté que les modèles GPT-5.2 sont bien meilleurs pour le travail autonome prolongé : suivre les instructions, rester concentrés, éviter les dérives, et implémenter les choses avec précision et exhaustivité.

Opus 4.5 a tendance à s’arrêter plus tôt et à prendre des raccourcis quand c’est possible, en redonnant rapidement la main. Nous avons également constaté que différents modèles excellent dans différents rôles. GPT-5.2 planifie mieux que GPT-5.1-Codex, même si ce dernier est entraîné spécifiquement pour le codage. Nous utilisons désormais le modèle le mieux adapté à chaque rôle plutôt qu’un modèle universel.

Une grande partie de nos améliorations est venue de la suppression de complexité plutôt que de son ajout. Au départ, nous avions créé un rôle d’intégrateur pour le contrôle qualité et la résolution des conflits, mais nous avons constaté qu’il créait plus de goulots d’étranglement qu’il n’en éliminait. Les workers étaient déjà capables de gérer eux-mêmes les conflits.

Le meilleur système est souvent plus simple qu’on ne l’imagine. Au départ, nous avons essayé de modéliser des systèmes issus de l’informatique distribuée et de la conception organisationnelle. Cependant, ils ne fonctionnent pas tous pour les agents.

Le bon niveau de structure se situe quelque part entre les deux. Trop peu de structure, et les agents entrent en conflit, dupliquent le travail et dérivent. Trop de structure crée de la fragilité.

Une part surprenante du comportement du système tient à la manière dont nous rédigeons les prompts des agents. Obtenir une bonne coordination entre eux, leur faire éviter des comportements pathologiques et leur permettre de rester concentrés sur de longues périodes a nécessité de nombreuses expérimentations. Le harness et les modèles comptent, mais les prompts comptent davantage.

#Et ensuite

La coordination multi-agent reste un problème difficile. Notre système actuel fonctionne, mais nous sommes encore loin d’être au point. Les planificateurs devraient se réactiver une fois leurs tâches terminées pour planifier l’étape suivante. Les agents s’exécutent parfois bien trop longtemps. Nous avons encore besoin de redémarrages périodiques pour lutter contre la dérive et la vision en tunnel.

Mais la question fondamentale — peut-on faire passer à l’échelle le codage autonome en mobilisant davantage d’agents sur un même problème ? — a une réponse plus optimiste que nous ne l’imaginions. Des centaines d’agents peuvent travailler ensemble sur une seule base de code pendant des semaines et faire réellement avancer des projets ambitieux.

Les techniques que nous développons ici viendront à terme enrichir les capacités de l’agent de Cursor. Si vous souhaitez travailler sur les problèmes les plus difficiles du développement logiciel assisté par IA, nous serions ravis d’avoir de vos nouvelles à hiring@cursor.com.