J'ai besoin de vider mon sac. Avant mon entretien chez @cursor_ai, je n'avais jamais vraiment utilisé Cursor.
Chez Meta, Claude Code prenait une ampleur explosive. J'avais même payé un abonnement personnel de 200 $ par mois pour mes projets secondaires. J'adorais sa simplicité et la rapidité avec laquelle je me sentais productif. Le point bloquant pour moi était de développer mon propre ensemble de compétences qui transformaient cc en presque tout ce que je voulais. J'avais même commencé à développer mon propre outil d'orchestration d'agents par-dessus.
Lors de mon entretien sur place, j'ai utilisé Cursor pendant 2 jours pour construire le projet d'entretien. C'était avant la sortie de Cursor 3, donc j'utilisais la fenêtre de l'éditeur. J'utilise vscode depuis tellement d'années que la plupart des raccourcis clavier étaient encore dans ma mémoire, donc reprendre l'IDE n'a pas été trop difficile. Je ne peux pas mentir cependant. Pendant la première heure ou deux, l'interface en ligne de commande me manquait vraiment. Cliquer sur des choses me semblait presque barbare. Mais il y avait quelques points qui m'ont vraiment marqué.
Premièrement, les modèles que j'utilisais à l'époque - Opus et Codex - me semblaient plus intelligents, d'une certaine manière. Et c'était incroyable de pouvoir changer de modèle à la volée et de les utiliser tous les deux en même temps sur différentes parties de mon projet (Opus pour le frontend, Codex pour les systèmes). Avant mon entretien, je vantais déjà les mérites de la révision contradictoire multi-modèle, donc pouvoir le faire nativement dans l'interface utilisateur me semblait très naturel. Encore mieux était la possibilité de générer des sous-agents de différents modèles, pour obtenir le meilleur des deux mondes dans une seule conversation.
Deuxièmement, la compaction était incroyablement rapide. En tant qu'utilisateur de cc, j'avais l'habitude que la compaction prenne plusieurs minutes, et j'étais donc toujours en état d'alerte constant concernant l'utilisation de mon contexte et de mon plan. J'ai donc été totalement choqué de voir à quel point c'était rapide dans Cursor. Au point que je n'avais pratiquement jamais besoin de regarder combien de contexte j'utilisais. Ça fonctionnait tout simplement, alors que j'avais souvent l'impression que le modèle devenait super stupide après la compaction dans cc.
Et la troisième chose que j'ai remarquée, c'est à quel point les interfaces graphiques (GUI) pouvaient offrir plus que les interfaces textuelles (TUI). Pouvoir ouvrir votre application directement dans le navigateur de Cursor et apporter des modifications de conception avec le mode Design me semblait intuitif et m'a fait réfléchir à quel point des interfaces utilisateur spécialement conçues pouvaient rendre le codage agentique plus efficace.
Construire Cursor avec Cursor
Depuis mon arrivée fin mars, je travaille principalement sur la fenêtre Agent de Cursor 3, et je l'utilise comme mon outil quotidien. Bien que je pense toujours que cc est un produit intéressant avec une excellente équipe, j'ai remarqué que sa simplicité pousse souvent les gens à vouloir construire leurs propres abstractions autour. Dans mon dernier emploi, j'avais l'impression qu'un nouvel outil d'orchestration interne basé sur cc était annoncé chaque semaine.
@bcherny parle beaucoup de cette idée de "demande latente" :
"Il y a cette idée très ancienne en matière de produit appelée demande latente... vous construisez un produit d'une manière qui est piratable, suffisamment ouverte pour que les gens puissent en abuser pour d'autres cas d'utilisation. Ensuite, vous observez comment les gens en abusent et vous construisez pour cela."
C'était exactement ça ! Le fait que les gens convergent vers des outils d'orchestration révèle la demande latente : utiliser une interface en ligne de commande fait de vous, l'humain, l'orchestrateur.
Mais chaque workflow d'agent que j'avais utilisé se concentrait sur la mauvaise chose. Exécuter plusieurs interfaces en ligne de commande dans une interface graphique manquait complètement le sujet. L'approche qui m'intéressait était de construire la confiance dans les agents.
En tant qu'ancien responsable d'ingénierie, j'ai rapidement réalisé que la gestion des agents ressemblait à la construction d'une équipe d'ingénierie humaine. Les nouvelles recrues doivent être intégrées pour comprendre la base de code, mais aussi comment le travail est effectué. Elles arrivent déjà pré-formées avec des compétences acquises lors de leurs expériences passées : comment déboguer, comment écrire du code et des tests de haute qualité, et comment communiquer, pour n'en citer que quelques-unes.
Les agents sont comme des nouvelles recrues dans un état constant d'amnésie et de stupidité. Ils ne se souviennent pas de ce que vous leur dites, et ils n'apprennent jamais vraiment rien de nouveau. Mais nous pouvons les équiper de règles, de compétences, d'outils et d'une mémoire à long terme qui peuvent s'en approcher. Ils sont capables mais stupides, et très faciles à former. Et j'ai vu leurs modes d'échec comme des opportunités de leur enseigner tout ce que je sais sur la façon de faire de l'ingénierie rigoureuse et approfondie.
Parce que quand il n'y a pas de rigueur, les agents feront tout ce qu'il faut, de manière servile, pour écrire le code que vous avez demandé. Et mon Dieu, ils peuvent et vont en écrire beaucoup. La parallélisation naïve ne fait que les faire écrire du travail bâclé plus rapidement.
Si vous voulez aller vite, allez d'abord en profondeur
Je pense que l'orchestration d'agents peut être faite de manière productive. Mais nous devons d'abord aller en profondeur.
Je rends open source pstack, mon ensemble personnel de compétences et de principes d'ingénierie que j'utilise tous les jours pour construire @cursor_ai. J'ai commencé à développer les premières itérations de ces compétences dans mes projets secondaires, et je les affine depuis.
Obtenez-le ici : https://cursor.com/marketplace/cursor/pstack
Ces compétences sont devenues parmi les plus utilisées par l'équipe Cursor, donc je suis ravi de les partager avec vous tous.
pstack apprend aux agents à être plus rigoureux en utilisant plusieurs modèles. J'ai pris tous les modes d'échec que j'ai observés et je les ai transformés en compétences. Le cœur du plugin est /poteto-mode, qui est une compétence d'ordre supérieur qui donne aux agents le bon manuel à suivre pour une tâche donnée. L'objectif n'est pas le nombre maximal de lignes de code, mais l'inverse : un impact maximal avec le moins de code possible.
La rigueur est appliquée en abordant les problèmes de la même manière que les ingénieurs expérimentés. Par exemple, une excellente façon d'aborder le débogage est de faire une recherche binaire dans l'espace du problème. Vous commencez avec quelques hypothèses sur ce qui pourrait se passer, puis vous essayez de les éliminer systématiquement jusqu'à ce que vous puissiez vous rapprocher de la véritable cause racine. S'il est difficile de reproduire le problème, vous pouvez essayer de forcer synthétiquement l'apparition du bug. Ou vous pouvez essayer d'ajouter de l'instrumentation ou des journaux de console pour vérifier l'état du programme pendant son exécution.
Ces étapes forment un manuel qui peut être utilisé par les agents pour déboguer les problèmes en profondeur au lieu de deviner, ce qu'ils sont heureux de faire si vous les laissez faire. pstack est livré avec de nombreuses compétences et manuels qui vous permettent d'aborder le génie logiciel avec ce même niveau de rigueur. J'ai actuellement des manuels pour :
- Création de compétences et évaluations
- Travail autonome
- Corrections de bugs et analyses médico-légales d'exécution
- Développement de fonctionnalités
- Parité visuelle et prototypage
- Et plus encore
Chaque fois que vous avez besoin de rigueur, préfixez votre invite avec /poteto-mode. Par exemple :
Vous pouvez également invoquer à la demande les autres compétences :
- /how : vous voulez une explication détaillée du fonctionnement réel d'un sous-système.
- /why : vous voulez savoir pourquoi quelque chose a été construit de cette façon. utilise vos MCP disponibles pour interroger chaque catégorie de preuve en parallèle (contrôle de source, suivi des problèmes, documentation longue, chat en temps réel, observabilité de l'infrastructure, suivi des erreurs, entrepôt d'analyse).
- /architect : vous êtes sur le point d'écrire du code qui traverse une limite de fonction et vous voulez d'abord régler les types et les structures de données.
- /arena : vous voulez N tentatives parallèles de la même chose, puis prendre les meilleures parties de chacune.
- /interrogate : vous voulez que différents modèles examinent quelque chose de manière contradictoire.
- /tdd : vous corrigez un bug. écrivez d'abord le test qui échoue, puis la correction.
- /unslop : vous nettoyez tout type d'écriture d'IA. les fait parler simplement.
- /reflect : vous voulez améliorer continuellement vos compétences après de longues conversations.
- /figure-it-out : vous faites quelque chose d'inhabituel ? conçoit un manuel rigoureux et vérifiable pour la tâche.
- /show-me-your-work : vous voulez une piste de décision vérifiable. enregistre les décisions dans un fichier tsv que vous pouvez valider.
Et enfin, vous pouvez créer votre propre compétence de mode avec /automate-me. Il extrait vos transcriptions récentes, rédige une compétence de votre mode à partir de la façon dont vous avez travaillé, et l'achemine via pstack en dessous.
pstack fonctionne avec n'importe quel outil de codage agentique, mais il fonctionne particulièrement bien dans les outils multi-modèles comme Cursor. De nombreuses compétences utilisent des workflows multi-modèles pour tirer parti des forces et faiblesses uniques de chaque modèle. C'est de l'orchestration d'agents, mais appliquée en profondeur d'abord plutôt qu'en largeur.
Le goulot d'étranglement avec les agents est la vérification. Les agents peuvent écrire une grande quantité de code rapidement. S'assurer que tout est correct est extrêmement difficile. Lorsque vous y parvenez, un véritable parallélisme des agents, comme dans une usine sans personnel pour le logiciel, pourrait être possible.
Mais d'abord, nous devons aller en profondeur et être rigoureux. Je pense que nous y parvenons en augmentant la confiance.
Essayez pstack et dites-moi ce que vous en pensez.
Zen et l'Art de la Maintenance Logicielle
Ces compétences m'aident à avancer avec plus de confiance lorsque j'écris du code. Mais la maintenance du code est désormais un cauchemar avec les agents qui écrivent tout le code. Les bugs, les problèmes de performance et les demandes de fonctionnalités prennent encore du temps à résoudre. Et maintenant, il y en a tellement plus !
J'utilise abondamment les automatisations Cursor chez Cursor. Ce sont des agents cloud qui peuvent être programmés, ou exécutés en réponse à des événements comme de nouveaux messages dans un canal Slack. Un exemple est mon bot Benny. Je lui ai donné les mêmes compétences que j'ai dans pstack.
Benny est encore un travail en cours, mais ma vision est d'automatiser autant que possible le processus de maintenance logicielle. L'idée est la suivante : si nous avons maintenant la confiance nécessaire pour résoudre les problèmes en "un seul essai" avec pstack, avec un bon degré de certitude que la qualité de la pull request est élevée, nous pouvons sûrement aussi automatiser les retours d'information.
Cette usine commence sa vie par le triage : la collecte d'informations auprès des employés sur les rapports de bugs. Nous utilisons beaucoup Cursor en interne et nous recevons donc beaucoup de retours d'employés sur nos versions candidates. Benny comprend les images et les pièces jointes vidéo, explore la base de code en utilisant les compétences pstack, et discute avec le rapporteur pour obtenir des informations sur les étapes de reproduction si ce n'est pas clair.
C'est une partie importante du processus de signalement de bugs. Sans étapes de reproduction claires et une compréhension de ce qui est cassé, les agents ne peuvent que deviner la solution. Nous devons leur donner une compréhension claire de l'endroit exact et de la manière dont cela casse.
Une fois trié, Benny crée un ticket avec ses conclusions après avoir examiné le code, l'historique git pour les régressions de bugs récentes, Slack pour d'autres messages concernant le même bug, et même Notion pour les décisions de conception et de produit sur la façon dont une fonctionnalité devrait fonctionner : est-ce un bug, ou a-t-elle été conçue pour fonctionner ainsi ?
Après la création du ticket, un autre bot Benny le prend en charge en utilisant une autre compétence que j'ai créée appelée /orchestrate.
D'abord, il essaie de reproduire le problème par l'utilisation de l'ordinateur. Les Agents Cloud Cursor peuvent exécuter Cursor lui-même dans le cloud, où ils interagissent avec le bureau, cliquent sur des éléments et envoient des entrées clavier. En interne, cela utilise d'autres compétences que j'ai créées pour contrôler nos produits par programmation en utilisant des protocoles comme CDP ou équivalent.
Cela nous permet de démontrer si le rapport de bug peut être reproduit. S'il reproduit le bug de manière cohérente, il essaie ensuite de le corriger. S'il s'agit d'un problème de performance, Benny peut prendre des traces CPU avant et après et des instantanés du tas. Des sous-planificateurs génèrent plus de travailleurs pour vérifier la correction en utilisant les compétences pstack et en vérifiant le travail par rapport au ticket s'il a été corrigé.
Des travailleurs supplémentaires sont générés dans cette exécution pour prendre une vidéo de l'avant et de l'après, et enfin un travailleur ouvre la pull request pour révision avec la vidéo dans la description.
Tout cela est encore un travail en cours et il y a énormément de travail à faire, mais je suis enthousiaste à l'idée d'avoir une équipe d'agents pour m'aider à corriger les bugs en toute confiance pendant que je dors ou que je fais d'autres choses. Rendre la révision de code évolutive est un autre grand domaine, et je pense que Cursor aura bientôt des fonctionnalités intéressantes pour aider.
Mais la clé pour construire votre propre usine logicielle est la confiance. À moins que vous ne puissiez faire confiance à un agent pour prendre en charge un problème de bout en bout, y compris la vérification, vous ne pouvez pas automatiser vos processus. En augmentant la confiance à l'aide de plugins comme pstack qui donnent à vos agents plus de profondeur en ingénierie, vous pouvez commencer à vous attaquer à des problèmes plus ambitieux. Essayer de paralléliser des agents auxquels vous ne faites pas encore confiance est un énorme gaspillage de tokens et introduit plus de travail bâclé dans votre base de code.
Merci d'avoir lu !
