Negli ultimi anni l’intelligenza artificiale è entrata rapidamente nel campo dell’architettura, introducendo strumenti capaci di intervenire in momenti molto diversi del processo progettuale. Oggi è possibile trasformare uno schizzo in un’immagine, generare alternative formali, produrre visualizzazioni e render o utilizzare modelli linguistici come supporto nella produzione e nell’organizzazione delle informazioni.
Gran parte di queste applicazioni si concentra però soprattutto all'inizio e alla fine del processo. Da una parte l’IA viene utilizzata per l’ideazione e l’esplorazione di possibili soluzioni; dall’altra interviene nella rappresentazione, nella visualizzazione e nella comunicazione del progetto.
Tra questi due momenti esiste però una fase più complessa e meno immediata: quella in cui il progetto prende realmente forma attraverso modellazione, modifiche, verifiche, correzioni e sucessive decisioni progettuali. È una fase nella quale il modello non rappresenta un risultato definitivo, ma uno strumento che cambia continuamente insieme al progetto.
La ricerca si concentra su questo spazio intermedio, chiedendosi non soltanto se l’IA possa generare un modello 3D, ma se sia in grado di accompagnarne lo sviluppo mentre il progetto cambia.
Il lavoro si inserisce inoltre in un percorso più ampio sul rapporto tra intelligenza artidiciale e architettura. La presentazione utilizza Archì, una piattaforma web nata da un progetto di ricerca già avviato dal relatore e dal correlatore, che questa tesi contribuisce ad ampliare come spazio aperto a future sperimentazioni.
La ricerca prende avvio da un’analisi della letteratura scientifica sul rapporto tra LLM e modellazione digitale in architettura. A partire da un insieme più ampio di pubblicazioni, l’attenzione è stata progressivamente ristretta ai contributi che presentavano una relazione diretta tra linguaggio naturale e ambienti CAD, parametrici o BIM.
Sono stati quindi selezionati cinque studi particolarmente pertinenti, accomunati dal tentativo di ridurre la distanza tra intenzione progettuale e strumenti di modellazione, ma differenti per modalità di interazione, livello di automazione e ruolo attribuito all’intelligenza artificiale.
Il confronto tra questi lavori permette di osservare approcci diversi allo stesso problema e di individuare con maggiore precisione ciò che risulta ancora poco esplorato.
I contributi realmente vicini a questa fase del processo progettuale risultano ancora relativamente pochi. Gli studi analizzati dimostrano comunque possibilità differenti: alcuni traducono il linguaggio naturale in comandi o codice, altri generano geometrie parametriche, altri intervengono su modelli BIM o utilizzano l’IA per costruire strumenti digitali di supporto alla progettazione.
Il limite emerge quando queste capacità devono essere utilizzate all'interno dello stesso processo e su problemi tra loro differenti. Molti sistemi risultano infatti efficaci nel compito per cui sono stati sviluppati, ma dipendono da script, parametri, componenti o strutture predisposte in anticipo. Quando cambia l’obiettivo progettuale, spesso è necessario modificare anche il sistema attraverso cui l'IA può intervenire.
Anche gli approcci più estesi riescono quindi ad accompagnare più fasi o più operazioni, ma mantengono una certa dipendenza da strumenti costruiti per esigenze specifiche. Questo limita la possibilità di passare liberamente, per esempio, dalla generazione di una geometria alla sua modifica, dalla risoluzione di un dettaglio alla riorganizzazione di una parte più ampia del modello.
Il problema non riguarda quindi soltanto la capacità dell'IA di eseguire una singola operazione, ma il modo in cui questa può inserirsi in un processo che cambia continuamente obiettivi, scala e livello di dettaglio. Un sistema realmente utile dovrebbe poter affrontare richieste anche molto diverse senza richiedere ogni volta una nuova configurazione. Dovrebbe inoltre riuscire a mantenere il legame con ciò che è già stato costruito, invece di ripartire da una struttura definita per un singolo compito.
Ciò che emerge come ancora poco sviluppato è quindi un workflow flessibile e riutilizzabile, capace di affrontare problemi progettuali diversi senza richiedere ogni volta una nuova struttura operativa, e di mantenere una relazione con lo stesso modello mentre il progetto viene progressivamente trasformato.
La lacuna individuata riguarda la continuità tra più richieste e la possibilità di mantenere una relazione con il modello già costruito.
Manca, in particolare, un approccio sufficientemente flessibile e riutilizzabile, capace di affrontare operazioni differenti senza richiedere ogni volta la predisposizione di una nuova struttura.
A partire da questa lacuna è stata impostata la sperimentazione. Sono state prese in esame configurazioni differenti di interazione tra progettista, modello linguistico e ambiente di modellazione, osservando come il cambiamento di strumenti e modalità operative modificasse il rapporto tra questi elementi.
L’obiettivo non era costruire un confronto numerico tra sistemi né individuare semplicemente quale fosse il migliore, ma verificare come ciascuna configurazione si comportasse durante il lavoro sul modello. L’attenzione si è concentrata sulla qualità dell’interazione, sulla possibilità di proseguire le operazioni già avviate, sul livello di controllo mantenuto e sulla quantità di mediazione tecnica richiesta.
Anche gli errori, i risultati parziali e le configurazioni progressivamente abbandonate sono stati considerati parte della sperimentazione, perché utili a comprendere quali condizioni favorissero o ostacolassero l'integrazione dell'IA nel processo di modellazione.
La sperimentazione si è sviluppata attraverso una successione di modelli con complessità progressivamente maggiore, utilizzati per verificare come l’IA affrontasse problemi geometrici e architettonici differenti.
Le prime prove hanno riguardato geometrie elementari, come una flangia composta da cerchi concentrici e fori radiali, utili soprattutto per osservare la capacità di scomporre una forma in primitive, parametri e relazioni.
Successivamente il campo è stato ampliato a ricostruzioni architettoniche, utilizzando più volte il Padiglione di Barcellona come riferimento. Le prime versioni erano fortemente semplificate e riconducevano l’edificio ai suoi elementi principali, mentre le prove successive hanno cercato di ricostruire in modo più articolato basamento, pareti, vasche, coperture e colonne.
Sono stati poi generati modelli tridimensionali modificabili, tra cui un primo grattacielo, differenti versioni dello stesso padiglione e una sedia le cui proporzioni potevano essere variate attraverso grasshopper mantenendo la stessa logica geometrica.
Le immagini mostrano quindi un insieme eterogeneo di risultati. Più che una raccolta di modelli finali, rappresentano il percorso attraverso cui la sperimentazione è passata da forme semplici a configurazioni architettoniche progressivamente più articolate.
Con il procedere delle prime prove, Rhino è emerso come l'ambiente più adatto alla sperimentazione. La scelta permetteva di mantenere all’interno dello stesso ecosistema modalità di lavoro differenti: modellazione diretta, scripting attraverso Python e modellazione parametrica con Grasshopper.
Questo rendeva possibile confrontare diverse forme di integrazione dell’intelligenza artificiale senza cambiare continuamente ambiente di modellazione e, allo stesso tempo, lavorare all’interno di un software adatto allo sviluppo effettivo di un progetto architettonico, dalla costruzione del modello tridimensionale fino alla produzione degli elaborati.
Non è stato invece individuato fin dall’inizio un unico sistema di intelligenza artificiale. La sperimentazione è proceduta attraverso configurazioni differenti, modificando progressivamente il modo in cui il modello linguistico comunicava con Rhino.
Le prime prove hanno utilizzato Gemini per verificare come un modello linguistico potesse descrivere e produrre informazioni geometriche interpretabili da un ambiente CAD. Questi tentativi hanno progressivamente spostato l’attenzione dalla semplice rappresentazione della geometria alla possibilità di descriverne direttamente il procedimento attraverso il codice.
Il passaggio successivo ha portato all’utilizzo di Claude per generare script Python eseguibili direttamente in Rhino. Una richiesta formulata in linguaggio naturale poteva così essere trasformata in una procedura capace di costruire concretamente la geometria all’interno del modello.
Questa configurazione rendeva già possibile un primo ciclo di generazione e correzione, ma manteneva una forte mediazione manuale. Il codice doveva essere trasferito in Rhino ed eseguito; eventuali errori dovevano poi essere recuperati, riportati nella conversazione e utilizzati come base per una nuova versione dello script.
Le sperimentazioni successive hanno quindi cercato di ridurre progressivamente questa distanza, passando dal codice trasferito manualmente, al controllo parametrico attraverso Grasshopper, fino a forme di integrazione sempre più diretta tra modello linguistico e ambiente di modellazione.
Il workflow finale nasce proprio da questa evoluzione: non dalla scelta iniziale di un singolo strumento, ma dal confronto tra modalità diverse di collegare linguaggio naturale, logica computazionale e modello 3D.
Nelle configurazioni precedenti, intelligenza artificiale e modello tridimensionale rimanevano ancora due ambienti separati. L’IA poteva produrre istruzioni e codice, ma era il progettista a trasferire continuamente informazioni tra la conversazione e il software di modellazione.
L’introduzione del Model Context Protocol (MCP) e del plugin RhinoAiMCP ha modificato questa struttura. Il plugin crea un collegamento tra Claude e Rhino attraverso un server locale che mette a disposizione del modello linguistico alcuni strumenti specifici. Nella configurazione utilizzata durante la ricerca, Claude poteva interrogare il documento attraverso get_scene, ottenendo informazioni sugli elementi presenti, e utilizzare rhinoceros_operator per richiedere l’esecuzione di operazioni direttamente all’interno di Rhino.
L’accesso non era completo né indiscriminato: Claude poteva conoscere e modificare soltanto ciò che gli strumenti messi a disposizione dal server MCP gli consentivano di leggere o utilizzare. La differenza rispetto alle prove precedenti era però sostanziale. Il progettista non doveva più trasferire manualmente ogni script o descrivere nuovamente lo stato del modello a ogni passaggio.
Il workflow assumeva così una struttura più continua. Una richiesta poteva essere formulata direttamente in linguaggio naturale; Claude poteva interpretarla, interrogare il documento quando necessario e richiedere un’operazione sulla geometria già presente. Il risultato veniva osservato e verificato e, se erano necessarie ulteriori modifiche, la richiesta successiva poteva partire dallo stato appena raggiunto, senza ricostruire ogni volta il modello da zero.
Questo passaggio ha cambiato anche il ruolo del modello tridimensionale all’interno della ricerca. Non era più soltanto l’output finale di una singola generazione, ma diventava il supporto sul quale conservare, verificare e sviluppare le trasformazioni del progetto.
Raggiunto questo livello di integrazione, le prove costruite appositamente per verificare singole funzioni iniziavano però a essere insufficienti. Da qui nasce il passaggio alla seconda fase della ricerca: l’applicazione del sistema a un vero processo progettuale.
Per mettere alla prova il workflow al di fuori di esercizi costruiti appositamente per la sperimentazione, è stato scelto il concorso internazionale Urban Toilets, dedicato alla progettazione del bagno pubblico come elemento capace di incidere sull’esperienza dello spazio collettivo. Il tema richiama un approccio ispirato alle esperienze giapponesi, nelle quali il servizio viene trattato come uno spazio architettonico dotato di una propria identità e capace di contribuire alla qualità dello spazio pubblico.
La scelta risultava particolarmente adatta alla ricerca perché affrontava una funzione essenziale della città, spesso considerata secondaria dal punto di vista progettuale, mettendo però in gioco questioni molto concrete: privacy, accessibilità, sicurezza, igiene, manutenzione, circolazione e rapporto con il contesto.
Il brief lasciava allo stesso tempo una notevole libertà. Non erano imposti una geometria, una superficie massima, un numero prestabilito di unità o una specifica organizzazione funzionale; anche sito e materiali potevano essere scelti liberamente. Questa apertura permetteva di sviluppare il progetto senza partire da una soluzione formale già definita e di osservare come le decisioni successive modificassero realmente il modello.
Urban Toilets era inoltre alla prima edizione. Non esistevano quindi progetti vincitori o tavole precedenti da utilizzare, anche indirettamente, come riferimento formale: il progetto doveva confrontarsi soprattutto con il brief, le FAQ e i criteri dichiarati dagli organizzatori.
La consegna introduceva infine un obiettivo concreto: sviluppare la proposta fino alla produzione di un unica tavola A1 orizzontale, accompagnata da un testo descrittivo. Il caso studio non richiedeva quindi soltanto la costruzione di alcune geometrie, ma portava il workflow dalla definizione dell’idea fino alla rappresentazione complessiva del progetto.
Alla struttura del concorso è stata aggiunta una condizione specifica della ricerca: concentrare l'intero sviluppo in meno di dieci giorni. Non si trattava di un limite imposto dal bando né di un test quantitativo di produttività, ma di una scelta metodologica pensata per raccogliere in un periodo ristretto una sequenza intensa di generazioni, verifiche e modifiche.
La durata ridotta permetteva inoltre di affrontare una criticità tipica delle ricerche su strumenti in rapidissima evoluzione: evitare che la ricerca venisse superata dagli stessi strumenti che stava analizzando.
All’interno di queste condizioni nasce SQRCL, un progetto che interpreta il bagno pubblico non come un edificio isolato, ma come un infrastruttura urbana capace di adattarsi a contesti ed esigenze differenti.
Il sistema prende forma a partire da una griglia regolare di 2 x 2 metri scelta anche sulla base di considerazioni emerse nelle sperimentazioni precedenti. La griglia offre una struttura semplice e riconoscibile sulla quale organizzare progressivamente il progetto, senza definire fin dall’inizio una configurazione unica e definitiva.
Su questa matrice vengono inserite capsule prefabbricate modulari, pensate per poter essere aggiunte, rimosse o sostituite nel tempo. Lo stesso sistema può così cambiare dimensione, capacità e organizzazione mantenendo però un linguaggio architettonico comune.
La modularità non riguarda soltanto i servizi igienici. Il progetto comprende anche spazi di transizione, attesa, sedute ed elementi tecnici, permettendo alla composizione di adattarsi alle caratteristiche del luogo e di costruire una relazione più articolata con lo spazio pubblico.
Anche materiali e sistema costruttivo seguono questa impostazione: capsule leggere e traslucide in policarbonato, associate a una struttura metallica e a componenti concepiti per la prefabbricazione, la sostituzione e la riconfigurazione.
A partire dal primo modulo è stata sviluppata progressivamente una famiglia di capsule con dimensioni e funzioni differenti, fino alla costruzione di un vero e proprio abaco. Ogni elemento manteneva la stessa matrice geometrica e lo stesso linguaggio, ma poteva adattarsi a esigenze diverse all’interno del sistema.
Una volta definita questa famiglia, la composizione generale non è stata affidata esclusivamente all’intelligenza artificiale. Alcune parti sono state organizzate e modificate direttamente in Rhino, introducendo nel processo un passaggio importante: l'intervento manuale del progettista non interrompe il workflow.
Grazie alla possibilità di interrogare nuovamente lo stato aggiornato del documento, Claude può infatti riprendere il lavoro anche dopo modifiche eseguite direttamente sul modello. Non è necessario descrivere nuovamente tutto ciò che è cambiato o ricostruire da zero il contesto precedente: la geometria presente in Rhino diventa il nuovo punto di partenza.
Il processo assume così una natura realmente ibrida. Alcune operazioni vengono sviluppate attraverso l’intelligenza artificiale, altre direttamente dal progettista, ma entrambe intervengono sullo stesso modello e possono alternarsi durante l’evoluzione del progetto.
Un altro esempio particolarmente significativo è stato lo sviluppo della porta scorrevole della capsula d'ingresso. La prima configurazione prevedeva una serie di elementi verticali capaci di seguire la curvatura del modulo ed era già sufficientemente completa rispetto alla richiesta iniziale. Una volta osservato il risultato, però, sono emerse nuove esigenze progettuali.
La porta è stata quindi modificata attraverso una successione di passaggi: sono cambiate dimensioni e numero delle lamelle, distanza tra gli elementi profilo esterno, percorso del sistema di scorrimento e alcuni dettagli funzionali. Ogni versione veniva valutata e utilizzata come base per quella successiva.
Questo esempio evidenzia un aspetto centrale della sperimentazione: una nuova richiesta non nasce necessariamente dalla correzione di un errore. Può nascere semplicemente dall’osservazione del risultato e da una nuova decisione del progettista. Il modello diventa così uno spazio nel quale generazione, verifica e revisione possono susseguirsi senza ripartire ogni volta dall’inizio.
La sperimentazione ha però mostrato anche i limiti di questa modalità operativa. Nel caso di alcune aperture delle capsule, successive strategie di correzione non sono riuscite a produrre con sufficiente controllo il profilo geometrico richiesto. In questi casi l’operazione è stata completata direttamente in Rhino.
Sono emerse inoltre difficoltà nelle operazioni più onerose e nelle scene più articolate, insieme all’assenza di un sistema integrato di versionamento del modello. Per conservare stati precedenti e poter tornare indietro durante la sperimentazione è stato quindi necessario ricorrere a salvataggi manuali.
Questi limiti fanno parte dei risultati della ricerca tanto quanto le operazioni riuscite. Permettono di distinguere dove il workflow riesce ad accompagnare efficacemente lo sviluppo del progetto, dove rimane necessario l’intervento diretto del progettista e quali aspetti richiedono ancora un’evoluzione degli strumenti.
La ricerca prendeva avvio da una domanda volutamente ampia: l'intelligenza artificiale è oggi in grado di progettare?
Al termine della sperimentazione, la risposta non può essere ridotta a un semplice sì o no.
La capacità dell’IA di generare geometrie non rappresentava infatti il punto centrale del lavoro. L’obiettivo era capire se potesse entrare in maniera più concreta nel processo progettuale, mantenendo una relazione con lo stesso modello mentre questo viene costruito, modificato e progressivamente ridefinito.
La sperimentazione ha però evidenziato anche che non tutte le operazioni traggono lo stesso vantaggio dall'assistenza dell'IA. Trasformazioni ripetitive o geometricamente articolate possono risultare particolarmente adatte a questo tipo di interazione, mentre operazioni semplici, visive o fortemente compositive possono essere più immediate se svolte direttamente dal progettista.
Per questo, allo stato attuale, il risultato più significativo non coincide con la sostituzione della modellazione tradizionale, ma con la possibilità di costruire un workflow ibrido. Il progettista può intervenire manualmente quando il controllo diretto risulta più efficace e affidare all’intelligenza artificiale le operazioni per le quali questa offre un vantaggio, passando continuamente da una modalità all’altra senza abbandonare lo stesso modello.
Il risultato non è quindi la proposta di un sistema autonomo che sostituisca l’architetto, ma la sperimentazione di un nuovo rapporto tra progettista, intelligenza artificiale e modello digitale. Un rapporto nel quale l’IA può ridurre parte della mediazione tecnica tra intenzione e modello, mentre le decisioni progettuali, la verifica dei risultati e la responsabilità delle scelte rimangono affidate all'architetto.
È in questo passaggio che si colloca il senso complessivo della ricerca: spostare l'attenzione dalla forma al processo. Il valore dell’intelligenza artificiale non risiede soltanto nella capacità di produrre un oggetto tridimensionale, ma nella possibilità di partecipare alle trasformazioni successive attraverso cui un progetto prende forma.
I limiti emersi durante la sperimentazione devono essere letti anche in relazione a un contesto tecnologico che cambia molto rapidamente. Timeout, difficoltà nella gestione di scene complesse o problemi nella ricostruzione di alcune geometrie descrivono le condizioni attuali degli strumenti utilizzati, ma non necessariamente limiti permanenti di questo tipo di integrazione.
Uno sviluppo immediato riguarda quindi il miglioramento della capacità di leggere e gestire modelli più articolati, l’affidabilità delle operazioni geometriche e l’introduzione di sistemi di versionamento e ripristino del modello. Parallelamente, è plausibile immaginare un’integrazione sempre più diretta dell’intelligenza artificiale nei software di progettazione, trasformando collegamenti oggi ancora sperimentali in funzioni accessibili direttamente all’interno dell’ambiente di lavoro.
Su un orizzonte più ampio, il tema riguarda però soprattutto il rapporto tra progettista e strumento digitale. Questo rapporto potrebbe estendersi anche ad ambienti immersivi, realtà virtuale o aumentata, verifiche normative, simulazioni e altri sistemi specializzati, mantenendo il modello tridimensionale come spazio comune di lavoro.
Questa tesi vuole essere un punto di partenza per una ricerca capace di evolvere insieme agli strumenti che sta studiando.
La domanda futura non riguarda soltanto quanto l’intelligenza artificiale sarà in grado di modellare, ma come cambierà il nostro modo di progettare quando diventerà parte integrante degli strumenti con cui lavoriamo.