Spec-driven Development per Infrastructure as Code: come sviluppare Terraform e OpenTofu nell'era degli agenti AI

Gli strumenti di AI generativa hanno cambiato radicalmente il modo in cui scriviamo software: oggi è possibile chiedere a un agente AI di generare interi moduli Terraform o progettare infrastrutture cloud complete partendo da una semplice descrizione in linguaggio naturale e/o da uno schema architetturale.

Questo approccio, spesso definito vibe coding, permette di ottenere risultati sorprendenti in tempi molto ridotti. Tuttavia, quando il codice viene prodotto principalmente da agenti AI, emerge un problema fondamentale: come garantire che ciò che viene generato sia realmente allineato ai requisiti?

È qui che entra in gioco lo Spec-Driven Development (SDD).

Lo Spec-Driven Development è una metodologia in cui la specifica diventa l’artefatto centrale del processo di sviluppo. Prima di scrivere codice, vengono definiti in modo esplicito requisiti funzionali, vincoli, criteri di accettazione e obiettivi architetturali. Il codice diventa quindi una conseguenza della specifica e non il punto di partenza, come accadeva nell’era pre AI.

Nel contesto dello sviluppo tradizionale questa pratica migliora la comunicazione tra stakeholder e sviluppatori che spesso veniva tralasciata. Con gli agenti AI, invece, assume un’importanza fondamentale. L’AI è infatti estremamente efficace nell’implementare una specifica dettagliata, ma tende a produrre risultati incoerenti quando riceve indicazioni vaghe o incomplete.

Questo principio diventa particolarmente rilevante nel mondo dell’Infrastructure as Code (IaC), dove errori apparentemente piccoli possono generare problemi operativi, costi imprevisti o vulnerabilità di sicurezza.

Applicare lo Spec-Driven Development a Terraform e OpenTofu

Il pattern che si è affermato negli ultimi mesi è questo: prima di aprire l’editor e iniziare a dialogare con un agente AI, si produce un documento di specifica. La specifica è una descrizione strutturata e dettaglaita del comportamento atteso, degli input e output, dei vincoli. Per definire le specifiche, alcuni team usano formati proprietari, altri usano markdown semplice, altri ancora adottano framework specifici come BMAD o OpenSpecs.

L’agente userà quella spec come contesto. Il risultato è che il modello ha meno margine per inventarsi implementazioni creative, e il platform engineer ha uno strumento per valutare se quello che ha generato è corretto rispetto alla specifica che si vuole implementare.

Il vantaggio non è soltanto la qualità del codice generato. La specifica diventa anche documentazione, riferimento per le review e base per i controlli automatici.

Vibe Coding per Infrastructure as Code

Nel contesto Terraform/OpenTofu questo approccio può accelerare enormemente la produttività. Il codice Terraform non descrive comportamenti, descrive risorse. Non scrivi “il sistema deve scalare automaticamente quando il carico supera l'80%”, scrivi aws_appautoscaling_policy con i valori giusti. La distanza tra il requisito di business e il codice è più corta, il che potrebbe sembrare un vantaggio, ma crea un problema diverso.

Quando si chiede ad un LLM di generare un modulo RDS per un ambiente di produzione, il modello produrrà qualcosa di tecnicamente valido. backup_retention_period = 7, multi_az = false, deletion_protection = true. Questi valori non sono sbagliati in assoluto. Ma riflettono delle decisioni: il multi-AZ era stato escluso per motivi di costo o per dimenticanza? La retention di sette giorni è compatibile con la tua RPO (Retention Point Objective)? Se queste specifiche non vengono formalizzate in una specifica, queste non sono decisioni, sono default. E i default in produzione tendono a restare lì finché qualcosa va storto.

Un altro esempio è il seguente, consideriamo un altro prompt:

“Crea un modulo Terraform per distribuire un bucket S3 con versioning abilitato, cifratura AES256 e blocco dell’accesso pubblico.”

L’agente può produrre in pochi secondi un modulo completo comprensivo di: variabili, output, documentazione, policy di sicurezza. Il problema emerge quando si tenta di scalare questo approccio su infrastrutture complesse, o su progetti brownfield, l’agente AI può generare moduli con naming incoerente e poco riutilizzabili, configurazioni duplicate e possibili violazioni degli standard aziendali.

Per questo motivo il vibe coding funziona al meglio quando viene guidato da una specifica strutturata. Una pratica efficace consiste nel dividere il lavoro in due parti: generazione della specifica e generazione del codice

La generazione della specifica puo essere fatta anche con un semplice prompt: “Genera una specifica tecnica per un VPC AWS destinato a un cluster Kubernetes di produzione”. A questo punto è possibile revisionare la specifica per verificare che sia tutto come ce lo si aspetta, prima che l’agente cominci a implementare il codice.

L’esperienza dimostra che la qualità dell’output aumenta significativamente e il numero di iterazioni necessarie diminuisce.

Il ruolo del Plan Mode nello sviluppo assistito da AI

Molti strumenti moderni introducono il concetto di Plan Mode, che cambia il comportamento dell’agente in modo rilevante: invece di procedere direttamente a modificare files, l’agente produce prima un piano dettagliato delle azioni da eseguire e attende l’ approvazione prima di iniziare a scrivere il codice. Viene cosi implementata la pratica a due passi descritta precedentemente.

Per il codice applicativo questo è utile. Per l’infrastruttura è quasi indispensabile, perché le modifiche a un file .tf non sono locali: toccano risorse reali, spesso con effetti che non sono immediatamente reversibili.

Il Plan Mode usato bene è uno strumento potente, è il momento in si analizza quello che l’agente AI ha intenzione di implementare sulla base del prompt, e si verifica che le modifiche proposte sono quelle che ci si aspetta. Se il prompt diceva “aggiungi un lifecycle rule sul bucket S3 per spostare gli oggetti su Glacier dopo novanta giorni” e il piano mostra che intende modificare anche la policy di accesso al bucket, quella divergenza è da correggere prima che venga scritto qualsiasi file.

Framework Spec-Driven: BMAD e OpenSpecs

Negli ultimi mesi sono emersi diversi framework che cercano di strutturare il lavoro degli agenti AI attorno alle specifiche, tra i più interessanti troviamo BMAD e OpenSpecs.

BMAD (Breakthrough Method for Agile AI-Driven Development) introduce un processo in cui ogni attività viene guidata da documenti strutturati che descrivono obiettivi, requisiti, criteri di accettazione etask di implementazione. L’idea centrale è che l’agente AI lavori sempre partendo da artefatti espliciti anziché da prompt isolati.

Applicato a Terraform, un flusso BMAD potrebbe essere:

1. Definizione dei requisiti infrastrutturali.
2. Produzione della specifica tecnica.
3. Revisione della specifica.
4. Generazione dei moduli Terraform.
5. Verifica tramite plan e controlli automatici. Questo approccio riduce la probabilità che l’AI introduca configurazioni indesiderate. La spec non è una formalità: è il documento che un agente AI usa come contesto e che un reviewer umano usa come criterio di verifica.

OpenSpec è un framework diverso, più snello. Per introdurre una modifica, invece di descriverla in un prompt, si utilizza /openspec:proposal con una descrizione dell’intenzione. OpenSpec legge le spec esistenti nel repository, esplora il codice rilevante, e produce una cartella strutturata con quattro file: un documento di proposta, le decisioni di design, i task di implementazione, e i delta delle spec, cioè le differenze tra i requisiti attuali e quelli che la modifica introduce. Tu rivedi tutto questo prima che venga scritto un singolo file.

La cosa interessante, in entrambi i frameworks, è dove vivono le specifiche: nel repository, accanto al codice, organizzate per capability. Non spariscono alla fine della sessione di chat, non restano in un documento condiviso che nessuno aggiorna. Ogni modifica produce un delta leggibile, committabile nella pull request e che dice esattamente cosa cambia nei requisiti del sistema, non solo nel codice.

Conclusioni

L’arrivo degli agenti AI sta trasformando il modo in cui sviluppiamo software e infrastruttura. Nel mondo Terraform e OpenTofu, il semplice utilizzo del vibe coding non è sufficiente per garantire qualità, sicurezza e governance.

Lo Spec-Driven Development offre una risposta concreta a questo problema. Spostando l’attenzione dalla scrittura del codice alla definizione delle specifiche, consente di sfruttare la velocità degli agenti AI mantenendo il controllo sui risultati.

L’integrazione di pratiche come il Plan Mode e l’adozione di framework come BMAD e OpenSpecs permette di costruire un processo più affidabile, in cui l’AI diventa un acceleratore della produttività anziché una fonte di complessità.

Per i team che gestiscono infrastrutture cloud moderne, la combinazione tra Terraform/OpenTofu, agenti AI e Spec-Driven Development rappresenta probabilmente uno dei modelli operativi più promettenti per i prossimi anni.