Perché l’AI non sa decidere l’infrastruttura (e cosa fare davvero)

Tutti parlano di “lascia che l’AI scriva il codice”. Per la logica di business funziona. Gestori di rotta, query, utility: qui i modelli linguistici si muovono con sicurezza. Ma c’è un punto cieco che resta fuori dalla narrazione.

Appena l’AI tocca un file Terraform, perde il filo.

Il problema del contesto

Il modello sa produrre HCL valido. Il guaio non è la sintassi, è il ragionamento che manca.

Prendi un caso semplice: vuoi aggiungere un evento “ordine creato” da pubblicare su SNS e consumare da SQS. L’AI genera topic, coda, sottoscrizione e policy. Sembra tutto a posto, ma ogni valore numerico e ogni scope sono scelte arbitrarie. Timeout di visibilità a 60 o 600 secondi? Policy ristretta a un bucket o aperta con wildcard? Retention di 14 giorni o default? Il modello sceglie numeri che ha visto spesso, senza sapere nulla del carico reale né degli incidenti successi l’anno scorso.

Il carico di revisione esplode

A prima vista il tempo risparmiato dovrebbe essere enorme. Invece la revisione diventa più pesante. Devi confrontare la sintassi HCL con la semantica IAM, controllare che le risorse rispettino l’architettura della pipeline, ricordare convenzioni mai scritte e verificare che il ruolo del servizio esista nell’account giusto.

Quando qualcosa va storto—timeout sbagliato, policy troppo larga—suona il tuo cercapersone, non la pipeline.

Separazione dei repository, separazione dei contesti

Il nodo non è la mancanza di tool. Puoi aggiungere moduli, cataloghi e validatori, ma il problema resta architetturale: il codice applicativo e quello infrastrutturale vivono in repository diversi, con cicli di revisione diversi. L’AI decide l’infrastruttura senza vedere la logica che dovrà supportare.

Dichiarare l’infrastruttura dentro il codice tipizzato

La via d’uscita è spostare la creazione delle risorse al momento della compilazione. Invece di descrivere topic e code in file separati, dichiari tutto direttamente nel codice TypeScript:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

Il framework genera provisioning, policy e code DLQ in base ai tipi e ai consumer dichiarati. Non ci sono più valori da indovinare: tutto deriva dal codice che userà davvero quelle risorse. La PR diventa un singolo diff TypeScript, senza cinquanta righe di Terraform da controllare a mano.

Perché conta per il “vibe coding”

Puoi delegare la logica di business all’AI perché è isolata e testabile. Per l’infrastruttura serve il contesto che vive altrove. L’unico modo per toglierlo dalle mani dell’agente—e dai revisori costretti a fare da compilatore—è eliminare la cucitura tra applicazione e risorse. Quando il framework compila l’infrastruttura a partire dal codice tipizzato, le decisioni pericolose escono dal campo dell’AI e il “vibe coding” diventa finalmente sicuro anche lì.