L’intelligenza artificiale (AI) è ormai pervasiva nel mondo dello sviluppo software e lungo tutto il suo ciclo di vita. Anche le pratiche di Architecture as Code (AaC) possono trarne un beneficio significativo. Il vantaggio, però, non è a senso unico: non è solo l’architettura a guadagnare dall’AI, ma è anche l’AI a diventare più efficace quando opera dentro un contesto architetturale esplicito, rigoroso e verificabile.

È proprio qui che entra in gioco l’Architecture as Code. Per anni l’architettura software è stata affidata a documenti, diagrammi, slide e conoscenza distribuita tra team diversi. Un patrimonio utile, ma spesso incompleto, rapidamente obsoleto e scollegato dall’evoluzione reale di codice, infrastruttura e runtime. Quando i sistemi crescono, questo disallineamento rende più difficile capire il quadro complessivo, prendere decisioni coerenti e mantenere il controllo dell’evoluzione architetturale.

Architecture as Code nasce per affrontare esattamente questo limite: trattare l’architettura come un artefatto vivo, versionato, automatizzabile e verificabile in modo continuo, non come documentazione statica da aggiornare in ritardo.

Il ruolo dell’AI?

In questo scenario, l’AI non è il punto di partenza, ma un abilitatore che riduce drasticamente il costo di rendere l’architettura leggibile, aggiornabile e verificabile. Il suo contributo più importante sta nella capacità di interpretare dati non strutturati – documentazione testuale, codice sorgente, log applicativi, ticket, configurazioni, diagrammi e persino schemi informali – che fino a poco tempo fa era difficile trasformare in conoscenza architetturale utilizzabile. Tutti questi elementi possono diventare input utili per estrarre vincoli, ricostruire modelli, validare scelte architetturali e interrogare in modo più efficace la conoscenza di un sistema.

È qui che il tema diventa rilevante non solo per gli architetti software, ma per l’organizzazione nel suo complesso. L’AI può aiutare a comprendere i sistemi non soltanto per come sono stati progettati, ma anche per come si comportano realmente. Può riconoscere pattern e layer nel codice, individuare violazioni architetturali, correlare segnali provenienti dal runtime, analizzare ticket e backlog, e mettere in relazione queste evidenze con il modello architetturale atteso. In questo modo, la conoscenza distribuita e frammentata può iniziare a trasformarsi in una base più strutturata, interrogabile e utile alla governance.

C’è però una condizione essenziale: l’AI, da sola, non basta. Senza contesto, regole esplicite e riferimenti affidabili, può generare risposte plausibili ma non necessariamente corrette, fino a produrre vere e proprie allucinazioni. L’AI non conosce il sistema, non possiede memoria operativa affidabile delle decisioni prese nel tempo e non può verificare autonomamente la correttezza di ciò che afferma. Per questo, la sua efficacia dipende dalla qualità del sistema di conoscenza entro cui viene inserita.

È qui che la sinergia con l’Architecture as Code diventa decisiva. AaC fornisce all’AI un modello condiviso, vincoli espliciti, decisioni tracciate e regole verificabili; l’AI, a sua volta, rende questi asset più facili da generare, leggere, confrontare e mantenere nel tempo. L’architettura offre struttura e affidabilità, l’AI aggiunge capacità di lettura, correlazione, generazione e validazione su scala. È dall’incontro tra queste due dimensioni che nasce la possibilità di una governance architetturale più continua, concreta e scalabile.

Approcci top-down, bottom-up e combinato

Architecture as Code può essere affrontata secondo tre approcci principali: top-down, bottom-up e combinato. Il primo parte dall’architettura desiderata e la rende esplicita; il secondo osserva il sistema esistente per ricostruirne la struttura reale. Mentre il terzo approccio mette in relazione queste due prospettive. Non si tratta di approcci in competizione, ma di modalità complementari, il cui valore emerge soprattutto quando vengono integrate. L’AI non li crea, ma oggi può renderli più accessibili, continui ed efficaci.

In un approccio top-down, l’AI può supportare la creazione di modelli architetturali a partire da requisiti, bozze o documentazione iniziale, aiutando a trasformare materiali ancora informali in rappresentazioni più ordinate, condivisibili e progressivamente verificabili. Possiamo persino partire da disegni architetturali tracciati su carta e arrivare a modelli strutturati pronti per strumenti come Structurizr o LikeC4. In questo caso, il vantaggio principale è che l’architettura viene dichiarata in modo intenzionale: si definiscono un target, dei vincoli e una direzione evolutiva chiara, utile per guidare i team e rendere più coerenti le decisioni. Il limite è noto: se non viene mantenuto vivo e confrontato con la realtà, il modello rischia di restare corretto sulla carta ma distante dal codice e dal comportamento effettivo del sistema.

Il percorso bottom-up parte invece dalla realtà esistente. Ed è spesso quello più vicino alla situazione concreta di molte aziende, dove i sistemi esistono già da anni e raramente sono nati con pratiche mature di Architecture as Code. Ci troviamo così davanti a un patrimonio applicativo ampio, stratificato e documentato in modo incompleto. In questi contesti l’AI può analizzare semanticamente il codice, leggere log e informazioni di runtime, inferire layer applicativi, riconoscere dipendenze e ricostruire una visione architetturale che non era mai stata formalizzata davvero. Il grande vantaggio di questo approccio è che parte dall’as-is e rende visibile ciò che il sistema fa realmente.
Il suo limite è che, da solo, descrive soprattutto l’esistente e rischia quindi di consolidare il passato più che orientare il futuro.

È per questo che l’approccio combinato è spesso il più efficace. In questo caso il top-down dichiara il modello target e rende espliciti vincoli, decisioni e obiettivi architetturali, mentre il bottom-up osserva il sistema reale, ne ricostruisce l’as-is e mette in evidenza dipendenze, deviazioni e comportamenti emergenti. L’AI agisce come elemento di connessione tra questi due livelli: aiuta a confrontarli, interpretarli e mantenerli allineati nel tempo. In altre parole, il design guida, il sistema risponde e l’intelligenza artificiale rende questo dialogo continuo e sostenibile.

Da questa combinazione nasce uno degli scenari più interessanti: la drift detection. Diventa infatti possibile confrontare ciò che il sistema dovrebbe essere, secondo il modello architetturale dichiarato, con ciò che codice, runtime e topologia mostrano realmente. Questo consente di individuare scostamenti, incoerenze e deviazioni, ma anche di interpretarli meglio: non tutte le differenze sono errori, alcune possono segnalare debito tecnico, altre evoluzioni non ancora formalizzate. È qui che il valore della combinazione tra AI e Architecture as Code emerge con particolare forza, perché rende possibile una governance architetturale più continua e concreta.

Non si tratta, però, solo di controllo. Un altro effetto importante di questi approcci, soprattutto quando vengono integrati, è l’accessibilità della conoscenza architetturale. Qui entra in gioco il concetto di conversational architecture: la possibilità di interrogare l’architettura in linguaggio naturale, chiedere quali vincoli esistono, quali dipendenze sono ammesse, dove si trovano le principali deviazioni o quali ADR motivano una certa scelta. In questo modo la conoscenza architetturale smette di restare confinata nei diagrammi o nella testa di pochi specialisti e diventa più consultabile, condivisibile e utile per team diversi.

L’architettura smette così di essere solo una disciplina di progettazione e diventa sempre più una piattaforma di conoscenza aziendale: una base viva, che può essere aggiornata, verificata e discussa in modo continuo rispetto a requisiti funzionali e non funzionali, ADR, linee guida e comportamento reale dei sistemi. Non più un documento statico scritto una volta e poi dimenticato, ma un patrimonio operativo che accompagna l’evoluzione del software.

In questo senso, considerare l’AI una semplice scorciatoia sarebbe riduttivo. Il suo valore non sta nel “fare tutto da sola”, ma nel rendere più concreto, continuo e praticabile il governo della complessità. L’Architecture as Code fornisce il linguaggio, la struttura e la disciplina; l’intelligenza artificiale aggiunge capacità di lettura, correlazione, generazione e validazione su scala.
Per la prima volta possiamo trattare l’architettura non come qualcosa che descriviamo, ma come qualcosa che il sistema è in grado di leggere, verificare e discutere con noi.