Claude Code e lo sviluppo di software

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

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.

---

---

© 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

---

---