Pi Coding Agent: costruire strumenti AI flessibili per flussi di lavoro reali

Introduzione

Il codice non è mai gratuito. Questa è la tesi centrale che Mario Zechner, creatore di Pi, sostiene discutendo lo stato dello sviluppo assistito dall’AI nel 2026. Sebbene gli agenti possano generare enormi quantità di codice rapidamente, le conseguenze di quel codice finiscono inevitabilmente per presentare il conto. Pi esiste perché Zechner ha riscontrato che gli agenti di programmazione esistenti non si adattavano ai suoi flussi di lavoro e, invece di adattarsi, ha costruito uno strumento che si adatta a lui.

Questa conversazione copre il motivo per cui la stabilità del flusso di lavoro conta più della velocità delle funzionalità, come lavorare effettivamente con gli agenti di programmazione senza andare in burnout e perché il settore potrebbe ripetere un errore vecchio di 30 anni con lo sviluppo basato su specifiche.

Perché esiste Pi: flessibilità del flusso di lavoro rispetto alla stabilità

Quando Claude Code è stato lanciato, Zechner ne era soddisfatto. Nel tempo, tuttavia, l’elevata frequenza di rilascio dello strumento è diventata un problema. Claude Code riceve da uno a tre aggiornamenti al giorno e con ogni rilascio arrivano modifiche alle definizioni degli strumenti, ai prompt di sistema e al comportamento sottostante. Per chi costruisce modelli di prompt personalizzati, comandi slash e descrizioni dei flussi di lavoro, questi cambiamenti invisibili rompono le cose.

Il modello stesso sembrava comportarsi in modo diverso di giorno in giorno, anche se la versione del modello rimaneva la stessa. Zechner attribuisce questo in parte ai cambiamenti nell‘“harness”, ovvero l’infrastruttura e i prompt di sistema che modellano il modo in cui un modello risponde. Testare gli effetti dei cambiamenti dell’harness sulla qualità dell’output è difficile perché non esiste un modo deterministico per misurarlo. Il risultato è che gli sviluppatori come Zechner non possono fare affidamento sul fatto che lo strumento si comporti in modo coerente, il che vanifica lo scopo di costruire flussi di lavoro personalizzati attorno ad esso.

Pi è nato da questa frustrazione. È un agente di programmazione minimale ed estensibile che può modificarsi per adattarsi ai tuoi flussi di lavoro invece di costringerti ad adattarti ai suoi vincoli. L’architettura sottostante astrae i provider LLM, include una libreria di interfaccia utente per terminale e fornisce astrazioni generali per il ciclo dell’agente. Ma la differenza fondamentale è il controllo: Zechner detta il design e può cambiarlo senza aspettare il ciclo di rilascio di un fornitore.

Come funziona realmente Pi: elaborazione parallela e revisione manuale

Il flusso di lavoro quotidiano di Zechner con Pi è metodico e deliberatamente low-tech. Non esegue un esercito di agenti in parallelo. Invece, usa un approccio “da cavernicolo”: mette in coda più sessioni, ognuna delle quali analizza un problema diverso dal tracker, quindi revisiona e itera su ciascuna di esse.

Per le correzioni di bug e l’implementazione di funzionalità, il processo inizia con una descrizione del problema. Zechner fornisce il problema a un agente con un modello di prompt personalizzato che dice: estrai tutte le informazioni rilevanti, ignora l’analisi nel problema ed esegui la tua analisi basandoti su ciò che vogliamo ottenere. Questa fase di analisi richiede circa cinque minuti per problema. Apre una seconda sessione per il problema successivo, una terza per un altro, creando una pipeline di pre-elaborazione parallela.

Una volta che l’agente finisce di analizzare un problema, Zechner revisiona i suggerimenti, controlla il codice personalmente e riproduce i problemi manualmente se necessario. Usa l’agente come una “paperella di gomma” (rubber duck), un partner di riflessione, finché non concorda con se stesso sull’approccio di implementazione. Quando dice all’agente di implementare, il contesto contiene così tanti guardrail che l’agente sa esattamente quali interfacce modificare, quali moduli toccare e come dovrebbero funzionare i test.

L’implementazione richiede altri 10-30 minuti. Quando l’agente segnala il completamento, Zechner apre un visualizzatore di diff e annota le singole righe con feedback. Clicca su fine, il feedback viene reinserito automaticamente nell’agente e l’iterazione continua finché il codice non è buono. Per le meccaniche principali, revisiona ogni modifica come farebbe con un essere umano. Per altre parti, approva senza un’ispezione approfondita.

Questo flusso di lavoro funziona perché Zechner ha oltre 10 anni di esperienza nelle basi di codice. Sa cosa funziona e cosa no. Per i nuovi sviluppatori o per coloro che non hanno tale esperienza, l’approccio sarebbe diverso e più rischioso.

La realtà dello sviluppo basato su specifiche

Il settore sta ripetendo un errore vecchio di 30 anni. Lo sviluppo a cascata (waterfall) si è dimostrato inefficace decenni fa, eppure con gli agenti AI siamo tornati all’iper-waterfall: scrivere specifiche dettagliate e farle implementare agli agenti. L’unica differenza è che ora non scrivi nemmeno la specifica da solo: usi il “vibe prompting” per far scrivere a un agente una specifica molto dettagliata, che poi un altro agente implementa.

Il problema è fondamentale. Una specifica completa è essenzialmente il programma stesso. Se scrivi una specifica in prosa in linguaggio naturale, lasci delle lacune. L’agente riempie quelle lacune con qualsiasi pattern abbia appreso da 20 anni di codice su Internet, gran parte del quale è spazzatura. Il risultato è una base di codice che sembra software scritto a sensazione, perché lo è.

C’è un controargomento: il codice ora costa poco e l’iterazione è veloce. In precedenza, una specifica waterfall poteva richiedere mesi per essere implementata. Ora potrebbe richiedere un giorno. Puoi testare il percorso manualmente. Ma Zechner non ha ancora visto prove che questo funzioni effettivamente per il software di produzione. Sospetta che, alla fine, gli sviluppatori si sveglieranno di notte rendendosi conto che tutto è rotto.

Detto questo, ci sono vincoli in cui lo sviluppo guidato dagli agenti ha senso. La riscrittura di Bun da Zig a Rust ha funzionato perché il progetto aveva una suite di test estesa. L’agente poteva verificare il proprio lavoro in una certa misura. In quei casi, strumenti come questo sono genuinamente utili. Ma per la maggior parte del software, l’approccio è rischioso.

Gestire l’open source su larga scala: il problema dei Clanker

Prima degli agenti, un progetto open source di successo poteva ricevere una o due pull request a settimana. Pi ora riceve da 50 a 60 pull request al giorno, tutte provenienti da agenti (Zechner li chiama “clanker”). Ogni PR ha una descrizione lunga come un libro di Harry Potter e include da 10 a 1.000 modifiche ai file.

La posizione predefinita è dichiarare ogni PR generata dall’agente come spazzatura e chiuderla automaticamente. Ma Zechner ha trovato una soluzione: richiedere alle persone di scrivere prima un problema con la propria voce, non più lungo di una schermata, spiegando esattamente cosa vogliono fare e perché. Se il problema è valido, lo approva e la persona può inviare una PR. Questo dimostra che sono umani, che comprendono il problema e che comprendono la soluzione.

Una volta approvate, arrivano PR significative. Le PR dei clanker smettono di apparire. I problemi continuano ad arrivare, ma Zechner li tria manualmente. Legge da 30 a 60 problemi chiusi al giorno, identificando quali sono legittimi e quali sono spazzatura. Nel suo ultimo triage, sono arrivati 50 problemi e ne sono sopravvissuti 2. Richiede circa 30 minuti perché la maggior parte è facile da identificare come rumore.

Per progetti della scala di OpenClaw, questo approccio manuale non funziona. Il consumo di token di Peter Steinberger ha raggiunto 1,3 milioni di dollari al mese, in parte perché automatizzare il filtraggio di problemi e PR su quella scala richiede un’infrastruttura sofisticata. Zechner ha scritto alcuni strumenti di visualizzazione per aiutare a raggruppare problemi simili, ma anche questo non è bastato. Il volume è di ordini di grandezza superiore.

Inferenza locale e il futuro dei modelli più piccoli

Zechner è ottimista riguardo all’esecuzione di modelli AI capaci localmente su hardware consumer. Per il suo progetto di robot, un giocattolo con uno smartphone come microcontrollore che esegue un agente di programmazione, utilizza Gemma 4 e Qwen 3.6, modelli mixture-of-experts più piccoli. Sono più che adeguati per un chatbot con controllo del motore e della fotocamera, e sono veloci.

La configurazione è conveniente. Il riconoscimento vocale con Parakeet richiede circa 10 gigabyte di memoria unificata. La sintesi vocale con Qwen TTS ne richiede altri 10 gigabyte. Qwen 3.6 ne richiede 4 gigabyte. Totale: 14 gigabyte di memoria unificata su macOS o una configurazione NVIDIA equivalente su Windows. È accessibile per molte persone, non per tutto il mondo, ma per una parte significativa.

Denise Asaves di DeepMind ha suggerito che gli attuali modelli giganti non hanno bisogno di tutti i loro parametri e possono essere distillati in modelli molto più piccoli senza perdere molta qualità dell’output. La speranza di Zechner è che il futuro preveda la distillazione di modelli grandi in modelli più piccoli che mantengano la maggior parte delle capacità, piuttosto che l’addestramento di modelli specializzati per compiti specifici. Antirez di Redis ha iniziato a lavorare su un motore di inferenza personalizzato per DeepSeek V4 chiamato ds4, eseguendolo su un laptop da 128 gigabyte. È un modello davvero capace che potrebbe gestire dal 60 al 70 percento dei problemi che Zechner gestisce con Pi.

Il costo del codice e la disciplina dell’artigianato

Zechner ha visto persone generare 500.000 righe di codice tramite agenti in una settimana. Il risultato è sempre lo stesso: disastro. Il codice non è mai gratuito perché le conseguenze alla fine ti colpiscono. Se pensi che qualsiasi quantità di codice vada bene ora, hai solo ritardato la punizione.

Il vero collo di bottiglia nello sviluppo del software non è la velocità di digitazione o la generazione di codice. È pensare, progettare ed esplorare lo spazio delle soluzioni. Gli agenti sono genuinamente utili per quella fase: puoi dire a più agenti di esplorare approcci diversi e vedere i risultati più velocemente. Ma l’output di quelle esplorazioni non è automaticamente riutilizzabile. Devi ancora comprenderlo, rifattorizzarlo e mantenerlo.

Per Zechner, il maggiore aumento di produttività derivante dagli agenti deriva dalla natura asincrona del lavoro. Può dare un compito a un agente, andare a una riunione e tornare ai risultati. Ma non crede che eseguire 10 agenti in parallelo aumenterà di 10 volte il suo output. Il solo cambio di contesto è estenuante. L’ha fatto una o due volte al mese, elaborando 30 problemi in un giorno, e il suo cervello era in pappa dopo.

L’aspetto collaborativo è ciò che apprezza di più. Avere un agente come partner di pair programming, fare domande, proporre opzioni, spiegare il codice, è come una bicicletta per la mente. Lo aiuta a riflettere sui problemi meglio che stare seduto da solo. Ma ciò richiede disciplina: non delegare tutto alla macchina, perché ogni volta che lo fa, finisce in un angolo a piangere perché niente va più bene e tutto va a pezzi.

Rifattorizzare Pi: costruire per il futuro

Pi ha accumulato un bagaglio storico. Parti di esso precedono l’uso degli agenti da parte di Zechner e sono solide. Altre parti, come l’esportazione HTML, non le ha mai guardate e non gli interessano finché funzionano. Alcuni pezzi sono scritti a sensazione.

Lo sforzo di rifattorizzazione ha diversi obiettivi. Primo, espandersi più facilmente in altri tipi di interfacce utente (web, native, qualsiasi cosa) senza rompere le estensioni esistenti. Secondo, abilitare la capacità remota: eseguire una sessione di Pi su una macchina e connettersi da un’altra, con adeguata durabilità e osservabilità. Terzo, rendere l’SDK di Pi distribuibile su Cloudflare Workers, Vercel e altri ambienti, non solo su computer locali con bash.

Zechner sta rifattorizzando sul branch principale perché non gli interessa la stabilità nel senso tradizionale. Lo sta facendo pezzo per pezzo, partendo dai pacchetti di livello più basso che comunicano con i provider LLM. L’agente di programmazione stesso continuerà ad apparire e funzionare allo stesso modo, ma tutta l’infrastruttura sottostante sarà pulita e riutilizzabile. Spera di finire quella fase in una o due settimane, poi passare qualche altra settimana sul nuovo meccanismo di estensione in cui le estensioni hanno componenti lato server e lato UI.

Perché Pi viene eseguito in modalità YOLO per impostazione predefinita

Pi non chiede il permesso prima di eseguire il codice. Questo è intenzionale. Dicendo alle persone che la modalità YOLO è pericolosa e che dovrebbero pensarci, Zechner spinge effettivamente le persone a pensare alla sicurezza. Vuole che guardino dentro se stessi per la consapevolezza della sicurezza e decidano come salvaguardare il lavoro agentico nel proprio ambiente.

La risposta è solitamente la containerizzazione. Se non vuoi che l’agente rompa il tuo computer, containerizza l’agente o gli strumenti che usa (lettura/scrittura file, bash, qualsiasi cosa). Questo risolve il problema. Ma Zechner non può decidere questo per te. Potrebbe includere la sandbox di Anthropic o bubble wrap, ma queste sono soluzioni incomplete. In un ambiente aziendale con vincoli infrastrutturali specifici, una sandbox integrata potrebbe non funzionare affatto.

Ciò che esiste in Claude Code è principalmente teatro della sicurezza. Claude Code ora chiede a un LLM se un comando bash è sicuro prima di eseguirlo in modalità automatica. Zechner non pensa che sia un bene. Un LLM non può determinare in modo affidabile se un comando è sicuro: può solo indovinare in base ai pattern.

Conclusione

Pi rappresenta una filosofia diversa: costruire strumenti che gli sviluppatori possono possedere e modificare, non strumenti che possiedono gli sviluppatori. Il successo di Pi non si misura in funzionalità o benchmark, ma nel fatto che Zechner possa mantenere in vita un piccolo team e continuare a esplorare le applicazioni del lavoro agentico, dalla programmazione alla robotica all’inferenza locale.

La lezione più ampia è che i flussi di lavoro contano più dell’hype. La stabilità, la prevedibilità e la capacità di personalizzare i propri strumenti valgono più dell’ultima funzionalità. E il codice non è mai gratuito: le conseguenze delle tue azioni finiranno per presentare il conto.