Superpowers: la disciplina di un genio, il conto di un junior sotto quattro Red Bull

Calma... calma! So che ti aspettavi un articolo su Superpowers, un notissimo plugin per Anthropic.

E invece no: prima di invocare qualsiasi framework agentico, dobbiamo approfondire l'identità del suo creatore, Jesse Vincent.

Te lo dico prima: non è l'evangelist dell'ultima ora salito sul carrozzone dell'intelligenza artificiale per fare qualche visual in più, ma bensì un veterano dell'open source, un costruttore di infrastrutture ostinatamente pragmatiche e concrete. Ma facciamo un po' di storia.

Chi è Jesse Vincent? E perché hai deciso di forkare una sua idea?

A metà degli anni Novanta, mentre il web muoveva i primi passi pionieristici, Vincent creò RT (Request Tracker). Nel 2001 fondò Best Practical Solutions attorno a quel progetto, trasformando un sistema di gestione ticket e issue tracking in una delle dorsali invisibili più utilizzate al mondo da università, istituzioni governative ed enti infrastrutturali. RT non cercava l'effetto speciale: faceva una cosa sola, e la faceva bene, metteva ordine dove serviva.

La sua reputazione nella comunità open source si è consolidata anche ai vertici dell'ecosistema Perl. Nel periodo critico dell'evoluzione del linguaggio, Vincent ha assunto il ruolo di pumpking, il capo ingegnere e release manager per Perl 5.12 e 5.14, imponendo una cadenza di rilasci regolare, retrocompatibilità e test rigorosi su una base di codice mastodontica.

Non contento di ottimizzare il flusso logico del software, ha deciso di intervenire perfino sulla materia fisica con cui gli sviluppatori interagiscono, co-fondando Keyboardio per progettare e produrre tastiere meccaniche ergonomiche da hacking, realizzate con telai in legno e firmware completamente personalizzabile.

Inutile dire che quando una personalità del genere scopre gli agenti LLM non lo fa con l'entusiasmo ingenuo di chi crede che l'output sia sfornato dal mago Merlino in persona, ma con il disincanto dell'ingegnere che odia il caos. Vincent ha guardato i coding agent e vi ha visto lo stesso difetto che tormenta i sistemi software da trent'anni: la mancanza di vincoli, l'assenza di metodologie verificabili e l'accumulo incontrollato di debito tecnico. La sua risposta non poteva che essere un metodo, aldilà dello strumento.

Ma ci serve un ulteriore passo indietro per farne uno ancora più grosso.

Cos'è il TDD? E perché nell'era degli LLM è ancora più importante?

Quasi una decina d'anni fa, quando ero un QA senior a capo di un piccolo team di junior e dovevo fargli mentorship, mi veniva chiesto fra i denti quale fosse l'utilità di avere un approccio TDD viste le deadline strette (un grande classico intramontabile). Lo so, "fa brutto" per uno junior scrivere il test di una classe che non esiste, vederlo fallire, scrivere un codice brutto solo per farlo passare e poi riscriverlo.

In realtà, questo approccio risolve due dei problemi più grandi della programmazione: l'ansia da foglio bianco e l'over-engineering. Ecco perché questo "giro lungo" è in realtà una scorciatoia pazzesca, sia per noi umani che per le IA.

I vantaggi per lo sviluppatore umano

Il flusso del TDD sposta il focus da "come lo implemento" a "come lo userò".

In pratica: creando il test di un componente che non esiste, ti metti nei panni del "cliente" di quel codice. Decidi come si chiamerà la funzione, quali parametri accetterà e cosa restituirà, senza farti influenzare dalle complessità dell'implementazione.

Se non vedi il test fallire almeno una volta (fase Red), non puoi essere sicuro al 100% che stia davvero testando qualcosa. Un test che passa subito potrebbe essere scritto male e non intercettare mai i futuri bug.

Separazione dei carichi cognitivi: il cervello umano fatica a fare due cose contemporaneamente, risolvere un problema logico complesso e scrivere codice pulito ed elegante (sì, potremmo scomodare Freud dicendo che il multitasking è solo un capriccio del capitalismo, ma non lo faremo qui). Nella fase Green, pensi solo a risolvere il problema, anche con codice orribile o hardcodato. Nella fase Refactor, spegni la modalità "problem-solving" e accendi quella "architetto", pulendo il codice in totale sicurezza perché hai il test che ti fa da rete di sicurezza.

L'implementazione minima ti costringe a scrivere solo il codice strettamente necessario a soddisfare il requisito attuale, lasciando da parte gli edge case a un secondo momento.

E dopo alcuni use case lo junior capiva... ma nei suoi occhi leggevo spesso "tutto molto bello, ma dovevamo consegnare ieri". Lo so: intorno al 2018, il TDD era un ideale nobile ma polarizzante, una tassa insostenibile sui tempi di consegna.

Oggi, nel 2026, lo scenario è completamente stravolto. Il TDD sta vivendo una seconda giovinezza, non perché gli sviluppatori siano diventati improvvisamente più disciplinati, ma perché il modo in cui scriviamo il codice è stato quasi del tutto demandato alla AI.

Per farla breve, nel 2018 l'obiezione principale al TDD era: "Ci metto il doppio del tempo, devo scrivere tutto due volte". C'era del vero. Scrivere prima il test e poi l'implementazione richiedeva un carico cognitivo notevole, soprattutto nella gestione del boilerplate code e dei mock.

Oggi lo sviluppatore umano deve solo concentrarsi sul definire le regole del gioco, il test. L'onere del flow passa all'harness.

E che c'entra con Superpowers di Obra?

Capisco che il post è durato fin troppo e quindi te la farò breve: il vero valore di Superpowers è impedire all'AI di comportarsi come uno sviluppatore junior sotto quattro red bull che scrive linee di codice a raffica senza pensare alle conseguenze.

Il cuore del framework è un ciclo vitale rigido in 7 fasi, dove ogni step è bloccante: l'AI non può passare al successivo se non ha soddisfatto i requisiti di quello precedente.

Il flusso operativo di Superpowers

1. 1

   Brainstorming & Allineamento

   Fase di stop e analisi

   I modelli linguistici hanno il "vizio" di iniziare a scrivere codice immediatamente. Superpowers impone un blocco software: l'agente deve dialogare con te finché non ha rimosso ogni minima ambiguità sul design e sui requisiti. Non viene toccato un solo file finché non c'è consenso totale.

2. 2

   Isolamento tramite Git Worktrees

   Configurazione dell'ambiente

   Invece di un semplice branch nella stessa cartella, il framework sfrutta i git worktree: una directory fisica separata sul disco per quel task, così il workspace principale resta immacolato.

3. 3

   Micro-Planning

   Scomposizione atomica

   L'obiettivo macro viene fatto a pezzi: l'AI redige un piano con micro-task da 2 a 5 minuti ciascuno, per prevenire il "context drift" nelle sessioni lunghe.

4. 4

   TDD Rigido

   La legge di ferro

   Red-Green-Refactor automatizzato: l'AI scrive prima il test e lo vede fallire, poi implementa il minimo indispensabile per superarlo. Se bara e scrive codice di produzione prima del test, il framework la costringe a cancellare tutto e ricominciare.

5. 5

   Subagent-Driven Development

   Delega e specializzazione

   L'orchestratore non scrive direttamente il codice finale: genera sotto-agenti effimeri con un contesto ridotto al minimo, uno scrive, un secondo indipendente convalida.

6. 6

   Revisione del codice

   Controllo di conformità

   Il codice prodotto dai sotto-agenti passa al setaccio di un audit che lo confronta con il piano approvato allo step 3. Funzioni non richieste o troppa "creatività" vengono respinte.

7. 7

   Consolidamento del branch & chiusura

   Pulizia e PR

   L'agente esegue l'intera suite di test per escludere regressioni; se tutto è verde, distrugge il worktree temporaneo, riporta i file nel branch principale e prepara la pull request.

E giusto uno showcase che non lascia spazio a dubbi. Immagina questo scenario comune: devi correggere un bug in cui un endpoint API fallisce perché manca uno slash finale nell'URL.

Scenario A: sviluppo senza Superpowers

Quando chiedi a un'AI standard (o a Claude Code) di risolvere questo problema, l'AI si comporta come un programmatore junior iperattivo.

• Azione immediata: va dritta al file di configurazione, aggiunge lo slash e risponde "Fatto! Ho corretto l'URL".
• Il problema: non ha eseguito la suite di test per vedere se quella modifica rompe le chiamate legacy. Non ha verificato se il bug dipendesse da un problema di routing più profondo.
• Il degrado: se la modifica causa un effetto domino, l'AI inizierà a scusarsi e a lanciare patch su patch nello stesso file. In pochi minuti, la finestra di contesto si riempie di tentativi falliti, l'AI inizia ad allucinare e ti ritrovi con un codebase instabile.

Scenario B: sviluppo con Superpowers

Con il framework attivo, l'approccio cambia radicalmente, trasformandosi in una procedura burocratica ultra-sicura.

• Fase 1 e 2: il comando /superpowers:brainstorm ti costringe a confermare che il problema sia solo lo slash. Subito dopo, isola il progetto in un git worktree dedicato.
• Fase 3 e 4 (TDD): l'AI non può toccare il codice di produzione. Deve prima scrivere un test d'integrazione che effettui la chiamata senza lo slash e verificare che fallisca.
• Fase 5 e 6 (Subagents): l'orchestratore non modifica il file, genera un sotto-agente isolato che applica la correzione e un secondo sotto-agente che fa la code review. Solo quando il test diventa verde, il codice viene approvato.

Ma non è tutto oro quello che brilla

Per ogni singolo micro-task, Superpowers spawna un sub-agente di esecuzione e uno di QA. Anche se configurato per delegare i compiti meccanici a modelli più economici, il volume totale di token, input più output per ogni ciclo di validazione, fa lievitare i costi. Non è una sensazione: su GitHub c'è un issue reale di un utente che ha esaurito l'intero budget di token di 5 ore del suo piano Plus (Codex) implementando un piano descritto come "relativamente semplice", un modulo Python di medie dimensioni scomposto in 20 step. Si è fermato al task 17 su 20 con i token finiti, e la tabella allegata all'issue mostra perché: solo per i primi 4 task, il framework ha già generato 17 sessioni separate tra orchestratore, implementazione e doppia revisione (spec compliance più code quality), per centinaia di KB di conversazione ciascuna.

Il problema ha anche un nome più preciso di quanto sembri a naso: manca una soglia che distingua un task piccolo e accoppiato da uno grande e scomponibile. Lo ha formalizzato per iscritto un utente in un altro issue, aperto contro la versione 6.1.1: subagent-driven-development non ha alcun criterio per decidere quando non conviene disperdere il lavoro su sotto-agenti isolati, e di conseguenza tratta un refactor di un'intera architettura e un cambio di colore su un pulsante CSS esattamente allo stesso modo, pagando in entrambi i casi il costo pieno del fan-out.

Non è solo materiale da issue tracker: la stessa domanda, "il codice che ne esce è davvero migliore, o paghi solo più ceremonia", è il punto di partenza di una recensione indipendente su YouTube, che ha costruito la stessa app Shopify due volte, una con Superpowers e una con Claude Code più planning mode, apposta per confrontare i due risultati.

Applicherà sempre e comunque lo stesso identico cerimoniale:

[Richiesta minima]
       ↓
[Brainstorming Socratico] (Obbligatorio)
       ↓
[Creazione di Git Worktree] (Obbligatorio)
       ↓
[Scrittura del Piano Atomico] (Obbligatorio)
       ↓
[Scrittura del Test TDD che fallisce] (Obbligatorio)
       ↓
[Sotto-agente 1: Scrittura codice]
       ↓
[Sotto-agente 2: Code Review]
       ↓
[Merge e Pulizia]

Per una modifica da 10 secondi su una singola riga di codice, lo sviluppatore si ritrova intrappolato in un loop di approvazioni e attese che può durare dai 3 ai 5 minuti. Questa rigidità lo rende inaccettabile per piccoli interventi quotidiani.

SIXTH SENSE: vedo i token bruciati!

Il celeberrimo film di Bruce Willis è sempre un colpo al cuore di ogni bravo millennial che si rispetti, e non sarò certo io a non citarlo (figuriamoci, a marzo sono quarant'anni).

La mia idea è semplice: Superpowers è l'ideona di un vero e proprio genio, ma non capisco perché ci siano tutti questi codici "da cerimoniale" che svalutano oscenamente l'idea.

È per questo che ho creato SIXTH SENSE, dove il dispatch di sotto-agenti paralleli avviene solo se i task sono indipendenti, complessi e voluminosi; i compiti piccoli o sequenziali vengono eseguiti direttamente in linea.

L'uso dei modelli scala con la complessità del lavoro, impiegando tier economici (haiku-batch) per modifiche minime a singolo file e riservando modelli di punta (opus-high) solo a decisioni puramente architetturali.

Le modifiche ben delimitate (Bounded) saltano le discussioni preliminari ed entrano direttamente nel ciclo red-green-refactor; parallelamente, il revisore avversariale Dylan Dog bypassa il triage formale per diff inferiori a 150 righe o su singolo file.

Gestendo, oltretutto, formidabilmente bene gli edge case.

Il framework non altera i principi cardine di Superpowers, ma ne razionalizza l'esecuzione: la complessità del processo si adatta alla dimensione del codice, evitando rigidità procedurali a prescindere dall'entità dell'intervento.

Insomma: dà quel senso pratico che "aggiusta il tiro" di un genio come Jesse Vincent.

Nella seconda parte dell'articolo vedremo nel merito che valore aggiunto porta SIXTH SENSE.

Fonti

• github.com/obra/superpowers: repository ufficiale di Superpowers, README e cartella skills/.
• Issue #1152: un utente Codex/Plus esaurisce l'intero budget di token di 5 ore su un piano di 20 step descritto come "relativamente semplice", con tabella di sessioni/dimensioni allegata.
• Issue #1917: proposta aperta contro la v6.1.1, subagent-driven-development non ha una soglia per decidere quando non conviene dispacciare a sotto-agenti isolati; tratta task piccoli e accoppiati come se fossero grandi e scomponibili.
• Superpowers + Claude Code: Full Test & Honest Review, AI Unleashed: stessa app Shopify costruita due volte, con e senza Superpowers, per confrontare i risultati.
• Jesse Vincent, Wikipedia: RT, Best Practical (2001), pumpking Perl 5.12/5.14, Keyboardio.
• github.com/dariovr1/sixth-sense: skill dispatching-parallel-agents, test-driven-development e dylan-dog, citate nel capitolo su SIXTH SENSE.