Spec-driven development: come governare lo sviluppo software assistito da AI

L’articolo in breve

I coding agent stanno cambiando il modo di sviluppare software. Sono in grado di analizzare repository, modificare più componenti, proporre piani di lavoro ed eseguire test, aumentando velocità e autonomia rispetto ai tradizionali strumenti di assistenza alla programmazione.

Ma maggiore autonomia significa anche maggiore dipendenza dal contesto. Per modificare correttamente un sistema, un agente deve sapere su quale codice intervenire, ma soprattutto comprendere il risultato atteso, il perimetro della modifica, i vincoli da rispettare e i comportamenti esistenti da preservare.

È in questo scenario che si inserisce lo spec-driven development (SDD), un approccio che porta le specifiche al centro del processo di sviluppo. Requisiti, vincoli, decisioni progettuali e criteri di accettazione diventano così un riferimento condiviso per guidare lo sviluppo assistito dai coding agent e verificare il risultato prodotto.

Che cos’è lo spec-driven development

Con spec-driven development si indica l’approccio nel quale le specifiche assumono un ruolo centrale nel processo di sviluppo, consentendo di raccogliere in modo strutturato ciò che il sistema deve fare, il perimetro dell’intervento, i vincoli da rispettare e i risultati attesi. Da questa base possono poi derivare il disegno tecnico, la suddivisione delle attività, il codice e i test.

Non si tratta solo di un principio teorico: nel biennio 2025-2026 sono nati strumenti dedicati proprio a strutturare il lavoro dei coding agent a partire dalle specifiche, come GitHub Spec Kit o Kiro di AWS, segno che l’approccio si sta consolidando come pratica concreta e non come tendenza isolata.

La differenza rispetto ad un semplice prompt riguarda soprattutto il modo in cui queste informazioni vengono organizzate e mantenute nel tempo. Una richiesta inserita in una conversazione può essere sufficiente per un’attività circoscritta, mentre una specifica può essere riletta, revisionata e versionata, mantenendo persone e strumenti diversi allineati lungo il ciclo di sviluppo.

Workflow spec-driven: dalla richiesta iniziale a un processo verificabile

Un workflow spec-driven introduce alcuni passaggi intermedi tra la richiesta iniziale e l’implementazione, con l’obiettivo di definire meglio il problema prima di scrivere codice e rendere verificabili le decisioni prese lungo il percorso.

Il processo può articolarsi, ad esempio, in queste fasi:

1. definizione dell’obiettivo e del perimetro;
2. raccolta dei requisiti funzionali e non funzionali;
3. individuazione di vincoli, dipendenze e casi limite;
4. definizione delle principali scelte tecniche;
5. suddivisione del lavoro in attività verificabili;
6. generazione o modifica del codice;
7. confronto tra risultato, test e criteri di accettazione.

La sequenza non deve essere necessariamente rigida. La specifica accompagna l’implementazione e può evolvere insieme al software, mantenendo allineati ciò che era stato richiesto e ciò che viene effettivamente realizzato.

Questo introduce anche più momenti di verifica. Il team può controllare il perimetro dell’intervento prima che venga definito il piano tecnico, valutare le scelte progettuali prima della generazione del codice e confrontare il risultato finale con criteri stabiliti in precedenza. Alcune ambiguità possono così emergere prima di tradursi in modifiche da correggere successivamente.

Quali informazioni devono entrare nella specifica

Alcune informazioni rilevanti per un sistema non derivano dal codice stesso, ma da regole di business, vincoli architetturali, esigenze di sicurezza o integrazioni con altri sistemi; altre riguardano comportamenti esistenti da preservare anche quando non risultano evidenti dall’implementazione.

La specifica serve a raccogliere questo contesto e a descrivere in modo più completo l’intervento da realizzare. Oltre all’obiettivo e al perimetro, può chiarire il comportamento atteso del sistema, le dipendenze coinvolte e le condizioni che devono essere rispettate durante lo sviluppo. Può inoltre indicare requisiti non funzionali, casi limite e criteri di accettazione, così da rendere più chiaro non soltanto cosa deve cambiare, ma anche cosa deve continuare a funzionare come prima.

Il livello di dettaglio dipende naturalmente dalla complessità dell’attività. Per una modifica circoscritta può essere sufficiente una specifica breve; quando invece l’intervento coinvolge più componenti o sistemi, diventa utile descrivere con maggiore precisione le relazioni tra le parti e le decisioni che non possono essere lasciate all’interpretazione dell’agente.

Se viene mantenuta e aggiornata insieme al software, la specifica può infine diventare una forma di memoria progettuale, utile per ricostruire nel tempo non soltanto ciò che è stato implementato, ma anche il contesto e le ragioni che hanno portato a determinate scelte.

Diversi modi di intendere lo spec-driven development

Lo SDD non prevede un livello di formalizzazione unico, ma va pensato come un continuum:

• Spec-first: la specifica viene prodotta prima dell’implementazione e guida una determinata modifica o funzionalità.
• Spec-anchored: specifiche e codice continuano a evolvere insieme: i documenti restano un riferimento durante la manutenzione e vengono aggiornati quando cambia il sistema.
• Spec-as-source: il livello più strutturato, in cui la specifica diventa l’artefatto principale da cui derivano implementazione, test e documentazione. È la visione più vicina a quella descritta da GitHub Spec Kit, che presenta le specifiche come artefatto primario e il codice come una loro espressione implementativa.

Non tutti i progetti richiedono di arrivare a questo livello. Il grado di formalizzazione dipende dalla complessità del software, dalla durata prevista, dal rischio e dalla necessità di tracciabilità.

Benefici e limiti dello spec-driven development

I benefici emergono con più evidenza in alcuni contesti tipici. Quando una modifica attraversa più componenti del sistema – frontend, backend, database, API, servizi esterni – mantenere requisiti e dipendenze in una base comune aiuta a evitare interpretazioni locali dello stesso problema. Vale lo stesso per le applicazioni enterprise, che devono rispettare standard architetturali, modelli autorizzativi e procedure interne, e per i sistemi regolamentati, dove collegare requisiti, decisioni, implementazione e test contribuisce alla tracciabilità del processo.

Un caso particolarmente rilevante è la modernizzazione applicativa: una codebase esistente contiene spesso anni di comportamenti, eccezioni e dipendenze documentati solo in parte, e prima di affidare modifiche significative a un agente è necessario ricostruire ciò che il sistema fa, distinguendo cosa può cambiare da ciò che deve essere preservato.

In generale, un approccio più strutturato porta a requisiti più chiari, maggiore continuità del contesto, una relazione più leggibile tra richiesta, decisioni, codice e test, e un migliore coordinamento tra ruoli diversi.

Dall’altra parte però la struttura ha un costo. Una specifica troppo dettagliata può richiedere più lavoro di quanto restituisca in beneficio, e se non viene aggiornata diventa rapidamente una rappresentazione obsoleta del sistema. Una specifica apparentemente completa, inoltre, può dare una falsa sensazione di controllo quando i requisiti di partenza sono incompleti o sbagliati. L’AI può aiutare a produrla e aggiornarla, ma non elimina la necessità di revisione: la qualità della specifica dipende sempre dalla capacità di comprendere il problema e prendere le decisioni giuste.

Conclusioni

Uno sviluppo più strutturato non riduce il contributo delle persone, ne rende più esplicite le responsabilità: chi definisce obiettivi e criteri di accettazione, chi rende visibili vincoli e decisioni progettuali, chi valuta fattibilità e impatti. Sono queste informazioni che il coding agent utilizza per analizzare il problema, pianificare e implementare.

Lo spec-driven development sposta parte dell’attenzione dalla quantità di codice che un agente è in grado di produrre alla qualità delle informazioni che guidano quella produzione.

Per le organizzazioni che gestiscono sistemi complessi, l’utilità dell’approccio dipende dalla capacità di mantenere requisiti, vincoli e decisioni sufficientemente chiari da poter essere condivisi, verificati e aggiornati nel tempo.