Se hai mai visto un agente cercare di correggere un bug, l'hai visto indovinare. Legge il codice, elabora una teoria, fa una modifica e spera. A volte ha ragione. Spesso ottieni una correzione che sembra sicura di sé ma nasconde silenziosamente il vero bug.
La Modalità Debug è ciò che abbiamo costruito per questo. Invece di starsene lì a ragionare sul codice, l'agente va a cercare prove su cosa fa il codice quando viene eseguito.
Ecco il ciclo:
- L'agente formula più ipotesi e inizia a lavorare prima su quella più plausibile.
- Quindi, viene aggiunto un logging per testare un'ipotesi (senza toccare l'implementazione).
- Un piccolo server di debug raccoglie l'output di runtime in .cursor/debug.log mentre il tuo programma viene eseguito.
- Riproduci il bug e l'agente può ora leggere i log e capire cosa è successo, invece di dover indovinare.
- Cursor trova la causa principale nei log, applica la correzione e rimuove il logging che aveva aggiunto.
Ecco come funziona su un bug reale, accelerato a circa un minuto:
Come lo usa il team
Alcune cose interessanti che abbiamo risolto internamente con la modalità debug:
- Una race condition che si verificava 1 volta su 20 esecuzioni. Corrompeva i metadati di git nelle nostre esecuzioni best-of-N. La Modalità Debug l'ha individuata in meno di un'ora.
- Un memory leak, tracciato in un unico passaggio. Era dovuto a un uso scorretto del nostro framework frontend. La correzione è stata una singola riga.
- Un crash nativo in profondità nel C++. Un crash di Electron che le persone di solito aggiravano. I log lo hanno reso individuabile.
- Un flicker SSR che era stato abbandonato. Un bug di rendering che nessuno voleva toccare, risolto una volta che l'agente ha potuto vedere cosa stava facendo la pagina in fase di runtime.
Provalo con Shift+Tab (è disponibile anche nella CLI, tramite /debug).
Sono sicuro che le persone lo stiano usando in modi a cui non ho pensato, quindi fatemi sapere!
