- 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
- 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
- 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
Aucun commentaire pour le moment.