# Sviluppo basato sulle specifiche > Come i tecnici di Asana hanno trasformato i prompt ripetuti agli agenti di programmazione in un flusso di lavoro duraturo basato sulle specifiche e cosa abbiamo appreso dopo circa tre mesi di utilizzo interno. Source: https://asana.com/it/inside-asana/spec-driven-development ## Sviluppo basato sulle specifiche: gli aspetti positivi e ciò che abbiamo appreso dopo tre mesi _Dopo tre mesi, avevamo un quadro più chiaro di quando la struttura aggiuntiva fosse stata d'aiuto e quando invece avesse costituito un ostacolo._ Uno dei nostri ingegneri stava preparando una migrazione dei dati e ha deciso di utilizzare lo sviluppo basato sulle specifiche (SDD) per pianificare il lavoro. L'SDD aveva lo scopo di aiutarlo a individuare tempestivamente le lacune, rendere l'approccio più facile da controllare e fornire all'agente una direzione chiara. Il piano risultante era dettagliato e, sulla carta, sembrava abbastanza ragionevole. Il lavoro era strutturato come segue: **Problema → Ricerca → Specifiche → Revisione → Implementazione → Verifica** Con l'avanzare dell'implementazione, il tecnico si è reso conto che due processi potevano entrare in conflitto e creare campi personalizzati duplicati. L'approccio stava anche rendendo il codice sempre più complesso e difficile da seguire. Fortunatamente, hanno individuato il problema, hanno interrotto l'implementazione, hanno redatto un documento di progettazione di una pagina e hanno taggato un paio di colleghi per avere il loro parere. Insieme, hanno lavorato sulla progettazione e hanno trovato un approccio più sicuro. Le specifiche originali hanno fatto quello che avevamo chiesto: hanno fatto sì che il progetto proseguisse nella direzione originale. Il problema era che la direzione era sbagliata. Una specifica dettagliata ha reso facile proseguire il progetto, anche quando l'idea di partenza era incerta. L'agente poteva sviluppare quell'idea più velocemente di quanto le persone potessero fermarsi a metterla in discussione. Quel progetto ha evidenziato un rischio legato all'aggiunta di struttura: un agente poteva trasferire la stessa ipotesi errata dalle specifiche al codice e ai test. Le specifiche, il codice e i test erano coerenti tra loro, ma ciò non significava che il presupposto di base fosse corretto. Per le decisioni più rischiose, era comunque necessario che qualcun altro tornasse all'obiettivo originale e cercasse i modi in cui l'implementazione avrebbe potuto violarlo. Tuttavia, gli agenti stavano affrontando lavori che duravano più di una sessione e spesso un prompt non era sufficiente per preservare l'obiettivo del progetto o le motivazioni alla base. Ciò ci ha portato a creare /spec-driven, un framework per flussi di lavoro incentrato sulle specifiche. Le specifiche mantenevano la direzione del progetto disponibile per la sessione successiva. Gli script fornivano il contesto ed eseguivano i controlli. Quando un'esecuzione evidenziava una regola, un controllo o un elemento di contesto mancante, potevamo aggiungerlo al flusso di lavoro in modo che gli agenti successivi non dovessero riscontrare nuovamente la stessa lacuna. C'è ancora un discreto disaccordo sul fatto che la struttura aggiuntiva dell'SDD valga la pena. [Microsoft](https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering) e [AWS](https://aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/) promuovono l'SDD, mentre [Thoughtworks lo descrive come emergente e controverso](https://www.thoughtworks.com/en-sg/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices) e [i professionisti riferiscono esperienze contrastanti](https://news.ycombinator.com/item?id=45610996). I detrattori avvertono che l'SDD può produrre più Markdown di quanto i tecnici riescano a gestire, trasformare una specifica dettagliata in codice scritto in prosa o lasciare un'altra descrizione del sistema che si discosta dal codice.[1][2][3] Dopo tre mesi di utilizzo effettivo, abbiamo capito che la domanda importante non era se utilizzare o meno l’SDD. Era ciò che mancava all'operatore in quel progetto. A volte la risposta era una specifica. Altre volte era un esempio migliore, un controllo automatizzato o un ingegnere che conosceva l'area. ## Perché abbiamo creato /spec-driven Alcuni ingegneri di Asana avevano già provato [GitHub Spec Kit](https://github.com/github/spec-kit/blob/main/docs/reference/workflows.md) e [OpenSpec](https://github.com/Fission-AI/OpenSpec/blob/main/docs/customization.md), ma nessuno dei due è diventato parte del loro flusso di lavoro abituale. Volevamo una versione che potessimo adattare man mano che imparavamo e collegare al processo di sviluppo di Asana. La modalità di pianificazione integrata poteva già analizzare il codebase e produrre un utile piano di implementazione prima di apportare modifiche. SDD ha aggiunto maggiore struttura a quel piano: ha mantenuto il problema, le decisioni chiave e i criteri di accettazione visibili durante l'implementazione e la verifica. Prima dell'implementazione, /spec-driven ha riproposto la sua comprensione del problema e ha sollevato le domande che avrebbero potuto modificare il piano. Ciò ha dato al progettista la possibilità di correggere la direzione prima che ci fosse del codice da riscrivere. Abbiamo memorizzato quello stato nel repository, in modo che nelle sessioni successive non si dovesse cercare di indovinare cosa fosse accaduto. Volevamo che le regole del flusso di lavoro fossero deterministiche, quindi gli script si occupavano della registrazione e dei controlli. Il modello si occupava delle parti che traevano vantaggio dal giudizio: porre domande, valutare i compromessi e spiegare le decisioni. Il flusso di lavoro includeva diversi comandi. I tecnici utilizzavano /spec-driven spec per affrontare le questioni aperte e produrre una specifica e un piano di implementazione. Dopo aver esaminato il piano, hanno usato /spec-driven ship per implementarlo, verificare il risultato e preparare il lavoro per la revisione. Una macchina a stati monitorava il progetto mentre avanzava attraverso questi comandi, in modo che le sessioni successive sapessero cosa era accaduto e cosa sarebbe successo dopo. Fin dall'inizio, volevamo che /spec-driven fosse più di un semplice modo per redigere e mettere in atto le specifiche. Volevamo anche che orchestrasse i flussi di lavoro agentici. Ordina le attività in base alle dipendenze e mantiene le modifiche ai file che si sovrappongono in cicli di esecuzione separati. Invia lavori indipendenti a più agenti in parallelo, quindi utilizza i risultati per decidere cosa può essere eseguito successivamente. Sembra un GPS per il lavoro: in qualsiasi momento è chiaro quale sia il prossimo passo e dove si trovino le decisioni realmente importanti, quindi è difficile rimanere bloccati.Gli sviluppatori di Asana hanno utilizzato /spec-driven sia in modalità spec-first che spec-anchored. Con l'approccio spec-first, hanno utilizzato una specifica per scegliere una direzione, quindi hanno smesso di aggiornarla. Con l'approccio spec-anchored, l'hanno mantenuta aggiornata man mano che il lavoro cambiava. I tecnici hanno anche redatto specifiche indipendenti per parti di un impegno più ampio, in modo che una persona potesse utilizzare il flusso di lavoro senza chiedere a tutto il team di adottarlo. ## Quando /spec-driven vale il lavoro extra La struttura aggiuntiva ha dato i maggiori risultati quando era necessario mantenere un contesto importante tra sessioni, passaggi di consegne o molte attività correlate. I progettisti potevano verificare come era cambiato il piano e la direzione del progetto rimaneva disponibile quando il lavoro passava a un’altra sessione di Agent o a un’altra persona. Due iniziative di prodotto hanno mantenuto specifiche aggiornate per circa due o tre mesi: una per la creazione di una nuova funzionalità importante, l'altra per il riporto delle date delle sottoattività alle attività principali. Ho appena terminato un'iniziativa piuttosto importante con Spec-driven e penso che mi abbia davvero aiutato! Ho lavorato al piano per circa due giorni e poi ho portato a termine tutto il lavoro di sviluppo e l'ho unito in tre giorni.Le specifiche hanno semplificato i passaggi di consegne. Qualcuno che riprendeva un progetto sospeso poteva vedere cosa il team stava cercando di fare, perché aveva assunto quella forma e cosa rimaneva da fare. Non ha dovuto ricostruire il progetto a partire dai commit e dalle conversazioni. I tecnici hanno anche utilizzato /spec-driven per coordinare grandi batch di lavoro gestiti dagli agenti. Nella console di amministrazione di Asana, dove i team IT delle aziende clienti gestiscono le impostazioni di sicurezza, accesso, integrazioni e condivisione a livello di organizzazione, gli ingegneri l’hanno utilizzata per spostare 66 impostazioni su framework condivisi. Lo spostamento di tali impostazioni ha richiesto circa 150 migrazioni su diversi framework della console di amministrazione. Ogni migrazione è diventata un ticket di Asana per un agente cloud e i tecnici le hanno eseguite in batch paralleli, aggiornando i ticket rimanenti in base ai risultati precedenti. Il team che ha gestito questo impegno ha riferito che il 91% delle migrazioni non ha richiesto alcuna revisione dopo il controllo e che l'impegno complessivo è stato portato a termine con oltre un mese di anticipo rispetto al piano originale. Un'altra migrazione di grandi dimensioni ha richiesto solo un breve prompt. La differenza stava nel livello di chiarezza già fornito dal codebase. Conteneva esempi che gli agenti potevano seguire e controlli che potevano verificare il risultato. Gli agenti della Console di amministrazione non riuscivano a capire tutti i requisiti dal codice, quindi il lavoro necessitava di una maggiore strutturazione. L'approccio /spec-driven ha anche contribuito alla creazione rapida di prototipi. I tecnici potevano rispondere rapidamente a un numero sufficiente di domande aperte sul prodotto per creare un'esperienza end-to-end funzionante. I PM e i designer potevano provare un prototipo prima che gli ingegneri investissero nel consolidamento della produzione. Se i tecnici decidevano di mantenere il codice, di solito era necessaria una pulizia sostanziale prima che potesse essere unito. A quel punto, il prototipo aveva già dimostrato se valesse la pena portare avanti l'idea. ## Cosa hanno evidenziato i primi dati Abbiamo incoraggiato tutti a provare /spec-driven una volta, ma non abbiamo imposto l'uso continuativo. Circa la metà degli ingegneri l'ha provato. Nell'ultimo mese, l'utilizzo settimanale ha riguardato da 30 a 50 ingegneri. Tra le competenze degli agenti integrate e sviluppate da Asana che gli sviluppatori hanno invocato direttamente, /spec-driven si è classificata al terzo posto. L’uso continuativo è stato incoraggiante, ma non ci ha detto in che modo /spec-driven abbia influito sulla consegna. La velocità di progettazione è notoriamente difficile da misurare. Le richieste pull e le aggiunte al codice di implementazione sono indicatori imperfetti della produttività, ma riteniamo che siano spesso misure utili per orientarsi. Per il confronto della velocità, abbiamo esaminato sette ingegneri e 524 richieste pull unite nell'arco di quattro mesi. Abbiamo confrontato il lavoro svolto prima e dopo il primo utilizzo evidente di /spec-driven da parte di ciascun ingegnere e abbiamo escluso specifiche, piani e altri artefatti del flusso di lavoro. Per il confronto relativo al ripristino, abbiamo classificato una richiesta pull come /spec-driven quando ha modificato i file di progetto del flusso di lavoro. Le richieste pull settimanali sono aumentate del 38% e le aggiunte di codice di implementazione sono aumentate di 2,66 volte. Un breve periodo di tempo con un volume insolitamente elevato ha influenzato il risultato delle aggiunte. Anche senza di esso, le aggiunte erano comunque superiori del 66%. Anche il tasso di ripristino esplicito è stato leggermente inferiore: 1,2% per il lavoro /spec-driven, rispetto all'1,66% per le altre richieste pull. Una maggiore quantità di codice non è necessariamente un buon risultato. Un agente può produrre un'implementazione di grandi dimensioni quando ne basterebbe una più piccola, quindi l'aumento delle aggiunte di codice potrebbe aver rispecchiato soluzioni inutilmente estese piuttosto che un maggior numero di lavori completati. La revisione normale ci ha fornito un controllo per evitare questa modalità di errore. Ci siamo affidati ai revisori affinché segnalassero le implementazioni più ampie o complesse di quanto richiesto dal problema, e queste modifiche sono state comunque approvate. Ciò ci ha dato una certa sicurezza sul fatto che le implementazioni sovradimensionate non fossero la causa dell’intero aumento. Questi confronti non sono stati controllati e non è stato possibile separare l'effetto di /spec-driven dalla combinazione di progetti o dai miglioramenti più ampi negli strumenti degli agenti. Nonostante queste limitazioni, siamo rimasti incoraggiati dai risultati. ## Cosa deve ancora essere migliorato ### La revisione dei documenti può diventare un collo di bottiglia La creazione di una specifica richiedeva da 30 minuti a diversi giorni, a seconda della familiarità del tecnico con l'area e della complessità e del rischio del progetto. I progettisti potevano usare /spec-driven per far redigere rapidamente una specifica da un agente, ma la revisione richiedeva comunque tempo. In un'occasione, un ingegnere ha impiegato ore per esaminare una richiesta pull con research.md, un file di lavoro in cui l'agente ha registrato ciò che aveva appreso dal codebase, dalla documentazione e dalle decisioni precedenti prima di redigere le specifiche. Alcuni di questi risultati erano vaghi, imprecisi o leggermente errati. Tale revisione ha evidenziato che non avevamo stabilito se questi file fossero note di lavoro temporanee o documentazione di cui i futuri progettisti avrebbero dovuto fidarsi. Alcuni ingegneri apprezzavano la documentazione relativa al modo in cui era stata presa una decisione. Altri temevano che l'archiviazione di ricerche imperfette le avrebbe fatte apparire autorevoli. In un team di infrastruttura, la revisione delle specifiche è diventata un nuovo ostacolo prima dell'implementazione. Ho pensato che i comandi e il flusso di lavoro sembrassero molto più complicati e lunghi rispetto alla semplice creazione di un piano e alla sua successiva implementazione.La maggior parte dei revisori non voleva leggere una lunga specifica e poi rivedere anche il codice. Quando il lavoro raggiungeva una richiesta pull, il passaggio di consegne doveva riassumere la decisione, il motivo per cui l'avevamo presa, gli aspetti che sembravano rischiosi e il modo in cui avevamo verificato il risultato. Se era la direzione stessa ad aver bisogno di una revisione, dovevamo chiederla prima, quando era ancora facile apportare modifiche. ### Una specifica utile cambia insieme al progetto I progettisti hanno continuato ad apprendere mentre implementavano il piano. Aggiornare le specifiche con ciò che avevano appreso richiedeva impegno. I suoi dettagli sono stati utili durante l'implementazione, poiché mostravano ciò che l'agente pensava di stare costruendo. In seguito, gran parte di questi dettagli ripeteva il codice. Ora riteniamo che una specifica funzionale debba crescere quando il progetto è incerto e ridursi quando il codice è in grado di spiegare l'implementazione. Ciò che rimane dovrebbe aiutare il lettore successivo a comprendere la progettazione, le decisioni importanti, i vincoli e i rischi non risolti. Le specifiche completate sollevano una domanda correlata: cosa dovrebbe succedere loro? Abbiamo aspettato troppo tempo per rispondere. Lasciarle nel monorepo le rende facili da trovare, ma lascia anche documenti di cui nessuno è responsabile. Le stiamo spostando in un archivio separato. Abbiamo ancora bisogno di un passaggio di consegne più breve che preservi ciò che conta in seguito. Se un documento creava più lavoro di quanto ne facesse risparmiare, non era utile. ## Creare cicli di feedback nel sistema A volte la soluzione non era un altro documento, bensì una modifica al sistema che circonda l'agente. Un esempio è stato un bug nel modo in cui /spec-driven leggeva il Markdown: le intestazioni e le caselle di controllo all'interno degli esempi potevano essere scambiate per traguardi effettivi o attività non completate. Dopo aver registrato il bug, abbiamo esaminato il resto di /spec-driven e trovato diversi comandi con un proprio piccolo parser Markdown e lo stesso punto debole. Li abbiamo sostituiti con un parser condiviso, abbiamo aggiunto test di regressione e un controllo dell'architettura e abbiamo implementato la correzione nell'ambiente. [OpenAI descrive un approccio correlato come harness engineering](https://openai.com/index/harness-engineering/): mettere le conoscenze importanti dove gli agenti possono trovarle, rendere le regole applicabili e utilizzare gli errori per migliorare l'ambiente circostante l'agente. Altri insegnamenti non potevano diventare un test o una regola di architettura. Abbiamo trasformato gli errori ricorrenti in indicazioni. Poiché /spec-driven guidava gli utenti attraverso un flusso di lavoro prevedibile, potevamo mostrare ogni lezione quando l'agente raggiungeva la fase pertinente. Sono stati comunque gli ingegneri a decidere quali lezioni fossero applicabili al di là del progetto originale. Abbiamo testato le linee guida su otto richieste pull passate, insieme a casi sintetici progettati per individuare consigli irrilevanti. In un test successivo, abbiamo provato tre di quelle attività passate con prompt brevi, medi e dettagliati, per un totale di nove confronti. La guida ha evidenziato una domanda aggiuntiva utile o un limite di pianificazione in otto dei nove confronti. Un test separato ha riguardato altre tre attività passate. Ha chiaramente migliorato due piani; nel terzo, l'agente non guidato aveva già individuato il problema. Le indicazioni più utili riguardavano i cambiamenti di comportamento, i consumatori e le varianti interessati e i contratti tra API, schemi o parser. Le valutazioni riguardavano solo domande e piani. Non abbiamo misurato se le indicazioni avessero accelerato l’implementazione. Anche le indicazioni specifiche sono diventate obsolete più rapidamente e talvolta sono emerse in attività non correlate. La manutenzione delle indicazioni e delle valutazioni ha richiesto più lavoro rispetto alla creazione della prima versione. Potevamo mappare la mina vagante con le linee guida, disinnescarla risolvendo il problema nel sistema sottostante o accettare il rischio che un agente o un revisore dovesse trovarla di nuovo. Di solito lo mappavamo prima perché era la soluzione più economica. Correggere l'API, il test, la documentazione o l'esempio sottostanti richiedeva più lavoro, ma andava a vantaggio di tutti ed eliminava la necessità di fornire indicazioni. ## Come affronteremmo ora l'approccio /spec-driven Volevamo evitare che i tecnici ripetessero gli stessi prompt e rispiegassero il progetto senza eliminare l'attrito utile. L'agente doveva comunque fermarsi quando aveva una domanda importante, quando mancavano prove o quando il passaggio successivo richiedeva un giudizio umano. Abbiamo elaborato alcune linee guida pratiche: - Per la maggior parte delle modifiche di entità ridotta e circoscritte a un ambito specifico, sono sufficienti una conversazione o un breve piano. - Utilizzare l'approccio spec-first per concordare una direzione. Mantenere le specifiche come punto di riferimento quando le decisioni devono rimanere valide anche nelle sessioni o nei passaggi di consegne successivi. - Non inserire tutti gli elementi mancanti nelle specifiche. L'harness dovrebbe fornire il contesto ed eseguire i controlli; il giudizio sull'architettura richiede comunque una revisione umana. Quando vale la pena mantenere una specifica, scrivetela per il prossimo lettore. Fate in modo che le decisioni e i rischi siano facili da trovare, inserite link alle prove invece di copiarle e decidete cosa dovrebbe accadere alle specifiche al termine del progetto. ## Quali sono i prossimi passi? Dopo tre mesi, i progettisti continuano a utilizzare /spec-driven quando il lavoro si estende su più sessioni, passa da una persona all'altra o si suddivide in molte attività correlate. L'hanno utilizzato per portare avanti progetti della durata di diversi mesi e per organizzare grandi gruppi di attività gestite dagli agenti. Questo è un buon risultato per un esperimento interno. Man mano che abbiamo ampliato /spec-driven per supportare più tipi di lavoro, alcune nuove funzionalità hanno risolto problemi reali per team specifici, ma hanno reso il flusso di lavoro più complesso per tutti. Nella prossima versione, vogliamo puntare a un nucleo più piccolo e mirato. Le persone hanno opinioni forti su SDD e sull'ingegneria dei cablaggi. Abbiamo imparato di più provandoli su un lavoro reale che discutendone. Prima di aggiungere altri processi, ora chiediamo cosa manca all'agente in quel progetto. Iniziate in piccolo, osservate dove il flusso di lavoro è d'aiuto o d'intralcio, quindi apportate modifiche in base a ciò che avete imparato. [1] Birgitta Böckeler, “[Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)”, ottobre 2025. [2] François Zaninotto, "[Spec-Driven Development: The Waterfall Strikes Back](https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html)", novembre 2025. [3] Gabriella Gonzalez, "[A sufficiently detailed spec is code](https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code)", marzo 2026. #### **Informazioni sull'autore** Walter Li è un informatico del team Core Storage Infrastructure di Asana e Rohan Batra è un informatico del team Backend Frameworks. Entrambi hanno trascorso alcuni mesi nel team Agent Success Tiger, dove hanno guidato lo sviluppo e la valutazione del flusso di lavoro /spec-driven descritto in questo articolo. #### **Ringraziamenti al team** Un ringraziamento speciale a Leo Zhang, Karol Krupa, Gordie Levitsky e Mitch Conquer per averci aiutato a definire e sviluppare /spec-driven e per essere stati tra i primi ad adottarlo. - [Scalabilità di LunaDb, il nostro sistema interno di caricamento dei dati dichiarativi](/it/resources/scaling-lunadb) Progettazione #### Ingegnere/a di piattaforme Noi di Asana abbiamo creato un sistema di caricamento dei dati chiamato LunaDb, che funge da spina dorsale della nostra app web. Nonostante il nome, non è un database. Piuttosto, ... - [Come Asana mi rende un responsabile tecnico più efficiente](/it/inside-asana/asana-makes-me-effective-engineering-manager) Progettazione #### Responsabile ingegneria infrastruttura dei dati As an engineering manager, I need to keep track of so many things. I have my own personal to-dos that I need to prioritize, making time for focused work while also handling incomi ... - [Scalare la nostra pipeline di invalidazione: Parte 1](/it/inside-asana/scaling-invalidation-pipeline-part-1) Progettazione #### Ingegnere/a di piattaforme At Asana, our invalidation pipeline is a key part of implementing near-realtime reactivity in the webapp. Reactivity is how each-and-every Asana tab keeps up-to-date with the lat ... - [Sviluppo basato sulle specifiche: gli aspetti positivi e ciò che abbiamo appreso dopo tre mesi](/it/inside-asana/spec-driven-development) Progettazione Dopo tre mesi, avevamo un quadro più chiaro di quando la struttura aggiuntiva fosse stata d'aiuto e quando invece avesse costituito un ostacolo.Uno dei nostri ingegneri stava prep ... - [Progettazione](/inside-asana/engineering-spotlight)