Il banco delle skill, parte 2: Skill TDD di Claude vs nessuna skill

La parte 1 di questa serie ha messo una skill contro un prompt vuoto su un compito di scaffolding ottenendo una vittoria schiacciante. La parte 2 no. Abbiamo costruito lo stesso bot Telegram due volte con Claude Sonnet, abbiamo dato a una delle esecuzioni la skill di test-driven-development con il punteggio più alto nel nostro catalogo, e la skill ha aggiunto token senza aggiungere un test significativo. Pubblichiamo questo risultato così com'è, perché un benchmark che pubblichi solo quando la skill vince non è un benchmark.

Configurazione e metodologia

Questo è N=1. Un compito, un modello, una skill, eseguita una volta per braccio. Non sono dati sufficienti per rivendicare una differenza percentuale nella qualità, e non faremo finta del contrario. Ciò per cui è sufficiente è mostrare cosa succede realmente in una singola sessione, riga per riga, cosa che la maggior parte del marketing delle skill non mostra affatto.

Il compito: costruire un bot Telegram per le attività su aiogram v3 con quattro comandi, /add, /list, /done, /delete, supportato da uno storage in memoria con scope per utente. Il brief richiedeva una chiara separazione: storage.py contenente la logica pura senza importazioni Telegram, bot.py che collega quella logica ai gestori aiogram, e test_storage.py che copre il livello di storage. Eseguire pytest finché non è verde, quindi fermarsi.

Entrambi i bracci hanno ricevuto il prompt identico, il modello identico (Claude Sonnet) e lo scaffold del repository identico da cui partire. L'unica variabile: il braccio con la skill aveva installato obra/superpowers' test-driven-development SKILL.md, la stessa skill che ha ottenuto un punteggio di 9.6 su 10 nel nostro catalogo per aver imposto un rigoroso ciclo red-green-refactor e per essersi rifiutata di lasciare che una sessione contrassegnasse il lavoro come fatto mentre un test falliva. Il braccio di base non aveva nulla installato oltre il comportamento predefinito di Claude Code. Il metodo completo su come scriptiamo e registriamo queste esecuzioni si trova in come testiamo le skill di Claude, e la rubrica di valutazione più ampia si trova alla nostra pagina della metodologia.

Cosa hanno prodotto entrambi i bracci

Entrambi i bracci hanno terminato. Entrambi hanno raggiunto un'esecuzione pytest completamente verde. Entrambi hanno prodotto la separazione in tre file richiesta dal brief, con la logica di storage isolata dal codice del gestore aiogram. In superficie, questo sembra un pareggio, e se aveste smesso di leggere a "entrambi sono diventati verdi", avreste concluso che la skill non ha fatto alcuna differenza e sareste andati avanti.

Nessuno dei due file bot.py ha fatto qualcosa di sorprendente. Ciascuno ha collegato i quattro comandi ai gestori Router e Message di aiogram, ha analizzato il testo dell'attività o l'indice dagli argomenti del comando e ha chiamato direttamente il livello di storage per il lavoro effettivo. Questo è esattamente ciò che il brief richiedeva: mantenere il file del bot snello, mantenere la logica testabile. Per quanto riguarda il cablaggio di aiogram, le due sessioni sono convergete quasi completamente, il che è di per sé un dato utile. Dove hanno diverguto è stato interamente sul lato storage, in ciò che ciascuno considerava degno di un test.

La differenza si manifesta in ciò che ogni braccio ha deciso valesse la pena testare, e nel costo per arrivarci.

I numeri

	Baseline (nessuna skill)	Skill (test-driven-development)	Delta
Token totali	48,536	52,480	+8%
Test scritti	23	13	-10
Test per percorsi di eccezione	9	5	-4
Stato finale pytest	Verde	Verde	Pareggio

Il braccio con la skill ha utilizzato più token per produrre una suite di test più piccola con meno copertura delle eccezioni. Questo è l'intero risultato. Nessun asterisco nascosto, nessun "ma se guardi la qualità del codice invece del numero di test". La sessione di base, eseguita senza alcun scaffolding di processo, ha scritto quasi il doppio dei casi di percorsi di eccezione.

Lettura delle suite di test: 23 vs 13

Il solo conteggio dei test è un segnale debole, quindi abbiamo letto entrambe le suite riga per riga invece di fidarci del numero nell'intestazione.

I 23 test della baseline coprivano i quattro comandi a livello di happy-path, poi si spingevano in casi limite che nessuno aveva chiesto esplicitamente: cosa succede quando si contrassegna come fatto un indice fuori intervallo, cosa fa un indice zero o negativo, se la lista delle attività di un utente si mescola con quella di un altro utente, e se l'eliminazione dell'elemento 2 sposta correttamente gli indici degli elementi 3 e 4 in modo che /done 3 punti ancora all'attività corretta in seguito. Quest'ultimo è il tipo di bug che sopravvive a una demo e poi si manifesta davanti a un utente reale la prima volta che elimina qualcosa dal centro di una lista. Nove dei 23 test esistevano puramente per sondare questi percorsi di eccezione.

I 13 test del braccio con la skill coprivano gli stessi quattro comandi a livello di happy-path, più cinque casi di percorsi di eccezione: principalmente indici fuori intervallo e uno scenario di aggiunta duplicata. Cosa manca rispetto alla baseline: nessun test esplicito di isolamento per utente, e nessun test che confermi il comportamento dell'indice dopo che un'eliminazione sposta la lista. La logica di storage in storage.py del braccio con la skill potrebbe benissimo gestire correttamente questi casi. Tuttavia, un comportamento corretto non testato e un comportamento corretto testato non sono la stessa affermazione, e l'intero scopo di una suite di test è colmare questa lacuna.

Nessuna delle due suite è cattiva. Tredici test con cinque casi di eccezione su un bot a quattro comandi è un punto di partenza difendibile secondo qualsiasi standard ingegneristico normale. Il confronto appare dannoso solo accanto a una baseline che, partendo da un prompt identico senza alcuno scaffolding red-green, ha scritto più test, non meno.

Perché questo non confuta il TDD

Ecco la cosa che un benchmark "one-shot" strutturalmente non può vedere: l'argomento del TDD non è mai stato "scriverai più test al primo tentativo". Riguarda ciò che accade in settimane di iterazione, attraverso la decima funzionalità aggiunta a una codebase che il modello non ha scritto da zero, nel momento in cui un ingegnere stanco (o un agente sotto pressione temporale) è tentato di rilasciare con un test rosso e risolverlo "più tardi".

Questa è un'affermazione sulla disciplina, non un'affermazione sull'output di un singolo tentativo, e questo benchmark ha eseguito esattamente un singolo tentativo. Non possiamo misurare la disciplina in una singola sessione perché la disciplina è ciò che ti impedisce di tagliare gli angoli nella sessione sei, e qui non c'è una sessione sei.

Abbiamo una traccia di come appare quella disciplina in pratica, dalle nostre note di test sulla pagina della skill test-driven-development: in una sessione di tre funzionalità, la skill si è rifiutata di saltare il ciclo red-green anche quando la correzione sembrava ovvia e la tentazione di passare direttamente al verde era lì. Ha scritto prima il test fallimentare, ha osservato che falliva per la giusta ragione, quindi ha scritto il codice minimo per superarlo, ogni volta, attraverso tutte e tre le funzionalità. Nessuno ha dovuto intervenire e dire "aspetta, scrivi prima il test". Questo è il comportamento che una skill di disciplina dovrebbe garantire, e non è lo stesso comportamento di "scrive più test in un tentativo su un modulo piccolo e ben definito".

Su un compito di queste dimensioni e così ben specificato, il giudizio di base di Claude Sonnet su cosa testare era già solido. La skill ha aggiunto un processo esplicito al giudizio che non necessitava ancora di molte correzioni, e quel processo è costato l'8% in più di token senza un corrispondente guadagno di qualità in questo particolare tentativo. Entrambe le cose possono essere vere: il TDD vale la pena di essere installato, e qui non ha aiutato.

C'è anche una spiegazione più semplice che vale la pena menzionare: scrivere un test fallimentare, osservarlo fallire, quindi scrivere il codice minimo per superarlo richiede più avanti e indietro rispetto a scrivere l'implementazione e un test per essa in un'unica passata. Quel sovraccarico è il punto della disciplina quando l'implementazione non è banale o il modello è propenso a saltare passaggi. Su un bot per le attività a quattro comandi, l'implementazione non è mai stata in dubbio, quindi il sovraccarico ha fornito un processo senza fornire un controllo su qualcosa che era effettivamente a rischio di andare storto.

Cosa significa questo se acquisti skill

La parte scomoda per noi, in particolare, è che vendiamo skill testate, e il nostro stesso banco di prova ha appena mostrato una skill con il punteggio più alto che non vince un confronto "one-shot" contro nessuna skill. Preferiamo che tu veda questo piuttosto che un "highlight reel".

Il messaggio pratico è quello di abbinare la skill al lavoro, non al punteggio. Un punteggio di catalogo di 9.6/10 significa che la skill fa ciò che dice in modo affidabile e non rompe la tua configurazione, non che vince ogni benchmark su ogni dimensione del compito. Se il tuo lavoro è un modulo piccolo e ben specificato che stai costruendo da zero, in un'unica sessione, il giudizio predefinito di un modello forte potrebbe già coprire i percorsi di eccezione che ti interessano, e una skill di processo è un sovraccarico che stai pagando senza un corrispondente vantaggio in quella sessione. Se il tuo lavoro è una codebase che toccherai per mesi, con più contributori e lunghi intervalli tra le sessioni in cui i tagli agli angoli si accumulano silenziosamente, questo è ciò che una skill di disciplina come il TDD è costruita per prevenire, e un benchmark a sessione singola non avrebbe mai catturato quel valore in primo luogo.

Le skill di velocità e le skill di disciplina rispondono a domande diverse. Leggi la descrizione di una skill per capire a quale domanda risponde prima di installarla per il lavoro sbagliato. Trattiamo come leggere quel segnale nel nostro riepilogo delle migliori skill di coding.

Riproducilo tu stesso

Il compito è abbastanza piccolo da poter essere rieseguito in un pomeriggio. Clona un progetto aiogram v3 vuoto, quindi esegui il prompt identico due volte: una volta in una sessione pulita di Claude Code, una volta con la skill test-driven-development di obra/superpowers installata. Chiedi /add /list /done /delete con storage in memoria per utente, una separazione storage.py/bot.py e una suite pytest che diventi verde prima di considerarlo fatto. Registra i token totali dal riepilogo di utilizzo di ogni sessione, quindi confronta manualmente i due file test_storage.py: conta le asserzioni e segnala specificamente qualsiasi cosa riguardi indici negativi, chiavi mancanti, isolamento per utente e spostamenti di indice dopo un'eliminazione. Queste quattro categorie sono dove abbiamo riscontrato il divario, e sono quelle che vale la pena controllare su qualsiasi app CRUD di tipo "todo" indipendentemente dalla skill che stai testando.

FAQ

Questo significa che la skill TDD è cattiva?

No. Significa che un benchmark "one-shot" su un modulo piccolo e ben specificato non è il test che mostra a cosa serve il TDD. Il valore della skill sta nel prevenire i tagli agli angoli in una sessione lunga o in un progetto lungo, cosa che questo benchmark, per sua natura, non ha eseguito abbastanza a lungo da misurare.

Perché il braccio con la skill ha scritto meno test se impone un processo più rigoroso?

Il ciclo red-green-refactor ti spinge a scrivere un test per il comportamento che stai per implementare, quindi a implementarlo, quindi a passare al comportamento successivo. Non ti spinge automaticamente a tornare indietro e aggiungere test per casi limite che nessuno ha esplicitamente richiesto, a meno che la sessione non dedichi tempo a fare brainstorming separatamente. Il braccio di base, non vincolato da un ciclo fisso, ha apparentemente dedicato più del suo output proprio a quel brainstorming.

Dovrei installare una skill TDD per Claude Code?

Se stai lavorando su una codebase a cui tornerai ripetutamente, specialmente con altri contributori o lunghi intervalli tra le sessioni, sì. È un'assicurazione contro una specifica modalità di fallimento: rilasciare silenziosamente con un test rosso perché la correzione sembrava ovvia. Quella modalità di fallimento non si manifesta in un benchmark di un singolo pomeriggio, ma si manifesta in progetti reali.

Cosa c'è dopo in questa serie?

La parte 3 de "Il banco delle skill" esamina una skill di debugging contro una caccia ai bug di un gioco snake non modificato. La parte 4 verifica uno script di automazione Google zx. Entrambi seguono la stessa regola di questo: stesso compito, stesso modello, una variabile, numeri stampati in entrambi i modi.

La serie Il banco delle skill

Parte 2 di 4. Leggi parte 1: costruzione di una landing page, parte 3: debugging di snake, e parte 4: verifica di uno script Google zx.