Gli AI agent stanno rapidamente passando dalla fase delle demo alla pratica quotidiana degli sviluppatori.
Non si tratta più soltanto di chiedere a un modello di generare una funzione, spiegare un errore o suggerire una soluzione. Gli agenti stanno iniziando a partecipare a workflow più complessi: possono lavorare con strumenti, mantenere contesto, seguire specifiche, orchestrare task e interagire con sistemi reali.
Ma cosa succede quando portiamo questo approccio oltre la singola attività di coding?
Alla Codemotion AI & Tech Conference, due talk affrontano proprio questa evoluzione da prospettive diverse ma complementari. Da una parte, Giovanni Galloro, Specialist Customer Engineer di Google Cloud, mostrerà come utilizzare Google Antigravity e agents-cli per progettare, sviluppare e integrare agenti basati sul Google Agent Development Kit (ADK). Dall’altra, Riccardo Carlesso, Developer Advocate di Google Cloud, porterà gli agenti nel mondo delle operations, mostrando come possano supportare il troubleshooting di sistemi cloud-native e Kubernetes.
Due casi d’uso diversi, ma una domanda comune: come cambia il software engineering quando gli agenti entrano in produzione?
Quando l’AI non scrive solo codice, ma costruisce altri agenti
Il primo intervento parte da un’idea particolarmente interessante: se oggi utilizziamo coding agent per aiutarci a sviluppare software, possiamo utilizzarli anche per costruire , distribuire e integrare altri agenti?Nel talk di Giovanni Galloro,Google Antigravity diventa il motore di un workflow di sviluppo agent-to-agent.
L’obiettivo è utilizzare agent skills, gestione del contesto e specifiche strutturate per guidare Antigravity nella creazione di un agente basato su Google Agent Development Kit (ADK).
Il punto non è semplicemente generare automaticamente del codice.
Un coding agent che lavora solo sui dati di training rischia infatti di non conoscere le ultime API del framework o le convenzioni corrette per il deploy e l’accesso ai dati. Le skill di agents-cli colmano questo divario fornendo al coding agent istruzioni strutturate e comandi dedicati per ogni fase: scaffolding del progetto, scrittura dei tool, validazione, test locale nel playground e deploy su Cloud Run.
Anche il modo in cui nasce la specifica cambia: prima di scrivere codice, Antigravity esplora la codebase esistente, intervista lo sviluppatore sulle decisioni architetturali (dal modello da usare alla struttura dei tool e alla condivisione dello stato) e produce un piano di implementazione condiviso.
Il risultato è un workflow in cui il coding agent guida la definizione dei requisiti, genera il progetto ADK, ne esegue il deploy e lo integra all’interno di un’applicazione esistente.
In pratica, il passaggio diventa:
specifica interattiva → piano architetturale → scaffolding e codice ADK → deploy → integrazione applicativa.
Questo approccio mette in discussione anche il ruolo tradizionale del coding agent. Se normalmente pensiamo all’agente come a uno strumento che accelera il lavoro dello sviluppatore, qui diventa parte del processo con cui progettiamo lo stesso sistema che utilizzerà altri agenti.
È un livello di astrazione particolarmente interessante per chi sta iniziando a costruire applicazioni agentiche in modo strutturato, ma anche per chi sta già affrontando problemi di architettura e sviluppo in contesti production-ready.
E quando l’agente arriva in produzione?
Il secondo talk sposta il punto di osservazione.
Una volta costruito il software, infatti, rimane tutto il lavoro necessario per farlo funzionare, monitorarlo e mantenerlo affidabile.
È qui che entra in gioco il talk di Riccardo Carlesso sull’Agentic SRE.
Il problema è familiare a chi lavora con sistemi distribuiti: quando qualcosa si rompe in produzione, l’investigazione richiede spesso di mettere insieme informazioni provenienti da molte fonti diverse.
Metriche, log, eventi, deployment, Kubernetes, sistemi di observability e runbook devono essere analizzati e correlati per arrivare a una diagnosi.
Gli strumenti esistono già. Quello che spesso richiede tempo è orchestrare il processo investigativo.
L’approccio presentato da Carlesso parte proprio da qui: utilizzare agenti e skill specializzate per automatizzare parte del workflow di troubleshooting, permettendo all’agente di raccogliere informazioni, utilizzare strumenti diagnostici, analizzare regressioni e arrivare a una possibile mitigazione.
Il caso mostrato durante il talk, l’Outage Investigator, rappresenta un esempio concreto di questo modello: un agente che può seguire un processo multi-step di investigazione e arrivare fino alla produzione di una prima documentazione tecnica dell’incidente.
outage -> investigazione -> remediation (stop the bleeding) -> RCA -> full fix -> postmortem -> Action Items (to avoid reoccurrence).
Anche in questo caso, quindi, il valore non è semplicemente nella capacità dell’AI di “rispondere”.
È nella capacità di agire all’interno di un workflow.
Due estremi dello stesso ciclo
Visti insieme, i due talk raccontano due momenti diversi dello stesso ciclo di vita del software.
Da una parte abbiamo l’agente che aiuta a costruire altri agenti: specifiche, architettura, codice e integrazione.
Dall’altra abbiamo l’agente che entra l’agente che entra nel vivo delle Operations : osservazione, diagnosi, troubleshooting, mitigazione e documentazione.
Il filo conduttore è quindi l’evoluzione del ruolo dell’AI nel software engineering.
L’agente non è più soltanto una feature dentro l’IDE o una chat accanto al codice. Può diventare un componente capace di utilizzare strumenti, seguire processi e collaborare con altri componenti.
Questo porta naturalmente anche nuove questioni di engineering: come definiamo i confini di un agente? Come gestiamo il contesto? Come rendiamo le sue azioni osservabili? Come strutturiamo le specifiche? Come manteniamo il controllo quando un agente può interagire con sistemi reali?
Sono problemi molto concreti, soprattutto quando si passa dalle demo a sistemi che devono essere mantenuti nel tempo.
Dall’AI-assisted development all’agentic software engineering
È proprio questo passaggio che rende interessanti entrambe le sessioni per chi lavora quotidianamente nello sviluppo software.
L’AI-assisted development ha iniziato trasformando singole attività: scrivere codice, generare test, fare refactoring o analizzare errori.
L’approccio agentico amplia il perimetro.
L’unità di lavoro non è più necessariamente una funzione o un file, ma può diventare un workflow completo.
E quando questo succede, cambiano anche le competenze necessarie per progettare questi sistemi. Entrano in gioco architettura, gestione del contesto, tool integration, orchestrazione, observability e controllo delle azioni.
Non significa necessariamente che gli sviluppatori smetteranno di scrivere codice.
Significa che il codice potrebbe diventare una parte di un processo più ampio, nel quale persone e agenti collaborano per progettare, costruire e gestire sistemi software.
Scopri i due talk alla Codemotion AI & Tech Conference
Se vuoi capire come questo cambiamento sta prendendo forma concretamente, i due interventi di Giovanni Galloro e Riccardo Carlesso offrono due punti di vista complementari.
Giovanni Galloro sarà sullo Stage III, giovedì 29 ottobre dalle 12:10 alle 12:40, con una sessione dedicata all’utilizzo di di Google Antigravity per progettare, sviluppare e integrare agenti con Google ADK. Riccardo Carlesso sarà invece sullo stage il giovedì 29 ottobre, con un approfondimento sull’utilizzo di agenti, skill e MCP per il troubleshooting in produzione.
Due sessioni, due momenti diversi del ciclo di vita del software e una stessa direzione: capire cosa succede quando gli AI agent smettono di essere semplicemente strumenti che usiamo e diventano parte del modo in cui costruiamo e gestiamo il software.
Scopri tutti i dettagli e gli altri appuntamenti nell’agenda della Codemotion AI & Tech Conference.
