Luca Tronchin, Software Engineering Manager di Bitrock, ha partecipato a KanDDDinsky 2026 a Berlino. Nell’articolo che segue, condivide i suoi principali spunti e riflessioni da due giorni trascorsi a esplorare la potente interazione tra IA, sistemi agentici e Domain-Driven Design, offrendo una lettura avvincente sul perché la modellazione del dominio sia oggi più critica che mai.
A metà ottobre ho trascorso due giorni a Berlino a KanDDDinsky, la conferenza della community europea sul Domain-Driven Design. Il tema di quest’anno era come il DDD e lo sviluppo agentico si rafforzino a vicenda. Mi aspettavo demo di agenti che scrivessero codice per noi. Ho trovato invece quattordici sessioni che, da angolazioni diverse, sono giunte alla stessa conclusione: l’IA ci rende più veloci, ma da sola non ci avvicina di un passo a ciò di cui il business ha effettivamente bisogno.
In questo articolo condivido le idee che ho portato a casa e perché, a mio parere, rendono le pratiche di modellazione più importanti oggi di quanto non lo fossero prima dell’AI.
L’AI moltiplica, confusione inclusa
Il keynote di apertura di Roman Sachse, basato sul suo lavoro presso un’azienda di logistica tedesca con 150 anni di storia, ha fornito la chiave di lettura dell’intera conferenza: l‘AI è un moltiplicatore, e un moltiplicatore applicato allo zero dà zero. Dove c’è un dominio solido, con processi e struttura, l’IA aggiunge un enorme valore. Dove c’è solo fuffa, amplifica la fuffa.
Vlad Khononov ha affermato la stessa cosa da un punto di vista architetturale: l’AI moltiplica i benefici della modularità, ma anche i danni quando la modularità manca. Un Big Ball of Mud è il terreno ideale per far sì che un agente produca caos più velocemente. Beija Nigl lo ha confermato con un’esperienza concreta: una codebase legacy priva di test o documentazione, presa in carico con il mandato di usare l’IA per tutto. Quando il team ha capito il dominio, l’AI li ha velocizzati; quando non lo aveva ancora capito, l’AI li ha portati fuori strada con assoluta sicurezza.
Il collo di bottiglia non è mai stato il codice
Se l’AI scrive il codice dieci volte più velocemente, perché i prodotti non vengono rilasciati dieci volte prima? Susanne Kaiser ha risposto con un dato che mi è rimasto impresso: in uno studio su 500.000 sviluppatori che utilizzano agenti di codifica, le pull request sono cresciute dell’86% e le righe di codice del 958%, ma i rilasci in produzione soltanto del 20%. Il lavoro si accumula prima di raggiungere l’utente.
Come ha sottolineato Susanne Kaiser, citando la Theory of Constraints di Eli Goldratt, qualsiasi miglioramento apportato al di fuori del collo di bottiglia è un’illusione: l‘AI non rimuove i colli di bottiglia; li espone. E il collo di bottiglia, come hanno ribadito Marco Heimeshoff e Alberto Brandolini, non è mai stato scrivere codice. È capire cosa si suppone che il software significhi. Senza un dominio chiaro, un LLM peggiora le cose prima di migliorarle: amplifica ogni ambiguità nel linguaggio, a tutta velocità e con totale sicurezza.
Nel keynote di chiusura, anche Andrea Magnorsky ha mostrato il prezzo di questa accelerazione. Secondo la telemetria di Faros AI su 22.000 sviluppatori, con una forte adozione dell’IA, le epic completate per sviluppatore crescono del 66%, ma gli incidenti per pull request aumentano del 243% e i bug per sviluppatore del 54%. In un sondaggio australiano sui benefici percepiti dell’IA, la “velocità” ha raccolto il 36% delle risposte e la “migliore qualità del codice” lo 0%.
Roman Sachse ha aggiunto un’osservazione che trovo illuminante. L’IA ha drasticamente accorciato ogni ciclo che passa attraverso un artefatto: un’idea viene provata il lunedì e valutata il martedì. Ma tutto ciò che passa attraverso le persone e le strutture organizzative richiede lo stesso tempo di prima. È lì che si sta giocando ora la trasformazione.
Bounded Context e Ubiquitous Language: le fondamenta degli agenti
La parte più concreta della conferenza ha riguardato la costruzione di sistemi agentici affidabili. Marco Heimeshoff ha ribaltato la prospettiva abituale: non è l’IA che ci aiuta a modellare, ma è la modellazione che fa funzionare l’IA. La risposta non è un prompt migliore; è l’harness: l’intero sistema costruito attorno al modello affinché svolga un lavoro affidabile senza che qualcuno debba sorvegliare ogni singolo passo.
E ciò che tiene insieme un buon harness è esattamente ciò in cui il DDD si è specializzato in quindici anni. I bounded context offrono a ciascun agente un mondo piccolo e ben recintato, con un contesto essenziale che impedisce al modello di vagare e sprecare token. L’Ubiquitous Language fissa l’intento, cosicché ciò che l’agente costruisce sia ciò che il business ha chiesto. Il consiglio pratico che ho portato a casa: partire dagli harness esistenti, per poi costruire il proprio, legato al dominio e alle parti del dominio di cui ciascun task ha bisogno.
Susanne Kaiser ha aggiunto un dettaglio che sembra piccolo ma non lo è: le prestazioni degli LLM calano quando i nomi nel codice perdono il loro significato. Un naming coerente e capace di rivelare le intenzioni serve sia alle persone che alle macchine. Golo Roden ha completato il quadro dal lato dei dati: l’event sourcing conserva non solo ciò che è accaduto, ma anche il perché, il quando e in quale ordine. Questo è esattamente il contesto che manca alla maggior parte dei sistemi di IA, i quali recuperano testo ma non significato.
Caratteristiche, prospettive future e costo totale
Una citazione di Kent Beck è ritornata in almeno tre talk: il valore economico di un progetto non è solo la somma delle funzionalità che possiede oggi, ma anche delle sue “opzioni future” (futures), le possibilità per ciò che potrà fare domani. L’AI velocizza la costruzione delle funzionalità, ma può bruciare le opzioni future altrettanto rapidamente. Le slide di Susanne Kaiser citano ricerche che mostrano come l’applicazione dell’IA a codice già problematico comporti un rischio di difetti superiore del 60%, e che i guadagni di produttività svaniscono nel giro di un paio di mesi sotto il peso della complessità e del debito tecnico.
Xin Yao ci ha ricordato che la metafora originale del debito tecnico di Ward Cunningham non riguardava il codice scritto male: riguardava l’apprendimento. Costruiamo con ciò che sappiamo oggi, impariamo usando il software, e il buon design di ieri non è più sufficiente. In altre parole, il valore di oggi è il debito tecnico di domani. Con il codice generato dall’IA, questo ciclo si accorcia e il debito si accumula più velocemente.
Poi c’è una domanda che sentiremo sempre più spesso: se costruire costa così poco, perché non generare tutto? Perché economico da generare non significa economico da possedere. La costruzione iniziale rappresenta circa il 20–30% del costo totale del ciclo di vita di un’applicazione; il resto è manutenzione, operatività, supporto ed evoluzione. Jacopo Romei ha portato lo stesso principio al di fuori del software, raccontando come ha fondato le sue aziende: le decisioni più irreversibili dovrebbero essere posposte finché non aiutano a comprendere le opportunità future, anziché precluderle troppo presto.
La parte che l’AI non fa: modellare insieme
Il talk di Alberto Brandolini, il creatore dell’EventStorming, è stato per me il più rivelatore. Ha descritto la riscrittura di un software personale con l’IA, ricoprendo lui stesso ogni ruolo: esperto di dominio, cliente, sviluppatore, architetto. Da soli è facile e potente. Ma è una grande semplificazione rispetto ai progetti reali, dove la conoscenza deve essere estratta a fatica dagli esperti di dominio e le persone devono concordare su un modello comune. Qui l’IA non aiuta: tende ad approvare, non ribatte e non fa emergere i dubbi che una buona sessione di modellazione porta alla luce.
Xin Yao è andata oltre: il debito più profondo in molti team non è tecnico; è sociale. Si accumula quando le assunzioni passano inosservate, quando i modelli mentali non cambiano, quando nessuno si prende la responsabilità di decidere in condizioni di incertezza.
Il keynote di chiusura di Andrea Magnorsky ha riportato la conversazione sulle persone. Partendo dalla storia di licenziamenti in un’azienda in crisi e da progetti greenfield in cui tutti dicono di sì ma ogni persona immagina un prodotto diverso, ha proposto un ciclo in tre fasi: costruire la community, comprendere, agire. Tra gli strumenti concreti: rendere esplicito il processo decisionale con gli Architecture Decision Record e il processo di consulenza di Andrew Harmel-Law, in cui chiunque può prendere una decisione architetturale dopo aver chiesto consiglio a coloro che ne saranno impattati e a chi ha esperienza nel settore.
E un semplice contratto sociale: ascoltare per comprendere, non per rispondere, e non per incontrarsi a metà strada. In un momento in cui, secondo un sondaggio da lei citato, il 72% dei lavoratori del settore tech si preoccupa dei licenziamenti e l’84% riferisce burnout, è un promemoria che vale quanto qualsiasi tecnica.
Cosa significa per chi costruisce software
Sono tornato da Berlino con una convinzione ancora più forte di quella con cui ero partito. L’AI non rende il Domain-Driven Design obsoleto: lo rende indispensabile. Per noi di Bitrock che lavoriamo ogni giorno su progetti software con i nostri clienti, questo si traduce in alcune scelte concrete:
- Sistemare il dominio, i confini e la titolarità prima di accelerare con l’IA, perché l’IA amplifica qualsiasi cosa trovi;
- Trattare i bounded context, l’ubiquitous language e il naming come requisiti per gli agenti, non come buone pratiche opzionali;
- Giudicare ogni software generato in base al suo costo di possesso, non solo da quanto velocemente viene alla luce;
- Rendere esplicito come vengono prese le decisioni, perché decidere bene in condizioni di incertezza è un lavoro di squadra;
- Mantenere gli esperti di dominio e il business al centro, con la modellazione collaborativa come momento in cui il valore viene creato.
Come ha detto Susanne Kaiser alla fine del suo talk, niente di tutto questo è nuovo. Ma oggi è necessario più che mai.
Autore: Luca Tronchin, Software Engineering Manager @ Bitrock