Quand un changement traverse une douzaine de fichiers, la complétion ne sert plus

Les vrais changements tiennent rarement en un seul endroit. Ajouter un champ touche le modèle de données, la couche d'interface, le formulaire devant l'utilisateur et les tests, répartis sur une douzaine de fichiers. La complétion classique excelle à deviner la demi-ligne qu'on allait écrire et ne sert à peu près à rien ici : on garde la liste en tête et on la parcourt point par point, en espérant n'avoir oublié aucun recoin. Cursor retourne la tâche et confie l'ensemble à un agent. On décrit le résultat voulu et, après avoir lu tout le dépôt, il travaille seul - modifie des fichiers, lance des commandes, voit une erreur et revient la corriger, jusqu'à ce que ça tourne.

Cursor n'est pas une fenêtre de discussion vissée sur un éditeur : il se présente comme un artisan du logiciel qui livre un travail fini.

Découper d'abord, étaler ensuite

Laisser un seul agent fixer une douzaine de fichiers et il perdra le fil. Cursor décompose en deux couches. L'interne est le sous-agent. Chacun vit dans sa propre fenêtre de contexte, prend un type de travail et rend sa conclusion au parent, si bien que l'exploration intermédiaire ne mange pas la conversation principale. Ils peuvent partir en même temps sur des parties différentes du dépôt au lieu de faire la queue. Trois sont fournis : l'un explore et analyse le code, l'un exécute des commandes, l'un pilote un navigateur par des outils MCP - et tous trois répondent depuis l'éditeur, la ligne de commande et un agent distant. On peut définir les siens, avec une consigne, un jeu d'outils et un modèle, et les réutiliser d'un projet à l'autre.

Projects : un coordinateur qui n'écrit pas de code

Quand la tâche dépasse une session, la couche Projects prend le relais, et sa division du travail est le plus intéressant : le coordinateur n'implémente rien. La description officielle dit qu'il n'écrit pas de code directement - il planifie le travail, distribue les tâches de réalisation et rapporte le résultat fini pour qu'on l'inspecte. Il ouvre autant d'agents que le travail en demande, menés en parallèle. Chaque projet tourne sur sa propre machine distante, donc fermer le portable n'interrompt rien ; quand il faut vérifier sur du matériel réel, le coordinateur démarre un agent local qui prend la suite.

Plus remarquable encore, ces agents n'oublient pas chacun de leur côté. Un projet tient un ensemble de fichiers synchronisés sur toutes les machines, distantes et locales, et les agents y ajoutent ce qu'ils ont trouvé, les conventions du projet et les pratiques que vous préférez. Si l'un découvre comment tester un service, tous les suivants peuvent reprendre cette conclusion : le coordinateur devient plus utile à mesure que le projet avance. Il peut aussi s'abonner à un canal de retours, s'exécuter à heures fixes ou suivre toutes vos demandes de fusion sans qu'on lui parle.

Là où le travail tourne vraiment

Des agents en parallèle ont besoin d'un endroit chacun. Les agents distants vivent dans des machines virtuelles isolées, dépôt déjà cloné, dépendances déjà installées, clés et réseau disponibles : ils construisent, testent et dialoguent réellement avec le logiciel qu'ils modifient, puis poussent le résultat sous forme de demande de fusion. Ils s'abonnent aussi aux demandes qu'ils ont ouvertes et traitent les échecs d'intégration continue et les commentaires de robots jusqu'à la fusion.

Les équipes dont le code ne peut pas partir dans un nuage public peuvent faire tourner leurs propres machines : l'exécution des outils reste dans votre réseau, le dépôt, les produits de construction et les clés restent sur des machines internes de votre infrastructure, et les appels d'outils sont traités localement. Une réserve partagée pour une équipe grandit et rétrécit avec le volume des requêtes, dort au repos et revient dans une fenêtre de reconnexion à la requête suivante - aucune machine ne brûle pour la prochaine invite.

Jusqu'où lâcher prise se règle

Tout déléguer n'est pas un interrupteur. Le cran le plus léger est la complétion à la touche, poussée par un modèle entraîné pour cela, qui prédit seulement votre prochaine modification, presque sans rien dire. Au milieu vient la réécriture ciblée, pour un changement local bien délimité. Au-dessus seulement arrive le mode agent, qui prend la tâche entière. Chaque changement laisse un point de reprise : l'évolution du code reste lisible et tout état antérieur est à un pas. Au stade du débogage, il instrumente le code et s'appuie sur de vraies données d'exécution pour trouver quoi corriger, au lieu de deviner.

L'entrée est peu coûteuse : l'offre gratuite ne demande pas de carte, elle vient simplement avec un nombre limité de requêtes d'agent. Plus d'usage et des modèles plus avancés supposent une offre payante - 20 dollars par mois pour une personne, 40 dollars par utilisateur pour une équipe, les quotas exacts figurant sur la page tarifaire officielle.

Faire écrire à un modèle un morceau de code convenable n'est pas le difficile. Le difficile est de lui faire découper seul un gros travail en petits qui avancent en parallèle, puis de remettre les morceaux ensemble - et c'est exactement ce que ces deux couches de division résolvent.