Il banco di prova delle skill: systematic-debugging vs. baseline

La Parte 3 del Skill Bench pone una domanda più specifica rispetto alle prime due: non "una skill è d'aiuto?", ma "una skill creata per un compito specifico supera un modello non assistito che svolge esattamente quel compito?". Il debugging è il test più pulito che abbiamo per questo, perché possiamo inserire i bug noi stessi, sapere precisamente cosa non funziona e controllare il report rispetto alla verità riga per riga.

Abbiamo quindi scritto un gioco Snake su canvas, lo abbiamo intenzionalmente rotto in tre modi specifici e abbiamo eseguito lo stesso gioco malfunzionante e la stessa segnalazione attraverso due sessioni identiche di Claude Sonnet. Una aveva la skill systematic-debugging installata. L'altra no. Stesso prompt, stesso modello, stesso bug. Solo la skill differisce.

Il risultato non è stata la vittoria netta che ci aspettavamo, ed è questa la parte che vale la pena leggere.

La trappola che abbiamo costruito

Siamo partiti da un'implementazione funzionante di Snake, quindi abbiamo intenzionalmente introdotto tre bug:

1. Vettori di direzione invertiti. ArrowUp e ArrowDown erano collegati ai vettori che si userebbero nelle normali coordinate cartesiane, non nelle coordinate del canvas, dove y aumenta verso il basso. Premi su, il serpente va giù.
2. Generazione del cibo nello spazio dei pixel invece che nello spazio della griglia. spawnFood utilizzava cv.width (400 pixel) come limite per una coordinata che avrebbe dovuto essere un indice di griglia in una griglia di 20 celle (GRID). Moltiplicando un passo della griglia per un intervallo di 400 si ottengono coordinate del cibo che atterrano fuori dal tabellone visibile circa il 95% delle volte.
3. Incremento del punteggio ad ogni tick. score++ si trovava nel ciclo di gioco principale invece che all'interno del ramo "il serpente ha mangiato il cibo", quindi il punteggio aumentava ad ogni frame indipendentemente da ciò che il serpente faceva.

Non abbiamo detto a nessuna delle due sessioni di Claude cosa non funzionasse. Abbiamo fornito a entrambi gli "arm" lo stesso bug report in stile giocatore, formulato nel modo in cui lo farebbe un tester realmente infastidito: "i controlli sembrano sbagliati, il cibo non appare mai, il punteggio aumenta da solo." Quindi abbiamo chiesto a ciascuna sessione di trovare e risolvere tutto ciò che causava questo.

Tre bug, una lamentela onesta, due Claude. Ecco cosa è emerso.

Cosa ha riportato ogni "arm"

Baseline (nessuna skill)

La sessione baseline ha analizzato il codice senza alcun metodo imposto, leggendo in sequenza il gestore degli input, il generatore di cibo e il ciclo di gioco. Ha individuato tutti e tre i bug introdotti:

• I vettori di direzione erano invertiti per l'asse y rispetto a come il rendering del canvas tratta il "basso".
• spawnFood moltiplicava cv.width dove avrebbe dovuto usare la costante della griglia, producendo coordinate in scala pixel in un gioco indicizzato per celle.
• L'incremento del punteggio si trovava al di fuori del controllo di collisione con il cibo, quindi veniva attivato incondizionatamente ad ogni frame.

Poi ha continuato a leggere e ha trovato un quarto problema che nessuno aveva introdotto: il controllo di auto-collisione confrontava la testa del serpente con la cella della coda prima che la coda fosse rimossa per quel frame. Quando il serpente si muove nel quadrato che la sua stessa coda sta lasciando, il controllo vede ancora quel quadrato come occupato e lo considera una collisione. Questo è un caso limite reale e ben noto di Snake. Esisteva nel nostro codice perché abbiamo scritto la logica di collisione prima di introdurre qualsiasi cosa, e la baseline per caso ha letto abbastanza a fondo da individuarlo.

"Arm" con skill (systematic-debugging installata)

L'"arm" con skill ha letto prima il file SKILL.md di systematic-debugging di obra/superpowers (una skill che abbiamo valutato separatamente 9.6/10 per la ricerca delle cause radice basata su ipotesi), quindi ha applicato il suo metodo: formulare un'ipotesi per ogni sintomo, testarla rispetto al codice, confermare prima di modificare qualsiasi cosa.

Ha trovato gli stessi tre bug introdotti, con un linguaggio di causa radice più conciso e preciso:

• "Inversione di direzione ricondotta alla convenzione y-down del canvas: ArrowUp mappa a {x:0,y:-1} assumendo y-up cartesiano, ma il canvas renderizza y crescente verso il basso, quindi su e giù sono scambiati."
• "La generazione del cibo utilizza un limite nello spazio dei pixel (cv.width = 400) dove il calcolo dovrebbe utilizzare un limite nello spazio della griglia (GRID = 20). Conferma tramite disallineamento delle unità: moltiplicare una frazione casuale in scala di griglia per un limite in scala di pixel posiziona circa il 95% delle generazioni fuori da canvas.width."
• "Il punteggio si incrementa incondizionatamente nel ciclo di tick invece di essere vincolato al ramo del cibo mangiato. Conferma tracciando il corpo del ciclo: score++ viene eseguito prima che il controllo di collisione venga eseguito, ad ogni frame."

Non ha trovato il quarto bug. Il problema di auto-collisione non è mai emerso, perché i sintomi riportati (controlli sbagliati, cibo mancante, punteggio fuori controllo) non indicavano la logica di collisione, e il metodo basato su ipotesi della skill rimane ancorato ai sintomi che gli sono stati forniti. Ha chiuso il report fiducioso che tutti i problemi fossero risolti, e alla lettera della lamentela, lo erano.

Il colpo di scena del quarto bug

Questo è il colpo di scena che abbiamo verificato a mano, rileggendo entrambi i diff rispetto al codice effettivo: l'"arm" con skill è stato più preciso riguardo ai bug che gli era stato chiesto di trovare, e l'"arm" baseline ha trovato un altro bug reale di cui nessuno aveva chiesto.

Questo non è un difetto di systematic-debugging come skill. Il debugging basato su ipotesi è costruito per fare esattamente ciò che ha fatto qui: prendere un sintomo segnalato, restringere a una causa testabile, confermare prima di correggere e fermarsi una volta che il sintomo è spiegato. Questa disciplina è precisamente il punto quando si è di fronte a un incidente di produzione con uno stack trace e un orologio che scorre. È anche, per costruzione, limitato ai sintomi. Non si addentra in codice che non è implicato dalla lamentela.

La sessione baseline non aveva tale ambito. Ha letto più del file di quanto fosse strettamente necessario, e leggere più del file è il modo in cui ci si imbatte in un bug che nessuno ha menzionato. L'esplorazione a ruota libera è inefficiente per sua natura, e qui l'inefficienza si è ripagata da sola.

La lettura onesta: nessuno dei due "arm" è "migliore" in generale. Un "arm" è preciso e richiede poca attenzione, ancorato a ciò che gli è stato detto. L'altro è meno focalizzato e, questa volta, abbastanza approfondito da cogliere qualcosa che il ticket non menzionava. Se il tuo bug report è completo, il report dell'"arm" con skill è quello che vuoi leggere. Se il tuo bug report potrebbe mancare di qualcosa, vuoi il secondo paio di occhi che la baseline ti ha dato gratuitamente.

I numeri

| | Baseline (nessuna skill) | "Arm" con skill (systematic-debugging) | |---| ---| ---| | Bug trovati (su 3 introdotti) | 3 / 3 | 3 / 3 | | Bug reale non introdotto trovato | Sì (collisione tail-vacate) | No | | Precisione causa radice | Corretto, meno formalizzato | Corretto, meccanismo nominato per bug | | Struttura del report | Ad hoc | Ipotesi → test → conferma, per bug | | Token utilizzati | 50,338 | 58,357 | | Delta token | — | +16% |

La skill è costata il 16% in più di token per un report che si legge meglio e individua il meccanismo con maggiore precisione, ma non ha superato una baseline a cui è stato semplicemente permesso di continuare a leggere. Questo è il risultato che non ci aspettavamo all'inizio, ed è la ragione per cui stiamo pubblicando il confronto grezzo invece di un verdetto che lusinga la skill.

Quando vuoi systematic-debugging

Il banco di prova di Snake sottovaluta il valore reale della skill, perché un gioco con bug introdotti e un file sorgente completo in vista è vicino al caso migliore per un modello non assistito: tutto ciò che è rilevante rientra in una singola lettura. Il debugging in produzione raramente è così.

Dove la ricerca delle cause radice basata su ipotesi si ripaga è il bug che si ripresenta. Nelle nostre note di catalogo su systematic-debugging, un caso di test era una race condition che Claude aveva già "risolto" tre volte separate nella stessa codebase, ogni volta applicando una patch a un'ipotesi plausibile invece della causa effettiva. La disciplina della skill (formulare l'ipotesi, progettare un test che la falsificherebbe, non toccare il codice finché il test non la conferma) è ciò che ha finalmente individuato l'interazione reale invece di produrre una quarta ipotesi. Questa è la forma di bug per cui systematic-debugging è pensato: ricorrente, elusivo, già ipotizzato tre volte, in una codebase troppo grande per essere letta da cima a fondo per capriccio.

È anche lo strumento giusto nel momento in cui stai gestendo un incidente di produzione. Hai un sintomo, un orologio che scorre e nessuna voglia che un modello si metta a leggere moduli non correlati. Limita l'ambito al report, conferma la causa, rilascia la correzione. Questa è una caratteristica, non una limitazione, esattamente in quel contesto.

Quando una scansione libera vince

Il nostro risultato su Snake sostiene anche il caso opposto: quando si sospetta che il bug report sia incompleto, o quando si sta eseguendo un passaggio pre-release piuttosto che inseguire un sintomo segnalato, una lettura non vincolata del codice fa qualcosa che un metodo basato su ipotesi strutturalmente non farà. Sta esaminando codice di cui nessuno si è ancora lamentato.

Questo è lo stesso scenario di una revisione manuale del codice rispetto a una risposta mirata a un incidente. Entrambi hanno il loro posto. L'errore è supporre che una skill di debugging sostituisca un passaggio di revisione piuttosto che affiancarlo. Se vuoi l'angolo generale del passaggio di revisione su questo, consulta la nostra opinione sul perché le skill non si attivano sempre come ti aspetti e come strutturiamo questi test.

Riproducilo tu stesso

Il banco di prova è abbastanza piccolo da poter essere ricostruito in venti minuti se vuoi verificare i nostri numeri piuttosto che prenderli per buoni. Scrivi un gioco Snake su canvas (movimento a griglia, un generatore di cibo, un contatore di punteggio, un ciclo di gioco) e introduci questi tre difetti:

1. Collega ArrowUp/ArrowDown a vettori in stile cartesiano (y: 1 per su, y: -1 per giù) invece che a vettori in stile canvas, dove l'aumento di y sposta verso il basso lo schermo.
2. Nella tua funzione di generazione del cibo, moltiplica la tua frazione casuale per la larghezza in pixel del canvas invece che per il conteggio delle celle della griglia, in modo che la coordinata risultante sia un valore in pixel trattato come un indice di griglia.
3. Sposta l'incremento del punteggio fuori dal ramo "la testa è appena atterrata sul cibo" e nel corpo incondizionato del ciclo di gioco.

Dai a una sessione di Claude solo la lamentela del giocatore ("i controlli sembrano sbagliati, il cibo non appare mai, il punteggio aumenta da solo"), mai la lista dei bug, e vedi cosa restituisce. Poi leggi la tua logica di collisione per il caso di "tail-vacate": controlla la prossima posizione della testa rispetto alla cella corrente della coda prima che la coda si muova, e vedi se è presente anche lì. La nostra lo era, senza che l'avessimo introdotto.

FAQ

La skill systematic-debugging rende Claude meno efficace nel trovare bug?

No. Ha trovato ogni bug introdotto con cause radice più precise rispetto alla baseline. Ciò che non ha fatto è superare l'ambito dei sintomi segnalati, il che ha permesso alla baseline di imbattersi in un quarto bug non introdotto. La disciplina dell'ambito è l'intento progettuale della skill, non un difetto.

Perché la baseline ha trovato un bug che la skill ha mancato?

La baseline non aveva ipotesi a cui rimanere ancorata, quindi ha letto più della codebase di quanto i sintomi segnalati richiedessero strettamente. Leggere più codice è il modo in cui si trovano cose di cui nessuno ha chiesto. È una strategia inefficiente che per caso ha dato i suoi frutti una volta, non un vantaggio generale.

Un aumento del 16% di token vale la pena per una skill di debugging?

Dipende dal bug. Per un problema ricorrente e difficile da individuare, la disciplina vale molto più del 16% in token, perché l'alternativa è Claude che indovina ripetutamente la stessa causa, come ha fatto nel nostro test di catalogo prima di applicare questa skill. Per un bug già ben definito e superficiale, il sovraccarico ti offre un report più pulito e poco altro.

Dovrei usare systematic-debugging per ogni correzione di bug?

Non per ogni bug. Usala quando un bug è ricorrente, quando un precedente tentativo di correzione non ha funzionato, o quando stai gestendo un incidente in tempo reale e hai bisogno di rimanere nell'ambito del sintomo segnalato. Per un primo passaggio su un nuovo bug report, o quando vuoi una scansione più ampia che potrebbe cogliere problemi adiacenti, una semplice sessione di debugging, o un passaggio di revisione dedicato, possono coprire terreno che la skill non coprirà. Consulta le nostre migliori skill di coding per vedere come classifichiamo le skill di debugging e review l'una contro l'altra.

---

Il Skill Bench, parte 3 di 4. Leggi gli altri confronti controllati: parte 1, la creazione della landing page, parte 2, il bot Telegram, e parte 4, l'audit di Google zx.