Il Framework GSD: Come Far Consegnare Davvero gli Agenti IA
L'agente che consegna davvero non è quello che gira con il modello migliore. Secondo uno studio di marzo 2026 di Morphllm che ha testato 15 agenti di codifica IA, lo stesso modello di base ottiene punteggi di 17 problemi di scarto a seconda del framework agente che lo racchiude. Lo scaffolding è la variabile. Il modello è quasi incidentale.
Il framework GSD (Get Shit Done) per gli agenti IA è la formulazione più chiara di questa idea che abbiamo visto. Sviluppato da Lex Christopherson e reso popolare dal video AI Labs "GSD Is the Missing Piece For Claude Code", GSD non è l'ennesimo strumento di codifica IA con opinioni. È una filosofia di scaffolding costruita su una semplice premessa: gli agenti falliscono a livello di workflow, non a livello di intelligenza.
Questo articolo scompone il framework GSD, perché funziona, cosa necessitano davvero le pipeline di agenti in produzione — e cosa abbiamo imparato gestendo più di 25 agenti cron autonomi ogni giorno in Context Studios.
Perché la Maggior Parte delle Pipeline di Agenti Fallisce
I dati Morphllm meritano riflessione. Claude Code ottiene 80,9% su SWE-bench Verified con il giusto scaffolding e la giusta orchestrazione. Lo stesso modello base in una pipeline di agenti mal strutturata può ottenere 17 punti in meno sullo stesso insieme di benchmark. Questo divario non è un divario del modello. È un divario architetturale.
La maggior parte delle pipeline di agenti muore per lo stesso insieme di problemi:
Caos della finestra di contesto. Senza una gestione esplicita dello stato, l'agente accumula rumore nei turni. Al momento in cui raggiunge il passaggio critico — la modifica del file, la chiamata API, la migrazione del database — ha perso la specifica originale in un mare di ragionamenti intermedi.
Criteri di successo ambigui. Un agente con istruzioni vaghe soddisferà la lettera del compito mancando lo spirito. "Aggiorna il flusso di autenticazione" porta a comportamenti imprevedibili. "Aggiungi un controllo per i token scaduti in auth/middleware.ts, restituisci 401 se scaduto, esegui la suite di test auth, conferma che tutti i 47 test passano" non lo fa.
Nessun loop fail-fast. Gli sviluppatori umani controllano costantemente il loro lavoro. Gli agenti, senza passaggi di verifica espliciti, allucinano un successo e vanno avanti. Il bug viene rilasciato.
Nessun percorso di recupero. Quando un agente si scontra con un muro — timeout, errore dello strumento, output inatteso — non c'è un piano. La pipeline rimane in sospeso silenziosamente o si blocca senza salvare i risultati parziali.
GSD affronta tutti e quattro i problemi.
Cosa è il Framework GSD
GSD è un sistema di sviluppo guidato da specifiche, costruito interamente sulle capacità native di Claude Code. Ha accumulato più di 23.000 stelle GitHub. L'intero sistema gira su circa 50 file Markdown, un helper CLI Node.js e due hook. Nessun runtime proprietario. Nessun lock-in del framework.
Il sistema è organizzato attorno a sei comandi slash che corrispondono a un workflow lineare:
/gsd:new-project— cattura l'idea e genera le specifiche/gsd:discuss-phase— chiarisce i requisiti prima di scrivere codice/gsd:plan-phase— suddivide il lavoro in compiti atomici ed eseguibili/gsd:execute-phase— esegue quei compiti, con parallelismo dove possibile/gsd:verify-work— valida l'output rispetto a criteri di successo espliciti/gsd:complete-milestone— archivia lo stato e rilascia
Dietro questi comandi si trovano 29 competenze, 12 agenti personalizzati e 2 hook. Ogni comando è un file Markdown con frontmatter YAML e sezioni con tag XML. Il tagging XML non è cosmetico: l'addestramento di Claude tratta i confini XML come segnali strutturali, il che rende il modello misurabilmente più affidabile nel seguire istruzioni in più passaggi.
GSD supporta Claude Code, OpenCode e Gemini CLI in modo equivalente. La filosofia di scaffolding si trasferisce tra gli agenti.
I Quattro Principi GSD
Il valore produttivo del framework deriva da quattro decisioni architetturali che qualsiasi sistema di agenti può adottare.
1. Specifica prima dell'esecuzione. Ogni workflow GSD inizia con una specifica leggibile da macchina — non una descrizione in linguaggio naturale di un obiettivo, ma un documento strutturato con vincoli, criteri di successo e permessi degli strumenti. Il comando /gsd:discuss-phase esiste specificamente per far emergere l'ambiguità prima che venga eseguita una singola riga di codice.
2. Ricerca parallela, sintesi sequenziale. Durante la fase di ricerca, quattro agenti vengono eseguiti simultaneamente — ognuno studia una dimensione diversa del problema: stack tecnologico, funzionalità, architettura, casi limite. Ognuno scrive i risultati in un file separato. Un agente sintetizzatore elabora poi quei risultati sequenzialmente, e un roadmapper produce il piano finale. Questo pattern fan-out/fan-in limita il carico sulla finestra di contesto di ciascun agente.
3. Stato persistente attraverso i reset del contesto. GSD scrive tutto in una directory .planning/: definizione del progetto, requisiti, roadmap e stato attuale. I commit Git avvengono dopo ogni passaggio. Un comando /gsd:resume-work rilegge quello stato dopo un reset. L'agente non riparte mai da zero. Claude Code /loop adotta un approccio simile a livello di sessione — stato persistente attraverso le finestre di contesto.
4. Passaggi deterministici gestiti da script. Gli script Bash gestiscono i compiti dove l'affidabilità esatta conta: controllare l'esistenza dei file, calcolare i numeri di fase, convalidare i conteggi dei test. LLM per il giudizio, script per il determinismo — questo confine è una delle decisioni progettuali più importanti in un sistema di agenti in produzione.
Realtà Produttiva: Cosa Abbiamo Imparato da 25+ Agenti Quotidiani
Context Studios gestisce più di 25 agenti autonomi su pianificazioni cron ogni giorno. Raccolta di intelligence, audit SEO, pipeline di contenuti, round di engagement social. Lo facciamo da abbastanza tempo da aver accumulato pattern di fallimento che la documentazione GSD non copre ancora, perché emergono solo in produzione.
La gestione dei timeout è una disciplina. Abbiamo aggiustato cinque job cron separati questa settimana perché gli agenti raggiungevano sistematicamente i limiti di esecuzione. Una pipeline di agenti ben progettata necessita di budget di timeout espliciti in ogni fase: la fase di ricerca ottiene N secondi, la fase di esecuzione M secondi, la fase di verifica P secondi. Senza budget per fase, l'agente brucia l'intera finestra temporale nel primo passaggio e fallisce nel momento peggiore.
L'anti-pattern Edit-su-file-grandi. Abbiamo avuto due fallimenti consecutivi della pipeline riconducibili alla stessa causa: un agente che usava strumenti di modifica file su file grandi senza leggerli prima. L'agente assumeva la struttura del file dal contesto, applicava una modifica mirata e corrompeva il file. Ora le nostre pipeline includono un vincolo esplicito read-before-edit nelle istruzioni di scaffolding.
I controlli preliminari del browser non sono opzionali. Diversi dei nostri agenti di automazione dipendono da una sessione browser. Un browser morto è un fallimento silenzioso — l'agente gira per 20 minuti, segnala successo e non ha fatto effettivamente nulla. Aggiungere un controllo di salute del browser come primo passaggio di qualsiasi pipeline dipendente dal browser elimina questa intera classe di fallimenti.
Auto-guarigione invece di recupero manuale. Costruiamo percorsi di recupero direttamente nel nostro scaffolding di agenti. Se il percorso primario fallisce, c'è un fallback. Se il fallback fallisce, il risultato parziale viene salvato e segnalato per revisione invece di essere scartato.
I 3 strumenti che hanno cambiato il nostro modo di programmare con gli agenti IA copre la parte degli strumenti — questo articolo riguarda la disciplina. Insieme delineano come la pipeline di agenti di Context Studios mantiene l'affidabilità su scala.
Costruire il Proprio Scaffolding in Stile GSD
Non è necessario adottare GSD nella sua interezza. I principi sono separabili.
Inizia scrivendo criteri di successo espliciti per ogni compito dell'agente. Non "scrivi test per il modulo auth" ma "scrivi test per il modulo auth con copertura ≥ 90% su auth/middleware.ts, con tutti i test esistenti ancora in successo." Questo singolo cambiamento elimina la più grande classe di fallimenti degli agenti.
Poi aggiungi gate di verifica. Dopo ogni passaggio importante, l'agente dovrebbe verificare che l'output atteso esista e corrisponda alle specifiche. È quello che il comando /gsd:verify-work di GSD automatizza.
Poi aggiungi la persistenza dello stato. Dopo ogni passaggio verificato, scrivi lo stato attuale su disco. Usa i commit Git come checkpoint.
Infine, traccia esplicitamente il confine LLM/script. Tutto ciò che deve essere esattamente giusto va in uno script. Tutto ciò che richiede giudizio va al modello.
I dati Morphllm confermano ciò che questa architettura prevede: il sistema di agenti che struttura correttamente queste decisioni supererà quello che esegue un modello nominalmente più potente ma con scaffolding debole.
FAQ
Cos'è il framework GSD per gli agenti IA? GSD (Get Shit Done) è un sistema di sviluppo guidato da specifiche, costruito sulle capacità native di Claude Code. Usa 50 file Markdown, 6 comandi slash e 2 hook per orchestrare un workflow di sviluppo completo dall'idea al codice consegnato. Nessun runtime personalizzato richiesto.
Perché lo scaffolding è più importante del modello IA? Lo studio Morphllm ha dimostrato che lo stesso modello ottiene punteggi variabili di 17 problemi a seconda della qualità dello scaffolding. Lo scaffolding determina come il modello riceve i compiti, gestisce il contesto, verifica gli output e si riprende dai fallimenti.
Quali sono le cause più comuni dei fallimenti delle pipeline di agenti IA in produzione? Le quattro cause principali: (1) esaurimento della finestra di contesto per cattiva gestione dello stato, (2) criteri di successo vaghi, (3) passaggi di verifica mancanti, (4) nessun percorso di recupero quando si verificano errori o timeout.
Come gestisce GSD i reset del contesto?
GSD scrive tutto lo stato del progetto in una directory .planning/ e fa commit dopo ogni passaggio. Un comando /gsd:resume-work rilegge quello stato dopo un reset.
Il framework GSD funziona con modelli diversi da Claude? Sì. L'architettura GSD supporta Claude Code, OpenCode e Gemini CLI in modo equivalente. I principi di scaffolding si trasferiscono a qualsiasi sistema di agenti.
Quanti agenti simultanei può gestire una pipeline in stile GSD? La fase di ricerca di GSD usa quattro agenti paralleli per impostazione predefinita. Il pattern fan-out/fan-in è scalabile. Le nostre pipeline basate su cron gestiscono più di 25 agenti quotidianamente con pianificazioni indipendenti e contesti isolati.
Lo Standard Produttivo è Cambiato
Il divario nei benchmark Morphllm — 17 problemi, stesso modello, scaffolding diverso — è la prova più chiara disponibile che la soglia di qualità per il lavoro degli agenti non riguarda più quale modello si usa. Riguarda quanto bene si definisce il lavoro, si vincola l'esecuzione, si verifica l'output e ci si riprende dai fallimenti.
GSD è un'implementazione di questa idea. I principi che la sottendono sono disponibili per qualsiasi sviluppatore disposto a scrivere specifiche esplicite, aggiungere gate di verifica e persistere lo stato attraverso i reset.
Gli agenti che consegnano in modo affidabile sono quelli con criteri di successo chiari. Vale anche per gli ingegneri umani.