Recensione di Pi Coding Agent: una CLI di coding AI minimale e personalizzabile

Pi Coding Agent è un’interfaccia di coding terminale minimale e open-source che include quattro strumenti predefiniti e lascia la maggior parte del comportamento a estensioni, abilità e al tuo stesso flusso di lavoro.

La maggior parte degli agenti di coding basati su IA sta diventando un prodotto sempre più complesso. Aggiungono modalità di pianificazione, sotto-agenti, livelli di autorizzazione, integrazioni con IDE, worker in background e un’orchestrazione sempre più elaborata attorno al modello. Pi采取 un approccio quasi opposto: l’agente predefinito parte con quattro strumenti di base — read, write, edit e bash — mentre la maggior parte del comportamento interessante è deliberatamente lasciata a estensioni, abilità, pacchetti e al tuo stesso flusso di lavoro.

Questa recensione è allineata con Pi v0.84.2, rilasciata il 14 agosto 2026. Il progetto è stato creato da Mario Zechner; si è trasferito presso Earendil Works nel maggio 2026, motivo per cui i pacchetti attuali utilizzano lo scope @earendil-works anziché i nomi precedenti @mariozechner. Pi sta cambiando rapidamente, quindi le API di configurazione ed estensione meritano un controllo della versione prima di standardizzarle all’interno di un team.

La riserva è altrettanto importante: Pi ti offre un controllo considerevolmente maggiore rispetto a molti agenti di coding e, di conseguenza, una maggiore responsabilità. Non fornisce un sandbox di sicurezza integrato o il tipo di sistema di permessi che gli sviluppatori potrebbero aspettarsi dopo aver usato Claude Code o strumenti simili. Di seguito copro la guida rapida, l’architettura, il supporto dei modelli, le estensioni, il modello di sessione, le implicazioni di sicurezza e dove credo che Pi si collochi tra gli strumenti di coding IA moderni.

Cos’è Pi Coding Agent?

Pi è meglio capito come un’interfaccia (harness) per agenti piuttosto che come un ambiente di coding finito e con opinioni precise. Questa distinzione è importante: un modello di coding risponde ai prompt, mentre un’interfaccia per agenti decide quale contesto quel modello vede, quali strumenti può chiamare, come i risultati degli strumenti vengono restituiti, come le sessioni persistono e cosa succede tra un turno e l’altro. Pi rende accessibili quasi tutti questi livelli, ed è per questo che si colloca all’estremità della costruzione di kit nel campo degli strumenti per sviluppatori IA piuttosto che tra i prodotti di coding con tutto incluso.

Il motivo più forte per usare Pi non è che abbia più funzionalità degli agenti di coding concorrenti — non le ha. Il motivo è che Pi espone di più l’agente stesso. Questo lo rende particolarmente attraente per sviluppatori senior, ingegneri di piattaforma, team di strumenti IA e chiunque abbia raggiunto il punto in cui i limiti del proprio agente di coding sono causati dall’interfaccia (harness) piuttosto che dal modello sottostante. Pi è meno convincente per chi vuole installare un agente, approvare alcuni predefiniti sicuri e non pensare mai più alla sua architettura: il suo minimalismo è produttivo solo se valorizzi il controllo che quel minimalismo crea.

Cosa ti dà realmente Pi

Il set di strumenti predefinito rivolto al modello è deliberatamente piccolo:

read
write
edit
bash

Sono disponibili strumenti di sola lettura aggiuntivi, tra cui grep, find e ls, e le recenti versioni di Pi consentono di configurare la selezione iniziale degli strumenti integrati.

Il predefinito sembra spoglio, ed è proprio questo il punto. Ogni strumento aggiuntivo aumenta il numero di decisioni che il modello deve prendere, espande il prompt di sistema e crea un’altra superficie comportamentale che potrebbe richiedere debug. Pi parte invece da un set primitivo capace e ti permette di aggiungere strumenti specializzati quando il tuo flusso di lavoro ne ha effettivamente bisogno.

La filosofia va oltre gli strumenti. Pi non rende deliberatamente i sotto-agenti integrati o una modalità di pianificazione obbligatoria centrali nel prodotto; quei comportamenti possono essere implementati attraverso estensioni o pacchetti installati. Questo rende Pi meno comodo fuori dalla scatola, ma dà agli sviluppatori più controllo su come quei meccanismi sono implementati. Se sei abituato ai sotto-agenti integrati di Claude Code, la guida ai sotto-agenti di Claude Code è un riferimento utile per ciò che staresti reimplementando. Trovo quell’approccio leggermente rinfrescante: Pi non finge che ci sia un unico modo corretto per operare un agente di coding IA.

Come installare Pi Coding Agent e avviare una sessione

Installa il pacchetto corrente dallo scope @earendil-works. I tutorial più vecchi potrebbero ancora mostrare i pacchetti @mariozechner di prima del trasferimento di maggio 2026; quei nomi sono obsoleti per le nuove installazioni.

Il nome collide anche con oh-my-pi, un fork della community dell’interfaccia Oh My Opencode. Quel progetto non ha nulla a che fare con questo agente di coding; la [recensione di Oh My Opencode](https://www.glukhov.org/it/ai-devtools/opencode/oh-my-opencode-experience/ “Esperienza pratica reale di Oh My Opencode oltre a benchmark della community. Scopri quando Ultrawork batte la versione vanilla di OpenCode, quando non lo fa e come evitare le sorprese in fatturazione che hanno colto di sorpresa gli utenti.”}) spiega il fork se sei atterrato sul Pi sbagliato.

Installazione e autenticazione

1. Installa Pi globalmente con npm:

   npm install -g --ignore-scripts @earendil-works/pi-coding-agent
   

   --ignore-scripts disabilita gli script di ciclo di vita delle dipendenze durante l’installazione. Pi non ha bisogno di quegli script per un’installazione npm normale e saltarli riduce un rischio comune nella catena di approvvigionamento.

2. Verifica l’installazione:

   pi --version
   

3. Entra in un progetto e avvialo:

   cd /path/to/project
   pi
   

Pi si aspetta un ambiente in grado di eseguire bash. Su Windows, usa WSL o Git Bash anziché cmd.exe.

Pi supporta l’autenticazione interattiva tramite abbonamento oltre a provider basati su chiave API. All’interno di Pi, il percorso più semplice è:

/login

Dopo l’autenticazione, seleziona un modello con:

/model

Puoi anche fornire le credenziali del provider attraverso variabili d’ambiente. Ad esempio:

export ANTHROPIC_API_KEY="your-api-key"
pi

Pi supporta attualmente un’ampia raccolta di provider di modelli, tra cui OpenAI, Anthropic, Google, Azure OpenAI, Amazon Bedrock, NVIDIA NIM, DeepSeek, Mistral, Groq, Cerebras, Cloudflare, xAI, OpenRouter e altri. È supportato anche un router llama.cpp per modelli serviti localmente: la [guida rapida llama.cpp](https://www.glukhov.org/it/llm-hosting/llama-cpp/ “Installa llama.cpp, esegui modelli GGUF con llama-cli e servi API compatibili con OpenAI usando llama-server. Flag principali, esempi e suggerimenti per la regolazione con un breve foglio di comandi.”}) copre il servizio di modelli GGUF con un’API compatibile con OpenAI, e la [guida all’hosting LLM](https://www.glukhov.org/it/llm-hosting/ “Guida completa all’hosting LLM nel 2026. Confronta Ollama, llama.cpp, vLLM, TGI, Docker Model Runner, LocalAI e provider cloud. Impara compromessi su costi, prestazioni e infrastruttura.”}) mappa i runtime locali, self-hosted e cloud circostanti se vuoi confrontare quel percorso con Ollama, vLLM o un provider ospitato. I provider personalizzati che parlano un’API supportata possono essere aggiunti attraverso ~/.pi/agent/models.json, e API personalizzate o flussi OAuth possono essere configurati con estensioni.

Questo design multi-provider è uno dei vantaggi pratici di Pi. Il modello e l’interfaccia di coding sono variabili separate: con Pi, puoi cambiare il modello mantenendo essenzialmente lo stesso ambiente di strumenti e sessione, il che rende i confronti tra modelli molto più significativi rispetto al confronto di prodotti di coding completamente diversi.

Inizia con una prima sessione controllata

Non fare del tuo primo prompt per Pi “rifattorizza la mia applicazione”. Inizia chiedendogli di ispezionare anziché modificare:

pi --tools read,grep,find,ls -p "Ispeziona questo repository. Spiegane l'architettura, identifica i punti di ingresso principali ed elenca i comandi che eseguiresti prima di apportare una modifica. Non modificare i file."

Quando ho eseguito quel prompt di sola lettura su un repository esistente, il risultato utile non è stato un saggio intelligente sull’architettura. È stato se il modello ha nominato i punti di ingresso reali e i comandi che avrei effettivamente eseguito prima di richiedere l’accesso in scrittura. Questo ti dà un’idea di come il modello selezionato naviga nel tuo albero senza conferirgli immediatamente un percorso di scrittura attraverso il set di strumenti normale.

Per il lavoro interattivo, creerei anche prima un ramo Git usa e getta:

git switch -c ai/pi-evaluation
pi

Pi può modificare file nella directory di lavoro e può eseguire comandi shell attraverso bash, quindi Git rimane uno dei livelli di rollback pratici più semplici quando lo si valuta. Se vuoi una sessione di test che non persista, pi --no-session funziona in modalità effimera.

Le istruzioni di progetto appartengono in AGENTS.md. Un file di partenza utile potrebbe essere simile a questo:

# Istruzioni del Progetto

- Leggi l'implementazione esistente prima di modificare i file.
- Mantieni le modifiche strettamente limitate al compito richiesto.
- Esegui `npm test` dopo le modifiche al codice.
- Esegui `npm run lint` prima di dichiarare il compito completato.
- Non modificare le migrazioni del database se non esplicitamente richiesto.
- Non accedere all'infrastruttura di produzione.
- Spiega qualsiasi comando distruttivo prima di eseguirlo.

Pi comprende anche CLAUDE.md durante la navigazione delle directory di progetto, e AGENTS.override.md può sovrascrivere le normali istruzioni di progetto per una directory.

Poi dagli un compito concreto:

Leggi il modulo di autenticazione e i suoi test.

Trova un problema di manutenibilità che possa essere risolto senza cambiare il comportamento pubblico. Spiega prima la modifica proposta, poi implementala ed esegui i test rilevanti.

Questa è una valutazione migliore dell’agente rispetto al chiedergli di generare una nuova applicazione giocattolo. Il codice esistente costringe l’agente a scoprire i vincoli, preservare il comportamento, scegliere i file rilevanti e verificare il suo lavoro.

Perché Pi Coding Agent è un’interfaccia modificabile

L’idea architetturale più importante di Pi è che l’agente di coding stesso dovrebbe rimanere modificabile. Il sistema di estensioni usa moduli TypeScript che possono registrare strumenti, sottoscriversi a eventi del ciclo di vita, intercettare chiamate agli strumenti, iniettare o trasformare il contesto, aggiungere comandi e modificare l’interfaccia terminale. Le estensioni locali al progetto possono anche essere ricaricate con /reload, il che rende la sperimentazione con l’interfaccia sorprendentemente immediata.

In forma semplificata, Pi sembra così:

Il diagramma è semplice perché Pi sta cercando di mantenere semplice il piano di controllo. Questo ti dà un’opzione insolita: quando l’agente manca di una capacità, non devi necessariamente aspettare che i manutentori di Pi la aggiungano — puoi aggiungere tu stesso il comportamento. Un’estensione può creare un nuovo strumento chiamabile dal modello, ispezionare una chiamata bash proposta e bloccare comandi che corrispondono alla tua politica, inserire informazioni dinamiche del progetto prima di un turno, alterare il comportamento di compattazione o esporre un comando personalizzato all’interno dell’interfaccia terminale. Questa è una superficie di estensione molto più profonda rispetto al cambiare un prompt di sistema.

L’integrazione MCP non è trattata come una parte obbligatoria e integrata del nucleo minimale di Pi. Può essere aggiunta attraverso lo stesso modello di estensibilità, il che è coerente con il design più ampio: le integrazioni specializzate vivono sopra il piccolo harness predefinito piuttosto che espanderlo permanentemente.

Lo stesso harness è anche riutilizzabile al di fuori del terminale interattivo. Pi include un SDK per incorporare la sessione dell’agente in applicazioni Node.js, e una modalità RPC (pi --mode rpc) che parla JSON su stdin/stdout per host non-Node, IDE e UI personalizzate.

L’idea dei quattro strumenti è più seria di quanto sembri

Inizialmente pensavo agli strumenti per agenti di coding in due gruppi. Il primo contiene primitivi: leggere un file, modificare un file ed eseguire un comando. Il secondo contiene comodità: ricerca nel repository, runner di test, tracker di issue, strumenti per browser, strumenti di deployment, helper per database, intelligenza del codice e pianificatori specializzati. Pi mantiene il livello primitivo piccolo e consente al livello di comodità di rimanere opzionale.

C’è un vantaggio architetturale in questo. Un team che lavora su infrastruttura Kubernetes può costruire un Pi molto diverso da un team che mantiene un monorepo TypeScript, senza che entrambi i team portino gli strumenti dell’altro nello stesso agente predefinito. È qui che Pi smette di sembrare un’alternativa a Claude Code ridotta e inizia a sembrare un framework per costruire il tuo stesso agente di coding.

Il prezzo è la manutenzione. Una volta che dipendi da estensioni personalizzate, il loro comportamento diventa parte della tua piattaforma di sviluppo: devi revisionarle, versionarle e occasionalmente aggiornarle man mano che Pi evolve. Questa è la tassa nascosta di Pi — ottieni la proprietà dell’agente, e la proprietà viene con la manutenzione.

Abilità e pacchetti mantengono la personalizzazione modulare

Non ogni comportamento personalizzato deve diventare un’estensione. Pi supporta abilità che impacchettano istruzioni, script e materiale di riferimento attorno a una capacità. Le abilità usano la divulgazione progressiva: Pi può pubblicizzare l’abilità disponibile al modello caricando le istruzioni complete solo quando la capacità è necessaria. Questo è utile per flussi di lavoro come revisioni di deployment, migrazioni del database, preparazione di rilasci o revisione del codice specifica del framework; invece di iniettare permanentemente pagine di istruzioni in ogni conversazione, l’agente può caricare guida specializzata su richiesta. Se già costruisci Claude Skills, la meccanica ti sembrerà familiare — vedi [Claude Skills e SKILL.md per sviluppatori](https://www.glukhov.org/it/ai-devtools/claude-code/claude-skills-for-developers/ “Costruisci Claude Skills affidabili con SKILL.md: compatibilità IDE tra VS Code, JetBrains e Cursor, layout della cartella, tuning dei trigger, script sicuri per agenti e test.”}) per il layout di SKILL.md e il tuning dei trigger.

Pi Packages va oltre raggruppando estensioni, abilità, template di prompt e temi. I pacchetti possono essere installati da npm o repository Git e possono essere agganciati a versioni specifiche:

pi install npm:@foo/pi-tools@1.2.3
pi list

Il modello di pacchetto è potente, ma tratta i pacchetti più come strumenti di sviluppo eseguibili che come collezioni di prompt inoffensive. Un’estensione Pi può eseguire codice con i permessi del processo Pi, e un’abilità può anche istruire il modello a eseguire codice, quindi installare un pacchetto sconosciuto merita essenzialmente lo stesso sospetto di installare una dipendenza di sviluppo sconosciuta.

Alberi di sessione in Pi Coding Agent

Molti assistenti di coding trattano una conversazione come un trascritto per lo più lineare. Pi memorizza le sessioni come un albero, il che significa che puoi tornare a un punto precedente, provare un altro approccio e mantenere entrambi i percorsi all’interno della sessione anziché distruggere una storia o creare un mucchio di chat non correlate.

I comandi principali sono straightforward:

/resume
/tree
/fork
/clone
/compact

/tree ti permette di navigare all’interno dell’albero di sessione corrente. /fork crea una nuova sessione da un messaggio utente precedente, mentre /clone duplica il ramo attualmente attivo in una sessione separata. Dalla riga di comando, pi -c continua la sessione più recente e pi -r sfoglia quelle passate.

La distinzione è diventata ovvia la prima volta che ho usato Pi per una sessione di debug anziché per un prompt greenfield. Ho lasciato che seguisse un’ipotesi sul layer di caching per un test di integrazione fallito, poi ho forciato dal messaggio in cui quella teoria era stata scelta e ho iniziato un secondo ramo sull’isolamento delle transazioni. L’indagine fallita è rimasta disponibile per contrasto invece di contaminare il nuovo percorso o costringere una chat fresca, il che è una rappresentazione utile di come funziona realmente il debug: spesso esistono più spiegazioni plausibili allo stesso tempo.

Pi persiste le sessioni come JSONL e può compattare automaticamente il contesto più vecchio man mano che le conversazioni si avvicinano ai limiti del modello; i rami possono anche essere riassunti quando ti sposti tra di essi. Classificherei questa funzionalità al di sopra di diverse funzionalità di agenti di coding più visibili: una buona gestione del contesto di solito conta più di un altro pulsante nell’interfaccia.

L’ingegneria del contesto è una capacità di primo livello

Pi rende anche possibile personalizzare ciò che raggiunge il modello. Le estensioni possono iniettare informazioni prima dei turni, alterare la storia e partecipare alla compattazione. Il sistema di compattazione predefinito riassume il materiale più vecchio mantenendo la conversazione recente, ma il meccanismo può essere sostituito o personalizzato.

Per i team avanzati, questo apre possibilità interessanti. Un grande monorepo potrebbe iniettare informazioni sulla proprietà solo per i file che l’agente sta attualmente toccando. Un progetto backend potrebbe far emergere metadati dello schema quando i file del database entrano nel contesto. Un agente di migrazione a lungo termine potrebbe mantenere uno stato strutturato al di fuori della conversazione invece di chiedere ripetutamente al modello di riscoprirlo. Questo è ciò che considero il vero punto di forza a lungo termine di Pi: la qualità degli agenti di coding è sempre più limitata dall’ingegneria del contesto, dal design degli strumenti e dall’orchestrazione piuttosto che dall’intelligenza grezza del modello, e Pi dà agli sviluppatori un accesso insolitamente diretto a quei livelli.

Sicurezza di Pi Coding Agent: nessun sandbox integrato

Il punto negativo più importante in questa recensione è semplice: Pi non fornisce un sandbox di sicurezza integrato. Di default, Pi esegue con i permessi dell’utente e del processo che lo ha avviato. I suoi strumenti possono leggere e modificare file accessibili ed eseguire comandi shell all’interno di quel contesto del sistema operativo.

Pi ha la fiducia del progetto, ma la fiducia del progetto non è un sandbox. La fiducia del progetto controlla se le impostazioni locali del progetto di Pi, estensioni, abilità, prompt e risorse simili vengono caricate. Una volta che stai lavorando in un progetto, non crea un confine di filesystem, rete, processo o credenziale attorno alle chiamate agli strumenti guidate dal modello. Apprezzo in realtà che la documentazione di Pi sia esplicita su questa distinzione: un pseudo-sandbox debole può essere più pericoloso di nessun sandbox perché gli utenti possono fidarsi di un confine che non esiste realmente. Pi si aspetta invece che l’isolamento significativo provenga da container, macchine virtuali, micro-VM o un altro runtime controllato da politica.

Per progetti personali usa e getta, potresti decidere che Git e i normali permessi del sistema operativo sono sufficienti. Per repository non fidati, agenti non sorvegliati, postazioni di lavoro contenenti credenziali di produzione o agenti che elaborano contenuto fornito esternamente, userei un isolamento più forte. La documentazione di Pi descrive tre pattern:

Il confine importante non è solo la directory di origine. Un agente che può eseguire comandi shell può potenzialmente interagire con la configurazione SSH, credenziali cloud, registri di pacchetti, servizi locali, stato del browser e qualsiasi altra cosa disponibile al processo. Una configurazione di qualità di produzione deve quindi pensare insieme a mount del filesystem, variabili d’ambiente, accesso alla rete e credenziali. Il mio pattern di valutazione preferito è:

Montare il repository reale in lettura/scrittura in un container consente comunque all’agente di modificare quel repository; i container aiutano solo nella misura in cui i loro mount, credenziali, capacità e accesso alla rete sono effettivamente vincolati. Gondolin ha una riserva correlata: gli strumenti delle estensioni personalizzate girano ancora sull’host a meno che non delegino anche loro nella VM.

C’è un’altra superficie di sicurezza da ricordare: estensioni e pacchetti. Un’estensione di terze parti è codice che gira all’interno dell’ambiente dell’agente. Revisionala prima dell’installazione, aggancia le dipendenze importanti ed evita di trattare una galleria di pacchetti pubblici come una revisione di sicurezza implicita.

Due controlli pratici prima di eseguire Pi su una macchina a cui tieni:

# Conferma la versione che hai effettivamente
pi --version

# Disabilita le operazioni di rete all'avvio (controlli di aggiornamento e telemetria di installazione)
export PI_OFFLINE=1
pi

PI_OFFLINE=1 disabilita tutte le operazioni di rete all’avvio, inclusi i controlli di aggiornamento, i controlli di aggiornamento dei pacchetti e la telemetria di installazione/aggiornamento. Se vuoi una suddivisione più fine, PI_SKIP_VERSION_CHECK=1 disabilita solo il controllo di versione, e PI_TELEMETRY=0 disabilita la telemetria di installazione/aggiornamento lasciando abilitati i controlli di aggiornamento.

Questo modello di sicurezza è il motivo principale per cui esiterei prima di dare Pi a un’organizzazione di ingegneria grande come predefinito non gestito. Pi fornisce i pezzi per costruire un ambiente forte, ma lascia deliberatamente molto di quell’ambiente a te.

Pi Coding Agent vs Claude Code e OpenCode

Pi ha più senso quando è confrontato per filosofia piuttosto che per numero di funzionalità. Tra gli agenti terminale, [OpenHands](https://www.glukhov.org/it/ai-devtools/openhands/ “OpenHands QuickStart per sviluppatori. Installa la CLI, configura la tua chiave API LLM, impara i flag principali della riga di comando e le modalità di sicurezza, ed esegui esempi pratici in flussi di lavoro interattivi e headless.”}) è il parente più vicino: gira anche dalla CLI, ma include sandboxing e un flusso di lavoro integrato più grande piuttosto che chiederti di assemblarne uno. [Claude Code](https://www.glukhov.org/it/ai-devtools/claude-code/ “Una guida pratica a Claude Code: installazione, comandi di avvio rapido, settings.json, permessi, prezzi ed esecuzione di backend completamente locali tramite Ollama o llama.cpp.”}) ha permessi, hook e sotto-agenti integrati sempre più sofisticati. [OpenCode](https://www.glukhov.org/it/ai-devtools/opencode/ “Una guida rapida pratica di OpenCode per sviluppatori: installazione e verifica, connessione di modelli/provider, esecuzione di flussi di lavoro CLI, uso del server + SDK JS e mantenimento di un breve foglio di comandi.”}) espone regole configurabili di allow, ask e deny oltre a concetti integrati di agente o sotto-agente. Pi parte più in basso nello stack.

Questo è il motivo per cui chiamare Pi un “clone di Claude Code” manca la parte interessante. Se sei contento del flusso di lavoro di Claude Code, Pi non lo migliora automaticamente: Claude Code ti dà più sicurezza e comportamento di orchestrazione dell’agente senza richiederti di assemblare quei pezzi da solo. Pi diventa interessante quando vuoi cambiare le assunzioni sottostanti al prodotto. Forse vuoi lo stesso harness tra Anthropic, OpenAI e modelli locali. Forse la tua organizzazione ha il suo sandbox. Forse hai bisogno di uno strumento che inietti metadati di architettura interna prima di ogni turno. Forse vuoi che la compattazione produca uno stato di ingegneria strutturato invece di un riassunto generico della conversazione. Questo è il territorio di Pi.

OpenCode è argomentabilmente più vicino filosoficamente perché offre anche una configurazione sostanziale. Anche lì, Pi sembra più un kit per costruire l’interfaccia stessa, mentre OpenCode espone più concetti di agente e permesso pronti all’uso.

Non c’è un vincitore universale qui. Per molti sviluppatori, i predefiniti con opinioni di Claude Code sono un vantaggio. Per altri, OpenCode può offrire un migliore compromesso. Pi è l’opzione che investigerei quando la frase “Vorrei che il mio agente di coding funzionasse diversamente” è diventata più importante di “Vorrei che il mio agente di coding avesse un’altra funzionalità”.

Dovresti usare Pi Coding Agent?

Pi Coding Agent è uno degli agenti di coding tecnicamente più interessanti perché si rifiuta di nascondere l’interfaccia. L’implementazione predefinita è deliberatamente piccola, ma l’API di estensione, le abilità, i pacchetti, il layer di provider, l’SDK, la modalità RPC e l’albero di sessione gli danno una superficie effettiva molto più grande di quanto suggeriscano i suoi quattro strumenti predefiniti.

Raccomanderei Pi più fortemente a sviluppatori esperti che amano costruire i propri strumenti. È particolarmente convincente per il lavoro di piattaforme IA, ricerca sperimentale di agenti di coding, flussi di lavoro di ingegneria specializzati e team che hanno già un’infrastruttura di esecuzione sicura. È anche utile per sviluppatori che vogliono confrontare modelli senza cambiare l’intero ambiente di coding ogni volta. Sarei più cauto per i principianti e per le organizzazioni che si aspettano controlli di politica di stile aziendale immediatamente dopo l’installazione.

Il sandbox mancante cambia come Pi dovrebbe essere distribuito, specialmente quando un agente è consentito di operare non sorvegliato o può incontrare istruzioni non fidate. Tratta Pi come un potente processo di sviluppo locale piuttosto che come un confine di sicurezza: per repository non fidati, operazione non sorvegliata o ambienti contenenti credenziali preziose, usa un sandbox basato su sistema operativo, container, VM o politica ed esponi solo le risorse richieste per il compito.

La mia valutazione complessiva è 8,4/10. Questa è una sentenza editoriale piuttosto che la media della tabella sopra, e potrebbe facilmente diventare più alta per l’utente giusto. La più grande debolezza e la più grande forza di Pi sono la stessa cosa: non finisce l’agente per te.

Dovresti passare da Claude Code? Non automaticamente. Usa Claude Code quando i suoi permessi integrati, sotto-agenti, hook e flusso di lavoro si adattano al modo in cui già lavori. Valuta Pi quando vuoi una proprietà più ampia dell’interfaccia, selezione del provider, costruzione del contesto e architettura degli strumenti. Per sviluppatori avanzati, non assumerei nemmeno che la scelta debba essere esclusiva: Claude Code può rimanere l’autista quotidiano rifinito mentre Pi diventa il laboratorio di agenti programmabili. Dopo abbastanza personalizzazione, quel laboratorio potrebbe trasformarsi nello strumento che preferisci realmente.

Licenza e costi

Pi stesso è open source e rilasciato sotto licenza MIT. Questo non rende gratuito l’inferenza del modello: il tuo costo effettivo dipende dal provider del modello, l’uso dell’API, l’autenticazione via abbonamento supportata, il calcolo locale e qualsiasi infrastruttura di sandbox che scegli di eseguire.

Riferimenti

• Repository di Pi Coding Agent: https://github.com/earendil-works/pi
• Sito web e installer di Pi: https://pi.dev
• Pacchetto npm: https://www.npmjs.com/package/@earendil-works/pi-coding-agent
• Micro-VM Gondolin: https://github.com/earendil-works/gondolin
• NVIDIA OpenShell: https://docs.nvidia.com/openshell/about/overview
• Licenza: MIT