GSD get-shit-done
Prompt lunghi, qualche battuta ben piazzata, una vaga direzione architetturale e l’illusione che l’intelligenza artificiale potesse trasformare il caos creativo in codice pronto per la produzione. Poi è arrivata la realtà, puntuale come un audit della Corte dei Conti. Contesto che marcisce, funzioni che compaiono dal nulla, refactoring che genera più bug di quanti ne risolva. In questo scenario entra in scena GSD, Get Shit Done, un repository che non promette magia ma disciplina, e che applica allo sviluppo assistito da AI una logica che molti avevano dimenticato, lo spec-driven development.
GSD parte da un presupposto brutale e corretto. I modelli di linguaggio sono straordinari finché il contesto resta pulito. Superata una certa soglia di token, anche il migliore dei sistemi inizia a comprimere, semplificare, poi inventare. È fisiologia, non un bug. Continuare a costruire sopra quel degrado è l’equivalente digitale di aggiungere piani a un edificio con le fondamenta che cedono.
Il punto di rottura arriva presto. A cinquantamila token il modello diventa diplomatico e “più conciso”. A centomila inizia a confondere le API. A centocinquantamila ti ritrovi a fare debugging del debugging, con una AI che spiega con sicurezza perché una funzione inesistente sarebbe stata definita “implicitamente”. Chiunque abbia provato a spedire software serio con il vibe coding riconosce questa parabola. È il momento in cui l’entusiasmo si trasforma in sarcasmo, e il sarcasmo in commit revertiti.
GSD interviene esattamente lì, non con un altro prompt framework, ma con una scelta architetturale netta. Ogni task vive in un contesto fresco, fino a duecentomila token, senza accumulare detriti cognitivi. Nessuna memoria a lungo termine che diventa rumore, nessuna continuità artificiale che illude di essere utile. Ogni attività è trattata come un’unità atomica, con una specifica chiara, un obiettivo verificabile e una finestra di contesto che nasce e muore con quel compito. È una filosofia che ricorda più l’ingegneria aerospaziale che l’hacking da weekend, e non è un caso che funzioni.
Il workflow di GSD è interessante non perché sia esotico, ma perché è noiosamente razionale. Si parte dalla discussione, una fase in cui l’AI non scrive codice ma fa domande, molte, finché non capisce davvero l’intento. È l’antitesi del prompt one-shot. Qui il modello viene usato come analista funzionale instancabile, non come stagista iperattivo. Quando la visione è chiara, entra la ricerca, condotta da agenti paralleli che esplorano il dominio, le best practice, i trade-off tecnici. Non è ricerca decorativa, è riduzione dell’incertezza.
Da lì si passa al piano, che non è una roadmap da presentazione, ma una scomposizione in task atomici, ciascuno con criteri di verifica integrati. Questa è una delle keyword semantiche più rilevanti, context engineering. Non si tratta di scrivere più testo, ma di strutturare il contesto in modo che il modello non debba indovinare nulla. Ogni task ha confini netti, input definiti, output misurabili. È qui che lo spec-driven development mostra il suo vantaggio competitivo rispetto al vibe coding, che vive di ambiguità e speranza.
L’esecuzione è quasi chirurgica. Un task, un contesto pulito, un commit. Nessuna sessione infinita, nessun accumulo di decisioni implicite. Il risultato è codice sorprendentemente stabile, non perché l’AI sia diventata più intelligente, ma perché è stata messa nelle condizioni di non sbagliare. Subito dopo arriva la verifica, che ribalta un altro mito dell’AI coding. Non è l’AI che decide se ha funzionato. Sei tu. Se qualcosa non va, il sistema non improvvisa una patch, ma genera un piano di fix, di nuovo strutturato, di nuovo atomico.
Questo approccio cambia radicalmente la sensazione di lavoro. Non è più una jam session creativa con un modello che suona a orecchio, ma una catena di montaggio di alta precisione. Qualcuno dirà che è meno divertente. Probabile. È anche infinitamente più efficace. Ed è qui che entra la terza keyword semantica, AI coding workflow. GSD non è solo un repo, è una dichiarazione di intenti su come dovrebbe funzionare davvero lo sviluppo assistito da intelligenza artificiale in contesti professionali.
C’è un’ironia sottile in tutto questo. Per anni abbiamo venduto l’idea che l’AI avrebbe eliminato la necessità di specifiche dettagliate. In realtà sta facendo l’opposto. Più il modello è potente, più diventa evidente che senza una specifica rigorosa il risultato è rumore. È una lezione che i CTO con qualche cicatrice sulle spalle conoscono bene. L’automazione non perdona l’ambiguità, la amplifica. GSD prende questa verità e la porta all’estremo, trasformando la specifica da documento noioso a motore operativo.
Dal punto di vista strategico, questo ha implicazioni enormi. Significa che il vantaggio competitivo non sta nell’accesso al modello più grande, ma nella capacità di progettare workflow che preservino la qualità del contesto. Significa che il futuro dell’AI nello sviluppo software non è un assistente creativo che “ci prova”, ma un sistema industriale che esegue compiti ben definiti con una precisione ripetibile. In altre parole, meno vibe, più ingegneria.
C’è anche un messaggio implicito per chi costruisce piattaforme e strumenti. L’ossessione per la continuità del contesto potrebbe essere mal riposta. A volte la soluzione non è ricordare di più, ma dimenticare meglio. Ripartire da zero per ogni task, con una specifica solida, è controintuitivo per chi viene dal mondo delle chat persistenti, ma è perfettamente logico per chi ha mai gestito un progetto software complesso.
GSD non è la fine del coding assistito da AI, è probabilmente il suo inizio adulto. È il momento in cui smettiamo di stupirci che “funzioni” e iniziamo a pretendere che funzioni sempre, sotto pressione, con scadenze e responsabilità reali. Il vibe coding resterà come esercizio creativo, come demo da conferenza, come passatempo. Lo spec-driven development, applicato con disciplina e supportato da context engineering serio, è ciò che permette di spedire software che non crolla al primo refactoring.
In fondo è una storia vecchia quanto l’ingegneria. Ogni nuova tecnologia passa dalla fase euforica a quella industriale. GSD si colloca esattamente in questo passaggio, con un nome volutamente volgare e un approccio sorprendentemente sobrio. Get shit done, sì, ma con una specifica in mano e un contesto pulito. Tutto il resto è rumore, anche quando sembra brillante.
Repository: https://github.com/glittercowboy/get-shit-done