AWS re:Invent 2025: portare gli agenti nei workflow aziendali per modernizzare applicazioni e automatizzare operations

3 Dicembre 2025

Dentro la strategia agent-first, AWS non si limita a proporre un runtime per costruire agenti: porta sul palco agenti già incapsulati in servizi verticali, progettati per lavorare su obiettivi lunghi, con memoria persistente e catene di azioni verificabili. L’assunto è che l’adozione enterprise non partirà da agenti generici lasciati ai team, ma da agenti specializzati dove il valore è immediatamente misurabile su processi ad alta intensità di lavoro. È in questa logica che si collocano due blocchi molto concreti: AWS Transform per la modernizzazione del legacy e i Frontier Agents per sviluppo, operations e sicurezza.

Transform viene presentato come prima istanza di “agentic modernization service”: una fabbrica di modernizzazione basata su agenti che analizzano un patrimonio applicativo, pianificano il percorso e poi eseguono trasformazioni coordinate in modo ripetibile. Non è un toolkit di migrazione, ma un servizio che internalizza in agenti l’esperienza necessaria a smontare e ricostruire grandi basi software. AWS lo rende subito quantitativo: i clienti hanno già analizzato circa 1,1 miliardi di linee di codice e risparmiato oltre 810.000 ore di lavoro manuale, numeri che inquadrano Transform come processo industriale, non come progetto sperimentale.

L’ambito iniziale è triplo e copre tre aree ad altissimo debito tecnico in enterprise IT: Windows/.NET, mainframe, virtualizzazioni VMware. La peculiarità, sottolineata anche nel comunicato, è la modernizzazione full-stack: non si interviene solo sul codice, ma su applicazione, database, framework UI, runtime e deployment, con l’obiettivo di portare tutto verso alternative cloud-native e open source.

La foto di apertura con il server obsoleto fatto esplodere in diretta visualizza bene cosa significa attaccare il technical debt in chiave agent-first: non un ritocco incrementale, ma la scomposizione controllata di una base tecnologica stratificata e fragile, fatta di dipendenze opache, patch storiche e costi di manutenzione che crescono più del valore prodotto. In questo senso gli agenti di modernizzazione operano come una forza di “smontaggio e ricostruzione industriale”: analizzano l’inventario applicativo, ricostruiscono le relazioni tra componenti, isolano i pezzi da rifare e quelli da ritirare, generano trasformazioni ripetibili e testabili, e riassemblano lo stack su fondamenta cloud-native. Il risultato atteso non è solo migrare il legacy, ma distruggere debito tecnico strutturale riducendo complessità, tempi di ciclo e vincoli di piattaforma: il server che salta in aria non è caos, è la rappresentazione di un legacy che viene disaggregato per essere rifondato su architetture più semplici, governabili e meno costose da evolvere.

Sul mondo Windows, Transform evolve proprio in direzione full-stack. L’agente analizza l’intero ambiente .NET e SQL Server, ricostruisce dipendenze applicative e di deployment, propone un piano coordinato e poi trasforma sia la logica applicativa e la UI sia la piattaforma dati e il sistema operativo verso stack Linux/open source, producendo report di trasformazione end-to-end. AWS lega il valore a due effetti congiunti: compressione del tempo di progetto (fino a 5× più rapido del manuale) e riduzione del costo di licensing e manutenzione, con risparmi dichiarati fino al 70% nei passaggi tipici SQL Server→PostgreSQL e Windows→Linux.

I casi citati servono a mostrare la scala. Teamfront modernizza circa 800.000 linee di codice in due settimane, preparando anche la migrazione del database verso PostgreSQL. Thomson Reuters usa Transform in modalità pipeline continua, modernizzando fino a 1,5 milioni di linee di codice al mese e riportando una riduzione del 30% dei costi e del 50% del debito tecnico. Sono numeri che delineano Transform come leva per trasformazioni a ondate, non come refactoring selettivo.

Sul mainframe, Transform riceve tre nuovi agenti che completano il ciclo dalla decisione strategica alla validazione tecnica. Un activity analysis agent misura utilizzo e criticità per decidere cosa modernizzare e cosa ritirare; un re-imagine blueprint agent ricostruisce il legacy in capability di business e flussi dati, riducendo la complessità di dominio; infine agenti specializzati automatizzano il testing generando test plan, script di test data e automazione, attaccando una fase che spesso pesa metà della timeline di un progetto mainframe. Garman ricorda che oltre un miliardo di linee di codice mainframe sono già passate in analisi su Transform, segno che il servizio viene usato per ingegnerizzare percorsi strutturali, non solo per migrazioni puntuali.

Nel mondo VMware, dove il problema non è riscrivere codice ma sbloccare l’inventario e le dipendenze tra sistemi, Transform introduce discovery on-prem con supporto a security review e un migration planning agent che usa contesto business anche da materiali non strutturati (documenti, file, chat, regole interne). L’agente costruisce un piano di migrazione a ondate e viene esteso a network migration avanzata integrando stack di sicurezza di vendor come Cisco ACI, Fortigate e Palo Alto Networks. L’idea è che la modernizzazione non sia solo “spostare VM”, ma riallineare rete e sicurezza con la nuova topologia cloud-native.

La svolta più ampia dell’anno è però AWS Transform Custom. Dopo il primo lancio, Garman racconta che i clienti hanno iniziato a chiedere di modernizzare qualsiasi cosa: non solo .NET o mainframe, ma linguaggi, framework e runtime disparati, spesso interni. Custom nasce per questo: permette di costruire agenti di trasformazione su misura che eseguono upgrade e migrazioni su qualunque stack, combinando trasformazioni pre-costruite per pattern comuni e trasformazioni definite dal cliente per casi specifici. AWS dichiara fino a 5× accelerazione rispetto al manuale e un loop di feedback che rende l’agente progressivamente migliore. Gli esempi citati da Garman sono volutamente eterogenei — Angular→React, VBA→Python, bash→Rust — proprio per mostrare che Transform diventa una piattaforma di modernizzazione generale, non solo per legacy “classico”.

I casi d’uso concreti rafforzano questo posizionamento. Air Canada usa Transform per modernizzare migliaia di funzioni Lambda legacy, stimando un -80% su tempo e costo rispetto a un progetto manuale. QAD|Redzone lo applica alla modernizzazione di un linguaggio proprietario (Progress/ABL) riducendo trasformazioni da due settimane a meno di tre giorni, con +60–70% produttività e 7.500 ore sviluppatore/anno risparmiate. Sono esempi che collegano l’agentica a ROI misurabile sul backlog reale.

AWS completa il quadro rendendo Transform estendibile con la composability initiative: partner come Accenture, Capgemini e Pegasystems possono innestare agenti e tool proprietari direttamente nel flusso, soprattutto per verticali regolati (fintech, sanità) dove le regole di trasformazione non sono generiche. Qui Transform smette di essere solo servizio AWS e diventa piattaforma su cui far vivere competenze di dominio terze.

Accanto a Transform, i Frontier Agents mostrano la stessa logica applicata al lavoro operativo quotidiano. AWS li definisce come agenti di nuova classe perché non sono multi-step transienti: sono persistenti, mantengono stato e contesto nel tempo, seguono obiettivi lunghi e possono operare in parallelo su più thread. È una proprietà essenziale quando gli agenti entrano in processi critici; “Frontier” non è una parola marketing sul modello, ma una definizione di comportamento software.

Kiro autonomous agent è il caso più visibile: un virtual developer con contesto continuativo sul codebase reale. Non suggerisce solo snippet su richiesta; segue backlog e repository, fa triage delle issue, collega bug simili, propone priorità, esegue refactoring multi-file, genera test e produce pull request complete per la revisione umana. Se i test o la review falliscono, riprende il contesto e itera proprio perché resta persistente sul task. In termini pratici, assorbe lavoro ripetitivo ad alta intensità lasciando agli sviluppatori la supervisione architetturale e la decisione finale.

Il Security Agent applica lo stesso schema al SecOps. Opera su design e codice mentre nascono: fa design review automatizzate, controlla PR per pattern vulnerabili, valuta uso di credenziali e configurazioni IAM, coordina penetration test e propone remediation già compatibili con le policy aziendali. La persistenza lo rende utile non solo quando c’è un alert, ma come ingegnere di sicurezza continuo che segue postura e drift nel tempo.

Infine il DevOps Agent è pensato per incident response e affidabilità. In ambienti con release frequenti e architetture distribuite, il collo di bottiglia è il triage e la root cause analysis. L’agente correla log e segnali, ricostruisce catene causali, produce ipotesi verificabili e traduce diagnosi in raccomandazioni di hardening su autoscaling, retry policy, circuit breaker, configurazioni di rete o database. Anche qui la persistenza abilita un ciclo preventivo: conserva memoria dei problemi ricorrenti e delle mitigazioni già applicate.

Transform e Frontier Agents, insieme, chiariscono il tratto comune della strategia AWS. L’agentica non viene proposta solo come toolbox da sviluppatori: viene consegnata come forza lavoro software già incardinata su processi ad alto ROI, dove persistenza, parallelismo e governance deterministica sono requisiti strutturali. Transform industrializza la modernizzazione del patrimonio applicativo; Kiro, Security Agent e DevOps Agent trasformano sviluppo, sicurezza e operations in un terreno agent-native. È la traduzione più concreta della tesi di Garman: il valore della GenAI emerge quando gli agenti diventano parte stabile dei processi, non quando restano un’interfaccia intelligente su prompt.