In questa serie di post, ti mostrerò come utilizzo pstack, il mio set personale di skill per svolgere un lavoro di ingegneria rigoroso. Mi ha permesso di rilasciare 2.000 PR al mese in produzione con grande affidabilità.
Personalmente, non ho mai dato molta importanza al numero di righe di codice o di PR che riuscivo a completare. Prima degli agenti, a nessuno importava, e giustamente, perché la produttività grezza non equivaleva sempre a qualità o a un risultato visibile per gli utenti. Era semplicemente una metrica di vanità.
Ma ho scoperto, nel corso della creazione di pstack, che il volume conta, specialmente quando si è in grado di mantenere o addirittura aumentare il livello di qualità del prodotto con gli agenti. Per esempio, ho iniziato a lavorare su Grok @Bot circa 2 mesi fa, quando era ancora agli inizi e il codebase era fresco ma cominciava a crescere. Nonostante il team stia crescendo e ora rilasci centinaia di PR al giorno nel codebase di Grok @Bot, pstack mi ha permesso di mantenere alta la qualità del codice per tutti, mentre monitoro costantemente il codice, rifattorizzo, aggiungo nuovi lint e controlli, e lavoro anche sulle funzionalità.
https://x.com/poteto/status/2090546476464451907
https://x.com/poteto/status/2078527882499150286
Essere il giardiniere e manutentore di Grok @Bot è qualcosa che sono riuscito a fare solo grazie a pstack. Il nostro slancio iniziale dopo aver costruito il prototipo era molto alto e molte persone si univano al team. Ho avuto un momento critico di opportunità per rifattorizzare l'intero codebase, mentre veniva costruito ed esteso e senza tempi di inattività, in qualcosa con solide fondamenta. Un codebase di alta qualità che scala indipendentemente da quanti ingegneri (e, cosa più importante, non ingegneri) vi contribuiscono. Tutto questo lavoro richiede che io rifattorizzi e migliori le fondamenta di Grok Bot mentre viene costruito, e puoi farlo solo quando le fondamenta riescono a tenere il passo con il numero di contributi.
Grok Bot è una delle app desktop AI più efficienti e performanti sul mercato
La prova è in Grok @Bot stesso. Nelle prossime settimane, ti dirò tutto ciò che devi sapere per poter costruire e mantenere un'app di alta qualità usando pstack.
Parte 1 – La verifica è tutto ciò di cui hai bisogno
La skill più critica da avere nel tuo kit è una skill di verifica di alta qualità. Questa skill è così importante da avere e mantenere che la considero più come un'infrastruttura critica piuttosto che "solo" una skill. Una buona skill amplificherà l'output dell'intero team, inclusi i non ingegneri. Se fatta bene, moltiplicherai l'output del tuo team per 100-1000x.
Se non hai familiarità con il termine, verifica significa che un agente può verificare il proprio lavoro. Può continuare fino a quando non riesce nel suo compito, perché ora può chiudere il ciclo senza che tu sia il collo di bottiglia. Se sei interessato a saperne di più sulla storia di come ho creato la mia prima skill di verifica per Cursor, dai un'occhiata al mio post precedente Loops You Can Trust.
Costruiamo insieme una skill di verifica
Per iniziare, installa pstack e poi esegui /create-verification-skill. Ti consiglio anche di aggiungere Dr Eggbot, il mio bot che ti aiuta a creare bot di alta qualità, al tuo roster. Dr Eggbot viene fornito con pstack. Insegnerà ai bot di codifica come usarlo, e può anche creare bot non di codifica con lo stesso rigore.
Puoi chiedere a Dr Eggbot di creare per te un bot ingegnere a cui poi puoi chiedere di eseguire /create-verification-skill e impostare una routine quotidiana per eseguire /maintain-verification-skill.
adoro Dr Eggbot
Mentre questo viene eseguito, esaminiamo cosa fa la skill e come crea per te una skill di verifica di alta qualità.
Ho distillato tutte le nostre skill di verifica che usiamo per costruire Grok @Bot e Cursor in questa skill come una sorta di meta-skill. Insegna al tuo agente come crearne una di alta qualità per la tua app.
Ora, qui è importante la scelta dello stack tecnologico. Se stai costruendo un'app in Electron o per il web, per esempio, puoi sfruttare i ricchi strumenti di debug disponibili per l'ecosistema JS. Ad esempio, il Chrome DevTools Protocol (CDP) ti permette di usare gli stessi strumenti disponibili negli strumenti di sviluppo del tuo browser. Oppure, se stai costruendo un'app iOS, usando il simulatore.
Idealmente, vuoi la capacità di interagire con la tua app, eseguirne il debug, fare tracce di performance e qualsiasi altro strumento di debug e sviluppo che useresti normalmente se stessi sviluppando l'app a mano. Se non hai un runtime ricco da utilizzare, potresti aver bisogno di chiedere al tuo agente di creare strumenti per te (ad esempio usando lldb, o un pacchetto personalizzato che funge da sidecar negli ambienti di sviluppo), o semplicemente usare ciò che hai a disposizione.
Personalmente, ritengo che la verifica agentica sia così importante che suggerirei senza ironia di costruire i tuoi ricchi strumenti di debug, o persino di scegliere uno stack tecnologico diverso, per avere vantaggi sleali e produttività estrema nella creazione di software. Come ho detto prima, dare agli agenti la capacità di verificare il proprio lavoro sblocca chiunque nella tua organizzazione per poter contribuire e convalidare che le loro modifiche funzionino effettivamente. Più il tuo stack tecnologico è difficile da debuggare e controllare, più sarà difficile usare gli agenti in modo produttivo.
Rendilo Riproducibile
In pstack, abbiamo un principio chiamato "Build the Lever". Ciò che significa nel contesto della creazione di una skill, è che preferiamo dare agli agenti strumenti piuttosto che solo markdown. Per le skill di verifica, questo significa creare una piccola CLI che scripta l'interazione e il debug della tua app in una utility piccola e adatta agli agenti. Ciò significa che gli agenti consumano meno token cercando di svolgere un compito (eseguire un comando CLI invece di scrivere uno script usa e getta per cliccare su qualcosa), e rende la tua skill di verifica più riproducibile e testabile.
Ecco un esempio ipotetico di una CLI che il tuo agente potrebbe creare per un'app Electron:
1# health2node .cursor/skills/verify-atlas/control-atlas.mjs doctor34# open a blank thread and send5node .cursor/skills/verify-atlas/control-atlas.mjs new-session6node .cursor/skills/verify-atlas/control-atlas.mjs send "list open tasks in this project"78# keyboard path9node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+KeyN"1011# accessibility snapshot of the live UI12node .cursor/skills/verify-atlas/control-atlas.mjs snapshot1314# screenshot for evidence15node .cursor/skills/verify-atlas/control-atlas.mjs screenshot /tmp/atlas-proof.png1617# wait for streaming / layout to settle18node .cursor/skills/verify-atlas/control-atlas.mjs wait-settle1920# flip a feature flag for the session21node .cursor/skills/verify-atlas/control-atlas.mjs feature-flag rooms_v2 on
Ora, tutti gli agenti possono usare questa CLI per navigare rapidamente e fare debug della tua app. Dovrai anche iniziare a pensare all'esperienza di sviluppo della tua app:
- seedare un database di sviluppo
- come gestire l'autenticazione, gli utenti di test, le chiamate API contro un ambiente di test/staging
- installare e avviare il tuo ambiente di sviluppo in modo coerente
Tutte queste sono cose a cui probabilmente hai già dovuto pensare quando scrivevi codice tu stesso. Quindi pensa a questa come all'utility principale dei tuoi agenti per fare lavoro di sviluppo sulla tua app. Mantienila ben curata e testata!
Ecco alcuni altri comandi di esempio che potresti voler considerare:
1- **Ispezione:** `info`, `snapshot`, `screenshot`, `components`2- **Navigazione:** `home`, `new-session`, `select-project`, `select-runtime`, `scroll`3- **Interazione:** `send`, `click`, `click-xy`, `aria-click`, `type`, `press`, `eval`, `upload-image`, `add-context`, `feature-flag`4- **Performance:** `trace`, `profile`, `record`, `perf-metrics`, `wait-settle`5- **Streaming:** `console`, `network-log`, `network-summary`6- **Salute e pulizia:** `doctor`, `cleanup`, `watch --restart`
Una volta che hai questa configurazione di base, dovresti già iniziare a vedere un grande miglioramento nei tuoi agenti. Dovrebbero essere in grado di navigare e fare debug della tua app con facilità.
Ti consiglio di dedicare del tempo qui per rendere questa CLI buona e priva di errori prima di fare qualsiasi cosa più avanzata. Dovrai anche pensare (o chiedere al tuo agente) di progettare una CLI adatta agli agenti. Ci sono molte risorse online a cui puoi indirizzare il tuo agente, ma le proprietà chiave che mi piacciono sono:
- l'API è facile da comporre - pensa alla filosofia dei moduli profondi di John Ousterhout
- qualsiasi comando con potenziali effetti collaterali distruttivi dovrebbe avere un'opzione --dry-run
- usa i sottocomandi per rivelare gradualmente le funzionalità piuttosto che tutte in una volta
- i messaggi di errore dovrebbero essere molto descrittivi e dire all'agente cosa dovrebbe fare invece
- testo --help ricco
- output restituiti in forma leggibile dalla macchina (es. JSON)
Vai più veloce con il parallelismo usando Cloud Agents invece dei worktree
Quando hai avuto un po' di successo nell'eseguire la tua skill di verifica per rilasciare qualche PR, potresti iniziare a chiederti se puoi parallelizzare di più. Per esempio, se un agente ora può prendere il tuo prompt e portarlo per lo più a uno stato unibile, non ti libera forse per eseguire più agenti?
Il tuo primo istinto sarà quello di aggiungere il supporto per i worktree, il che significa che i tuoi agenti possono usare git per creare una copia tracciata del repo dove possono fare modifiche in isolamento rispetto al checkout principale. In teoria, questo ti permette di eseguire più agenti contemporaneamente senza che le loro modifiche si sovrascrivano a vicenda.
Ti consiglierei di non farlo. Per prima cosa, usa molto spazio di archiviazione e risorse sulla tua macchina. Potresti riuscire a eseguire fino a 10 agenti in parallelo con i worktree a seconda della dimensione del tuo repo e di quanto è potente la tua macchina. Ma c'è un modo molto migliore!
I cloud agents di Cursor sono agenti che vengono eseguiti nel cloud, sull'infrastruttura di Cursor. Questi agenti hanno accesso a un computer reale, il che significa che possono installare dipendenze, eseguire la tua app, fare video e screenshot, e interagire con la tua app come farebbe un utente reale. Se hai investito abbastanza nel passaggio precedente per rendere buona la tua esperienza di sviluppo, non dovrebbe essere un grande sforzo riuscire a configurare i cloud agent. Quando configuri per la prima volta il tuo ambiente cloud, inviamo un agente per aiutarti a configurarlo e farlo funzionare correttamente. Dopo la prima build, prendiamo uno snapshot il che significa che le successive esecuzioni del cloud agent partono sempre rapidamente.
Consiglio vivamente di prendersi il tempo per configurare i cloud agent, poiché sblocca un enorme aumento di produttività nel parallelismo. In un post successivo ti mostrerò come eseguire centinaia di subagenti in parallelo nel cloud! Ma per ora, configura il tuo ambiente e portalo in uno stato in cui puoi iniziare a sentirti sicuro di eseguire tutti i tuoi agenti nel cloud.
Mantieni gli agenti intelligenti con le Feature Map
Man mano che la tua app diventa più complessa, gli agenti hanno bisogno di più indicazioni per essere in grado di trovare le funzionalità e interagire con esse. Per fare questo, ho ideato qualcosa che chiamo Feature Map. Come suggerisce il nome, è una mappa facilmente ricercabile di tutte le funzionalità disponibili nella tua app, cosa fa e come arrivarci dal punto di vista dell'utente.
Ecco una Feature Map di esempio che ho preparato per un'app fittizia chiamata Atlas. Sono solo un paio di file markdown menzionati nel SKILL.md della verifica.
Puoi mettere questo file ovunque, ma in /create-verification-skill creiamo automaticamente una directory references/features insieme a un README.md. Il readme è la mappa stessa: una panoramica di alto livello di tutte le principali funzionalità disponibili, con collegamenti a dettagli specifici. Una funzionalità di esempio assomiglia a questo:
1# Preferenze23Overlay delle preferenze a schermo intero e il suo set di schede.45## Sotto-funzionalità67- settings-overlay: overlay a schermo intero aperto dall'ingranaggio o Cmd/Ctrl+,8- settings-nav: navigazione a sinistra delle schede (Generale, Aspetto, Modelli, Piano e Utilizzo, ...).9- settings-search: ricerca nell'overlay (Cmd/Ctrl+K mentre le impostazioni sono aperte).10- theme-picker: controllo rapido del tema su Aspetto.1112## Come arrivarci (dal punto di vista dell'utente)1314Clicca sull'ingranaggio accanto all'avatar dell'account, o premi Cmd/Ctrl+,. Scegli una scheda dalla navigazione a sinistra. Digita nella casella di ricerca delle preferenze per saltare. Escape o il controllo di chiusura lo chiude.1516## Guidarlo con control-atlas1718bash19node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+Comma"20node .cursor/skills/verify-atlas/control-atlas.mjs snapshot21node .cursor/skills/verify-atlas/control-atlas.mjs press "Escape"2223- Radice dell'overlay: cerca un dialog/regione chiamato Preferenze nell'albero a11y.24- Schede: clicca per nome visibile. Piano e Utilizzo potrebbe essere assente per alcuni stati dell'account.25- Mentre le impostazioni sono aperte, Cmd/Ctrl+K è la ricerca delle preferenze, non la tavolozza globale (vedi `multi-surface-journeys.md`).2627## Insidie2829- Chiudere le impostazioni a metà suite può lasciare il focus in un punto inutile. `new-session` o `home` recuperano.30- Alcune schede sono bloccate da entitlement. Salta con un motivo esplicito dell'account.
Non preoccuparti di scriverli tu stesso! Quando esegui /create-verification-skill, il tuo agente esaminerà automaticamente la tua app e catalogherà tutto e creerà questi riferimenti per te.
La Feature Map, quando combinata con la CLI, è uno dei motivi principali per cui le skill di verifica di pstack sono così buone. Gli agenti ora hanno contesto su ogni singola funzionalità e su come arrivarci, risparmiando preziosi token nella loro finestra di contesto e insegnando loro esattamente a cosa serve e come arrivarci.
Puoi pensare alla Feature Map come una forma di "memoria materializzata". Se usi gli agenti da un po', probabilmente hai familiarità con il concetto di memoria - tipicamente queste potrebbero essere memorizzate come semplici file markdown (es. un vault Obsidian), o anche qualcosa di più complesso come un database vettoriale. Personalmente, penso che il tuo codebase sia la forma ultima di memoria. Il codice è una proiezione delle decisioni che tu e il tuo team avete preso e rappresenta la fonte di verità su ciò che è successo e come funzionano effettivamente le cose. Una Feature Map è solo una forma più compatta di questo, progettata per risparmiare token. E poiché è solo markdown all'interno di una skill, tutti coloro che contribuiscono al tuo codebase beneficiano di questa memoria condivisa.
Ciò significa che mantenere la skill di verifica è molto importante. Ti consiglio di eseguire /maintain-verification-skill almeno una volta al giorno per assicurarti che i tuoi agenti abbiano sempre i dettagli più recenti sul controllo della tua app. Potresti anche scoprire, man mano che usi di più la tua skill di verifica, che gli agenti le aggiorneranno automaticamente mentre lavorano sulla tua app. /maintain-verification-skill cattura tutto ciò che viene perso.
Come usare la tua skill di verifica
Per riferimento, ecco una skill di verifica di esempio creata per un'app fittizia: https://github.com/poteto/verification-skill-example. Come promemoria, esegui /create-verification-skill per crearne una, che include una CLI di base e una Feature Map.
Ecco come la uso tipicamente con pstack.
Prima di tutto, ovviamente, è iniziare il tuo prompt con /poteto-mode. Se stai usando pstack tramite Cursor, puoi anche premere Opt + Invio invece di solo Invio quando autocompleti /poteto-mode - questo aggiunge la skill come Custom Mode, che fissa la skill in modo che il tuo agente riceva un promemoria per usare la skill ad ogni nuovo turno.
Digita /poteto-mode e premi Opt + Invio per fissarlo come Custom Mode
In Grok @Bot, installa il plugin, poi digita /poteto-mode.
Puoi usare pstack anche in Grok Bot!
Esempio: Costruire nuove funzionalità
Per costruire nuove funzionalità, uso tipicamente la skill di verifica insieme a /poteto-mode per far sì che l'agente verifichi il suo lavoro. Per esempio, potrei dare un prompt come:
/poteto-mode build <descrizione della funzionalità, qualsiasi contesto utile>. usa /control-app per verificare le tue modifiche e mostrami un video e screenshot come prova
Con /control-app che è il risultato di /create-verification-skill. In Grok @Bot, darei un prompt come:
spawna un cloud agent per usare /poteto-mode per buildare <descrizione della funzionalità, qualsiasi contesto utile>. usa /control-app per verificare le tue modifiche e mostrami un video e screenshot come prova
La piccola differenza qui è che in Grok @Bot dici al tuo bot di spawnare un cloud agent invece di fare il lavoro da solo. Il motivo principale per cui preferisco farlo è che libera il tuo bot per fare altre cose e mantiene pulita la sua finestra di contesto. In questo senso, penso ai miei bot più come coordinatori che gestiscono e supervisionano i cloud agent. I cloud agent significano anche che puoi sfruttare l'intera gamma di modelli disponibili in Cursor che hanno la propria macchina separata, quindi il computer del tuo bot rimane libero per altre cose.
Esempio: Lavoro sulle performance
spawna un cloud agent per usare /poteto-mode per migliorare il tempo di caricamento iniziale della nostra app. prima usa /control-app per fare una traccia dello status quo e identificare opportunità di miglioramento. poi fai una correzione mirata e usa /control-app +
/swarm per confermare il miglioramento
/swarm è una delle migliori skill da combinare con la tua skill di verifica. Distribuisce un numero qualsiasi di cloud agent per eseguire la tua skill di verifica, così puoi fare cose come confermare un miglioramento delle performance con una dimensione del campione sufficiente, o fare fuzz testing della tua app per assicurarti di non aver rotto o regredito nulla.
Esempio: Riprodurre automaticamente i report degli utenti
Quando sei soddisfatto della tua skill di verifica, puoi inserirli all'interno delle routine di Grok @Bot, o Cursor Automations. Le routine e le automazioni ti permettono di eseguire cose su pianificazione, o attivare quando si verifica un evento.
Per esempio, se inserisci il feedback degli utenti in Slack, e/o hai il tuo canale di feedback interno, puoi far sì che i tuoi bot ascoltino ogni report e provino automaticamente a riprodurli con un cloud agent. Se la tua skill di verifica e la Feature Map sono abbastanza buone, potresti persino decidere di auto-correggere anche i problemi.
C'è una ragione per cui ho detto prima che la verifica è una delle skill più importanti nel tuo kit. Ti dà una base su cui costruire nuove skill e routine. E, cosa più importante, tutto il tuo team ne trae beneficio.
Investi nella tua skill di verifica
Una volta creata la tua skill di verifica, mantienila affilata con /maintain-verification-skill. Continua a migliorare la CLI e investi nella skill come faresti con un'infrastruttura critica. Potresti persino voler mettere una rotazione di reperibilità su di essa - ecco quanto è importante per sbloccare una produttività 100-1000x per il tuo team.
Questa skill è la base per molte altre skill che tratteremo nella guida pstack, e si compone magnificamente con tutte loro.
- pstack: https://x.ai/bot/plugin/9717366 (link github
- Dr Eggbot: https://x.ai/bot/93gOz3op1UQdBdbekQFLK
Ti consiglio di aggiungere Dr Eggbot, il mio bot che ti aiuta a creare bot di alta qualità, al tuo roster. Dr Eggbot viene fornito con pstack. Insegnerà ai bot di codifica come usarlo, e può anche creare bot non di codifica con lo stesso rigore.
Puoi chiedere a Dr Eggbot di creare per te un bot ingegnere a cui poi puoi chiedere di eseguire /create-verification-skill e impostare una routine quotidiana per eseguire /maintain-verification-skill.
Grazie per aver letto e resta sintonizzato per la Parte 2!
