Il London AI Engineer Summit 2026 doveva essere una celebrazione del progresso. Invece, è sembrato uno specchio tenuto di fronte a una professione in mezzo a un esaurimento nervoso.
Per tre giorni all’inizio di aprile, centinaia di ingegneri IA, costruttori di piattaforme e ricercatori si sono riuniti per condividere ciò che avevano imparato. Quello che è emerso è stato uno schema: tutti stanno costruendo con gli agenti, nessuno ha capito come controllarli, il settore è diviso tra andare veloce o pensare con attenzione, e l’intera premessa secondo cui l’IA ci avrebbe reso più produttivi si è ribaltata in qualcosa di più cupo.
Questo è ciò che abbiamo davvero imparato.
Perché gli ingegneri IA stanno codificando con agenti che non possono controllare?
La conversazione più onesta del summit è avvenuta in un corridoio, non sul palco. Un ingegnere di una fintech di medie dimensioni ha descritto il problema così: “Avvio un prompt, e tre ore dopo il mio agente ha riscritto metà della codebase, aggiunto funzionalità che non avevo chiesto, e consumato 800 £ in calcolo. Non posso allontanarmi dalla scrivania.”
Questo è FOMAT: Fear of Missing Attention Time. Non è una battuta — è l’ansia definitoria dell’ingegneria IA del 2026.
Il collo di bottiglia dell’orchestrazione
Tutti al summit stavano usando agenti. GitHub Copilot, Claude, framework agentici personalizzati — gli strumenti sono maturi. Ma l’orchestrazione no. Il divario tra “ho un agente” e “il mio agente fa quello che intendevo e nient’altro” è enorme.
Il problema si manifesta in tre modi:
Fuga di token. Gli agenti non hanno punti di arresto naturali. Senza guardrail espliciti, continuano a iterare. “Solo un altro refactor,” pensa l’agente, e all’improvviso hai bruciato il budget mensile.
Scope creep. Una richiesta di “migliorare la gestione degli errori” diventa “riscrivere l’intero sistema di gestione errori, aggiungere osservabilità, rifattorizzare il livello di logging e implementare il tracing distribuito”. L’agente non aveva torto — era accurato. Ma non era ciò che avevi chiesto.
Latenza imprevedibile. Non puoi sapere quanto durerà un’attività agentica. Dipende da quante sotto-task l’agente decide di generare, quanti fallimenti incontra, e se decide di riprovare o cambiare direzione. Questo rende impossibile pianificare i workflow guidati da agenti in sistemi di produzione.
Quale fu (e non fu) il consenso del summit
Non c’era consenso sulle soluzioni. Alcuni team usano limiti rigidi di token. Altri implementano “checkpoint dell’agente” — costringendo gli agenti a fermarsi e chiedere il permesso prima di continuare. Alcuni si stanno muovendo verso sistemi di agenti gerarchici dove un “agente manager” supervisiona agenti lavoratori e può interromperli.
L’approccio di FlowHunt — definizioni esplicite di workflow con nodi agente, gestori di errori e logica di branching — è stato menzionato più volte come pattern potenziale. L’idea: non lasciare che gli agenti decidano la struttura del workflow. Definiscila in anticipo, poi lascia che gli agenti eseguano singoli passaggi.
Ma anche quello sembrava un cerotto. Il problema reale è che il comportamento dell’agente è intrinsecamente probabilistico. Puoi ridurre la varianza, ma non puoi eliminarla.
Come la divisione OpenAI-Anthropic ha ridefinito cosa significhi “buon codice”?
Lunedì mattina, Ryan Lopopolo di OpenAI è salito sul palco e ha tenuto una keynote che si può riassumere così: Smetti di leggere il codice. Diventa un miliardario di token.
Il suo argomento: In un mondo agentico, il volume di codice è la metrica che conta. Il tuo agente dovrebbe generare migliaia di righe al giorno. Il tuo compito è definire la specifica di output e lasciare che l’agente massimizzi il throughput. Leggere e comprendere ogni riga è un collo di bottiglia. Fidati dei test. Fidati dell’agente. Muoviti veloce.
Entro mercoledì, Mario Zechner di Anthropic ha tenuto la contro-keynote: Rallenta e leggi il maledetto codice.
Il suo argomento: La velocità è una trappola. Ogni riga di codice che il tuo agente scrive è una responsabilità. Devi comprenderla, ragionarci sopra e essere in grado di mantenerla. I team che vinceranno tra cinque anni sono quelli che priorizzano chiarezza e intenzione sulla velocità. Gli agenti dovrebbero essere strumenti per pensare, non per generare codice senza riflessione.
Lo spettro
Il summit si è suddiviso grossolanamente in tre campi:
| Posizione | Sostenitori | Approccio | Rischio |
|---|---|---|---|
| Massimalista dei token | OpenAI, alcuni ingegneri di scale-up | Lasciare che gli agenti generino aggressivamente; focus sulla qualità dell’output tramite test | Codebase non mantenibili, debito di sicurezza, fragilità tecnica |
| Centro intenzionale | La maggior parte degli ingegneri enterprise | Usare gli agenti per lo scaffolding; gli umani forniscono architettura e gusto | Velocità più lenta, ma sistemi più stabili |
| Code-First | Anthropic, alcuni ingegneri di ricerca | Gli agenti aumentano il pensiero umano; gli umani scrivono la maggior parte del codice | Throughput inferiore, ma massima qualità del codice |
Nessuna parte ha torto. Il disaccordo riguarda come appare il fallimento. Lopopolo ottimizza per la velocità di iterazione. Zechner ottimizza per la sostenibilità. Nel 2026, i team stanno imparando che non si può ottimizzare per entrambi.
Il problema dei colloqui
Una conseguenza concreta: le assunzioni sono rotte. Se sei un massimalista dei token, non ti importa se un candidato sa programmare — ti importa se sa fare prompting efficace e valutare l’output dell’agente. Se sei code-first, vuoi vedere ragionamento tecnico profondo.
Quindi quando un candidato entra a un colloquio, né l’intervistatore né il candidato sanno contro quale framework vengono valutati. Un partecipante al summit l’ha descritto come “fare colloqui nella nebbia”.
Pronto a far crescere il tuo business?
Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.
Perché gli IDE stanno morendo mentre il traffico di GitHub esplode?
GitHub ha riportato un aumento del traffico di 15x su base annua. Cloudflare ha riportato picchi simili. Nel frattempo, gli IDE tradizionali — VS Code, JetBrains, Sublime — stanno vedendo un calo dell’uso tra i team nativi IA.
Sembra contraddittorio finché non capisci cosa sta effettivamente succedendo.
L’IDE era uno strumento locale per pensare
Un IDE era progettato perché un singolo sviluppatore scrivesse codice localmente. Aveva evidenziazione della sintassi, autocompletamento, strumenti di debug e un albero dei file. Era un ambiente autocontenuto.
Quel modello si rompe quando il tuo “sviluppatore” è un agente. Un agente non ha bisogno di evidenziazione della sintassi. Non ha bisogno di un debugger. Ha bisogno di:
- Accesso a più file simultaneamente
- La capacità di eseguire codice e vedere i risultati
- Integrazione con il controllo di versione
- Funzionalità di collaborazione (perché agente e umano lavorano insieme)
Tutto questo ora vive nel browser. GitHub Codespaces, VS Code Web e strumenti simili stanno sostituendo gli IDE locali.
Cosa sta effettivamente crescendo
Il picco di traffico di GitHub non sono sviluppatori che scrivono codice nel browser. Sono sviluppatori che revisionano, commentano e mergeano codice generato dagli agenti. È il livello di collaborazione che sta esplodendo, non quello di editing.
Ecco perché anche Cloudflare vede picchi di traffico — gli sviluppatori usano l’infrastruttura cloud per eseguire agenti e orchestrare workflow. Il modello “IDE locale + ambiente di sviluppo locale” viene sostituito da “orchestrazione di agenti cloud-native + revisione basata su browser”.
L33T C0d3 è morto
Una sessione aveva esattamente quel titolo. Il punto: la nozione romantica dell’ingegnere brillante, solo alla tastiera, che crea codice elegante — è finita. Il codice è ora un output collaborativo tra umano e agente. Le competenze che contano sono:
- Prompt engineering (come specificare ciò che vuoi)
- Valutazione dell’output (il codice dell’agente è buono?)
- Pensiero architetturale (in quale struttura deve lavorare l’agente?)
- Integrazione (come si integra il codice generato dall’agente nei sistemi esistenti?)
Scrivere codice elegante non è più una competenza primaria. È qualcosa che fanno gli agenti. Gli umani fanno tutto il resto.
Cosa sta realmente accadendo con MCP — morto o in fiore?
Questo è stato il dibattito più confuso del summit.
Da un lato, i singoli ingegneri IA e i manutentori di framework di agenti dicevano: “MCP è morto. Non ne abbiamo bisogno. I nostri agenti possono chiamare direttamente le API.”
Dall’altro lato, gli architetti enterprise e i team di sicurezza dicevano: “L’adozione di MCP sta accelerando più velocemente di quanto possiamo costruire strumenti per esso.”
Entrambe le affermazioni sono vere. Descrivono popolazioni diverse.
Perché gli ingegneri IA pensano che MCP sia morto
Per uno sviluppatore solitario che costruisce un agente semplice, MCP aggiunge attrito. Devi:
- Definire server MCP per i tuoi strumenti
- Gestire l’overhead del protocollo
- Gestire autenticazione e autorizzazione
- Distribuire e mantenere i server
È più facile dare al tuo agente accesso diretto all’API e lasciare che capisca il resto.
Perché le aziende stanno adottando MCP rapidamente
Per un’organizzazione che esegue agenti in produzione, MCP diventa improvvisamente essenziale. Ecco perché:
Isolamento di sicurezza. Non vuoi che gli agenti abbiano accesso diretto al tuo database, sistema di pagamento o dati dei clienti. MCP ti permette di creare un’interfaccia controllata che gli agenti possono chiamare senza esporre i sistemi sottostanti.
Verificabilità. Ogni azione dell’agente passa attraverso il server MCP, che la registra. Hai un record completo di ciò che l’agente ha fatto e perché.
Gestione delle credenziali. Invece di incorporare chiavi API nei prompt degli agenti o nelle variabili d’ambiente, i server MCP gestiscono le credenziali in modo sicuro.
Limitazione di velocità e imposizione di quote. Puoi controllare quanto di una risorsa un agente può consumare.
Secondo CData Software, l'80% delle aziende Fortune 500 sta valutando o implementando MCP a inizio 2026, principalmente per queste ragioni.
La risoluzione
Il consenso del summit: MCP non è morto. Semplicemente non è rilevante per l'80% dello sviluppo IA che è sperimentale e solitario. Ma per il 20% che è produzione e multi-team, MCP sta diventando imprescindibile.
Ecco perché le MCP App proliferano. Anthropic, OpenAI e fornitori terzi stanno costruendo server MCP preconfezionati per strumenti comuni (Salesforce, Slack, Jira, database). Le aziende possono adottarli senza costruire server personalizzati.
Iscriviti alla nostra newsletter
Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.
L’IA ci sta rendendo più produttivi o solo più sovraccarichi?
Qui il summit si è fatto cupo.
L’IA doveva essere un moltiplicatore di forza. Avresti speso meno tempo in compiti di routine e più in pensiero strategico. La produttività sarebbe schizzata alle stelle.
Invece, la produttività è schizzata alle stelle — e così anche le aspettative di carico di lavoro.
Il paradosso di Jevons in tempo reale
Il paradosso di Jevons, applicato originariamente al consumo di carbone, afferma: Quando una risorsa diventa più efficiente, il consumo totale aumenta perché la risorsa diventa più economica e attraente.
In termini di IA: Gli agenti hanno reso la generazione di codice più economica e veloce, quindi i manager ora si aspettano che ogni ingegnere:
- Produca 10x più output
- Scriva documentazione esaustiva
- Costruisca suite complete di test
- Supporti l’internazionalizzazione (i18n)
- Gestisca i casi limite
- Faccia tutto da solo
I guadagni di produttività sono stati consumati da aspettative gonfiate.
Cosa hanno detto gli ingegneri
Un ingegnere di una startup con sede a Londra: “Prima scrivevo 500 righe di codice al giorno e mi sentivo produttivo. Ora scrivo 5.000 righe al giorno — generate dagli agenti — e sono esausto perché devo revisionare tutto, testarlo, documentarlo e spiegarlo agli stakeholder. Faccio settimane da 60 ore.”
Un altro: “Il mio manager dice: ‘Ora hai un agente, quindi dovresti riuscire a gestire il doppio dei progetti.’ Non sono più produttivo. Sono solo più occupato.”
Un ricercatore: “Gli agenti sono bravi a generare codice. Non sono bravi a decidere quale codice generare. Quel peso decisionale si è completamente spostato sugli umani. Non stiamo automatizzando la parte difficile; stiamo automatizzando la parte facile e costringiamo gli umani a pensare di più.”
Il punto cieco della produttività
La California Management Review di UC Berkeley ha pubblicato nel gennaio 2026 una ricerca che documenta questo fenomeno. L’intuizione chiave: L’adozione dell’IA non riduce il lavoro; cambia la natura del lavoro.
Vecchio lavoro: Scrivere codice. Nuovo lavoro: Dirigere gli agenti, valutare l’output, mantenere la qualità, gestire lo scope creep.
Il nuovo lavoro è cognitivamente più duro, anche se c’è meno digitazione.
Perché l’Europa è così esitante sull’ingegneria IA?
Il summit aveva un forte contingente europeo, e il loro messaggio era coerente: L’Europa non si sta muovendo alla stessa velocità degli USA nell’adozione dell’ingegneria IA.
L’incombenza normativa
Il Regolamento UE sull’IA è ancora in implementazione. Le aziende sono incerte sulla responsabilità. Se un agente IA prende una decisione che danneggia un cliente, chi è responsabile? L’azienda? Il fornitore del modello? L’ingegnere?
Questa incertezza paralizza. Molte aziende europee stanno aspettando di vedere come si svilupperanno le prime cause prima di costruire sistemi agentici seri.
Il divario di competenze
Gli ingegneri software tradizionali in Europa non stanno diventando ingegneri IA allo stesso ritmo degli USA. C’è scetticismo sul trasferimento delle competenze. Molti ingegneri europei stanno aspettando di vedere se l’ingegneria IA è un vero percorso di carriera o un ciclo di hype.
Preoccupazioni per la privacy
L’Europa è anche più cauta nella gestione dei dati. Gli agenti hanno bisogno di accesso ai dati per essere utili. Ma le aziende europee esitano a dare agli agenti accesso ai dati dei clienti, anche con le salvaguardie MCP in atto.
La strada avanti
Gli ingegneri europei al summit non erano anti-IA. Erano pro-cautela. Il sentimento: “Gli USA si muovono veloci e rompono le cose. Noi ci muoveremo più lentamente e cercheremo di non rompere troppo. Tra cinque anni vedremo chi aveva ragione.”
Come stanno cambiando davvero i ruoli di ingegneria IA?
Verso la fine del summit, è emerso uno schema: I ruoli tradizionali di ingegneria software vengono svuotati e sostituiti da tre nuovi archetipi.
I tre ruoli
| Ruolo | Responsabilità | Competenze |
|---|---|---|
| AI PM | Definire il comportamento dell’agente, le metriche di successo, i vincoli | Pensiero di prodotto, progettazione di prompt, framework di valutazione |
| Babysitter di agenti | Monitorare l’esecuzione, catturare gli errori, intervenire quando necessario | Debugging, osservabilità, gestione errori, risposta agli incidenti |
| Arbitro del gusto | Valutare la qualità dell’output, fornire feedback, guidare il raffinamento | Revisione del codice, pensiero architetturale, giudizio estetico |
Nessuno di questi ruoli comporta scrivere codice nel senso tradizionale. Tutti comportano la direzione, la valutazione e il raffinamento del comportamento dell’agente.
Cosa sta scomparendo
I ruoli di “ingegnere junior” vengono compressi. Non c’è più un percorso chiaro da “so scrivere codice semplice” a “so progettare sistemi”. I passaggi intermedi vengono automatizzati.
Questo crea un precipizio di competenze: o sei bravo nel prompting e nella valutazione (nel qual caso sei prezioso), o non lo sei (nel qual caso competi con gli agenti).
Cosa sta crescendo
I ruoli che richiedono gusto, giudizio e pensiero architetturale stanno crescendo. Così come quelli che richiedono profonda competenza di dominio (perché gli agenti hanno bisogno degli umani per valutare se stanno risolvendo il problema giusto).
Al summit non c’era consenso se questo sia positivo o negativo. Alcuni lo vedevano come liberazione dal coding di routine. Altri come una minaccia per la professione.
Cosa è cambiato tra dicembre 2025 e febbraio 2026?
Una sezione del summit era dedicata a uno specifico punto di svolta: qualcosa si è spostato nell’ecosistema degli agenti IA intorno al capodanno.
Il software auto-miglioratore è diventato reale
OpenClaw e framework simili hanno iniziato a consentire agli agenti di migliorare iterativamente i propri output senza prompting umano costante. Invece di “agente, scrivi una funzione per calcolare X”, è diventato “agente, scrivi una funzione per calcolare X e continua a migliorarla finché non passa tutti i test e gestisce i casi limite”.
L’intuizione chiave, articolata da diversi ricercatori: Smettete di chiedere agli agenti consigli banali.
Invece di chiedere a un agente di “migliorare questa funzione”, chiedigli di “rendere questa funzione a prova di proiettile”. Lascia che decida cosa significa. L’agente:
- Scriverà test
- Troverà casi limite
- Rifattorizzerà per chiarezza
- Aggiungerà gestione errori
- Documenterà la logica
Tutto senza che gli venga chiesto ogni passaggio.
Questo ha cambiato il modello mentale da “agente come strumento” ad “agente come collaboratore autonomo”. E ha cambiato le dinamiche del carico di lavoro: invece che gli agenti riducessero il lavoro umano, lo hanno aumentato (perché gli umani ora dovevano valutare output degli agenti molto più sofisticati).
Le contraddizioni con cui conviviamo
Il summit si è concluso senza risoluzione, cosa che è sembrata onesta. Ecco le contraddizioni che definiscono l’ingegneria IA nell’aprile 2026:
Contraddizione 1: Gli agenti sono abbastanza potenti da essere pericolosi (FOMAT è reale), ma non abbastanza potenti da essere fidati senza supervisione.
Contraddizione 2: Velocità e qualità vengono trattati come opposti, ma entrambe sono necessarie.
Contraddizione 3: MCP è simultaneamente morto (per i singoli) e in fiore (per le aziende).
Contraddizione 4: L’IA ci ha reso più produttivi, ma anche più sovraccarichi.
Contraddizione 5: Tutti stanno costruendo con gli agenti, ma nessuno ha capito come costruire bene con essi.
Contraddizione 6: L’ingegneria IA è un vero percorso di carriera, ma le competenze che pensavamo contassero (scrivere codice) non contano più.
Queste non sono problemi da risolvere. Sono tensioni da gestire. I team che vinceranno nel 2026 sono quelli che riconoscono queste contraddizioni invece di fingere che non esistano.
Domande frequenti
Cosa ci portiamo via
Il summit di Londra è stata un’istantanea di una professione in transizione. L’ingegneria IA è reale, ma non è ciò che pensavamo sarebbe stato. È più caotica, più contraddittoria e più dipendente dall’umano di quanto l’hype suggerisse.
I migliori ingegneri al summit non erano quelli con gli agenti più sofisticati. Erano quelli che avevano capito che gli agenti sono uno strumento per pensare, non un sostituto del pensare. Erano quelli che avevano costruito processi per gestire il comportamento degli agenti, valutare l’output e mantenere la qualità. Erano quelli che avevano accettato che i guadagni di produttività arrivano con nuovi tipi di lavoro, non con meno lavoro.
Se stai costruendo sistemi IA nel 2026, le lezioni del summit sono chiare:
L’orchestrazione conta più della capacità dell’agente. Un agente mediocre con buona orchestrazione batte un agente brillante senza controlli.
La chiarezza è più preziosa della velocità. Muoversi veloci e rompere le cose funziona finché non funziona più. Su larga scala, non funziona.
L’adozione enterprise è reale, ma l’adozione individuale è ancora sperimentale. Se sei uno sviluppatore solitario, puoi muoverti veloce. Se sei un team, hai bisogno di guardrail.
Le competenze che contano sono cambiate. Prompt engineering, valutazione dell’output e pensiero architetturale sono le nuove competenze fondamentali.
Aspettati di lavorare di più, non di meno. L’IA è un moltiplicatore di produttività, ma i guadagni vengono consumati da aspettative più alte. Pianifica di conseguenza.
Il summit non ha risposto alla domanda “Com’è l’ingegneria IA?” Ci ha mostrato la risposta: somiglia a noi, che cerchiamo di capirlo in tempo reale.
{{ cta-dark-panel heading=“Smetti di orchestrare agenti manualmente” description=“Il workflow builder di FlowHunt ti permette di definire il comportamento dell’agente, impostare guardrail e automatizzare attività IA multi-step. Niente più FOMAT. Niente più indovinare cosa stanno facendo i tuoi agenti.” ctaPrimaryText=“Prova FlowHunt gratis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Prenota una demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
