Costruire un Agent non è semplice.
Un anno fa dovevamo gestire da soli il contesto e la memoria, ragionare su RAG e database vettoriali e mettere a punto con grande attenzione l'accuratezza nell'uso dei tool. La comparsa di Claude Code / Claude Agent SDK ha cambiato tutto questo. Oggi sempre più team iniziano a costruire Agent direttamente con Claude Agent SDK + VM. Ma il problema è quindi diventato più semplice? No.
Eseguire Claude Code dentro le VM è ancora qualcosa di molto impegnativo.
-
Ogni sessione utente ha bisogno di una VM indipendente. In alcuni scenari la capacità di persistenza delle VM può tornare utile, ma rende anche le VM difficili da aggiornare e da orchestrare. Per esempio, dal punto di vista dell'utente ci si aspetta che il software installato sulla VM sia ancora disponibile mesi dopo. Ma anche le parti della VM che comunicano con il livello di orchestrazione devono poter ricevere aggiornamenti progressivi.
-
Creare e orchestrare VM su larga scala. Un singolo cluster k8s supporta l'orchestrazione di qualche migliaio di pod circa, il che è sufficiente per i cluster di servizi applicativi. Ma non basta del tutto in scenari in cui ogni sessione deve avviare un pod di Claude Code.
-
Adottare soluzioni basate su k8s comporta la latenza introdotta da k8s, rendendo difficile ottenere prestazioni entro 1 secondo.
-
Adottare soluzioni basate su e2b richiede di gestire da soli la persistenza, e sia il caricamento sia il download dei file sono molto lenti.
-
La soluzione e2b non riesce a soddisfare requisiti specifici di ambiente di rete, e il deployment privato è complicato.
Come risolviamo questi problemi? Impariamo dalla storia. Quando il calendario torna indietro di oltre un decennio, nel 2012, nel mondo non esistevano il serverless, né k8s, né docker. Gli ingegneri backend dovevano mantenere manualmente un processo di servizio su una macchina fisica per far girare un servizio. All'epoca ssh e ansible erano strumenti standard per gli ingegneri di sistema. I processi di servizio dipendevano fortemente dai vari ambienti e strumenti presenti sulla macchina fisica. Ottenere configurazioni coerenti degli ambienti tra le diverse macchine fisiche era molto impegnativo, e lo scaling su larga scala era un'impresa importante a cui i team dovevano prepararsi con largo anticipo. Ricordo ancora quando un ingegnere modificò l'ambiente di una macchina e dimenticò di sincronizzarlo con gli ambienti delle altre, causando in produzione un ghost bug difficilissimo da individuare. Quel periodo era un vecchio tempo molto doloroso.
Nel 2012 comparve docker. Docker impacchettava tutti gli ambienti e gli strumenti in un'unica immagine, risolvendo il problema dell'incoerenza degli ambienti. La community capì gradualmente che un processo di servizio in esecuzione in una macchina virtuale su una macchina fisica poteva essere gestito come un processo sulla macchina fisica stessa. Ma l'orchestrazione di docker richiedeva comunque ai team di ingegneria di costruire un sistema di orchestrazione. E una volta che il processo di servizio dentro docker diventava accoppiato alla rete e al file system della macchina fisica, l'orchestrazione diventava una cosa molto dolorosa.
Nel 2014 i servizi stateless iniziarono a diventare la tendenza dominante. Quell'anno videro la luce Kubernetes e AWS Lambda. Ciascuno descriveva il futuro dei servizi stateless da una prospettiva diversa. Servizi stateless significava che la logica di servizio evitava l'accoppiamento con gli indirizzi di rete e non dipendeva più localmente da file system persistenti.
Poi vennero i 10 anni del cloud native: l'ondata dei servizi stateless diede vita a un gran numero di infrastrutture cloud native, come:
- Service gateway Istio/Linkerd/Envoy/Treafik
- Piattaforme CI/CD Argo CD / Flux
- Piattaforme di osservabilità Prometheus/Grafana/ELK Stack
- Analisi delle call chain Jaeger/Zipkin/OpenTelemetry
- Storage Rook/MinIO/JuiceFS
E ora siamo a un nuovo inizio. Dieci anni fa un'unità di calcolo era un processo di servizio api in java/python. A partire da quest'anno, questa unità di calcolo è diventata un coding agent.
ACFS è come l'epoca in cui si mantenevano manualmente i processi di servizio sulle macchine fisiche. E2B è come Docker. Senza piattaforme di orchestrazione dei task, piattaforme di osservabilità e capacità di storage distribuito per la persistenza dello stato, la scalabilità resta una cosa difficile per i coding agent. E la Serverless Agent Infra che mi aspetto possiede queste capacità:
- Capace di persistere in modo appropriato le sessioni e le working directory del coding agent senza perdere il contesto.
- Estremamente veloce, capace di mettere all'opera un coding agent entro 100ms.
- Dotata di Logging / Metric / Tracing del comportamento dell'Agent facili da comprendere per le persone, rendendo più semplice capire e regolare i pattern comportamentali dell'Agent.
- Gli sviluppatori non devono più preoccuparsi di dettagli come macchine virtuali, container e altri dettagli operativi, rendendo molto semplice l'orchestrazione su larga scala.
Penso che tutta l'infrastruttura in grado di soddisfare queste capacità sia già pronta: per esempio firecracker ha validato le prestazioni e la stabilità delle microVM, e ci sono anche molte scelte di piattaforme di osservabilità distribuita e di sistemi di file storage. Ma come sviluppatore che ha vissuto l'esperienza di usare e2b per incapsulare Claude Code, integrare tutto questo insieme è ancora molto difficile. Per esempio, quando Claude Code in E2B viene interrotto inaspettatamente da un OOM, è difficile per gli ingegneri monitorarlo, e ancora più difficile recuperare la scena e i log di quel momento.
Spero che gli sviluppatori dopo il 2026 non debbano più affrontare un processo così doloroso, proprio come la maggior parte degli ingegneri nel 2026 non ha più bisogno di usare ssh per inizializzare manualmente le macchine fisiche.
Questo è il sogno di VM0. Spero che un giorno potrò guidare un coding agent attraverso un'API ergonomica, come:
cosnt agent = vm0.run({
framework: 'claude-code',
prompt: 'buy me a coffee'
})
