Comment nous avons configuré notre environnement d’agents Cloud
Lorsque nous avons décidé de donner des ordinateurs aux agents Cloud pour qu’ils puissent tester leurs modifications, la première étape a été de nous assurer qu’ils savaient les tester efficacement sur notre propre base de code.
Faire fonctionner notre monorepo pour les agents Cloud nous a appris que l’environnement de développement est un produit à part entière, dont les utilisateurs sont des agents. Il faut faire en sorte que le cloud reflète le développement local, rendre le dépôt suffisamment lisible pour que les agents puissent exécuter et tester le code sans connaissances tacites, et maintenir cet environnement en bon état à mesure que la base de code évolue.
La création de cet environnement a changé notre façon de travailler. En décembre, les agents Cloud ont rédigé environ une PR sur dix fusionnées dans le monorepo de Cursor. Aujourd’hui, ils en rédigent plus de la moitié.
7-day rolling share of merged PRs from cloud agents
Faire correspondre le cloud au développement local
La première étape pour que les Agents Cloud fonctionnent bien dans notre dépôt a consisté à faire en sorte que notre dépôt fonctionne bien dans une VM cloud. Cette étape est familière à tout ingénieur qui configure un environnement de développement distant pour la première fois.
La plupart des développeurs Cursor travaillent localement sur des Mac, mais nos VM cloud fonctionnent sous Linux. Nous avons donc dû adapter divers utilitaires de développement et scripts d'installation pour qu'ils fonctionnent sur des VM Ubuntu. Nous avons ajouté des dépendances de développement essentielles à un Dockerfile défini par Cursor, qui sert d'image de base pour les Agents Cloud.
Nous avons également travaillé avec notre équipe de sécurité pour ajouter des fonctionnalités de sécurité au produit d’Agent Cloud, afin que les utilisateurs puissent injecter en toute confiance les secrets requis dans l’environnement de l’agent. Ces fonctionnalités incluent des restrictions sur le trafic réseau sortant, un accès Git distant limité et relayé, l’analyse des secrets dans les commits et les messages de commit, ainsi que le masquage des secrets dans les résultats des outils, ce qui empêche l’agent de lire les valeurs des secrets même s’il essaie.
Une interface simplifiée pour les agents
Même après avoir mis en place notre environnement de développement sur des VM Ubuntu, les agents avaient encore du mal à exécuter notre code. Ce n’était pas surprenant : notre expérience développeur était désordonnée et exigeait d’apprendre et de retenir de nombreuses commandes et options de build, ainsi que des scripts utilitaires.
Nous avons créé des skills expliquant comment compiler et exécuter de nombreuses parties du système, mais cela n’a apporté qu’une aide limitée. Les skills peuvent documenter les bonnes commandes, mais celles-ci restaient complexes et truffées de pièges.
Pour réduire cette complexité, nous avons créé une CLI appelée anydev, que les agents peuvent utiliser pour démarrer tous les services. Nous faisons également passer les scripts utilitaires courants par anydev et avons doté anydev de plusieurs menus --help expliquant l’utilisation de chaque sous-commande. anydev dispose aussi d’un processus superviseur qui surveille et redémarre les commandes de build de longue durée, déchargeant entièrement le modèle de cette responsabilité.
anydev a suffisamment simplifié l’expérience de développement pour que les agents puissent exécuter leur code de manière fiable. Les skills ont aidé à documenter son utilisation, mais le principal changement était que les agents n’avaient plus à jongler avec des commandes de build spécialisées en plusieurs étapes, à éviter des pièges cachés ou à superviser des processus de longue durée.
C’est à ce moment-là que les Agents Cloud, chacun disposant de son propre ordinateur, ont commencé à apporter une réelle valeur ajoutée par rapport aux agents locaux. Grâce à l’utilisation de l’ordinateur, à leur outil recordScreen et à un environnement de développement fonctionnel, les agents pouvaient désormais tester leurs modifications de bout en bout et prouver la justesse de leur travail à l’utilisateur.
Ils pouvaient également partager dans Slack des démonstrations enregistrées par l’agent lorsqu’une personne corrigeait un signalement de bug, ou dans une PR lorsqu’ils proposaient une modification. Pour de nombreuses tâches, les ingénieurs pouvaient désormais fusionner et déployer en toute confiance le code généré par un Agent Cloud sans jamais extraire la branche localement.
Un environnement auto-réparateur
L’environnement autour de l’agent évolue constamment. Le maintenir opérationnel implique donc de mettre continuellement à jour son fonctionnement et ce à quoi il peut accéder.
Pour diagnostiquer et restaurer les environnements défaillants à mesure qu’ils rencontrent des problèmes, nous avons créé Cursor Cloud MCP. Nous avons choisi MCP, car il nous offrait des outils détectables dynamiquement, dotés d’interfaces que nous pouvions modifier sans avoir à recréer la boucle de l’agent. Les Agents Cloud l’utilisent pour inspecter leur propre environnement et détecter les échecs d’installation, les règles de trafic sortant, les secrets modifiés, et bien plus encore. Ils peuvent ainsi diagnostiquer et résoudre les problèmes dès qu’ils surviennent, et restaurer plus rapidement les environnements défaillants.
Avec Cursor Cloud MCP en place, nous avons configuré une automatisation appelée Cloud Doctor, qui vérifie périodiquement les défaillances, mémorise quelles erreurs peuvent être transitoires ou significatives, analyse les causes racines et peut ouvrir des PR pour résoudre les problèmes avec un niveau de confiance élevé.
Améliorer l’expérience des agents
Même dans un environnement sain, les agents empruntent parfois des chemins longs ou détournés pour vérifier leurs modifications. Ils peuvent utiliser le mauvais skill, rencontrer des problèmes évitables dans la VM ou suivre des workflows plus longs que nécessaire.
Nous utilisons également Cursor Cloud MCP à cette fin. Les agents Cloud Doctor inspectent les traces pour déterminer où un autre agent s’est trompé, quels skills ou commandes étaient trompeurs et quels workflows sont systématiquement lents. À partir de ces résultats, Cloud Doctor corrige le skill, simplifie le parcours ou modifie l’environnement pour faciliter la tâche de l’agent suivant.
Cette boucle améliore continuellement l’expérience développeur des agents eux-mêmes. Lorsque l’environnement est sain et auto-réparateur, les agents s’exécutent de manière fiable et les développeurs confient aux Agents Cloud des tâches plus importantes.
Cela nous a permis de passer à l’échelle en interne pour l’adoption des Agents Cloud, qui produisent désormais la majorité du code que nous livrons.
Préparez votre environnement pour les agents cloud
L'essentiel de la productivité des agents cloud repose sur l'environnement. Pour déterminer si votre base de code est prête, commencez par répondre à trois questions :
- Les agents ont-ils accès aux mêmes outils et données qu'un développeur ?
- Les agents peuvent-ils trouver des skills qui expliquent comment vos développeurs travaillent réellement ?
- Les agents peuvent-ils tester et vérifier les workflows essentiels ?
Si vous souhaitez obtenir de l'aide pour préparer votre environnement, contactez-nous.
Pour en savoir plus, découvrez comment Faire a doublé le débit hebdomadaire de traitement des PR grâce aux agents cloud.
