Claude Code e lo sviluppo di software

Vi riporto senza commenti questo thread su Perplexity. È un po' lungo, ma secondo me molto interessante.

apr 15, 2026

Mio prompt per Perplexity Pro: Quali funzionalità sono offerte da Superpowers per Claude?

Superpowers è un framework open-source agentico con oltre 139.000 stelle su GitHub e incluso ufficialmente nel marketplace Anthropic dal 15 gennaio 2026. Nella sua versione attuale (5.0.7), supporta nativamente più piattaforme: Claude Code, Cursor, Gemini CLI, GitHub Copilot CLI, Codex e OpenCode. Il principio di base è che le skill si attivano automaticamente — non sono suggerimenti opzionali, ma flussi di lavoro obbligatori

Mio prompt: Come indico quel che deve fare l’app da creare?

Ci sono tre modi per indicare a Superpowers cosa deve fare la tua app, dal più semplice al più strutturato:
Modo 1: Descrizione libera nel brainstorm
Il metodo più naturale è lanciare il brainstorm con una frase descrittiva in linguaggio normale :
/superpowers:brainstorm Voglio creare una web app ispirata a Notion
con editor di testo ricco, tabelle interattive e Kanban drag-and-drop.
Deve essere responsive e supportare la persistenza dei dati.
Da lì, Superpowers fa da solo: pone domande una alla volta per raffinare i dettagli — stack tecnologico, autenticazione, database, deployment. Non devi anticipare tutto, basta l’idea di partenza .
Modo 2: Descrizione con vincoli già definiti
Se hai già delle preferenze tecniche, puoi includerle nel prompt iniziale per ridurre le domande :
/superpowers:brainstorm Voglio costruire un prototipo per <descrizione problema>.
Aiutami a chiarire i vincoli e i requisiti esatti.
Stack: Next.js + Supabase. Autenticazione con OAuth Google.
Superpowers userà il contesto già fornito e salterà le domande ovvie, concentrandosi sui punti ancora aperti .
Modo 3: Conversazione informale (senza slash command)
Non è nemmeno necessario ricordare i comandi esatti: puoi parlare normalmente :
Usa Superpowers per aiutarmi a fare brainstorming su questa funzione
Le skill si attivano anche conversazionalmente — non appena Claude capisce che stai descrivendo qualcosa da costruire, la skill di brainstorming parte automaticamente .
Cosa succede dopo
Una volta che approvi il design emerso dal dialogo, Superpowers passa automaticamente alla fase di pianificazione senza bisogno di altri input . Il piano generato è pensato per essere “chiaro abbastanza da poter essere seguito da un junior engineer senza contesto di progetto” — quindi più sei preciso nella fase di brainstorming, più il piano sarà accurato.

Mio prompt: Ma una frase come quelle che mi hai mostrato non è un requisito, sono goal generici.

Hai centrato un punto fondamentale. Il brainstorming è esattamente il meccanismo per trasformare un goal generico in una spec concreta — non ti viene chiesto di arrivare già con i requisiti scritti. Ecco come funziona nella pratica:
Il tuo compito: dare solo il “perché”
Tu dici a Superpowers cosa vuoi ottenere, non come farlo :
Voglio un'app per tracciare le spese del team
Questo è sufficiente per avviare il processo. Superpowers non si aspetta un documento di requisiti .
Il lavoro di Superpowers: estrarre la spec con domande
La skill di brainstorming usa domande socratiche per “tirare fuori” i requisiti dalla conversazione . Per esempio, dopo il tuo goal generico, Claude potrebbe chiedere:
“Chi usa l’app — solo tu o tutto il team?”
“Le spese devono essere approvate da qualcuno?”
“Serve integrazione con strumenti come Notion o Slack?”
“Vuoi categorie fisse o personalizzabili?”
Una domanda alla volta, non un interrogatorio lungo . Dopo ogni risposta, affina la comprensione e va più in profondità.
Il risultato: un design document vero
Solo dopo questo dialogo, Superpowers produce un documento strutturato con :
requisiti funzionali precisi
scelte architetturali motivate
edge case considerati
stack tecnologico definito
Lo mostra a sezioni per farti validare o correggere prima di procedere . Solo dopo la tua approvazione esplicita si passa alla pianificazione.
[…]
Il principio di fondo è che Claude "tease a spec out of the conversation" — la spec emerge dal dialogo, non deve esistere prima.

Mio prompt: Un'applicazione che non sia un esperimento scolastico ha requisiti che di solito richiedono almeno qualche centinaio di pagine di testo o spesso di requisiti strutturati tipo UML. Come può l'utente scrivere qualche frase e far sì che Claude esegua?

La tua osservazione è corretta e la risposta onesta è: Superpowers non è adatto per sviluppare software enterprise reale con requisiti complessi. È un tool per un target specifico, e il marketing spesso oscura questo fatto.
Il target reale di Superpowers
Superpowers è progettato esplicitamente per prototipi, MVP, tool interni e side project . Lo stesso autore del plugin lo usa per costruire funzionalità su app personali in poche ore . Il “brainstorm socratico” che estrae i requisiti con domande funziona solo quando il dominio è sufficientemente semplice da essere esplorato in una conversazione.
I limiti strutturali con sistemi complessi
Per un’applicazione enterprise reale, gli strumenti AI come Claude Code (con o senza Superpowers) hanno limiti architetturali ben documentati :
Context window insufficiente: molti agent non riescono a gestire repository con più di 2.500 file, e ignorano completamente file oltre 500KB . I sistemi enterprise con decenni di business logic superano questi limiti banalmente.
“Capiscono snippet, non sistemi”: gli agent AI generano codice che funziona in isolamento, ma collassano quando devono integrare legacy systems, RBAC, CI/CD pipeline, autenticazione enterprise .
Nessuna memoria architetturale tra sessioni: ogni sessione riparte da zero. I pattern architetturali definiti ieri non vengono applicati automaticamente domani .
Debito tecnico accelerato: il codice generato ottimizza per “far funzionare il demo”, non per manutenibilità, con naming inconsistente, error handling casuale e duplicazioni dell’ordine dell’8x .
Il gap tra spec e realtà
Hai ragione che un’applicazione non scolastica richiede centinaia di pagine di requisiti. Quel corpus non può essere sostituito da una conversazione di brainstorming perché :
Include logica di business accumulata in anni che nessun dialogo riesce a ricostruire
Definisce vincoli non funzionali (performance, sicurezza, compliance, SLA) che gli agent ignorano sistematicamente
Richiede decisioni architetturali trasversali che un agent senza memoria persistente non può mantenere coerenti
Presuppone conoscenza del contesto organizzativo (processi, utenti, integrazioni esistenti) che non è comunicabile in poche frasi
Cosa Superpowers fa davvero bene
Il valore reale di Superpowers è come acceleratore per sviluppatori esperti su task ben circoscritti : automatizzare una pipeline, costruire un componente UI, aggiungere una feature isolata a un sistema esistente. In quel contesto, il piano a task da 2–5 minuti con TDD ha senso. Per un sistema enterprise, invece, serve ancora un team di ingegneri che scriva le spec, progettisca l’architettura e usi l’AI come assistente — non come sostituto del processo ingegneristico .

Mio prompt: Ci sono framework più potenti di Superpowers?

Sì, esistono due framework comparabili a Superpowers — GSD e GSTACK — che risolvono problemi diversi. Eccoli a confronto, con una lettura onesta dei limiti di ciascuno.
GSD — Get Shit Done
Creato da Lex Christopherson, GSD attacca il problema del context rot: il fenomeno per cui dopo 200K token l’agente dimentica le istruzioni iniziali . La soluzione architetturale è radicale: ogni fase ha il proprio orchestratore separato, che scrive il proprio stato su disco in XML strutturato e poi si spegne . La fase successiva parte con un context window completamente fresco. Include quality gate che rilevano deriva dallo scope e tagli non autorizzati al piano . È il framework più adatto per sessioni lunghissime che durano giorni o settimane con molti file coinvolti .
GSTACK — di Garry Tan (CEO di Y Combinator)
GSTACK non disciplina un singolo agente, ma simula un team di 23 persone: CEO, product manager, lead ingegnere, QA, security officer, designer . Ogni ruolo vede solo il contesto necessario al proprio lavoro — l’ingegnere non vede il roadmap prodotto, il QA non vede i dettagli implementativi . Il principio chiave è il cosiddetto “boil the lake”: ogni ruolo fa perfettamente le poche cose di sua competenza invece di fare tutto in modo mediocre . Include testing reale con Playwright, audit OWASP/STRIDE e review strategica pre-codice. È pensato per founder-engineer che costruiscono un prodotto, non per chi fa pura infrastruttura .
Come scegliere
L’analisi di Pulumi è diretta: la scelta dipende dal tuo specifico failure mode :
Il codice funziona oggi e si rompe domani → Superpowers (TDD obbligatorio)
La qualità cala dopo la prima ora → GSD (context fresco per ogni fase)
Spedisci funzionalità che nessuno ha chiesto → GSTACK (review prodotto prima del codice)
Tutti e tre i problemi insieme → GSTACK per la direzione + Superpowers per il TDD
Però il problema fondamentale rimane
Nessuno dei tre risolve il limite che hai sollevato prima: nessun framework riesce a gestire requisiti enterprise complessi partendo da una frase generica. GSD e GSTACK aggiungono governance e memoria persistente, ma presuppongono comunque che lo scope sia abbastanza delimitato da essere gestito in una sessione o in poche fasi . Per sistemi reali a larga scala, restano strumenti per sviluppatori esperti su task circoscritti, non sostituti del processo ingegneristico tradizionale .

Ho fatto fare a Claude il fact-check su quanto scritto da Perplexity.

Giudizio finale: Il post è utile e informativamente onesto nel messaggio di fondo, ma Perplexity ha introdotto diversi errori tipici dei LLM: numeri specifici non documentati (139k stelle, 8x duplicazioni, 2.500 file, 500KB), un'imprecisione concettuale seria (il context rot a "200K token"), un'informazione errata (XML per GSD) e una confusione di categoria (23 comandi ≠ 23 persone). Prima di pubblicare ti consiglio di correggere questi punti.

Mio prompt a Claude: Come giudichi le conclusioni di carattere generale sulle potenzialità di questi framework?

È una domanda interessante, e vale la pena risponderci con franchezza — anche perché le conclusioni del post toccano un dibattito reale nel campo dell’ingegneria del software.
Cosa regge bene. La tesi centrale — che questi framework non sostituiscono il processo ingegneristico su sistemi complessi — è corretta e importante. Il post ha il merito di dirlo chiaramente in un momento in cui il marketing del settore tende a oscurarlo. L’osservazione che il brainstorming socratico funziona solo quando il dominio è abbastanza semplice da essere esplorato in una conversazione è precisa. Così come il rilievo sulla mancanza di memoria architetturale tra sessioni, che è un limite strutturale reale e non banalmente superabile.
Dove le conclusioni sono troppo nette. Il post tratta la distinzione “prototipo vs. enterprise” come se fosse binaria e stabile, ma non lo è per due ragioni che un ingegnere del software dovrebbe considerare.
La prima è che i sistemi enterprise moderni sono raramente monoliti. Sono composizioni di servizi, moduli, componenti con confini relativamente definiti. E proprio su quei confini — una nuova feature, un microservizio isolato, un componente UI — questi framework producono valore concreto anche in produzione. Dire che “non sono adatti per sistemi enterprise” senza questa qualificazione è impreciso.
La seconda è che il limite non è solo nel framework, è nella skill di chi lo usa. Un ingegnere senior sa decomporre un requisito complesso in task circoscritti su cui Superpowers o GSD operano bene. Il framework non risolve il problema della requirements engineering, ma non ci prova nemmeno — opera a valle di essa. Il post tende a presentare questo come un difetto dei framework, mentre è semplicemente il loro scope corretto.
La lacuna più rilevante. Il post non discute quello che è probabilmente il cambiamento più importante che questi strumenti stanno introducendo: non sostituiscono il processo ingegneristico, ma spostano dove il valore umano è necessario. Il lavoro di programmazione meccanica si automatizza; il lavoro di thinking — capire il dominio, definire i confini, valutare i trade-off architetturali — diventa più critico, non meno. Questa riflessione mancava e avrebbe reso le conclusioni molto più interessanti.
Un punto di attenzione metodologico. C’è un rischio nella struttura dell’articolo che vale la pena nominare: la parte che risponde alla domanda sui limiti enterprise è quasi interamente generata da Perplexity sulla base di affermazioni comuni nel discorso pubblico sull’AI coding — “context window insufficiente”, “nessuna memoria architetturale”, “debito tecnico accelerato” — ma senza fonti primarie verificabili e con almeno un dato inventato (l’8x). Queste affermazioni sono plausibili e in parte vere, ma la loro presentazione come dati documentati è problematica. Come software engineering professor, un lettore esperto noterebbe l’assenza di citazioni a ricerche empiriche.
In sintesi: le conclusioni sono sostanzialmente condivisibili nel messaggio, ma sarebbero più robuste con una distinzione più precisa tra “sostituire il processo” e “operare dentro il processo”, e con una riflessione su come questi strumenti ridefiniscono — piuttosto che eliminare — il ruolo dell’ingegnere.

Qui il thread completo su Perplexity.

Disclaimer: questo post è stato realizzato con il supporto di Perplexity Pro e Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Discussione su questo Post

Assolutamente, procediamo.