Guida GSD per sviluppatori

Guida GSD per sviluppatori

Indice dei contenuti – Guida GSD per sviluppatori

1. Cos’è GSD e perché esiste
2. A cosa serve nell’ecosistema AI — il problema del “context rot”
3. Architettura e struttura del sistema
4. I comandi principali
5. Caso d’uso pratico: dalla installazione all’implementazione
6. Best practice per usare GSD al meglio
7. Limiti e come aggirarli
8. Conclusioni: la formazione continua fa la differenza

1. Cos’è GSD e perché esiste

Sei un developer. Hai un’idea chiara in testa, apri Claude Code, scrivi qualche prompt e… dopo mezz’ora l’AI inizia a fare scelte strane, dimentica le decisioni prese all’inizio, produce codice sempre meno coerente. Ti suona familiare?

È esattamente da questa frustrazione che nasce GSD, ” Get Shit Done“, un progetto open source creato da un developer indie con una premessa provocatoria: “Io non scrivo codice. Lo fa Claude Code. Il problema è che Claude Code, da solo, non è abbastanza affidabile.”

GSD è un framework leggero di meta-prompting, context engineering e spec-driven development pensato per funzionare con Claude Code, OpenCode e Gemini CLI. Non è l’ennesimo wrapper di prompt, è un sistema che gestisce il come l’AI lavora, non solo cosa le chiedi di fare. Con oltre 12.800 stelle su GitHub, ingegneri di Amazon, Google, Shopify e Webflow tra i suoi utenti e una community attiva su Discord, GSD si è affermato come un riferimento serio nel mondo dello sviluppo AI-assistito.

Il nome è volutamente diretto. Niente cerimonie sprint, niente story point, niente Jira workflow. Solo un sistema che funziona.

2. A cosa serve nell’ecosistema AI — il problema del “context rot”

Chi usa Claude Code o tool simili in modo intensivo conosce il fenomeno: più avanza la sessione, più la qualità degrada. L’AI “dimentica” decisioni architetturali, produce output inconsistenti, riempie il context window con ridondanze accumulate.

Questo si chiama context rot, ed è il nemico principale di chi vuole costruire software serio con l’AI.

GSD è progettato esplicitamente per risolverlo attraverso tre meccanismi:

• Il primo è il context engineering strutturato: ogni fase del progetto viene documentata in file dedicati che fungono da memoria persistente tra sessioni diverse. Non devi rispiegare ogni volta cosa stai costruendo — il sistema lo sa già.
• Il secondo è l’esecuzione con agenti in contesti freschi: i task vengono eseguiti da subagent con un context window pulito, senza ereditare il rumore accumulato nella sessione principale. Il tuo contesto principale rimane leggero e reattivo anche dopo ore di lavoro.
• Il terzo è l’XML prompt formatting: ogni piano di esecuzione viene strutturato in XML ottimizzato per Claude, con istruzioni precise e step di verifica già integrati, eliminando l’ambiguità che causa comportamenti imprevedibili.

3. Architettura e struttura del sistema – Guida GSD per sviluppatori

Quando inizializzi un progetto con GSD, viene creata una cartella .planning/ con una serie di file strutturati che rappresentano la memoria del progetto:

PROJECT.md contiene la visione generale ed è sempre caricato. REQUIREMENTS.md raccoglie i requisiti v1/v2 con tracciabilità completa. ROADMAP.md descrive fasi e milestone. STATE.md tiene traccia delle decisioni prese, dei blocchi e della posizione corrente nel workflow.

Per ogni fase vengono poi generati PLAN.md, con il task atomico strutturato in XML,e SUMMARY.md, con il resoconto di cosa è stato fatto e i commit associati.

Ogni piano di esecuzione segue un formato XML preciso che include il nome del task, i file coinvolti, le istruzioni per l’agente, il comando di verifica e la definizione di “fatto”. Non c’è spazio per l’interpretazione: o passa la verifica o no.

L’orchestrazione avviene tramite multi-agent: un orchestratore leggero coordina ricercatori, pianificatori, esecutori e verificatori che lavorano in parallelo nei loro contesti isolati. Il risultato pratico è che la finestra di contesto principale rimane al 30-40% anche dopo fasi complesse.

Ogni task completato riceve il proprio commit atomico con messaggio semantico. Il risultato è una git history chirurgica, dove ogni cambiamento è tracciabile, revertibile e comprensibile anche per sessioni future.

4. I comandi principali

GSD si usa attraverso slash command all’interno di Claude Code. Il workflow core si articola in sei comandi fondamentali.

/gsd:new-project inizializza il progetto: raccoglie requisiti, fa ricerche di dominio, crea roadmap e la propone per approvazione. /gsd:discuss-phase N cattura le decisioni implementative prima della pianificazione — è qui che definisci layout, comportamenti, edge case. /gsd:plan-phase N fa ricerca, crea 2-3 piani atomici e li verifica. /gsd:execute-phase N esegue tutti i piani in onde parallele con contesti freschi. /gsd:verify-work N ti guida attraverso l’acceptance testing deliverable per deliverable. /gsd:complete-milestone archivia la milestone e tagga la release.

Per il lavoro quotidiano ci sono anche /gsd:quick per task ad hoc senza pianificazione completa, /gsd:debug per il debugging sistematico con stato persistente, /gsd:progress per sapere dove sei e cosa c’è dopo, e /gsd:set-profile per bilanciare qualità e costo dei token scegliendo tra i profili quality, balanced e budget.

5. Caso d’uso pratico: dalla installazione all’implementazione – Guida GSD per sviluppatori

Supponiamo di voler costruire una piccola API REST con autenticazione. Ecco il flusso completo.

Installazione — Un solo comando da terminale:

npx get-shit-done-cc@latest

L’installer chiede runtime e scope. Per lavorare solo sul progetto corrente si sceglie l’installazione locale. Si verifica il tutto con /gsd:help dentro Claude Code.

Mapping del codebase (se hai già del codice) — Prima di tutto si esegue /gsd:map-codebase. Spawna agenti paralleli che analizzano stack, architettura e convenzioni esistenti. Fondamentale su progetti brownfield.

Inizializzazione — Si lancia /gsd:new-project. Il sistema fa domande finché non ha capito tutto: obiettivi, tech stack, vincoli, casi limite. Poi crea tutti i file di progetto e propone una roadmap. Si approva e si è pronti.

Discussione della fase — /gsd:discuss-phase 1 porta in superficie le zone grigie: come strutturare i token JWT, come gestire gli errori, quale formato restituire dall’API. Ogni decisione viene salvata e guida la pianificazione successiva.

Pianificazione — /gsd:plan-phase 1 produce piani atomici verificati. A questo punto il sistema sa esattamente cosa costruire e come.

Esecuzione e verifica — /gsd:execute-phase 1 fa girare gli agenti in parallelo, ognuno nel proprio contesto pulito, e committa ogni task completato. Poi /gsd:verify-work 1 guida il testing manuale: per ogni deliverable chiede “funziona?” e se la risposta è no, spawna agenti di debug e crea fix plan pronti per la re-esecuzione immediata.

Il ciclo discuss → plan → execute → verify si ripete per ogni fase, fino al completamento della milestone.

6. Best practice per usare GSD al meglio

Non saltare mai /gsd:discuss-phase. È la fase in cui il sistema capisce la tua visione, non produce una versione generica. Più sei specifico qui, più il risultato finale assomiglia a quello che immaginavi.

Configura il profilo modello in base al contesto. Il profilo balanced, Opus per planning, Sonnet per execution, è il punto ottimale per la maggior parte dei progetti. Usa budget per esplorazione, quality solo per le fasi critiche.

Prima di qualsiasi analisi del codebase, aggiungi i file sensibili alla deny list in .claude/settings.json con le regole Read(.env) e simili. GSD ha protezioni integrate, ma prevenire è meglio.

Usa /gsd:quick per bug fix, piccoli refactoring e task di configurazione. Mantiene i vantaggi di GSD, commit atomici e state tracking, senza il peso della pianificazione completa.

Se esci a metà fase, usa sempre /gsd:pause-work prima di chiudere e /gsd:resume-work quando torni. Non affidarti alla memoria della sessione precedente.

Aggiorna GSD regolarmente. Il progetto evolve velocemente e le nuove versioni portano spesso miglioramenti significativi al sistema di orchestrazione.

7. Limiti e come aggirarli

GSD è potente, ma non è una bacchetta magica. È utile conoscere i suoi limiti prima di integrarlo nel workflow.

• Il costo in token è il limite più concreto. L’orchestrazione multi-agente consuma significativamente più token di un singolo prompt diretto. Su progetti grandi con profilo quality, i costi possono salire. La soluzione è usare il profilo budget nelle fasi esplorative e riservare i modelli più potenti alle fasi di execution critica.
• Il overhead sulla pianificazione può essere controproducente per task molto piccoli. Correggere un typo o cambiare un colore non giustifica l’intero workflow. In questi casi /gsd:quick è sempre la scelta giusta.
• La dipendenza dai runtime supportati è una limitazione strutturale. GSD è progettato per Claude Code, OpenCode e Gemini CLI. Chi lavora in altri ecosistemi deve valutare le porte community disponibili, che però non hanno lo stesso livello di manutenzione del progetto principale.
• Su codebase legacy molto grandi, /gsd:map-codebase può produrre analisi incomplete su sistemi mal documentati. In questi casi è consigliabile integrare l’analisi automatica con documentazione manuale aggiunta direttamente nei file di contesto.

8. Conclusioni: la formazione continua fa la differenza

GSD è un esempio concreto di quanto velocemente si stia evolvendo il panorama dello sviluppo software. Non basta “sapere che esiste l’AI”, bisogna conoscere strumenti specifici, architetture emergenti come il context engineering, pattern di orchestrazione multi-agente, e soprattutto saper integrare tutto questo in un workflow produttivo reale.

La vera sfida per i team IT oggi non è tecnologica: è formativa. Chi si ferma ad osservare rischia di trovarsi rapidamente fuori contesto in un settore che si rinnova ogni pochi mesi. Padroneggiare strumenti come GSD richiede tempo, guida esperta e pratica applicata, non basta leggere una guida.

L’unica soluzione efficace è la formazione continua strutturata. Un team che investe in aggiornamento costante sulle tecnologie AI non solo lavora meglio oggi, costruisce una capacità adattiva che vale su ogni strumento che arriverà domani.

In questo senso, i Corsi AI Generativa di Innovaformazione rappresentano una risposta concreta per le aziende che vogliono portare il proprio team IT al livello successivo. I corsi sono rivolti alle aziende, si attivano con calendario concordato in base alle esigenze del team e si svolgono in modalità online classe virtuale, garantendo flessibilità operativa senza rinunciare all’interazione diretta con i docenti.

È inoltre possibile attivare i percorsi formativi nell’ambito dei progetti Fondimpresa per la formazione finanziata: un’opportunità concreta per le imprese che vogliono investire sulle competenze AI senza gravare sul budget ordinario, con supporto nella gestione della pratica.

Formarsi sull’AI Generativa non è più un’opzione per i team che vogliono restare competitivi. È la condizione necessaria per padroneggiare davvero il nuovo scenario tecnologico.

Scopri i Corsi AI Generativa di Innovaformazione.

Contatti

• info@innovaformazione.net
• tel. 3471012275 (Dario Carrassi)

Per altri articoli di settore consigliamo di navigare nel nostro blog QUI.

(fonte) (fonte)