{"id":36435,"date":"2026-08-24T12:14:10","date_gmt":"2026-08-24T10:14:10","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36435"},"modified":"2026-08-25T16:25:56","modified_gmt":"2026-08-25T14:25:56","slug":"7-lezioni-di-ai-adoption-da-chi-ci-e-gia-passato","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/intelligenza-artificiale\/7-lezioni-di-ai-adoption-da-chi-ci-e-gia-passato\/","title":{"rendered":"7 Lezioni di AI Adoption da chi ci \u00e8 gi\u00e0 passato"},"content":{"rendered":"\n

C’\u00e8 un momento, in ogni ciclo tecnologico, in cui la conversazione cambia registro. Non si parla pi\u00f9 se<\/em> adottare l’AI, ma come<\/em> \u2014 e soprattutto a quale costo organizzativo, cognitivo e di qualit\u00e0<\/em>. Se sei un developer senior, probabilmente hai gi\u00e0 superato la fase dell’entusiasmo da demo e sei entrato in quella pi\u00f9 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.<\/p>\n\n\n\n

Da Codemotion AI & Tech Conference Milano<\/a><\/strong> 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 \u00e8 un elogio acritico dell’AI adoption. \u00c8, piuttosto, una mappa dei trade-off \u2014 esattamente quello che serve a chi deve prendere decisioni tecniche, non solo entusiasmarsi a un keynote.<\/p>\n\n\n\n

1. Partire dalla scala: cosa succede quando devi convincere 300 ingegneri<\/h2>\n\n\n\n

Il punto di partenza naturale \u00e8 organizzativo. Nel talk “Scaling AI Adoption: The Real Challenges of Transforming 300 Engineers”<\/strong>, Alfonso Graziano racconta cosa significa spingere un’organizzazione oltre la fase di sperimentazione, verso uno sviluppo “AI-native” ripetibile \u2014 non un singolo team illuminato, ma centinaia di persone con livelli di maturit\u00e0 molto diversi tra loro.<\/p>\n\n\n\n

La parte pi\u00f9 utile per un pubblico senior non \u00e8 la lista dei successi, ma quella dei fallimenti: pattern di resistenza, falsi partenza, over-reliance sugli strumenti e \u2014 soprattutto \u2014 il divario tra produttivit\u00e0 percepita e produttivit\u00e0 reale<\/strong>. \u00c8 un promemoria salutare: l’adozione dell’AI a livello enterprise non \u00e8 un problema di procurement di licenze, \u00e8 un problema di cambiamento comportamentale su larga scala, e i numeri di produttivit\u00e0 auto-riportati vanno sempre presi con le pinze.<\/p>\n\n\n\n

2. Poi la configurazione: l’agente non \u00e8 un tool, \u00e8 un sistema da governare<\/h2>\n\n\n\n

Se il talk di Graziano lavora al livello dell’organizzazione, quello di Alexio Cassani \u2014 “Configurare l’harness: da Claude Code come tool a Claude Code come sistema di lavoro”<\/strong> \u2014 scende al livello dell’ingegneria vera e propria. La tesi \u00e8 netta: un coding agent moderno arriva gi\u00e0 con il suo harness; quello che cambia i risultati non \u00e8 costruirne uno da zero, \u00e8 configurarlo bene.<\/p>\n\n\n\n

Cassani attraversa le superfici che governano il comportamento dell’agente \u2014 istruzioni di progetto, skill, permessi, hook, subagent, MCP, fino al plugin che rende la configurazione condivisibile in team \u2014 e insiste su un punto che ogni tech lead dovrebbe interiorizzare: non tutte le regole vanno nello stesso posto. Una conoscenza contestuale non \u00e8 un hook. Un vincolo che deve valere sempre non \u00e8 una riga di istruzioni infilata in un prompt. \u00c8 una lezione di architettura, applicata alla governance degli agenti, non di prompt engineering.<\/p>\n\n\n\n

3. Il potenziale individuale: quando un solo ingegnere sostituisce un team<\/h2>\n\n\n\n

Da qui il discorso si sposta sul singolo contributor. “Kill the Standup: How One Engineer Ships What Five Cannot”<\/strong> di Matteo Collina \u00e8 probabilmente il talk pi\u00f9 provocatorio del gruppo. Partendo dalla legge di Brooks sui canali di comunicazione \u2014 che crescono come n(n-1)\/2 \u2014 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\u00f2 spedire in due settimane quello che un team spedisce in due mesi.<\/p>\n\n\n\n

Ma il talk non \u00e8 un panegirico ingenuo. Collina \u00e8 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\u00e0 in produzione<\/strong> con una PR assistita da AI che non ha revisionato a dovere. \u00c8 un caso di studio prezioso proprio perch\u00e9 non nasconde il rischio: la “cave engineering” funziona solo se il gusto tecnico regge il peso dell’autonomia.<\/p>\n\n\n\n

4. Il contrappunto necessario: quando l’adozione produce solo “slop”<\/h2>\n\n\n\n

Ogni narrazione sull’AI adoption che si rispetti ha bisogno di un contrappeso, e qui arriva “Everything is slop, let’s slow the f<\/strong>k 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.<\/p>\n\n\n\n

\u00c8 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\u00e0, ed \u00e8 bene saperlo prima di scalare qualcosa che non regge.<\/p>\n\n\n\n

5. La domanda architetturale che precede ogni adozione: serve davvero un agente?<\/h2>\n\n\n\n

Prima ancora di configurare o scalare, c’\u00e8 una domanda che troppo spesso si salta: l’architettura giusta \u00e8 davvero quella agentica? Jigyasa Grover la affronta di petto in “When NOT to use an agent: Choosing Between Workflows, Services, and LLM Orchestration”<\/strong>, ricordando che gli agenti non sono un upgrade automatico \u2014 sono un trade-off, con non-determinismo, superficie di attacco pi\u00f9 ampia, complessit\u00e0 di valutazione e imprevedibilit\u00e0 operativa.<\/p>\n\n\n\n

Il valore del talk per un developer senior \u00e8 il framework di confronto tra tre pattern architetturali \u2014 workflow deterministici, architetture service-oriented con augmentation LLM, orchestrazione agentica piena \u2014 analizzati su assi molto concreti: isolamento dei fallimenti, prevedibilit\u00e0 di latenza e costo, osservabilit\u00e0, confini di sicurezza, strategia di test di regressione. \u00c8 l’antidoto al riflesso “automazione? integrazione? ragionamento? costruisci un agente” che sta diventando pericolosamente di default.<\/p>\n\n\n\n

6. Il processo che si riadatta: la revisione del codice sotto pressione agentica<\/h2>\n\n\n\n

Se gli agenti scrivono codice pi\u00f9 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”<\/strong>, partendo da un problema che molti team avevano gi\u00e0 silenziosamente accettato \u2014 PR non revisionate per giorni, diff da 500 righe skimmate, approvazioni a timbro su cambi che nessuno capiva davvero \u2014 e mostrando come l’arrivo massivo di PR generate da agenti abbia reso la situazione insostenibile.<\/p>\n\n\n\n

La proposta \u00e8 il modello dello “Swiss cheese”: pi\u00f9 livelli di difesa imperfetti \u2014 spec-driven development, competizione tra agenti multipli, verifica automatizzata, contesto runtime corretto fin dall’inizio \u2014 che insieme producono un sistema pi\u00f9 affidabile di ogni singolo componente. \u00c8 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.<\/p>\n\n\n\n

7. La chiusura necessaria: perch\u00e9 servono pi\u00f9 ingegneri, non meno<\/h2>\n\n\n\n

Chiudiamo con il talk che, a nostro avviso, d\u00e0 senso a tutti gli altri: “Why Coding Agents Need You More Than Ever”<\/strong> di Alfonso Fuggetta. La domanda “l’AI render\u00e0 i developer obsoleti?” viene liquidata come falsa semplicit\u00e0, sia nella sua versione hype che in quella di negazione (“\u00e8 solo autocomplete”).<\/p>\n\n\n\n

La tesi di Fuggetta \u00e8 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 \u00e8 un gap che il prossimo modello colmer\u00e0 \u2014 \u00e8 un vuoto strutturale che va colmato con metodo, conoscenza di dominio, giudizio di design, processo e profondit\u00e0 ingegneristica. La conclusione, scomoda e liberatoria allo stesso tempo, \u00e8 che gli agenti capaci non riducono il bisogno di ingegneria del software: lo aumentano.<\/p>\n\n\n\n

Il filo che tiene insieme i sette talk<\/h2>\n\n\n\n

Letti in sequenza, questi talk non raccontano una singola storia lineare (“l’AI funziona” o “l’AI non funziona”), ma un apprendimento a pi\u00f9 livelli che rispecchia esattamente le domande che un developer senior si pone oggi:<\/p>\n\n\n\n