Tutti parlano di Continual Learning come se significasse una cosa sola: aggiornare i pesi del modello. Ma c'è una verità scomoda nell'ecosistema degli agenti: la stragrande maggioranza degli agenti in produzione oggi sfrutta modelli frontier chiusi. Quando non possiedi i pesi, non puoi certo fare fine-tuning. Per la maggior parte dei costruttori di agenti, il continual learning a livello di pesi è fuori discussione, specialmente quando si lavora ai vertici delle capacità (pensa a Fable 5 o GPT 5.6).
Questo non significa che gli agenti non possano imparare. I sistemi agenziali possono migliorare su tre livelli: modello, harness e contesto [0] — e gli ultimi due sono completamente sotto il tuo controllo. È qui che si cela un'enorme (ma spesso trascurata) opportunità: l'apprendimento a livello di harness ti permette di analizzare le tracce di produzione per migliorare sistematicamente il codice, gli strumenti e le istruzioni che alimentano ogni istanza del tuo agente, mentre l'apprendimento a livello di contesto ti permette di personalizzare a livello di agente, utente e organizzazione, così il tuo prodotto migliora a ogni interazione. Fai tutto quanto sopra e otterrai miglioramenti cumulativi che puoi rilasciare ogni giorno.
Nel resto di questo articolo, ti guiderò attraverso come abbiamo applicato il continual learning a Replit Agent nell'ultimo anno, condividendo tutte le lezioni apprese lungo il percorso.
Valutare e migliorare Replit Agent su larga scala
La maggior parte degli utenti di Replit Agent inizia con un'idea. Descrivono l'obiettivo in linguaggio naturale — senza un repository, una suite di test o un framework scelto — e si aspettano che l'agente lo trasformi in un'app funzionante. Il risultato potrebbe essere un sito web, una presentazione di Slides, un'app mobile, diversi artefatti collegati o qualcosa di completamente diverso.
I vibe coder di solito non controllano i diff o l'output dei test. Il successo per Replit Agent è ingannevolmente semplice: l'app dovrebbe funzionare quando gli utenti ci cliccano sopra.
Questo cambia il compito della valutazione. Un singolo punteggio può aiutare con una decisione di rilascio specifica, ma non può dirci, settimana dopo settimana, se Replit Agent sta migliorando per gli utenti. Per rispondere a questa domanda, la valutazione deve diventare parte del ciclo di miglioramento.
NASA Lewis Research Center, Central Control Room nell'Engine Research Building, 1968 — La misurazione conta quando cambia ciò che viene rilasciato.
La valutazione ora deve fare di più
La valutazione degli agenti un tempo sembrava un processo a senso unico: esegui la valutazione, produci un punteggio e prendi una decisione di rilascio. Questo funziona quando i rilasci sono lenti e la cosa misurata cambia raramente. Si rompe quando modelli, prompt, strumenti e superfici di prodotto cambiano tutti rapidamente.
Il vecchio ciclo faceva sembrare la valutazione limitata. Ma Replit Agent cambia troppo rapidamente perché un singolo punteggio possa sostenere l'intera decisione. Un punteggio può confrontare due candidati su una singola fetta di compiti. Non può spiegare ciò a cui tengono gli utenti, dove si rompe la produzione o cosa migliorare dopo.
La valutazione doveva passare da un controllo di lancio a un ciclo di miglioramento.
Il vecchio compito di valutazione termina con una decisione umana di rilascio; quello nuovo alimenta un sistema continuo che impara dalla produzione e rilascia agenti migliorati.
Il sistema ha due pilastri di misurazione e un ciclo di ottimizzazione. I benchmark offline ci dicono se le modifiche candidate possono completare compiti simulati di creazione di app prima che le rilasciamo. I test A/B online e le tracce di produzione mostrano come gli utenti reali vengono influenzati dopo il rilascio delle modifiche. Questi segnali poi rifluiscono nelle valutazioni e nelle decisioni di rilascio.
Nessun livello è sufficiente da solo. I benchmark individuano le regressioni prima del rilascio. I test A/B mostrano se il comportamento in produzione è cambiato. I cluster di tracce spiegano i fallimenti sotto le metriche aggregate. Il giudizio umano mantiene il ciclo di miglioramento puntato verso i giusti risultati di prodotto e ingegneria. La forma è analoga al modello del formaggio svizzero nell'ingegneria della sicurezza: ogni strato ha buchi, ma insieme catturano più di quanto qualsiasi strato possa fare da solo.
I benchmark esistenti si fermano prima dell'utente
Benchmark di coding agenziale come SWE-bench [1] e Terminal-Bench [2] valutano il codice in ambienti vincolati e ripetibili. Questi benchmark sono preziosi e ampiamente adottati, ma perdono il segnale a cui un vibe coder tiene.
Replit Agent spesso crea il codebase da zero. Gli utenti non portano route fisse, firme di funzioni, selettori o test; portano una richiesta di prodotto. L'agente sceglie lo stack, lo schema, le route, i componenti e i flussi di interazione.
Questo crea un divario di correttezza funzionale. Un agente può soddisfare i vincoli locali di un benchmark di coding e fallire comunque in ciò che l'utente vede: se l'app finita fa ciò che è stato richiesto. Per il vibe coding, l'obiettivo di valutazione è l'artefatto stesso: si carica, il flusso di lavoro principale funziona e il risultato corrisponde alla richiesta?
Presentazione di ViBench
La necessità di questo stile di valutazione end-to-end è precisamente il motivo per cui abbiamo costruito ViBench [3], il nostro benchmark pubblico per il vibe coding, che misura un segnale semplice ma importante: l'applicazione costruita dall'agente soddisfa le specifiche?
ViBench inizia con un documento dei requisiti di prodotto (PRD) in inglese semplice tratto da tracce di produzione anonimizzate di Replit. Da lì, l'agente riceve il PRD e costruisce un'app funzionante da zero, senza essere vincolato all'impalcatura, alle route o ai riferimenti che i benchmark di coding tradizionali richiedono.
Tuttavia, la stessa flessibilità che rende ViBench realistico richiede un agente di valutazione altrettanto flessibile, uno che rimanga ancorato al PRD. Nei benchmark in stile SWE-bench, il progetto esiste già, quindi la superficie di valutazione è fissa. Nel vibe coding, l'agente sceglie lo stack, le route, i componenti e il flusso. La valutazione deve esplorare qualunque cosa abbia inventato.
A tal fine, ogni compito di ViBench abbina il PRD a una serie di piani di test in linguaggio naturale che descrivono le interazioni a livello di funzionalità e le asserzioni che l'app finita deve soddisfare. L'agente di valutazione usa Playwright come spina dorsale flessibile, che gli permette di esercitare funzionalità complesse come simulazione offline, manipolazione di file e multi-tenancy. Poiché non conosce i locator o la struttura dell'app a priori, lavora in un ambiente notebook, scoprendo progressivamente come è costruita l'app e interagendo con essa passo dopo passo, un approccio tratto dalla precedente ricerca di Replit sui test automatici [4].
Eseguire ViBench, e le nostre valutazioni in generale, alla scala di Replit richiede anche un forte supporto infrastrutturale [5]. Internamente, ci appoggiamo alla stessa infrastruttura di produzione che ci permette di creare sandbox isolati e ben forniti per costruire app ed eseguire i nostri agenti. Poiché possiamo biforcare rapidamente quelle sandbox [6], eseguiamo gran parte della valutazione in parallelo, senza rischiare contaminazione incrociata tra le valutazioni.
Oltre a costruire app da zero, la stessa base di ViBench, un PRD in linguaggio naturale valutato da piani di test in linguaggio naturale, si adatta a una gamma di scenari di vibe coding. Per valutare come un agente lavora all'interno di un'app esistente, più vicino ai carichi di lavoro a metà traiettoria di Replit, lo avviamo su un codebase esistente e misuriamo quanto bene riesce a rilasciare estensioni di funzionalità da un PRD di funzionalità. Quel codebase può provenire dalle nostre implementazioni di riferimento o da app che l'agente ha stesso vibe-codato, che chiamiamo Vibe-to-ref e Vibe-on-Vibe nella nostra pubblicazione. Quando rilasciamo nuove superfici di prodotto, la stessa spina dorsale ci permette di derivare rapidamente nuovi problemi per valutare nuovi modelli di interazione, come abbiamo fatto per le scomposizioni parallelo-e-unione e sub-agente dell'Agente 4.
ViBench mantiene il valutatore comportamentale fisso mentre varia l'input e la strategia di costruzione.
I primi risultati di ViBench ci hanno dato due lezioni utili. In primo luogo, i punteggi dei benchmark di coding frontier non sempre si trasferiscono alla creazione completa di app, specialmente per i modelli a pesi aperti. In secondo luogo, la maggior parte dei modelli peggiora quando estende il proprio codice, poiché gli errori spesso si accumulano. Insieme, queste lezioni ci danno una collina migliore da scalare: non solo scrivere codice che supera i test, ma costruire app che possono sopravvivere alla prossima richiesta dell'utente.
L'A/B è come ci teniamo onesti
Ci fidiamo profondamente delle valutazioni offline, ma non sono l'unico giudice. Abbiamo visto abbastanza aggiornamenti degli agenti apparire buoni in ambienti controllati, solo per regredire nel comportamento reale degli utenti, da sapere che la produzione ha bisogno del proprio livello di misurazione.
Gli utenti sono non scriptati, sempre attivi e operano a una scala che nessun benchmark offline può replicare completamente. Abbandonano progetti, cambiano idea, combinano funzionalità in modi sorprendenti e scoprono modalità di fallimento che non sapevamo di dover testare.
Quindi facciamo A/B sulla maggior parte degli aggiornamenti che influenzano l'agente: prompt, strumenti, revisioni dell'harness, cambi di modello e modifiche comportamentali più ampie. Spesso più esperimenti vengono eseguiti contemporaneamente — con attribuzione mantenuta chiara per evitare di nascondere effetti di interazione. I test A/B mettono in luce il comportamento, il sentiment e il successo dell'utente: gli utenti hanno continuato, il costo si è comportato in modo inaspettato, il sentiment è cambiato e gli utenti hanno rilasciato qualcosa?
I test A/B ci danno una lettura controllata del comportamento in produzione, ma le metriche aggregate non si spiegano da sole. È una vittoria? Qual è il cambiamento di comportamento alla radice?
Una sfida con i test A/B è che i risultati sono difficili da interpretare. Se la durata di esecuzione aumenta, l'agente ha fatto più lavoro utile o si è bloccato? Se il costo diminuisce, abbiamo migliorato l'efficienza o l'agente ha smesso silenziosamente di fare qualcosa di prezioso? Se il sentiment cala, quali casi d'uso sono regrediti, quali modalità di fallimento sono nuove e quali utenti hanno rinunciato?
Telescope: cosa si sta rompendo
I test A/B ci dicono quando il comportamento in produzione si è spostato. Telescope — il nostro sistema per l'analisi e il clustering delle tracce — aiuta a spiegare perché.
Alla scala di produzione, nessun ingegnere può leggere ogni traccia. Telescope organizza schemi ripetuti in cluster di problemi su cui ingegneri e agenti possono agire. Riassume le traiettorie di fallimento, le incorpora, raggruppa casi simili e classifica nuove sessioni man mano che la distribuzione cambia. L'obiettivo non è solo contare i fallimenti, ma scoprire quelli nascosti in bella vista.
GIF
Raggruppare ciò che non sapevamo di cercare.
Telescope usa sfaccettature brevi e basate su prove, ispirate allo stesso approccio bottom-up di Clio [7]. Per le tracce, ricostruisce la sessione a partire dai messaggi dell'utente, dalle risposte visibili dell'agente, dalle chiamate agli strumenti, dagli errori, dai metadati e da altro contesto. Da lì, Telescope riassume cosa è andato storto, incorpora quei riassunti e usa il clustering basato sulla densità [8] per formare gruppi di problemi emergenti.
Le sfaccettature rendono l'indagine più rapida, specialmente quando il clustering da solo non è sufficiente. Quando i report di supporto puntano a un problema ampio, come i fallimenti delle porte, ingegneri e agenti possono prima cercare nel livello compatto, esplorare le sfaccettature rilevanti e poi approfondire le sessioni rappresentative con il contesto di log e osservabilità necessario per spiegarlo.
In aggregato, la stessa struttura trasforma i fallimenti sparsi in domande di prodotto: quali flussi di lavoro dominano, quali vengono abbandonati, cosa si rompe ripetutamente e se una mitigazione sta riducendo il cluster previsto.
Per maggiori dettagli su questa architettura sottostante, consulta il post approfondito su Topics dei nostri collaboratori di Braintrust [9].
Il ciclo: dalle prove ai miglioramenti dell'agente
Una volta che la misurazione esiste, il collo di bottiglia si sposta. ViBench, i test A/B e Telescope possono dirci cosa è fallito, dove è fallito e quanto spesso sta accadendo. Dobbiamo ancora trasformare quelle prove in correzioni plausibili.
Ci rivolgiamo a un ciclo di auto-miglioramento per affrontare questo problema. Il principio operativo è semplice: se gli agenti sono utili per costruire software, dovrebbero essere utili anche per migliorare l'agente. Ogni passaggio inizia leggendo i log di produzione, i cluster di tracce e i fallimenti recenti per trovare un'ipotesi che valga la pena perseguire. Poi costruisce un candidato, apre una PR bozza con il ragionamento allegato, misura il risultato rispetto a ViBench, ai risultati A/B, ai dati della traiettoria e ai benchmark recenti, e raccomanda se rilasciare, iterare o abbandonare.
Il ciclo di ottimizzazione scopre problemi, propone modifiche all'agente, le valuta e decide se rilasciare, iterare o abbandonare.
Il rilascio non diventa automatico. Il ciclo può preparare le prove e l'implementazione di prima passata; gli ingegneri rivedono ancora il risultato e possiedono la decisione di lancio.
Ogni esecuzione registra cosa ha provato e cosa è successo, inclusi i fallimenti. Quel registro migliora il ciclo nel tempo: le esecuzioni future possono riutilizzare ciò che ha funzionato, evitare vicoli ciechi noti e proporre modifiche che generalizzano.
L'iterazione dell'agente diventa più veloce senza rinunciare al controllo ingegneristico. Dato un nuovo modello, superficie di prodotto o obiettivo di affidabilità, il ciclo può trovare proattivamente modifiche ai prompt, proposte di skill, correzioni agli strumenti e cambiamenti all'harness mentre gli ingegneri mantengono il sistema puntato verso l'ottimo di prodotto più ampio.
Un esempio concreto
Una recente esecuzione è iniziata con un piccolo cluster di Telescope in crescita. La configurazione dell'ambiente si stava silenziosamente degradando in una lunga coda di scenari di avvio a freddo. Queste sessioni non erano ovvie dalle metriche aggregate, ma il cluster mostrava uno schema che valeva la pena indagare.
Dopo aver portato alla luce lo schema, il ciclo ha letto le traiettorie interessate, proposto una patch, aggiunto un test di regressione ed eseguito il candidato rispetto a ViBench per confermare che il percorso felice non regredisse. Gli ingegneri hanno esaminato le prove, approvato la modifica e l'hanno spinta in produzione lo stesso giorno.
Dopo il rilascio della patch, il sentiment si è ripreso e gli utenti interessati sono stati sbloccati. Questa è la forma che vogliamo — un ciclo che trova un vero schema di fallimento, lo collega agli utenti interessati, propone il giusto livello di correzione e riporta abbastanza prove perché un umano decida se rilasciare.
Dove il gusto umano conta ancora di più
Gran parte di questo può funzionare in modo autonomo: raggruppare i fallimenti, proporre ipotesi, costruire candidati, eseguire valutazioni e assemblare prove. Gli umani stabiliscono ancora la direzione e presidiano la maggior parte delle uscite, inclusi:
- Selezione dell'ipotesi. Un sistema può portare alla superficie mille fallimenti, ma gli umani decidono quali domande meritano il budget notturno del ciclo. Non tutti i cluster sono ugualmente importanti e non tutte le regressioni puntano al giusto problema di prodotto.
- Architettura di implementazione. Le tracce potrebbero mostrare che gli utenti stanno abbandonando un flusso di lavoro, ma decidere se appianare quel percorso, cambiare il comportamento dell'agente o riprogettare la superficie è un giudizio di ingegneria e prodotto.
- Cura della valutazione. Questo non è lavoro amministrativo; modella la collina che l'agente scala. Se la valutazione premia il comportamento sbagliato, il ciclo di ottimizzazione ottimizzerà fedelmente verso la cosa sbagliata.
- Approvazione del lancio. Rilasciare una modifica all'agente non significa solo leggere un numero. L'approvazione del lancio significa leggere le prove, comprendere il raggio d'esplosione, decidere se il rischio è accettabile e possedere il rollout.
Quell'equilibrio conta: il ciclo può fare più della ricerca, misurazione e sintesi. Gli ingegneri scelgono ancora la direzione, prendono le decisioni di prodotto e decidono cosa rilasciare.
Chiudere il cerchio
La valutazione non è più solo un gate prima del lancio. Aiuta a decidere cosa riparare, cosa testare e cosa rilasciare.
Il lavoro non è produrre un numero migliore. È trasformare i fallimenti degli utenti in rilasci migliori, così che più idee diventino app di cui le persone sono orgogliose di pubblicare.
Siamo entusiasti di continuare a spingere la frontiera degli agenti autonomi, con un focus sull'affidabilità per i compiti di coding più complessi. Se sei interessato a lavorare su agenti di coding autonomi, assumo sempre nel team AI di Replit — contattami a [email protected]
Autori: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Riferimenti
[0] Continual learning for AI agents
[1] SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
[2] Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces
[3] ViBench: A Benchmark on Vibe Coding
[4] Enabling Agent 3 to Self-Test at Scale with REPL-Based Verification
[5] Quantifying infrastructure noise in agentic coding evals
[6] Inside Replit’s Snapshot Engine: The Tech Making AI Agents Safe
[7] Clio: Privacy-Preserving Insights into Real-World AI Use
[8] Hierarchical Density Estimates for Data Clustering, Visualization, and Outlier Detection
[9] How we made continuous trace intelligence possible at scale
