pstack : les règles de Lauren Tan pour des agents dignes de confiance

La plupart d’entre nous utilisent les agents de code de la même façon : on en ouvre un, puis un deuxième, puis cinq de plus, et on passe la soirée à relire des pull requests dont on n’est pas tout à fait sûr. Lauren Tan prend le chemin inverse. Elle commence par rendre un seul agent digne de confiance, et seulement ensuite elle le multiplie. Des comptes rendus d’un live qu’elle a donné en octobre lui attribuent environ 2 500 PR fusionnées en août 2026, en précisant qu’elle n’a jamais fait de ce chiffre un objectif.

Sa méthode tient dans pstack, un plugin de skills qui tourne désormais aussi dans Grok Bot, les agents toujours actifs de xAI. J’ai lu le dépôt, les fichiers de skills et son propre guide. Voici ce que j’en retiens, en séparant clairement ce que j’ai pu vérifier de ce que je n’ai pas pu.

Qui est Lauren Tan

Lauren Tan signe poteto en ligne. Le README de pstack indique qu’elle a travaillé sur de grosses bases de code chez Meta, Netflix et Cursor, et qu’elle fait partie de l’équipe cœur de React, où elle contribue au React Compiler ; son nom figure d’ailleurs sur les annonces du compilateur sur react.dev. Des sources secondaires ajoutent qu’elle a passé environ six ans chez Meta, qu’elle en est partie en mars 2026, qu’elle a rejoint Cursor au printemps (mars ou avril selon les sources) et qu’elle travaille aujourd’hui sur l’ingénierie de Grok Bot. Un portrait la décrit comme autodidacte et fait remonter son parcours à des macros Excel. Je n’ai pas trouvé de source de première main pour ce dernier point : prenez-le comme une jolie histoire plutôt que comme un fait.

Trois idées

1. Faire confiance à un agent avant de les multiplier. Dans sa conférence, elle explique que le débit vient de la confiance, pas du nombre d’agents ouverts. Elle a commencé comme tout le monde, avec un à cinq agents, en lisant chaque conversation et en corrigeant sans arrêt. Du parallélisme sans confiance, c’est simplement plus de mauvaises PR, plus vite.

2. Corriger à la racine. Quand un agent se trompe, un rappel dans le prompt est la correction la plus faible. La skill /correct de pstack grimpe une échelle : changer l’architecture d’abord, puis les types, puis une règle de lint ou un contrôle en CI, puis un test, et la doc seulement en dernier recours. Chaque nouveau contrôle doit échouer sur l’erreur réelle d’origine. Le principe derrière s’appelle encode lessons in structure : une consigne qu’on répète doit devenir un lint, un script ou une vérification à l’exécution. Ses matinées, à l’en croire, consistent entre autres à relire l’historique des commits, à annuler ce qui cloche et à ajouter une règle de lint pour que ça ne se reproduise pas.

3. La vérification est une infrastructure. Dans The Complete Guide to pstack, elle écrit que vérifier, c’est simplement permettre à un agent de contrôler son propre travail, et qu’une bonne skill de vérification est l’outil le plus important d’une équipe. Elle propose de la traiter comme une infrastructure critique, astreinte comprise.

Ce que contient pstack

Le plugin vit dans le dépôt cursor/plugins de Cursor, sous licence MIT. Son point d’entrée, /poteto-mode, oriente chaque demande vers l’un de 23 playbooks (correction de bug, fonctionnalité, refactoring, enquête…), délègue le code à des sous-agents et refuse de déclarer un travail terminé sans preuve. La page pstack dans Grok Bot affiche 54 skills ; le total bouge à chaque version. Tel qu’affiché sur cette page :

Groupe	Skills
Pour commencer	/poteto-mode, /setup-pstack, /poteto-help
Construire	/architect, /arena, /swarm, /figure-it-out, /sharpen, /tdd, /blast-radius, /benchmark-checklist
Relire et vérifier	/interrogate, /create-verification-skill, /maintain-verification-skill, /no-comments, /correct, /reflect
Écrire et personnaliser	/unslop, /technical-writing, /typescript-best-practices, /automate-me, /make-bot-ui
Comprendre et expliquer	/how, /why, /teach, /recall, /ketchup, /bro, /in-your-own-words, /show-me-your-work

S’y ajoutent 24 principes (prove it works, fix root causes, test behavior, not implementation, subtract before you add…). La répartition par défaut des modèles, confirmée par le README, confie le code à Grok (grok-4.7 sur la page) et garde les changements les plus difficiles, la rédaction et le jugement pour Claude Opus 5.5.

Monter un bot ingénieur, étape par étape

Voici la mise en place telle que je la comprends, d’après la page pstack et la fiche de Dr Eggbot :

1. Ajouter le plugin. Dans Grok Bot, ajoutez pstack via Connect apps. Il s’applique à tout le compte, et taper / fait apparaître poteto-mode.
2. Installer Dr Eggbot. Ce bot de Lauren, disponible sur la Bot Marketplace, conçoit d’autres bots. Les bots de code suivent l’exigence du poteto-mode : une seule mission, zéro remplissage, un travail vérifié. Les autres reçoivent une mission, une voix et des anti-missions explicites, ce qu’ils ne doivent jamais faire.
3. Premier lancement. Lancez /setup-pstack, puis /create-verification-skill sur un vrai dépôt.
4. Deux bilans de santé. Dr Eggbot installe deux routines : le lundi, un audit des routines qui consomment des tokens pour rien ; en semaine, une relecture des conversations récentes pour repérer les malentendus. Les deux se taisent quand il n’y a rien à proposer.
5. Demander le bot. Connectez GitHub et Cursor, puis décrivez l’ingénieur que vous voulez. Avec mes mots :

Crée-moi un bot ingénieur pour mon dépôt.
Sa seule mission : coordonner le travail d'ingénierie, pas l'écrire.
- Confier le gros du code à des cloud agents Cursor ou à un Project Cursor, et assurer le suivi.
- Passer en /poteto-mode seulement quand la tâche exige de la rigueur :
  bug retors, refactoring, problème de perf.
- Avant de dire « terminé », exiger une preuve : un test qui échoue sur l'ancien code
  et passe sur le nouveau, plus un enregistrement avant/après.
Anti-missions :
- ne jamais écrire lui-même de gros morceaux de code
- ne jamais fusionner une pull request non vérifiée
- ne jamais déployer
S'il n'y a rien d'utile à signaler, ne rien dire.

6. Vérifier qu’il a compris. Avant de le laisser tourner, demandez au bot de vous réexpliquer sa mission (c’est le rôle de /in-your-own-words). Si son résumé dérive, corrigez la consigne maintenant, pas après dix PR.

La boucle « vérifier d’abord »

La règle que pstack impose est simple : pas de « terminé » sans preuve. Pour un bug, la preuve est un test qui échoue sur l’ancien code et passe sur le nouveau. Un test qui passe les deux fois ne prouve rien. Pour tout ce qui se voit, les cloud agents de Cursor tournent sur leur propre machine virtuelle, utilisent l’application dans un navigateur et joignent captures et vidéos à la pull request : l’agent peut donc enregistrer une vidéo avant/après. Un humain regarde ensuite la preuve, pas seulement le diff, et décide de fusionner ou non.

Étude de cas : vérification formelle des notifications

Les tests vérifient les chemins auxquels on a pensé. Certains bugs se cachent dans les enchaînements auxquels on n’a pas pensé : deux appareils, un portable en veille, un message qui arrive à la mauvaise milliseconde. C’est là qu’intervient /create-formal-verification-skill. La skill est sortie en bêta avec pstack v0.15.27, et Lauren a écrit que modéliser leur code en TLA+ avait déjà fait remonter plusieurs bugs.

TLA+ en un paragraphe. TLA+ est un langage créé par Leslie Lamport pour décrire des systèmes, surtout concurrents et distribués, avec des mathématiques simples. On décrit les états (compteur du badge, lu ou non lu, Ne pas déranger activé ou non, portable en veille ou réveillé), les actions possibles (un message arrive, on l’ouvre, on répond, le portable se réveille) et les règles qui doivent toujours tenir. Un model checker, TLC, parcourt ensuite tous les états atteignables et tous les ordres possibles des actions, dans les limites fixées, et quand une règle casse, il fournit la plus courte suite d’étapes qui y mène.

Le cas d’usage décrit autour de la skill (je n’ai pas retrouvé le récit d’origine, lisez donc les détails comme une illustration) se déroule ainsi. L’agent dessine d’abord un statechart du système de notifications : badge, état non lu, Ne pas déranger, synchronisation entre portable et téléphone. La skill en tire un kit de vérification TLA+, et le checker explore tous les entrelacements. Trois cas limites en sortent :

• une réponse comptée comme une lecture, alors que le message n’a jamais été ouvert ;
• le téléphone qui vibre en mode Ne pas déranger ;
• le portable qui affiche encore « non lu » au réveil, alors que le message a été lu sur le téléphone.

Chaque bug est corrigé, puis le modèle est revérifié. La skill laisse aussi une skill propre au projet, pour que les agents suivants relancent le contrôle à chaque changement, et /statechart traduit chaque violation en langage courant.

Ce que j’en retiens

• Commencer avec un seul agent. Rendre son travail vérifiable avant d’en ajouter un deuxième.
• Chaque correction répétée est une règle qui manque. En faire un type, un lint ou un contrôle en CI, pas une ligne de plus dans le prompt.
• Traiter la vérification comme un produit. Une skill de vérification, une carte des fonctionnalités et des enregistrements permettent de juger sur preuve au lieu de lire chaque diff.
• Donner des anti-missions aux bots. Ce qu’ils ne doivent pas faire compte autant que ce qu’ils doivent faire.
• Sortir les méthodes formelles là où l’ordre compte. Notifications, synchronisation, tout ce qui implique deux appareils : de bons candidats, à condition de rejouer les bugs sur le vrai code.

Je n’ai pas encore fait tourner pstack sur mes propres projets. Dans un prochain article, je monterai le bot ingénieur sur un vrai dépôt, j’essaierai la skill de vérification et, si elle s’y prête, un modèle TLA+, et je raconterai ce qui tient la route en pratique.

Résumé indépendant, sans lien avec Cursor ni xAI. Les chiffres et citations viennent des sources ci-dessous.