Dal “Bring Your Own Agent” agli Agent Evals: come costruire un ciclo di sviluppo in cui gli agenti AI siano componenti governabili, testabili e realmente affidabili.
Come in tutte le innovazioni informatiche c’è un momento in cui una tecnologia smette di essere semplicemente uno strumento interessante e comincia a diventare parte fondamentale della produzione entrando nel campo dell’ingegneria vera e propria. È successo con i sistemi di versionamento, con la continuous integration, con i container e, più recentemente, con le piattaforme cloud-native: in tutti questi casi il passaggio decisivo non è stato soltanto adottare un nuovo strumento, ma integrarlo all’interno di processi capaci di renderla ripetibile, controllabile e, soprattutto, affidabile.
Con gli AI agent ci troviamo oggi davanti a un passaggio simile. Un agente non si limita più a suggerire una porzione di codice o a rispondere a una domanda dello sviluppatore, ma può ricevere un obiettivo, analizzare un repository, consultare documentazione, utilizzare strumenti, modificare file, eseguire test e arrivare fino alla preparazione di una pull request. In altre parole, può partecipare concretamente al processo attraverso il quale un requisito viene trasformato in software.
Ed è proprio qui che nasce una domanda molto più interessante della semplice discussione sulle capacità dei modelli: che cosa succede quando un agente entra davvero nel ciclo di sviluppo?
La risposta non può essere semplicemente che scriveremo più codice in meno tempo. Se gli agenti devono diventare parte del processo, dobbiamo iniziare a considerarli per quello che sono: nuovi componenti del sistema di sviluppo, che devono essere progettati, versionati, testati, osservati e governati con la stessa attenzione che riserviamo agli altri artefatti software.
È questo il punto di partenza dell’Agentic Software Development Life Cycle, un’evoluzione del tradizionale SDLC nella quale gli agenti diventano ‘cittadini’ effettivi al processo di sviluppo.
Quando l’agente smette di essere un assistente
La prima generazione di strumenti AI per sviluppatori ha introdotto un modello relativamente semplice. Lo sviluppatore poneva una domanda, il modello elaborava una risposta e la persona decideva cosa farne. Poteva chiedere una spiegazione, una funzione, un test o un suggerimento per correggere un errore, mantenendo comunque il controllo diretto di ogni passaggio.
Gli agenti cambiano questo paradigma perché possono lavorare verso un obiettivo anziché limitarsi a rispondere a una singola richiesta. Possono scomporre un problema, decidere quali strumenti utilizzare, verificare il risultato di un’operazione e proseguire con quella successiva. La differenza può sembrare sottile, ma dal punto di vista dell’ingegneria del software è enorme, perché significa che una parte del processo può essere delegata a un sistema capace di prendere decisioni operative.
Immaginiamo, per esempio, una normale Request for Enhancement. Oggi uno sviluppatore deve comprendere il requisito, capire quali parti del sistema siano coinvolte, analizzare il codice esistente, costruire un piano di implementazione e infine realizzare la modifica. In un Agentic SDLC alcuni di questi passaggi possono essere affidati a uno o più agenti, che analizzano la richiesta e il repository, contribuiscono alla definizione del piano, realizzano la modifica e verificano il comportamento del sistema.
Questo non significa sostituire lo sviluppatore. Significa piuttosto spostare il lavoro umano verso le attività nelle quali comprensione del contesto, responsabilità e giudizio rimangono fondamentali.
Per questo, quando si parla di agenti, la domanda più utile probabilmente non è quanto siano autonomi, ma quanto bene abbiamo progettato la loro autonomia.
Bring Your Own Agent
Da questa considerazione nasce naturalmente il concetto di Bring Your Own Agent, o BYOA. Se gli agenti diventano componenti del processo di sviluppo, è difficile immaginare che una singola implementazione possa essere la soluzione migliore per ogni team, progetto o fase del ciclo di vita.
Un’organizzazione potrebbe avere agenti specializzati nell’analisi del codice, nella generazione dei test, nella documentazione o nella sicurezza, e potrebbe voler utilizzare modelli e framework differenti a seconda del caso d’uso. La possibilità di ‘portare’ il proprio agente diventa quindi soprattutto una questione architetturale: l’infrastruttura deve essere in grado di eseguire e governare componenti differenti senza obbligare il team a costruire ogni volta un sistema completamente nuovo.
È un principio molto vicino a quello che ha guidato l’evoluzione del cloud-native. Kubernetes non ha avuto successo perché ha eliminato la complessità dei sistemi distribuiti, ma perché ha fornito un modello standard attraverso il quale gestire workload differenti. L’idea del BYOA segue una logica simile: lasciare libertà nella scelta del componente, mantenendo però standard e regole comuni nel modo in cui quel componente viene eseguito, osservato e integrato nel processo.
In questo scenario, l’approccio open source rappresenta il fondamento naturale del BYOA. L’utilizzo di standard aperti e di tecnologie basate sulla collaborazione delle community consente alle organizzazioni di adottare, combinare e governare agenti e framework differenti senza subire vincoli di vendor lock-in. È la stessa filosofia che ha guidato la crescita del cloud-native, in cui la libertà di scelta si unisce alla condivisione di regole comuni, garantendo piena visibilità su come gli agenti operano e interagiscono con il codice.
Questa distinzione diventa ancora più importante quando si parla di sovranità digitale. Avere il controllo del proprio Agentic SDLC non significa necessariamente costruire internamente un grande modello linguistico. Significa poter decidere quali modelli utilizzare, dove eseguirli, quali dati possono raggiungere, quali strumenti possono utilizzare e come vengono verificati i risultati prodotti.
La libertà di cambiare un modello o un framework senza dover riscrivere l’intero processo diventa quindi una caratteristica architetturale, non semplicemente una preferenza tecnologica.
Dobbiamo sapere chi ha fatto cosa
C’è però un passaggio ulteriore. Se un agente entra davvero nel processo di sviluppo, non possiamo considerarlo una sorta di assistente anonimo che produce codice e poi scompare. Dobbiamo poter ricostruire il suo lavoro, proprio come facciamo per qualsiasi altro passaggio della nostra pipeline.
Quando una modifica arriva in produzione, siamo abituati a sapere da quale commit proviene, quali dipendenze sono state utilizzate e quale versione del software è stata distribuita. Con gli agenti dobbiamo applicare lo stesso principio: sapere quale agente ha lavorato alla modifica, quale modello stava utilizzando, con quale configurazione, quali strumenti aveva a disposizione e quale contesto gli era stato fornito.
Questo livello di tracciabilità diventa importante soprattutto quando qualcosa va storto. Se una modifica introduce un problema, non dovrebbe essere necessario indovinare cosa sia successo o ripetere l’esperimento sperando di ottenere lo stesso risultato. Dovremmo poter ricostruire il percorso che ha portato a quella modifica e capire in quali condizioni l’agente ha preso le proprie decisioni.
In questo senso, trattare l’agente come una componente del processo di sviluppo significa soprattutto renderne il comportamento identificabile, riproducibile e verificabile. Ed è proprio questo che permette di portare gli agenti fuori dalla fase sperimentale e dentro sistemi software che devono funzionare davvero in produzione.
Il mondo cloud-native ha già sviluppato molti dei concetti necessari per affrontare questo problema: artefatti versionati, registri, pipeline automatizzate, firme, attestazioni e meccanismi per verificare la provenienza di ciò che viene distribuito. L’evoluzione dell’AI porta questi concetti in un territorio nuovo, nel quale modelli, configurazioni, agenti e risultati delle valutazioni entrano progressivamente nella stessa supply chain.
L’obiettivo non è aggiungere complessità all’AI, ma fare esattamente il contrario: utilizzare pratiche ingegneristiche mature per rendere più prevedibile una tecnologia che, per sua natura, introduce una componente di variabilità.
Il problema non è soltanto generare codice
Ed è proprio questa variabilità a introdurre una delle questioni più interessanti dell’Agentic SDLC.
Un agente può produrre codice che compila e che supera i test già presenti nel progetto, ma questo non significa necessariamente che abbia svolto correttamente il lavoro richiesto. Potrebbe aver interpretato male un requisito, modificato un componente che non avrebbe dovuto toccare, introdotto una soluzione eccessivamente complessa oppure utilizzato uno strumento al di fuori dei limiti che gli erano stati assegnati.
Con un sistema tradizionale siamo abituati a verificare principalmente il risultato del software. Con un agente dobbiamo iniziare a verificare anche il comportamento che ha portato a quel risultato.
È qui che entrano in gioco gli Agent Evals, che possono essere considerati, con una certa semplificazione, una sorta di CI/CD del comportamento dei sistemi AI.
L’idea è costruire scenari ripetibili nei quali l’agente riceve un determinato compito e il sistema valuta automaticamente ciò che è accaduto. Non si tratta soltanto di stabilire se la risposta sia corretta, ma di verificare se l’agente abbia rispettato i requisiti, utilizzato gli strumenti appropriati, modificato le parti corrette del sistema e prodotto un risultato coerente con gli standard definiti dal team.
In questo modo la valutazione smette di essere un’attività manuale e occasionale e diventa una parte del processo di delivery.
Gli Agent Evals come nuova quality gate
La vera forza degli eval emerge quando smettono di essere semplicemente un sistema per assegnare un punteggio e diventano una quality gate della pipeline.
Possiamo immaginare un flusso nel quale una RFE viene prima analizzata da un agente, trasformata in un piano di implementazione e quindi affidata a un agente di sviluppo. Il codice prodotto viene sottoposto ai normali controlli di qualità e, successivamente, l’intero comportamento dell’agente viene verificato attraverso una serie di eval progettati specificamente per quel progetto.
Se il risultato non raggiunge una determinata soglia, la pipeline si ferma. Se un test fallisce, la modifica non procede. Se l’agente viola una policy o utilizza uno strumento non autorizzato, il processo viene bloccato.
La modifica può arrivare alla code review soltanto quando l’insieme dei controlli ha fornito sufficienti garanzie.
Questo introduce una distinzione importante rispetto alla semplice generazione automatica di codice. L’obiettivo non è produrre più software possibile, ma aumentare la velocità mantenendo il controllo sulla qualità del risultato.
In altre parole, l’AI diventa davvero utile quando il lavoro che ci fa risparmiare non viene semplicemente spostato nella fase successiva sotto forma di attività di verifica manuale.
L’autonomia deve essere progettata
Parlare di agenti autonomi può facilmente far pensare a sistemi ai quali concedere la massima libertà possibile. In un ambiente di produzione, però, dovrebbe essere esattamente il contrario.
L’autonomia deve essere progettata e delimitata.
Un agente potrebbe avere accesso in lettura al repository ma non in scrittura, potrebbe creare una pull request senza poter effettuare direttamente il merge oppure potrebbe essere autorizzato a eseguire test e modificare un ambiente temporaneo senza avere alcun accesso all’infrastruttura di produzione.
Questi limiti non rappresentano necessariamente un ostacolo, piuttosto sono ciò che permette all’automazione di essere utilizzata in un contesto reale.
La vera autonomia, soprattutto in un ambiente enterprise, non coincide quindi con l’assenza di vincoli ma è la capacità di operare autonomamente all’interno di un perimetro definito e verificabile.
Anche in questo caso l’esperienza maturata nell’ecosistema cloud-native offre un modello interessante: sistemi complessi diventano gestibili quando responsabilità, permessi e confini vengono esplicitati e trasformati in regole che la piattaforma può applicare automaticamente.
Dalla RFE alla release
A questo punto è possibile immaginare un Agentic SDLC completo, nel quale il passaggio da una richiesta a una release non sia più una sequenza di attività esclusivamente manuali, ma un processo nel quale uomini e agenti collaborano all’interno di confini ben definiti.
Una RFE può essere analizzata da un agente che la confronta con il codice e con la documentazione esistente, contribuendo a trasformarla in una specifica più precisa. Un altro agente può costruire il piano di implementazione, mentre un agente di sviluppo realizza la modifica in un ambiente isolato.
A quel punto entrano in gioco gli strumenti che conosciamo già: test automatici, analisi statica, controlli di sicurezza e continuous integration. Ma, accanto a questi, vengono eseguiti gli Agent Evals, che verificano il comportamento del sistema agentico e confrontano il risultato con criteri stabiliti in precedenza.
Soltanto quando questi controlli vengono superati la modifica può arrivare alla revisione umana e proseguire verso la release.
La differenza rispetto all’utilizzo occasionale di un copilota è sostanziale. L’agente non è più uno strumento che lo sviluppatore apre quando ne ha bisogno, ma diventa un componente del sistema di delivery.
La sovranità passa anche dalla supply chain
Questo modello porta inevitabilmente a un’altra questione: la supply chain.
Quando il software viene sviluppato con il contributo di agenti, la catena degli artefatti coinvolti diventa più articolata. Non abbiamo soltanto il codice sorgente e le sue dipendenze, ma anche modelli, configurazioni, agenti, tool e risultati delle valutazioni che contribuiscono al processo.
Diventa quindi importante poter rispondere a una domanda molto semplice: da dove proviene ciò che stiamo distribuendo?
Possiamo verificare l’integrità di un codice? Possiamo associarlo alla sua provenienza? Possiamo sapere quale versione di un modello o di un agente abbia contribuito a una determinata release? Possiamo dimostrare che ciò che stiamo eseguendo corrisponde effettivamente a ciò che è stato valutato?
È qui che concetti come OCI, registri di artefatti, firme e attestazioni assumono un’importanza che va ben oltre l’infrastruttura. Diventano strumenti per costruire una supply chain nella quale anche gli elementi AI possano essere identificati, verificati e governati.
La sovranità digitale, in questo senso, non consiste soltanto nel decidere dove eseguire un modello. Consiste nel mantenere il controllo dell’intera catena attraverso la quale quel modello, quell’agente e il software che ne deriva arrivano fino alla produzione.
È proprio in questo ambito che l’impegno open source diventa centrale. Promuovere una supply chain software aperta, trasparente e verificabile significa assicurarsi che ogni componente, dai modelli ai framework degli agenti, fino agli artefatti generati, possa essere ispezionato, tracciato e governato con rigorosi standard ingegneristici. La vera sovranità digitale nell’era dell’AI non si ottiene blindando i sistemi, ma costruendo una filiera aperta in cui la fiducia è il risultato di trasparenza, verificabilità e collaborazione.
L’obiettivo non è sostituire gli sviluppatori
La questione è molto più concreta. Gli agenti possono prendere in carico una parte crescente del lavoro necessario per trasformare un requisito in software, ma più aumenta la loro capacità di agire, più diventa importante progettare il sistema che li circonda.
Servono specifiche migliori, architetture modulari, standard, ambienti isolati, policy, osservabilità, test e sistemi di evaluation. Serve inoltre una supply chain capace di descrivere la provenienza degli artefatti e di fornire evidenze sulla loro integrità.
In altre parole, l’arrivo degli agenti rende ancora più importante l’ingegneria del software.
Il vero salto non sarà quindi passare dal programmatore all’agente, ma passare dall’agente utilizzato come strumento occasionale all’agente inserito in un processo nel quale ogni componente può essere versionato, verificato e governato.
È questo il significato più interessante del Bring Your Own Agent: lasciare ai team la libertà di scegliere e costruire i propri agenti senza rinunciare agli standard della piattaforma, poter utilizzare modelli e framework differenti mantenendo un processo comune e aumentare progressivamente l’autonomia senza perdere la capacità di controllare ciò che accade.
Perché la domanda decisiva nell’era degli agenti non sarà più soltanto quanto codice può scrivere l’AI, ma capire quanto possiamo fidarci del software che l’AI contribuisce a costruire.
E la risposta, ancora una volta, passerà dall’ingegneria del software.
Scopri come l’AI sta cambiando il modo di sviluppare software nel talk “Bring Your Own Agent: Building Real-World Agents for a Sovereign SDLC” di Daniele Zonca e Matteo Mortari alla Codemotion AI & Tech Conference di Milano.
