Devo togliermi un peso dallo stomaco. Prima del mio colloquio da @cursor_ai, non avevo mai usato Cursor.
Da Meta, Claude Code stava esplodendo. Ho persino pagato un abbonamento personale da 200 $ al mese per i miei progetti personali. Amavo la sua semplicità e la velocità con cui riuscivo a sentirmi produttivo. Il punto critico per me era sviluppare un mio set di competenze che trasformasse cc in quasi tutto ciò che volevo. Ho persino iniziato a sviluppare un mio strumento di orchestrazione degli agenti basato su di esso.
Durante il mio colloquio in sede, ho usato Cursor per 2 giorni, costruendo il progetto del colloquio. Questo era prima del rilascio di Cursor 3, quindi usavo la finestra dell'editor. Uso vscode da così tanti anni che la maggior parte delle scorciatoie da tastiera erano ancora nel mio contesto, quindi tornare all'IDE non è stato troppo difficile. Non posso mentire, però. Durante la prima o due ore, la CLI mi mancava sicuramente. Cliccare sulle cose sembrava quasi barbaro. Ma ci sono state alcune cose che mi hanno davvero colpito.
Innanzitutto, i modelli a cui ero abituato all'epoca - Opus e Codex - sembravano più intelligenti, in qualche modo. Ed era fantastico poter cambiare modello al volo e usarli entrambi contemporaneamente su parti diverse del mio progetto (Opus per il frontend, Codex per i sistemi). Prima del mio colloquio, parlavo già entusiasticamente della revisione avversaria multi-modello, quindi poterlo fare nativamente nell'interfaccia utente mi è sembrato molto naturale. Ancora meglio era la possibilità di generare sottoagenti di modelli diversi, così da ottenere il meglio di entrambi i mondi in una singola conversazione.
In secondo luogo, la compattazione era incredibilmente veloce. Come utente di cc, ero abituato a compattazioni che richiedevano molti minuti, quindi ero sempre in uno stato di costante vigilanza sul mio contesto e sull'utilizzo del piano. Sono rimasto totalmente scioccato dalla velocità in Cursor. Tanto che non ho mai avuto bisogno di controllare quanto contesto stessi usando. Funzionava e basta, mentre in cc spesso sentivo che il modello diventava super stupido dopo la compattazione.
E la terza cosa che ho notato è quanto le GUI possano offrire rispetto alle TUI. Poter aprire la tua app direttamente nel browser di Cursor e apportare modifiche al design con Design Mode è sembrato intuitivo e mi ha fatto riflettere su quanto le interfacce utente appositamente progettate possano rendere la codifica agentica più efficace.
Costruire Cursor con Cursor
Da quando sono entrato a fine marzo, ho lavorato principalmente sulla finestra dell'agente di Cursor 3, usandola come driver quotidiano. Sebbene pensi ancora che cc sia un prodotto interessante con un grande team, ho notato che la sua semplicità tende a spingere le persone a voler creare le proprie astrazioni che lo avvolgono. Nel mio ultimo lavoro, sembrava che ogni settimana venisse annunciato un nuovo strumento di orchestrazione interno basato su cc.
@bcherny parla molto di questa idea di "domanda latente":
"C'è un'idea molto vecchia nel prodotto chiamata domanda latente... costruisci un prodotto in modo che sia hackerabile, che sia abbastanza aperto da permettere alle persone di abusarne per altri casi d'uso. Poi osservi come le persone lo abusano e poi costruisci per quello."
Era esattamente questo! Le persone che convergono su strumenti di orchestrazione espongono la domanda latente: usare una CLI ti rende, l'umano, l'orchestratore.
Ma ogni flusso di lavoro agentico che avevo usato si concentrava sulla cosa sbagliata. Eseguire più CLI in una GUI mancava completamente il punto. L'approccio che mi interessava era costruire fiducia negli agenti.
Come ex engineering manager, ho subito capito che gestire gli agenti era simile a costruire un team di ingegneri umani. I nuovi assunti devono essere inseriti per comprendere il codebase, ma anche come si svolge il lavoro. Arrivano già pre-addestrati con le competenze acquisite dalle loro esperienze passate: come fare debug, come scrivere codice e test di alta qualità e come comunicare, solo per citarne alcune.
Gli agenti sono come nuovi assunti in uno stato costante di amnesia e stupidità. Non ricordano ciò che gli dici e non imparano mai nulla di nuovo. Ma possiamo dotarli di regole, competenze, strumenti e memoria a lungo termine che possono approssimare questo. Sono capaci ma stupidi, e molto insegnabili. E ho visto i loro modi di fallire come opportunità per insegnare loro tutto ciò che so su come fare ingegneria profonda e rigorosa.
Perché quando non c'è rigore, gli agenti faranno sì, in modo servile, tutto il necessario per scrivere quel codice che hai chiesto. E ragazzi, possono e scriveranno un sacco di codice. La parallelizzazione ingenua li fa solo scrivere schifezze più velocemente.
Se vuoi andare veloce, prima vai in profondità
Credo che l'orchestrazione degli agenti possa essere fatta in modo produttivo. Ma dobbiamo andare in profondità prima.
Sto rilasciando come open source pstack, il mio set personale di competenze e principi ingegneristici che uso ogni giorno per costruire @cursor_ai. Ho iniziato a sviluppare le prime iterazioni di queste competenze nei miei progetti personali e le ho perfezionate da allora.
Scaricalo qui: https://cursor.com/marketplace/cursor/pstack
Queste competenze sono diventate alcune delle più utilizzate dal team di Cursor, quindi sono entusiasta di condividerle con tutti voi.
pstack insegna agli agenti a essere più rigorosi usando più modelli. Ho preso tutti i modi di fallire che ho osservato e li ho trasformati in competenze. Il cuore del plugin è /poteto-mode, una competenza di ordine superiore che fornisce agli agenti il playbook giusto da seguire per un determinato compito. L'obiettivo non è il massimo delle LOC, ma l'opposto: il massimo impatto con la minima quantità di codice.
Il rigore viene applicato affrontando i problemi nello stesso modo in cui lo fanno gli ingegneri esperti. Ad esempio, un ottimo modo per affrontare il debug è la ricerca binaria nello spazio del problema. Inizi con alcune ipotesi su cosa potrebbe succedere e poi cerchi di escluderle sistematicamente finché non ti avvicini alla vera causa principale. Se è difficile da riprodurre, potresti provare a forzare sinteticamente il bug. Oppure potresti provare ad aggiungere strumentazione o log della console per controllare lo stato del programma mentre viene eseguito.
Questi passaggi formano un playbook che può essere utilizzato dagli agenti per eseguire il debug approfondito dei problemi invece di indovinare, cosa che sono felici di fare se glielo permetti. pstack viene fornito con molte competenze e playbook che ti permettono di affrontare l'ingegneria del software con lo stesso livello di rigore. Attualmente ho playbook per:
- Creazione di competenze e valutazioni
- Lavoro autonomo
- Correzione di bug e analisi forense del runtime
- Sviluppo di funzionalità
- Parità visiva e prototipazione
- E altro ancora
Ogni volta che hai bisogno di rigore, anteponi /poteto-mode al tuo prompt. Ad esempio:
Puoi anche invocare opzionalmente su richiesta le altre competenze:
- /how: vuoi una spiegazione dettagliata di come funziona effettivamente un sottosistema.
- /why: vuoi sapere perché qualcosa è stato costruito in questo modo. utilizza i tuoi MCP disponibili per interrogare ogni categoria di prove in parallelo (controllo del codice sorgente, tracciatore di problemi, documenti lunghi, chat in tempo reale, osservabilità dell'infrastruttura, tracciamento degli errori, magazzino analitico).
- /architect: stai per scrivere codice che attraversa un confine di funzione e vuoi che i tipi e le strutture dati siano definiti prima.
- /arena: vuoi N tentativi paralleli della stessa cosa, per poi prendere le parti migliori di ciascuno.
- /interrogate: vuoi che modelli diversi rivedano qualcosa in modo avversario.
- /tdd: stai correggendo un bug. scrivi prima il test fallito, poi la correzione.
- /unslop: stai ripulendo qualsiasi tipo di scrittura AI. li fa parlare in modo semplice.
- /reflect: vuoi migliorare continuamente le tue competenze dopo lunghe conversazioni.
- /figure-it-out: stai facendo qualcosa di insolito? progetta un playbook rigoroso e verificabile per il compito.
- /show-me-your-work: vuoi una traccia decisionale verificabile. registra le decisioni in un tsv che puoi committare.
E infine, puoi creare la tua competenza mode con /automate-me. Estrae le tue trascrizioni recenti, abbozza una competenza your-mode da come hai lavorato e la instrada attraverso pstack sottostante.
pstack funziona con qualsiasi strumento di codifica agentica, ma funziona particolarmente bene in strumenti multi-modello come Cursor. Molte delle competenze utilizzano flussi di lavoro multi-modello per sfruttare i punti di forza e di debolezza unici di ciascun modello. È orchestrazione di agenti, ma applicata in profondità piuttosto che in ampiezza.
Il collo di bottiglia con gli agenti è la verifica. Gli agenti possono scrivere una grande quantità di codice rapidamente. Assicurarsi che sia tutto corretto è estremamente difficile. Quando ci si arriva, la vera parallelizzazione degli agenti, come in una fabbrica oscura per il software, potrebbe essere possibile.
Ma prima, dobbiamo andare in profondità ed essere rigorosi. Penso che ci arriveremo aumentando la fiducia.
Prova pstack e fammi sapere cosa ne pensi.
Zen e l'Arte della Manutenzione del Software
Queste competenze mi aiutano a muovermi con più sicurezza quando scrivo codice. Ma mantenere il codice è ora un incubo con gli agenti che scrivono tutto il codice. Bug, problemi di prestazioni e richieste di funzionalità richiedono ancora tempo per essere risolti. E ora ce n'è così tanto!
Faccio ampio uso delle automazioni di Cursor in Cursor. Sono agenti cloud che possono essere programmati o eseguiti in risposta a eventi come nuovi messaggi in un canale Slack. Un esempio è il mio bot Benny. Gli ho dato le stesse competenze che ho in pstack.
Benny è ancora un work in progress, ma la mia visione è automatizzare il più possibile il processo di manutenzione del software. L'idea è questa: se ora abbiamo la fiducia di risolvere i problemi per lo più "al primo colpo" con pstack, con un buon grado di certezza che la qualità della PR sia alta, sicuramente possiamo automatizzare anche il feedback.
Questa fabbrica inizia la sua vita con il triage: raccogliere informazioni dai dipendenti sulle segnalazioni di bug. Usiamo molto Cursor internamente e quindi riceviamo molti feedback dai dipendenti sui nostri release candidate. Benny comprende allegati di immagini e video, esplora il codebase usando le competenze di pstack e chatta con il segnalatore per informazioni sui passaggi di riproduzione se non sono chiari.
Questa è una parte importante del processo di segnalazione dei bug. Senza chiari passaggi di riproduzione e una comprensione di cosa è rotto, gli agenti possono solo indovinare la soluzione. Dobbiamo dare loro una chiara comprensione di esattamente dove e come si rompe.
Una volta triato, Benny crea un ticket con i suoi risultati dall'analisi del codice, dalla cronologia git per recenti regressioni di bug, da Slack per altri messaggi sullo stesso bug e persino da Notion per decisioni di design e prodotto su come una funzionalità dovrebbe funzionare: è un bug o è stato progettato per funzionare in questo modo?
Dopo che il ticket è stato archiviato, un altro bot Benny lo preleva usando un'altra competenza che ho creato chiamata /orchestrate.
Prima, cerca di riprodurre il problema attraverso l'uso del computer. Cursor Cloud Agents può eseguire Cursor stesso nel cloud, dove interagiscono con il desktop, cliccano su cose e inviano input da tastiera. Internamente, questo utilizza più competenze che ho creato per controllare i nostri prodotti a livello di programmazione usando protocolli come CDP o equivalenti.
Questo ci permette di dimostrare se la segnalazione di bug può essere riprodotta. Se riproduce costantemente il bug, allora cerca di risolverlo. Se è un problema di prestazioni, Benny può prendere tracce della CPU e snapshot dell'heap prima e dopo. I subplanner generano più worker per verificare la correzione usando le competenze di pstack e controllando il lavoro rispetto al ticket se è stato risolto.
In questa esecuzione vengono generati worker aggiuntivi per registrare un video del prima e del dopo, e infine un worker apre la PR per la revisione con il video nella descrizione.
Questo è ancora tutto un work in progress e c'è un sacco di altro lavoro da fare, ma sono entusiasta di avere un team di agenti che mi aiuti a correggere i bug con sicurezza mentre dormo o faccio altre cose. Rendere la revisione del codice scalabile è un'altra grande area, e penso che Cursor avrà alcune interessanti funzionalità imminenti per aiutare.
Ma la chiave per costruire la tua fabbrica di software è la fiducia. A meno che tu non possa fidarti di un agente per gestire un problema dall'inizio alla fine, inclusa la verifica, non puoi automatizzare i tuoi processi. Man mano che aumenti la fiducia usando plugin come pstack che danno ai tuoi agenti più profondità ingegneristica, puoi iniziare ad affrontare problemi più ambiziosi. Cercare di parallelizzare agenti di cui non ti fidi ancora è un enorme spreco di token e introduce più schifezze nel tuo codebase.
Grazie per aver letto!
