Nous avons mené des expériences en faisant tourner des agents de codage de façon autonome pendant plusieurs semaines.

Notre objectif est de comprendre jusqu’où nous pouvons repousser la frontière de la programmation basée sur des agents pour des projets qui prennent généralement des mois à des équipes humaines.

Cet article décrit ce que nous avons appris en faisant tourner des centaines d’agents en parallèle 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 fonctionnent bien pour des tâches ciblées, mais sont lents pour des projets complexes. La prochaine étape naturelle consiste à exécuter plusieurs agents en parallèle, mais déterminer comment les coordonner est difficile.

Notre première intuition était qu'une planification en amont serait trop rigide. Le chemin à suivre dans un projet de grande envergure est ambigu, et la bonne répartition du travail n'est pas évidente au départ. Nous avons commencé par une coordination dynamique, dans laquelle les agents décident quoi faire en fonction de ce que les autres sont en train de faire.

#Apprendre à se coordonner

Notre approche initiale donnait un statut égal aux agents 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 s’emparent de la même tâche, nous utilisions un mécanisme de verrouillage.

Cela a échoué de façons intéressantes :

1. Les agents gardaient les verrous trop longtemps ou oubliaient de les libérer complètement. Même lorsque le verrouillage fonctionnait correctement, il devenait un goulot d’étranglement. Vingt agents se retrouvaient ralentis jusqu’au débit effectif de deux ou trois, la plupart du temps étant passé à attendre.

2. Le système était fragile : les agents pouvaient se bloquer tout en maintenant des verrous, essayer d’acquérir des verrous qu’ils détenaient déjà, ou mettre à jour le fichier de coordination sans acquérir de verrou du tout.

Nous avons essayé de remplacer les verrous par un contrôle de concurrence optimiste. 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 il restait des problèmes plus profonds.

Sans hiérarchie, les agents sont devenus très réticents à prendre des risques. Ils évitaient les tâches difficiles et effectuaient à la place de petits changements sûrs. Aucun agent ne prenait la responsabilité des problèmes difficiles ou des implémentations de bout en bout. Cela a entraîné des phases de travail qui tournaient en rond pendant de longues périodes, sans réel progrès.

#Planificateurs et exécutants

Notre approche suivante a été de 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.

• Les 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.

• Les exécutants prennent en charge des tâches 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 s'acharnent simplement sur la tâche qui leur est assignée jusqu'à ce qu'elle soit terminée, puis poussent leurs changements.

À la fin de chaque cycle, un agent chargé de juger 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 de très grands projets sans qu'aucun agent ne développe une vision tunnel.

#Fonctionnement 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 fonctionné pendant près d’une semaine, écrivant plus de 1 million de lignes de code réparties sur 1 000 fichiers. Vous pouvez explorer le code source sur GitHub.

Malgré la taille de la base de code, de nouveaux agents peuvent encore la comprendre et faire des progrès significatifs. Des centaines de workers s’exécutent en parallèle, poussant leurs changements sur la même branche avec un minimum de conflits.

Même si cela peut sembler n’être qu’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 in-place de Solid vers React dans la base de code de Cursor. Cela a pris plus de trois semaines avec +266K/-193K modifications. Cela nécessite toujours une revue attentive, mais réussissait notre CI et les premiers contrôles.

Une autre expérience visait à améliorer un produit à venir. Un agent exécuté sur la durée a rendu le traitement vidéo 25 fois plus rapide grâce à une version Rust efficace. Il a également ajouté la prise en charge d’un zoom et d’un panoramique fluides avec des transitions à ressort naturelles et des flous de mouvement, en suivant le curseur. Ce code a été fusionné et sera bientôt en production.

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

• Java LSP : 7,4K commits, 550K LoC
• Windows 7 emulator : 14,6K commits, 1,2M LoC
• Excel : 12K commits, 1,6M LoC

#Ce que nous avons appris

Nous avons exécuté des milliers de milliards de tokens avec ces agents pour atteindre un seul objectif. Le système n’est pas parfaitement efficace, mais il est bien plus performant que ce que nous attendions.

Le choix du modèle est crucial pour les tâches extrêmement longues. Nous avons constaté que les modèles GPT-5.2 sont bien meilleurs pour un travail autonome prolongé : suivre les instructions, rester concentrés, éviter la dérive et mettre en œuvre les demandes avec précision et de manière complète.

Opus 4.5 a tendance à s’arrêter plus tôt et à prendre des raccourcis lorsque c’est pratique, en rendant rapidement le contrôle. Nous avons aussi constaté que différents modèles excellent dans différents rôles. GPT-5.2 est un meilleur planificateur que GPT-5.1-Codex, même si ce dernier est spécifiquement entraîné pour le code. Nous utilisons désormais le modèle le plus adapté à chaque rôle plutôt qu’un modèle universel.

Beaucoup de nos améliorations sont venues de la réduction de la complexité plutôt que de son ajout. Nous avions initialement créé un rôle d’intégrateur pour le contrôle qualité et la résolution de conflits, mais nous avons constaté qu’il créait plus de goulots d’étranglement qu’il n’en résolvait. Les agents étaient déjà capables de gérer les conflits eux-mêmes.

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

Le bon niveau de structure se situe quelque part au milieu. 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 étonnamment importante du comportement du système dépend de la façon dont nous formulons les prompts pour les agents. Obtenir une bonne coordination, éviter les comportements pathologiques et maintenir la concentration sur de longues périodes a nécessité de vastes expérimentations. Le harness et les modèles comptent, mais les prompts comptent encore plus.

#Et ensuite

La coordination multi-agents reste un problème difficile. Notre système actuel fonctionne, mais nous sommes encore loin d'être optimaux. Les planificateurs devraient se réactiver dès que leurs tâches se terminent pour planifier la prochaine étape. Les agents s'exécutent parfois beaucoup 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 centrale — peut-on faire passer le codage autonome à l'échelle en ajoutant davantage d'agents à un problème — la réponse est plus optimiste que nous ne l'attendions. Des centaines d'agents peuvent collaborer sur une même base de code pendant des semaines et faire de réels progrès sur des projets ambitieux.

Les techniques que nous développons ici façonneront à terme les capacités d'agents de Cursor. Si vous êtes intéressé par le travail sur les problèmes les plus difficiles du développement logiciel assisté par l'IA, nous serions ravis d'avoir de vos nouvelles à hiring@cursor.com.