C’è un momento, in ogni ciclo tecnologico, in cui la conversazione cambia registro. Non si parla più se adottare l’AI, ma come — e soprattutto a quale costo organizzativo, cognitivo e di qualità. Se sei un developer senior, probabilmente hai già superato la fase dell’entusiasmo da demo e sei entrato in quella più scomoda: capire cosa funziona davvero quando l’agente lascia il playground e finisce in produzione, in un monorepo con dieci anni di storia, revisionato da un team che non ha scritto quel codice.
Da Codemotion AI & Tech Conference Milano abbiamo selezionato sette talk che, messi in fila, raccontano un percorso di apprendimento coerente: dalla scala organizzativa (centinaia di ingegneri) alla configurazione fine di un singolo agente, dal potenziale individuale alla disciplina necessaria per non farsi travolgere dal rumore. Non è un elogio acritico dell’AI adoption. È, piuttosto, una mappa dei trade-off — esattamente quello che serve a chi deve prendere decisioni tecniche, non solo entusiasmarsi a un keynote.
1. Partire dalla scala: cosa succede quando devi convincere 300 ingegneri
Il punto di partenza naturale è organizzativo. Nel talk “Scaling AI Adoption: The Real Challenges of Transforming 300 Engineers”, Alfonso Graziano racconta cosa significa spingere un’organizzazione oltre la fase di sperimentazione, verso uno sviluppo “AI-native” ripetibile — non un singolo team illuminato, ma centinaia di persone con livelli di maturità molto diversi tra loro.
La parte più utile per un pubblico senior non è la lista dei successi, ma quella dei fallimenti: pattern di resistenza, falsi partenza, over-reliance sugli strumenti e — soprattutto — il divario tra produttività percepita e produttività reale. È un promemoria salutare: l’adozione dell’AI a livello enterprise non è un problema di procurement di licenze, è un problema di cambiamento comportamentale su larga scala, e i numeri di produttività auto-riportati vanno sempre presi con le pinze.
2. Poi la configurazione: l’agente non è un tool, è un sistema da governare
Se il talk di Graziano lavora al livello dell’organizzazione, quello di Alexio Cassani — “Configurare l’harness: da Claude Code come tool a Claude Code come sistema di lavoro” — scende al livello dell’ingegneria vera e propria. La tesi è netta: un coding agent moderno arriva già con il suo harness; quello che cambia i risultati non è costruirne uno da zero, è configurarlo bene.
Cassani attraversa le superfici che governano il comportamento dell’agente — istruzioni di progetto, skill, permessi, hook, subagent, MCP, fino al plugin che rende la configurazione condivisibile in team — e insiste su un punto che ogni tech lead dovrebbe interiorizzare: non tutte le regole vanno nello stesso posto. Una conoscenza contestuale non è un hook. Un vincolo che deve valere sempre non è una riga di istruzioni infilata in un prompt. È una lezione di architettura, applicata alla governance degli agenti, non di prompt engineering.
3. Il potenziale individuale: quando un solo ingegnere sostituisce un team
Da qui il discorso si sposta sul singolo contributor. “Kill the Standup: How One Engineer Ships What Five Cannot” di Matteo Collina è probabilmente il talk più provocatorio del gruppo. Partendo dalla legge di Brooks sui canali di comunicazione — che crescono come n(n-1)/2 — Collina sostiene che l’AI ha cambiato l’equazione: un singolo ingegnere con autonomia, gusto tecnico e un’AI che rimuove il collo di bottiglia sul throughput può spedire in due settimane quello che un team spedisce in due mesi.
Ma il talk non è un panegirico ingenuo. Collina è esplicito su cosa succede quando il modello si rompe: autonomia senza gusto tecnico produce disastri, e lui stesso lo ammette raccontando di aver introdotto una vulnerabilità in produzione con una PR assistita da AI che non ha revisionato a dovere. È un caso di studio prezioso proprio perché non nasconde il rischio: la “cave engineering” funziona solo se il gusto tecnico regge il peso dell’autonomia.
4. Il contrappunto necessario: quando l’adozione produce solo “slop”
Ogni narrazione sull’AI adoption che si rispetti ha bisogno di un contrappeso, e qui arriva “Everything is slop, let’s slow the fk down”** di Mario Zechner. Il talk parte da un’osservazione che chiunque mantenga un progetto open source conosce fin troppo bene: repository sommersi da issue e PR generate da agenti, esperienze entusiasmanti su progetti hobby greenfield che non si traducono affatto in codebase di produzione reali.
È il talk che un pubblico senior aspetta in ogni conference sull’AI: quello che non vende la trasformazione ma la mette in discussione, chiedendo come si possa recuperare disciplina e agency senza rinunciare del tutto ai benefici degli strumenti agentici. Messo accanto ai talk di Graziano e Collina, funziona da correttivo epistemico: l’adozione ha un lato oscuro fatto di volume senza qualità, ed è bene saperlo prima di scalare qualcosa che non regge.
5. La domanda architetturale che precede ogni adozione: serve davvero un agente?
Prima ancora di configurare o scalare, c’è una domanda che troppo spesso si salta: l’architettura giusta è davvero quella agentica? Jigyasa Grover la affronta di petto in “When NOT to use an agent: Choosing Between Workflows, Services, and LLM Orchestration”, ricordando che gli agenti non sono un upgrade automatico — sono un trade-off, con non-determinismo, superficie di attacco più ampia, complessità di valutazione e imprevedibilità operativa.
Il valore del talk per un developer senior è il framework di confronto tra tre pattern architetturali — workflow deterministici, architetture service-oriented con augmentation LLM, orchestrazione agentica piena — analizzati su assi molto concreti: isolamento dei fallimenti, prevedibilità di latenza e costo, osservabilità, confini di sicurezza, strategia di test di regressione. È l’antidoto al riflesso “automazione? integrazione? ragionamento? costruisci un agente” che sta diventando pericolosamente di default.
6. Il processo che si riadatta: la revisione del codice sotto pressione agentica
Se gli agenti scrivono codice più velocemente di quanto i team riescano a rivederlo, il collo di bottiglia si sposta sulla PR review. Vladi Stevanovic lo affronta in “The Swiss cheese fix: why PR quality needs layers”, partendo da un problema che molti team avevano già silenziosamente accettato — PR non revisionate per giorni, diff da 500 righe skimmate, approvazioni a timbro su cambi che nessuno capiva davvero — e mostrando come l’arrivo massivo di PR generate da agenti abbia reso la situazione insostenibile.
La proposta è il modello dello “Swiss cheese”: più livelli di difesa imperfetti — spec-driven development, competizione tra agenti multipli, verifica automatizzata, contesto runtime corretto fin dall’inizio — che insieme producono un sistema più affidabile di ogni singolo componente. È un talk che completa il quadro: l’adozione dell’AI non richiede solo nuovi strumenti, richiede processi ridisegnati attorno a un volume di codice generato che i processi vecchi non erano pensati per assorbire.
7. La chiusura necessaria: perché servono più ingegneri, non meno
Chiudiamo con il talk che, a nostro avviso, dà senso a tutti gli altri: “Why Coding Agents Need You More Than Ever” di Alfonso Fuggetta. La domanda “l’AI renderà i developer obsoleti?” viene liquidata come falsa semplicità, sia nella sua versione hype che in quella di negazione (“è solo autocomplete”).
La tesi di Fuggetta è strutturale: un LLM non ha un riferimento interno di correttezza, non ha comprensione del dominio per cui sta costruendo, non ha orientamento verso il futuro del sistema, non ha memoria tra sessioni. Non è un gap che il prossimo modello colmerà — è un vuoto strutturale che va colmato con metodo, conoscenza di dominio, giudizio di design, processo e profondità ingegneristica. La conclusione, scomoda e liberatoria allo stesso tempo, è che gli agenti capaci non riducono il bisogno di ingegneria del software: lo aumentano.
Il filo che tiene insieme i sette talk
Letti in sequenza, questi talk non raccontano una singola storia lineare (“l’AI funziona” o “l’AI non funziona”), ma un apprendimento a più livelli che rispecchia esattamente le domande che un developer senior si pone oggi:
- A livello organizzativo, l’adozione è un problema di cambiamento comportamentale su scala, non di strumenti (Graziano).
- A livello di configurazione, la qualità dei risultati dipende da come si governano le superfici dell’agente, non dal tool in sé (Cassani).
- A livello individuale, l’autonomia amplificata dall’AI è potentissima ma fragile senza gusto tecnico (Collina).
- A livello critico, serve la disciplina di riconoscere quando l’adozione produce solo rumore (Zechner).
- A livello architetturale, la domanda giusta non è “quale agente” ma “serve davvero un agente” (Grover).
- A livello di processo, i flussi di revisione vanno ridisegnati a strati per reggere il nuovo volume (Stevanovic).
- A livello strategico, tutto questo aumenta — non riduce — il valore dell’ingegneria del software vera (Fuggetta).
Se c’è una lezione unica da portare a casa, è questa: l’AI adoption matura non è l’accumulo di strumenti, è l’accumulo di giudizio su quando, dove e come usarli. Ed è esattamente il tipo di giudizio che, a quanto pare, continua a servire un ingegnere umano.
Vuoi sentire questi talk dal vivo?
Questi sette speech — e molti altri sullo stesso filo di AI adoption, agentic engineering e ingegneria del software nell’era degli LLM — sono nel programma di Codemotion AI & Tech Conference, a Milano. Se lavori con il codice ogni giorno e vuoi confrontarti con chi questi trade-off li ha già affrontati in produzione, è il posto giusto per farlo.
