Cursor Projects place un coordinateur au-dessus de milliers d’agents de programmation

Cursor a lancé Cursor Projects en bêta le 10 septembre, en plaçant un agent coordinateur au-dessus de potentiellement milliers de sous-agents de programmation. Le coordinateur n’écrit pas de code. Il planifie, délègue, suit les résultats et reste disponible pendant que les autres agents exécutent le travail en parallèle.

Cette répartition du travail constitue le pari central de Cursor Projects. Les développeurs ne devraient plus avoir à superviser chaque agent ni à traduire un vaste projet en une succession de prompts isolés. Ils peuvent décrire le résultat global recherché et guider un coordinateur qui gère la couche d’exécution.

Il s’agit aussi d’un défi direct au modèle actuel de centre de commande pour le développement agentique. L’application Codex d’OpenAI aide les développeurs à exploiter plusieurs agents parallèles, tandis que Cursor veut que son coordinateur gère ce parallélisme à leur place. La concurrence se déplace d’une meilleure complétion de code vers le contrôle de travaux d’ingénierie de longue durée.

Cursor Projects transforme un objectif en opération continue

Le changement important ne réside pas dans le nombre d’agents, mais dans la nouvelle couche qui décide de ce que tous ces agents doivent faire.

Selon l’annonce officielle de Projects, les utilisateurs supervisent chaque Project en échangeant avec un agent coordinateur. Ce coordinateur découpe le travail en missions et dirige d’autres agents chargés de rechercher, d’implémenter, de tester et de réviser le code.

Cursor indique que le coordinateur délègue le travail au lieu de l’exécuter lui-même. Il peut ainsi rester réactif pendant que les sous-agents poursuivent leurs missions. Un développeur peut modifier les priorités ou formuler un retour sans attendre la fin de chaque tâche active.

Chaque Project s’exécute principalement dans le cloud, sur son propre ordinateur. Le travail peut continuer après la fermeture de l’ordinateur portable du développeur, et le système peut faire fonctionner davantage d’agents qu’une machine locale ne pourrait raisonnablement en prendre en charge.

L’exécution locale reste intégrée à la conception. Lorsqu’une modification nécessite l’accès à l’environnement d’un développeur, le coordinateur peut démarrer un agent local pour effectuer des tests ou d’autres tâches propres à cette machine.

Projects conserve également des fichiers partagés entre les ordinateurs cloud et locaux utilisés par ses agents. Ces fichiers peuvent contenir des recherches, des artefacts d’implémentation, des instructions de test, des détails d’architecture et des préférences apprises lors de travaux antérieurs.

Ce contexte partagé répond à une faiblesse récurrente du développement agentique. Une nouvelle session de programmation commence souvent par une nouvelle explication du dépôt, de ses conventions et du travail déjà réalisé.

Cursor Projects traite plutôt le contexte comme un actif du projet. Lorsqu’un sous-agent découvre la bonne manière de tester un service, les agents suivants peuvent réutiliser ces instructions.

Le produit introduit également les abonnements, des déclencheurs persistants connectés à des événements ou à des calendriers. Un coordinateur peut surveiller des pull requests, suivre un canal Slack ou exécuter une tâche à des horaires définis.

Cela modifie l’unité fondamentale d’interaction. Le développeur ne demande plus simplement à un agent d’achever une tâche. Il met en place une opération qui continue de répondre aux nouveaux travaux.

Cursor identifie trois catégories initiales : le développement de fonctionnalités, les grandes migrations et la maintenance continue. Chacune dépasse la durée de vie d’un chat classique et s’étend généralement sur plusieurs pull requests.

Le travail sur une fonctionnalité peut commencer par des agents qui étudient la base de code et consignent leurs conclusions. Le coordinateur prépare ensuite un plan et répartit le travail d’implémentation ou de test entre plusieurs sous-agents.

Après la mise en production, le même Project peut conserver le raisonnement qui a motivé les décisions antérieures. Cursor affirme qu’il peut surveiller les journaux et répondre aux signalements de bugs à l’aide de ce contexte accumulé.

Les migrations suivent un rythme différent. Le coordinateur applique progressivement une approche convenue, permettant aux développeurs d’examiner attentivement les premières pull requests avant de lui accorder davantage de marge de manœuvre.

La maintenance continue, que Cursor appelle gardening, n’a pas de point final défini. Un Project peut surveiller les régressions, les problèmes récurrents de qualité du code ou les composants qui devraient rejoindre un système de conception partagé.

Il ne s’agit pas de nouvelles activités d’ingénierie. Le changement tient au fait que Cursor les présente comme des charges de travail persistantes et coordonnées, plutôt que comme des conversations distinctes avec des agents de programmation individuels.

Comment Cursor Projects fonctionne au-delà d’un seul chat

Le mécanisme de Cursor associe délégation, contexte durable, exécution cloud et déclencheurs récurrents dans une boucle de contrôle unique et continue.

Pour comprendre le fonctionnement de Cursor Projects, il faut commencer par le modèle coordinateur-travailleurs. Le coordinateur porte la responsabilité du résultat global, tandis que des sous-agents spécialisés prennent en charge des portions de travail limitées.

Un sous-agent peut examiner un service, implémenter un composant, exécuter une suite de tests ou enquêter sur une défaillance. Le coordinateur évalue ces résultats et décide des prochaines étapes.

Cette architecture permet de répartir le travail. Les tâches indépendantes peuvent s’exécuter simultanément, tandis que les tâches dépendantes peuvent attendre les éléments dont elles ont besoin.

L’exécution parallèle ne résout pas à elle seule la coordination des grands projets. Davantage d’agents peuvent aussi produire des recherches redondantes, des modifications incompatibles, des hypothèses contradictoires et une file de révision plus importante.

Le coordinateur est donc particulièrement important lorsqu’il peut répartir le travail proprement. Il doit attribuer des objectifs distincts, préserver les dépendances et décider quels résultats méritent une itération supplémentaire.

Anthropic a documenté des enseignements similaires lors de la création de son système multi-agents. Son agent principal délègue les recherches à des travailleurs spécialisés, mais l’entreprise a constaté que des missions vagues créaient des doublons et des lacunes de couverture.

Anthropic a également indiqué que l’utilisation parallèle d’outils avait réduit jusqu’à 90 % le temps de recherche pour des requêtes complexes. L’entreprise a toutefois souligné que la complexité de coordination augmente rapidement à mesure que davantage d’agents rejoignent une tâche.

Ces constats s’appliquent directement au développement logiciel. Ajouter des travailleurs augmente le débit potentiel, mais accroît également le nombre d’interfaces où les hypothèses peuvent diverger.

Le contexte partagé de Cursor vise à réduire cette divergence. Il offre aux agents un espace persistant où stocker des connaissances opérationnelles qui disparaîtraient autrement à la fin d’une conversation.

Le contexte peut inclure des informations propres au dépôt, telles que les commandes de compilation ou les exigences de test. Il peut aussi enregistrer des préférences, des décisions architecturales et les enseignements tirés d’approches ayant échoué.

Cela crée une forme de mémoire de projet. Elle se distingue de la fenêtre de contexte temporaire d’un modèle, car les artefacts utiles restent accessibles entre différents agents et environnements d’exécution.

Pour les équipes d’ingénierie, cette mémoire peut devenir aussi importante que le code généré. Une modification dépourvue de son raisonnement peut être difficile à maintenir, en particulier lorsqu’un autre agent prend en charge la modification suivante.

Le contexte persistant soulève aussi une question de gouvernance. Les équipes devront déterminer quelles instructions générées par les agents restent fiables et à quel moment les anciennes directives doivent être révisées.

Une instruction de test erronée pourrait se propager dans les futures missions. Une note architecturale obsolète pourrait orienter plusieurs sous-agents vers la même implémentation incorrecte.

Projects n’élimine donc pas le travail de documentation. Il modifie qui crée la documentation, à quelle fréquence elle évolue et à quel point les travailleurs automatisés en dépendent directement.

Les abonnements ajoutent un autre mécanisme. Plutôt que d’attendre le prompt d’un développeur, un Project peut réagir lorsqu’une pull request est ouverte, qu’une vérification planifiée commence ou qu’un message Slack signale un problème.

Le coordinateur devient ainsi piloté par les événements. Il peut relier le travail de développement aux signaux déjà présents dans l’environnement opérationnel d’une équipe.

Le résultat ressemble davantage à une fonction d’ingénierie permanente qu’à un assistant temporaire. Le Project observe, attribue le travail, évalue la progression et réagit à nouveau lorsque les conditions changent.

Cette structure explique pourquoi Cursor met l’accent sur les travaux qui survivent à un chat. Une petite modification a rarement besoin d’une coordination persistante, mais une migration ou un programme de maintenance en a besoin.

La pression se déplace de la vitesse de programmation vers la coordination

Cursor Projects pousse chaque plateforme de programmation agentique à démontrer que des agents parallèles peuvent produire des systèmes cohérents, et pas simplement davantage de modifications.

OpenAI a présenté son application Codex comme un centre de commande destiné à gérer plusieurs agents de programmation. Les développeurs peuvent exécuter des tâches dans des fils distincts, examiner les modifications, commenter les diffs et travailler sur des missions parallèles.

Le modèle de l’application Codex maintient le développeur visiblement impliqué dans l’orchestration de ces fils. Cursor Projects transfère une plus grande part de cette orchestration à un agent coordinateur.

Cette distinction est plus importante qu’une simple liste de fonctionnalités Cursor Projects contre Codex. Les deux produits prennent en charge le travail dans le cloud, l’exécution parallèle et les tâches de plus longue durée.

La question plus profonde concerne l’emplacement de la responsabilité de gestion. Le développeur coordonne-t-il plusieurs agents capables, ou un agent de niveau supérieur les coordonne-t-il sous la direction humaine ?

Cursor privilégie la seconde voie pour les ensembles de travaux importants. L’utilisateur guide un coordinateur, et celui-ci décide du nombre de travailleurs à créer ainsi que de l’endroit où les déployer.

Cette approche peut réduire la charge de planification humaine. Les développeurs n’ont pas besoin de créer manuellement un fil distinct pour chaque zone du dépôt, échec de test ou option d’implémentation.

Elle peut aussi rendre le système plus difficile à inspecter. Lorsque la délégation devient récursive, le chemin entre une demande humaine et une modification précise du code s’allonge.

Une interface de centre de commande expose plus directement les tâches individuelles. Une interface pilotée par un coordinateur peut masquer cette complexité, mais une complexité cachée ne disparaît pas.

Cette tension façonnera davantage les comparaisons entre Cursor Projects et Codex que les seuls benchmarks bruts de modèles. Les équipes doivent savoir comment chaque système délimite le travail, expose les décisions, gère les conflits et prend en charge la révision.

La manière dont Cursor présente son produit reflète ce changement. En février, l’entreprise a décrit une « troisième ère » du développement logiciel, centrée sur des flottes d’agents prenant en charge des ensembles entiers de travaux.

Ses précédentes recherches sur le passage à l’échelle des agents ont étudié des centaines d’agents concurrents travaillant sur un même projet. Ces expérimentations ont impliqué plus d’un million de lignes de code généré et des milliers de milliards de tokens.

L’échelle de la recherche ne se traduit pas automatiquement par une fiabilité en production. Elle montre néanmoins que Cursor étudie la coordination comme un problème d’ingénierie distinct.

OpenAI poursuit la même destination générale depuis une autre direction d’interface. Ses documents consacrés à Codex mettent l’accent sur les agents parallèles, les environnements isolés, l’organisation des projets, les compétences et les automatisations en arrière-plan.

Les deux entreprises dépassent le chat à agent unique. La question non résolue est de savoir quel niveau d’abstraction les développeurs accepteront avant de se sentir déconnectés du code et du raisonnement qui le sous-tend.

La pression concurrentielle s’étend également au-delà de Cursor et d’OpenAI. Toute plateforme de programmation conçue autour d’un agent interactif doit désormais répondre à des demandes qui s’étendent sur des mois, plusieurs dépôts et des événements opérationnels récurrents.

Un modèle performant peut achever une tâche isolée. Un système de projet durable doit préserver les priorités, se remettre des échecs, intégrer les résultats et décider à quel moment demander l’aide d’une personne.

Il s’agit d’une catégorie de produit différente. La qualité du modèle reste essentielle, mais l’orchestration, la mémoire, l’isolation, l’observabilité et les contrôles de révision déterminent de plus en plus si le système fonctionne en production.

Les développeurs continueront de se soucier de la qualité du code et de la rapidité. Les acheteurs en entreprise demanderont aussi qui peut retracer une décision, limiter l’accès d’un agent et arrêter un processus incorrect.

Cursor Projects relève ces attentes sans les résoudre. Sa bêta offre à Cursor l’occasion de démontrer si un développement piloté par un coordinateur peut fonctionner en dehors de projets internes étroitement surveillés.

Les résultats internes de Cursor sont prometteurs, mais ne constituent pas une preuve indépendante

Cursor a publié des chiffres d’adoption frappants, mais ils mesurent l’activité au sein de Cursor plutôt que des améliorations vérifiées de la qualité logicielle.

Cursor affirme utiliser Projects en interne depuis plusieurs mois. Les charges de travail signalées comprennent l’adoption de frameworks, le remplacement de systèmes de styles, la livraison de fonctionnalités et la maintenance de systèmes de design sur de nombreuses pull requests.

L’entreprise indique que les nouveaux utilisateurs de Projects fusionnent 30 % de pull requests en plus. Elle affirme également que les personnes utilisant principalement Projects fusionnent six fois plus de pull requests.

Ces chiffres méritent une interprétation prudente. Cursor n’a pas publié la taille de l’échantillon, la période d’observation, la méthode de contrôle, la composition des dépôts ni les détails statistiques dans son annonce.

Le volume de pull requests mesure aussi le débit, pas nécessairement la valeur. Davantage de changements fusionnés peuvent indiquer une livraison plus rapide, mais cette métrique ne révèle ni les taux de défauts, ni la fréquence des annulations, ni la charge de revue, ni le coût de maintenance.

Des effets de sélection pourraient influencer la comparaison. Les ingénieurs qui adoptent Projects le plus intensivement peuvent travailler sur des tâches se répartissant facilement entre agents, ou être déjà à l’aise avec la gestion de l’automatisation.

Les chiffres de Cursor doivent donc être considérés comme des éléments de preuve internes sur le produit. Ils étayent la nécessité de tests supplémentaires, mais n’établissent pas un gain de productivité général pour toutes les organisations d’ingénierie.

L’exemple du système de design est plus concret. Cursor indique qu’un Project interne analyse les nouvelles pull requests, extrait des composants et crée des règles de lint après avoir constaté deux fois la même erreur.

L’entreprise prévoit que ce Project interviendra sur 20 à 100 pull requests par jour. Au départ, un ingénieur humain examinait chaque correction, puis a réduit la supervision à mesure que le système s’améliorait.

Cette progression illustre le modèle de confiance visé par Cursor. Les équipes commencent par une revue étroite, observent si les corrections tiennent dans le temps, puis élargissent progressivement l’autonomie.

Elle révèle aussi la charge de travail que Projects pourrait créer. Un système intervenant sur 100 pull requests par jour peut submerger les relecteurs si ses changements sont bruyants, redondants ou difficiles à prioriser.

Les conflits de fusion créent un autre risque. Des sous-agents parallèles peuvent travailler efficacement sur des zones indépendantes, mais les changements qui se chevauchent exigent une coordination au niveau du code et de l’intention.

Les tests ne résolvent pas entièrement ce problème. Deux changements peuvent réussir leurs tests locaux tout en produisant une interaction indésirable après intégration.

Les frontières de sécurité comptent également. Un coordinateur persistant peut accéder au code source, aux machines locales, aux pull requests, aux messages Slack, aux journaux et aux signaux liés au déploiement.

Chaque connexion enrichit le contexte utile du système. Chacune élargit aussi les conséquences d’instructions erronées, d’autorisations excessives ou d’entrées compromises.

Les déclencheurs d’abonnement exigent une vigilance particulière. Un message malveillant ou trompeur dans un canal surveillé pourrait tenter d’influencer un agent, à moins que le système ne sépare le contenu non fiable des instructions autorisées.

Les équipes devront établir des règles claires sur ce que le coordinateur peut lire, les actions qu’il peut initier et les modifications qui exigent toujours une approbation. Les pistes d’audit doivent relier le travail délégué à l’événement qui l’a déclenché.

La mémoire à long terme présente un défi connexe. Le contexte partagé devient plus utile avec le temps, mais un contexte incorrect peut également persister et façonner le travail futur.

Les organisations ont besoin de moyens pour inspecter, réviser, expirer et attribuer les instructions stockées. Sans cela, la mémoire du projet risque de devenir une couche de configuration opaque.

Cursor a déjà décrit l’objectif des codebases autonomes, dans lesquelles des agents peuvent fusionner des changements, gérer des déploiements progressifs et surveiller la production. Projects rapproche cette vision d’un produit destiné aux utilisateurs.

Toutefois, le langage de l’autonomie ne doit pas masquer la responsabilité. Les logiciels de production continuent d’avoir des conséquences en matière de sécurité, de fiabilité, de droit et de clients, qui restent à la charge de l’organisation qui les déploie.

Le véritable test de la bêta n’est pas de savoir si le coordinateur peut générer de nombreuses pull requests. Il s’agit de déterminer si les équipes peuvent comprendre ces changements et maintenir leur confiance à mesure que le travail délégué monte en charge.

Les migrations d’envergure offrent le test initial le plus clair

Les migrations constituent le cas d’usage initial le plus solide, car elles combinent un travail répétable, des progrès mesurables et des points de contrôle naturels pour la revue humaine.

Une migration d’envergure contient souvent des centaines de changements associés. Les équipes peuvent devoir remplacer un framework, mettre à jour une API, supprimer un système de styles ou appliquer une nouvelle convention de dépôt.

Les premiers changements exigent une réflexion approfondie. Les ingénieurs doivent identifier les cas limites, établir le modèle souhaité et confirmer que les tests détectent des régressions significatives.

Les changements ultérieurs répètent souvent la méthode établie. Cela rend le travail adapté à un coordinateur capable d’attribuer des zones limitées du dépôt à des sous-agents distincts.

Cursor indique que ses équipes ont utilisé Projects pour des migrations couvrant des centaines de pull requests. Les développeurs examinent de près le travail initial, puis réduisent leur intervention lorsque l’approche se révèle stable.

C’est une meilleure adéquation que de demander à des milliers d’agents d’inventer simultanément une fonctionnalité fortement couplée. Les tâches de migration ont souvent des frontières plus nettes et des critères d’achèvement plus objectifs.

Les progrès sont également visibles. Les équipes peuvent compter les modules migrés, les échecs non résolus, les corrections issues de la revue, les conflits de fusion et les régressions après le déploiement.

Ces mesures aident les organisations à évaluer le fonctionnement de Cursor Projects en pratique. Elles révèlent si le débit supplémentaire des agents réduit le temps écoulé ou déplace simplement l’effort vers la revue et le nettoyage.

Le développement de fonctionnalités est un test plus difficile. Les fonctionnalités comportent des décisions produit ambiguës, des exigences changeantes, des arbitrages d’expérience utilisateur et des dépendances qui apparaissent pendant l’implémentation.

Un coordinateur peut paralléliser la recherche, le prototypage, les tests et le travail sur les composants. Il a toutefois besoin d’une escalade fiable lorsque les sous-agents rencontrent des hypothèses incompatibles.

Le système doit également préserver une intention produit cohérente. Un ensemble de composants techniquement correct ne garantit pas une fonctionnalité utile ou compréhensible.

La maintenance continue est encore plus difficile, car elle ne possède pas de ligne d’arrivée naturelle. Le coordinateur doit distinguer le travail préventif utile d’une activité interminable et de faible priorité.

Un Project surveillant chaque pull request peut identifier des schémas récurrents. Toutefois, il peut aussi produire du bruit d’automatisation ou traiter à répétition des symptômes plutôt que des problèmes de conception sous-jacents.

Les équipes qui envisagent la bêta devraient commencer par des charges de travail limitées et réversibles. Une migration par codemod, l’extension des tests ou un nettoyage ciblé du système de design offrent des résultats observables.

Elles devraient enregistrer davantage que les seuls volumes de fusion. Parmi les mesures utiles figurent le temps de revue humaine, la fréquence des corrections, les défauts rouverts, le taux d’annulation, le travail dupliqué et la consommation totale de calcul.

L’équipe devrait également définir des conditions d’arrêt avant d’augmenter l’autonomie. Un seuil d’échecs de tests, d’accès inattendu à des fichiers, de corrections répétées lors de la revue ou de conflits de fusion peut déclencher une intervention humaine.

La mémoire du projet mérite une revue active pendant ces pilotes. Les ingénieurs devraient examiner ce que les agents stockent et confirmer que le contexte partagé reflète les pratiques actuelles du dépôt.

Ce travail se relie naturellement à une base de connaissances d’ingénierie. Le contexte généré par les agents devient plus utile lorsque les équipes peuvent le comparer à une documentation technique faisant autorité.

Une migration réussie fournirait des preuves plus solides qu’une démonstration soignée. Elle montrerait que le coordinateur peut préserver une même approche à travers de nombreux changements sans perdre le contrôle de la qualité d’intégration.

Ces preuves clarifieraient également la question Cursor Projects vs Codex. Les équipes pourraient comparer la délégation pilotée par un coordinateur aux tâches parallèles attribuées manuellement, en utilisant le même dépôt et les mêmes standards de revue.

Le meilleur système ne générera pas nécessairement le plus de code. Il réduira l’effort total nécessaire pour parvenir à un résultat stable, compréhensible et maintenable.

Ce qui déterminera la capacité de Cursor Projects à passer à l’échelle

Trois signaux détermineront si Projects devient une couche de contrôle de l’ingénierie ou reste une bêta impressionnante pour un travail exceptionnellement structuré.

Le premier signal est l’existence de preuves de production indépendantes. Cursor a partagé des chiffres internes sur les pull requests, mais les équipes externes doivent communiquer les taux de défauts, l’effort de revue et le délai de livraison.

Les preuves les plus solides proviendront de projets ayant de véritables conséquences opérationnelles. Les migrations d’envergure, les fonctionnalités multi-services et les programmes de maintenance persistants devraient produire des comparaisons mesurables avant-après.

Si les équipes livrent plus vite sans augmenter les régressions ni la charge de revue, le modèle de coordinateur de Cursor gagnera en crédibilité. Si le volume de fusions augmente tandis que le nettoyage s’amplifie, l’affirmation centrale s’affaiblit.

Le deuxième signal est une meilleure observabilité et gouvernance. Les développeurs doivent pouvoir voir pourquoi le coordinateur a créé une tâche, quel contexte il a utilisé et comment un résultat a influencé les décisions ultérieures.

Les administrateurs ont également besoin de limites d’autorisations pour les machines cloud, les agents locaux, les dépôts, les systèmes de communication et les signaux de déploiement. Une automatisation persistante ne peut pas reposer sur une confiance générale.

Des contrôles utiles incluraient des traces de délégation, des politiques d’approbation, des historiques de contexte, des limites de ressources et des mécanismes d’interruption clairs. Ces fonctionnalités déterminent si les entreprises peuvent gérer le coordinateur comme une infrastructure.

Si Cursor rend la délégation récursive compréhensible, l’entreprise peut préserver la commodité de l’abstraction sans obliger les équipes à renoncer à leur visibilité. Des contrôles insuffisants limiteraient l’adoption aux dépôts présentant moins de risques.

Le troisième signal est la réponse des plateformes concurrentes. OpenAI prend déjà en charge des agents Codex parallèles et développe des automatisations en arrière-plan liées à des déclencheurs cloud.

Une évolution vers une délégation gérée par les agents validerait la manière dont Cursor présente le marché. Une insistance continue sur l’orchestration humaine directe préserverait une différence significative entre les produits.

Les travaux d’Anthropic offrent également une référence technique importante. Ses recherches sur le modèle orchestrateur-travailleurs montrent à la fois les gains de performance des spécialistes parallèles et la croissance rapide des problèmes de coordination.

Les concurrents n’ont pas besoin de copier l’interface de Projects. Ils peuvent défier Cursor en proposant des flux de revue plus solides, une exécution plus sûre, un suivi des tâches plus clair ou une mémoire de projet plus fiable.

Cursor Projects n’est donc pas simplement une nouvelle sortie d’agent de programmation. C’est une proposition visant à réorganiser la relation entre les développeurs et les travailleurs automatisés.

Le développeur monte d’un niveau au-dessus des tâches d’implémentation individuelles. Le coordinateur devient responsable de la décomposition, de la planification, de la continuité et de l’action récurrente.

Ce modèle présente un attrait évident pour les migrations et les programmes de maintenance que les équipes peinent à achever. Il concentre aussi davantage de jugement au sein d’un système dont les décisions peuvent se multiplier à travers de nombreux sous-agents.

La bêta réussira lorsque les équipes pourront déléguer des résultats plus vastes sans perdre le raisonnement, les contrôles et la responsabilité qui sous-tendent le code. L’échelle seule ne suffira pas à établir ce résultat.

Les développeurs évaluant Cursor Projects devraient choisir une charge de travail limitée, définir des mesures de qualité et observer où l’attention humaine se déplace réellement. Le coordinateur élimine-t-il le travail de coordination, ou le déplace-t-il vers la revue, la maintenance du contexte et la réponse aux incidents ?

Cette réponse compte au-delà de Cursor. Elle indiquera si la prochaine phase du développement de l’IA appartient à des personnes gérant de nombreux agents ou à des agents coordinateurs les gérant à notre place.