Pi Durable: quando l'agente AI non muore più col crash. Mario Zechner & Armin Ronacher

Mario Zechner (badlogic, creatore di Pi) e Armin Ronacher (creatore di Flask, ora in Earendil)

L'incidente che ha acceso la scintilla

La conversazione si apre con una confessione di Mario Zechner: mentre costruiva Pi, il suo agente ha provato a condividere un file con un altro dei suoi dispositivi — e per circa un giorno l'intero filesystem è finito esposto su internet pubblico. Non è un'anomalia: è il prezzo che si paga quando agenti autonomi girano per giorni o mesi su macchine reali. È da qui che nasce la domanda centrale dell'episodio: come si costruisce un agente che sopravvive ai crash?

La risposta di Zechner e Ronacher è Pi Durable, un package sperimentale appena rilasciato insieme a Pi 1.0 (1 ottobre 2026) dalla startup Earendil. Ma la puntata è molto più di una tech demo: è una conversazione densa su cosa gli LLM sanno fare oggi, su cosa ancora no, e su dove sta andando lo sviluppo software assistito dall'AI.

Cos'è la "durabilità" (in cinque frasi)

Zechner riassume il concetto in modo netto:

"L'agente si avvia in un processo, l'agente chiama degli strumenti, il processo muore. Quello che vuoi è: riavviare il processo, e l'agente continua esattamente da dove si era fermato."

Senza che l'umano debba digitare "continua", senza perdere i risultati degli tool call o gli stream dell'assistente, e con lo stato dell'applicazione persistito e ripristinato in modo affidabile.

Perché serve? Per gli agenti long-running: anything che gira per giorni o anni — un bot Slack che vive in un workspace per un'eternità, un agente che gestisce la posta, un workflow CI che non si spegne mai. Pi Durable risolve anche un secondo problema strutturale: storicamente Pi caricava l'intera conversazione (o l'intero albero di sessione) in memoria, un approccio che non scala quando la storia cresce all'infinito.

Dettaglio non banale: il tutto è deployabile ovunque — Vercel, Cloudflare Durable Objects, E2B, un laptop, o il telefono di Zechner stesso.

L'architettura: il "sandwich degli effetti"

Qui la puntata diventa tecnica davvero interessante. Quando il moderator chiede a Zechner di spiegare l'architettura citando l'event sourcing (lo schema classico: coda di eventi, ogni azione viene commessa prima di essere eseguita), la risposta è secca: no, non facciamo event sourcing. È quello che fanno tutti gli altri, e presenta molti problemi.

Invece, Pi Durable modella ogni operazione come un "effect sandwich" — un sandwich di tre strati:

1. Intento (prima): prima di eseguire qualsiasi cosa, salvi in storage: "Sto per eseguire questa operazione con questi input". Se crashi qui, al riavvio il sistema sa che l'input era già validato e pronto.
2. Esecuzione (durante): qui casca l'asino. Se l'effetto coinvolge un sistema esterno (es. avviare una GitHub Action) e il processo muore mentre parla con GitHub, non sai se è partito o no. La soluzione è l'idempotenza: prima di lanciare, ottieni un ID, salvalo, poi esegui con quell'ID. Se il sistema esterno ti risponde "è già in corso", aspetti; se no, lo avvii. Zechner definisce l'idempotenza "la parola preferita di Armin" — con un vaffanculo di circostanza da parte di Ronacher.
3. Risultato (dopo): l'effetto finisce, salvi il riscontro, e di quel sandwich non devi più pensare a nulla.

"Un task può spawnare un altro task e aspettare che finisca. E questa è tutta la magia. Non c'è nient'altro."

Tutto ciò che accade nell'harness è quindi un task che è un effect sandwich — la chiamata LLM (prepara context window e parametri → chiama il modello → persisti la risposta), un singolo tool call, e così via, annidati.

Lo stato applicativo: un document store con time-travel

Il secondo pilastro è uno store di documenti (pensato come una mini-MongoDB per oggetti JSON) con una twist specifica per l'uso agentic. Immagina una to-do list su cui lavori con l'agent: il documento si aggiorna via via che la sessione avanza. Ora, se torni indietro nel transcript, quale versione del documento vuoi?

• La versione come era a quel punto nel tempo (la vecchia to-do list di metà conversazione)
• Oppure l'ultima versione, indipendentemente da dove ti trovi nel transcript

Pi Durable permette di associare entrambi i tipi a qualsiasi posizione del transcript. Esempio concreto di Zechner: un canvas di disegno — l'agent può rileggere i tratti, la conversazione evolve insieme al disegno, e se torni indietro nel transcript ottieni proprio quella versione del disegno.

Per serializzare le modifiche hanno valutato JSON Patch (RFC), l'hanno trovato carente per questo caso d'uso, e hanno inventato un formato proprietario ottimizzato per l'agentic. L'interfaccia usa JavaScript Proxy: al programmatore sembra un normale oggetto, dietro registra ogni mutazione come operazione da riverificare. È, ammette Zechner, "un hack, un hack lento" — ma funziona bene per il loro caso. (Ronacher osserva con un po' di amarezza che dopo vent'anni di web development il problema degli update strutturali su dati immutabili non è mai davvero stato risolto in modo standard: c'è Immer, c'è Automerge, ma nulla di universalmente adottato.)

Tutto il package è ~12.000 righe di codice: piccolo abbastanza da essere comprensibile, potente abbastanza da fare out-of-the-box tutto ciò che serve a un agent, compresa la compaction.

Cosa gli LLM sanno fare (e cosa no)

La conversazione poi si allarga, ed è qui che l'episodio diventa particolarmente prezioso. Zechner e Ronacher condividono mesi di uso intensivo:

Dove sono impressionanti: quando c'è un Oracle

La regola empirica di Ronacher: quando il task è binario — è fatto o non è fatto — alla fine ce la fanno. Esempi dal vissuto:

• Ronacher ha fatto costruire a DeepSeek un emulatore Nintendo DS da zero partendo da ROM di test. Ha guardato Dolphin e altri, ma ha dovuto scriverlo in modo completamente diverso. Funziona.
• Ha preso una libreria di serializzazione e ha ordinato all'agent di implementare tutti i formati (TOML, CBOR, MessagePack, JSON) e poi di fuzzare il tutto. Ne sono emersi molti bug: "con un LLM sopra, il fuzzing è rocket fuel per tutto il testing."
• Il caso più estremo, raccontato da Zechner: un suo software desktop di sicurezza è stato crackato da uno sviluppatore cinese con due account Codex. Ha usato un reverse-clanker per riprodurre l'attacco e capire come erano passate le difese. Il modello ha reverseato le strutture native del JVM, letto la memoria del processo, mappato la rappresentazione nativa su quella Java. "È stato come fantascienza. Nessun reverse engineer umano sarebbe arrivato così lontano, e certo non in quel l'arco di tempo."
• Anche Ronacher ha avuto un'esperienza simile con un adattatore USB CarPlay cinese: il modello ha decifrato da solo la protezione sull'upload del root image e trovato un CGI file sulla web interface per bypassare i controlli. "Non ho fatto nulla. L'ho solo collegato."

La lezione operativa, condivisa anche da chi gestisce Bun (Jared): se hai un suite di test grossa che funge da oracolo, puoi dare il via libera a un team di agenti e dire "fai girare la suite, io ti guadio ai punti critici". L'architettura di Bun ne è un esempio.

Dove faticano: l'architettura

E qui la provocazione di fondo. Il moderator chiede se i nuovi modelli siano migliorati in architettura software. Risposta di Zechner, in due parole: "Nah, they're not". Anzi, sono forse peggiori — ma non perché siano più stupidi:

"Sono peggiori nel risultato perché gli dai molto più controllo. Con ogni release ci provo a costruire qualcosa, e mi sento progressivamente meno soddisfatto di quello che fanno da soli. Perché mi fido sempre di più."

Il modello di analisi di Ronacher è affascinante: i modelli sanno discutere di architettura ed è difficile trovare una risposta davvero sbagliata. Ma la traiettoria più probabile per risolvere un problema vive altrove nei pesi. Perché? La spiegazione è tutta nel training data:

"Posso creare training data per security, per costruire qualcosa che esiste già e ha un oracolo, per siti web, per front-end, per quello che vuoi. Ma non ho training data per il processo di design e architettura di qualcosa di nuovo. Quella è l'unica parte della programmazione che di solito non viene codificata in forma testuale — ed è per questo che siamo bloccati qui."

Si scherza sul fatto che le startup fallite vendranno le registrazioni delle loro riunioni di architettura ai lab (un imprenditore robotics che Zechner ha incontrato in Germania fa già business vendendo training data fisico ai laboratori). Ma il problema di fondo resta: anche se i trace delle conversazioni venissero pesati di più, manca un segnale — come fa il training a sapere quale di dieci iterazioni di design sia poi quella che ha funzionato? È un problema di classificazione, e un modello potrebbe farlo, ma le conversazioni ad alto valore sono poche e difficili da etichettare a scale umana.

La comunicazione che impazzisce

Zechner si lamenta di un effetto collaterale bizzarro: i modelli parlano sempre in modo più contorto, con "ogni parola un nuovo lemma del thesaurus". Ha abbandonato un'intera release di Opus per questo, ed è passato di nuovo a un modello diverso. Fortunatamente, le release più recenti (Sol 6.1, Opus 5.5) hanno "ton down" e sono tornati a macchine che parlano come persone normali.

Un aneddoto tech su un modello che impressiona di più in un dominio specifico: l'ultimo Opus fa breakthrough quotidiani nel navigate l'interfaccia hardware-software nei task di inferenza. Ma, osserva Zechner, "non puoi costruire app con quello" — è hill climbing, non sviluppo di prodotto.

Earendil: non una company di coding agent

La seconda metà della puntata è dedicata alla visione. Earendil, la startup fondata per portare avanti Pi, si sta organizzando su due binari:

1. Prodotti — pensati per essere usati anche da non-ingegneri. Ma esplicitamente non coding agent: "Non vogliamo essere una company di coding agent l'anno prossimo." C'è stato già un'esperienza precedente: Lefos, un personale agent dietro un'interfaccia di testo pura (email). Il concetto — un'entità che sta con te e ti aiuta senza imporsi a terzi — piace a entrambi, ma lo spazio si sta riempiendo di "massive crazy contraption", e Ronacher è chiaramente preoccupato: "Hai già un sacco di gente che cerca di hackerarti, e poi hai milioni di utenti che loggano tutto nella loro macchina. È una catastrofe." (Citato un thread recente: un GrokBot avrebbe pubblicato le finanze personali dell'utente su Slack aziendale.)
2. Infrastruttura — primitive che altri possano usare per costruire i propri agenti. Pi Durable è esattamente questo: non un prodotto finito da mettere in mano a tutti, ma un substrato. "Non ti serve Pi Durable. Potresti totally costruirlo da solo. Ma abbiamo avuto più progetti in cui abbiamo dovuto rifare da capo questa roba, e il core design che faccia davvero funzionare la cosa — non le righe di codice, il design — è un sacco di lavoro."

Sullo sfondo, una curiosità: durante la puntata si parla anche di Jeff, il modello-classificatore di Anthropic. Ronacher lo ama: "Un classificatore generico one-shot, addestrato bene, ha trovato il product-market fit." È utile per filtrare volumi enormi di contenuto (email, conversazioni) prima di passarli a un modello più lento e costoso. Ironia della sorte: il supporto MCP in Pi è arrivato proprio perché Zechner aveva bisogno di code mode per Jeff — da lì a MCP erano cinque minuti.

La scelta di Pi: minimalismo come strategia

Un tema ricorrente è il rapporto con gli altri harness. Zechner e Ronacher studiano poco la concorrenza per principio ("è una distrazione enorme, e non sai se lo hanno fatto perché risolve un problema o perché 'il codice è gratis'"). Eccezioni: AMP (rispetto profondo per il team e per gli Orbs), DeepSeek harness (architettura di plugin da tenere d'occhio, interfaccia desktop "il Pi dei desktop app"), e sì — OpenCode, citato come esistente dal 2025: "Non lo guardo più di tanto. Ho visto il B2, molto interessante. Anche loro si stanno battendo con la durabilità, il che è divertente da vedere."

Sul perché Pi abbia appeal: open source, e "comprehensible" — un harness dove capisci cosa succede, non un concentrato di bug e session che si mixano tra loro (accusa rivolta in modo più sfumato a Claude Code, pur riconoscendone il miglioramento).

Il futuro: molti clanker, molti umani, molte macchine

Il racconto di Zechner sulla direzione futura di Pi è forse la parte più visionaria. Parte dall'esperienza personale con PIM (Pi mobile): un agente che gira quasi interamente sul telefono (tranne il LLM), che può connettersi alle altre macchine — Hetzner, laptop, telefoni — come ambiente di esecuzione. Ha sostituito Claude for Android nella sua vita quotidiana.

"Pi è una proof of concept per software agentic self-modifiable. Ha funzionato. E ora dobbiamo alzarci e evolverci in una forma dove non sia io e il clanker, ma molti clanker su molte macchine che parlano a molti umani. Deve essere possibile saltare da una parte all'altra e riconnettere agenti e umani in qualsiasi configurazione io voglia."

Il passo successivo: un plugin system (ispirato, almeno concettualmente, a DeepSeek), e la sfida della multiplayer — non esistono buoni harness multiplayer. Ronacher confessa di cercare di onboardare sua moglie su Hermes per coordinarsi meglio. Zechner ha fatto addirittura scrivere a suo figlio di quattro anni un videogioco per la moglie per il compleanno.

Ma il vero problema, ripetuto con enfasi da Zechner, è l'onboarding:

"Tutti ti danno una chat box e una sidebar, e poi 'Buona fortuna, fai da te. Sei una segretaria, sii più efficiente con l'AI.' F** you. È solo stupido. Nessuno ci ha messo impegno nel prendere qualcuno e trasformarlo in un utente capace."*

Il gap cognitivo, secondo lui, è semplice: chi non sa, non sa che può chiedere — e non ha le competenze per fare quel salto logico. È esattamente la lezione che si impara imparando a programmare: non sprecare un'ora a tentare da solo, poi chiedi.

Il verdetto della community

I commenti sotto il video confermano un sentimento trasversale: rispetto per la coppia Zechner-Ronacher e per Pi come progetto. "Ogni secondo che questi due parlano è puro valore", scrive un utente. Un altro riporta di aver smesso di "ponytail" (termine slang per il codice minimalista ossessivo) il proprio codice dopo averlo fatto passare da un LLM: è raddoppiato di dimensioni, ma è migliore e più veloce. C'è chi annuncia di abbandonare Pi per un proprio harness personalizzato — segno che l'ecosistema è vivo.

Un commento ironico ricorda che la description del video ha invertito i ruoli (Ronacher creatore di Flask, Zechner creatore di Pi), e qualcuno approfitta per fare una battuta su DHH, citato nella puntata per il suo "pensa due volte, i modelli mangeranno anche l'architettura" — che Ronacher smonta argomentando che DHH "ultimamente non capisce cosa fa il machine learning".

In sintesi

Pi Durable non è una risposta definitiva al problema degli agenti long-running, ma è un primitivo pulito e piccolo che affronta il problema per quello che è: crash come evento ordinario, non come eccezione. L'effect sandwich, l'idempotenza come contratto con i sistemi esterni, e il document store con time-travel sono idee eleganti che potrebbero filtrare in molti altri harness (OpenCode incluso — come notato con malizia da Zechner).

Sotto la superficie tecnica, però, la puntata regala qualcosa di più raro: una fotografia onesta di dove siamo. Gli LLM possono crackare JVM, emulare console, fuzzare librerie — ma non possono ancora progettare. E l'unica persona che può fare il salto da "non lo so" a "chiedo all'agente" è ancora un umano con un po' di curiosità e un po' di tempo da perdere.