Avis sur l’agent de codage Pi : un CLI de codage IA minimal et modifiable
Un petit agent de codage qui attend que vous le façonniez.
Pi Coding Agent est un harnais de codage en terminal minimaliste et open source, livré avec quatre outils par défaut et qui laisse la plupart des comportements aux extensions, aux compétences et à votre propre flux de travail.
La plupart des agents de codage IA deviennent de plus en plus de grands produits. Ils ajoutent des modes de planification, des sous-agents, des couches d’autorisation, des intégrations IDE, des workers en arrière-plan et une orchestration de plus en plus élaborée autour du modèle. Pi adopte presque l’approche opposée : l’agent par défaut démarre avec quatre outils de base — read, write, edit et bash — tandis que la plupart des comportements intéressants sont délibérément laissés aux extensions, aux compétences, aux paquets et à votre propre flux de travail.

Cette revue est alignée sur Pi v0.84.2, publiée le 14 août 2026. Mario Zechner a créé le projet ; il a été transféré à Earendil Works en mai 2026, ce qui explique pourquoi les paquets actuels utilisent le périmètre @earendil-works plutôt que les anciens noms @mariozechner. Pi évolue rapidement, il est donc judicieux de vérifier la version des API de configuration et d’extension avant de les standardiser au sein d’une équipe.
Le piège est tout aussi important : Pi vous donne considérablement plus de contrôle que beaucoup d’agents de codage, et par conséquent davantage de responsabilité. Il ne fournit pas de bac à sable de sécurité intégré ni le type de système d’autorisation que les développeurs peuvent attendre après avoir utilisé Claude Code ou des outils similaires. Ci-dessous, je couvre le démarrage rapide, l’architecture, la prise en charge des modèles, les extensions, le modèle de session, les implications en matière de sécurité et l’endroit où je pense que Pi se situe parmi les outils de codage IA modernes.
Qu’est-ce que Pi Coding Agent ?
Pi est le mieux compris en tant que harnais d’agent plutôt qu’un environnement de codage fini et opinionné. Cette distinction est importante : un modèle de codage répond aux invites, tandis qu’un harnais d’agent décide quel contexte ce modèle voit, quels outils il peut appeler, comment les résultats des outils lui sont renvoyés, comment les sessions persistent et ce qui se passe entre les tours. Pi rend presque toutes ces couches accessibles, c’est pourquoi il se situe à l’extrémité « construction de kit » du domaine des outils de développement IA plutôt que parmi les produits de codage tout-en-un.
| Domaine | Ma note | Pourquoi |
|---|---|---|
| Architecture | 9/10 | Noyau petit avec des points d’extension inhabituellement clairs |
| Flexibilité des modèles | 9/10 | Prise en charge large des fournisseurs et changement facile de modèle |
| Extensibilité | 10/10 | Les extensions TypeScript peuvent modifier les outils, les événements, le contexte et l’interface utilisateur |
| Gestion des sessions | 9/10 | Les sessions basées sur des arbres rendent l’expérimentation inhabituellement naturelle |
| Facilité d’utilisation initiale | 8/10 | Facile à démarrer, mais l’utilisation avancée suppose une confiance technique |
| Réglages de sécurité par défaut | 5/10 | Pas de bac à sable intégré ni de frontière d’autorisation complète |
| Gouvernance d’équipe | 6/10 | Possible à construire, mais beaucoup est intentionnellement non intégré |
La raison la plus forte d’utiliser Pi n’est pas qu’il a plus de fonctionnalités que les agents de codage concurrents — ce n’est pas le cas. La raison est que Pi expose davantage l’agent lui-même. Cela le rend particulièrement attrayant pour les développeurs seniors, les ingénieurs plateformes, les équipes d’outillage IA et toute personne qui a atteint le point où les limitations de son agent de codage sont causées par le harnais plutôt que par le modèle sous-jacent. Pi est moins convaincant pour quelqu’un qui veut installer un agent, approuver quelques réglages de sécurité par défaut et ne plus jamais réfléchir à son architecture : son minimalisme n’est productif que si vous valorisez le contrôle que ce minimalisme crée.
Ce que Pi vous donne réellement
Le jeu d’outils par défaut destiné au modèle est intentionnellement petit :
read
write
edit
bash
Des outils supplémentaires en lecture seule, y compris grep, find et ls, sont disponibles, et les versions récentes de Pi permettent de configurer la sélection initiale des outils intégrés.
L’aspect par défaut semble maigre, et c’est le but. Chaque outil supplémentaire augmente le nombre de décisions que le modèle doit prendre, élargit l’invite système et crée une autre surface comportementale qui peut nécessiter du débogage. Pi commence plutôt par un ensemble de primitives capable et vous laisse ajouter des outils spécialisés lorsque votre flux de travail en a réellement besoin.
La philosophie va au-delà des outils. Pi ne fait délibérément pas de sous-agents intégrés ou d’un mode de planification obligatoire le centre du produit ; ces comportements peuvent être implémentés via des extensions ou des paquets installés à la place. Cela rend Pi moins pratique hors de la boîte, mais donne aux développeurs plus de contrôle sur la façon dont ces mécanismes sont implémentés. Si vous êtes habitué aux sous-agents intégrés de Claude Code, le guide des sous-agents de Claude Code est une référence utile pour ce que vous seriez en train de réimplémenter. Je trouve cette approche légèrement rafraîchissante : Pi ne prétend pas qu’il existe une seule bonne façon de faire fonctionner un agent de codage IA.
Comment installer Pi Coding Agent et démarrer une session
Installez le paquet actuel depuis le périmètre @earendil-works. Les anciens tutoriels peuvent toujours afficher les paquets @mariozechner d’avant le déménagement de mai 2026 ; ces noms sont obsolètes pour les nouvelles installations.
Le nom entre également en collision avec oh-my-pi, une fourchette communautaire du harnais Oh My Opencode. Ce projet n’est pas lié à cet agent de codage ; la revue de Oh My Opencode explique la fourchette si vous êtes tombé sur le mauvais Pi.
Installation et authentification
-
Installez Pi globalement avec npm :
npm install -g --ignore-scripts @earendil-works/pi-coding-agent--ignore-scriptsdésactive les scripts de cycle de vie des dépendances pendant l’installation. Pi n’a pas besoin de ces scripts pour une installation npm normale, et les sauter réduit un risque courant de chaîne d’approvisionnement. -
Vérifiez l’installation :
pi --version -
Entrez dans un projet et démarrez-le :
cd /path/to/project pi
Pi s’attend à un environnement capable de bash. Sur Windows, utilisez WSL ou Git Bash plutôt que cmd.exe.
Pi prend en charge l’authentification par abonnement interactif ainsi que les fournisseurs basés sur des clés API. À l’intérieur de Pi, la voie la plus simple est :
/login
Après l’authentification, sélectionnez un modèle avec :
/model
Vous pouvez également fournir des identifiants de fournisseur via des variables d’environnement. Par exemple :
export ANTHROPIC_API_KEY="your-api-key"
pi
Pi prend actuellement en charge une large collection de fournisseurs de modèles, y compris OpenAI, Anthropic, Google, Azure OpenAI, Amazon Bedrock, NVIDIA NIM, DeepSeek, Mistral, Groq, Cerebras, Cloudflare, xAI, OpenRouter et plusieurs autres. Un routeur llama.cpp est également pris en charge pour les modèles servis localement : le démarrage rapide de llama.cpp couvre le service de modèles GGUF avec une API compatible OpenAI, et le guide d’hébergement LLM cartographie les environnements d’exécution locaux, auto-hébergés et cloud environnants si vous souhaitez comparer cette voie avec Ollama, vLLM ou un fournisseur hébergé. Les fournisseurs personnalisés qui parlent une API prise en charge peuvent être ajoutés via ~/.pi/agent/models.json, et les API personnalisées ou les flux OAuth peuvent être câblés avec des extensions.
Cette conception multi-fournisseurs est l’un des avantages pratiques de Pi. Le modèle et le harnais de codage sont des variables séparées : avec Pi, vous pouvez changer le modèle tout en conservant essentiellement le même outillage et l’environnement de session, ce qui rend les comparaisons de modèles considérablement plus significatives que la comparaison de produits de codage complètement différents.
Commencer par une première session contrôlée
Je ne ferais pas de votre première invite Pi « refactorise mon application ». Commencez par lui demander d’inspecter plutôt que de modifier :
pi --tools read,grep,find,ls -p "Inspect this repository. Explain its architecture, identify the main entry points, and list the commands you would run before making a change. Do not modify files."
Lorsque j’ai exécuté cette invite en lecture seule sur un dépôt existant, le résultat utile n’était pas un essai d’architecture ingénieux. C’était de savoir si le modèle nommait de vrais points d’entrée et les commandes que j’exécuterais réellement avant de demander un accès en écriture. Cela vous donne un aperçu de la façon dont le modèle sélectionné navigue dans votre arborescence sans lui accorder immédiatement un chemin d’écriture via le jeu d’outils normal.
Pour un travail interactif, je créerais également d’abord une branche Git jetable :
git switch -c ai/pi-evaluation
pi
Pi peut modifier les fichiers dans le répertoire de travail et peut exécuter des commandes shell via bash, donc Git reste l’une des couches de retour en arrière les plus simples et pratiques lors de son évaluation. Si vous souhaitez une session de test qui ne persiste pas, pi --no-session s’exécute en mode éphémère.
Les instructions du projet appartiennent dans AGENTS.md. Un fichier de départ utile pourrait ressembler à ceci :
# Project Instructions
- Read the existing implementation before modifying files.
- Keep changes narrowly scoped to the requested task.
- Run `npm test` after code changes.
- Run `npm run lint` before declaring the task complete.
- Do not modify database migrations unless explicitly requested.
- Do not access production infrastructure.
- Explain any destructive command before running it.
Pi comprend également CLAUDE.md lors de la navigation dans les répertoires du projet, et AGENTS.override.md peut remplacer les instructions de projet normales pour un répertoire.
Ensuite, donnez-lui une tâche concrète :
Read the authentication module and its tests.
Find one maintainability problem that can be fixed without changing public behaviour. Explain the proposed change first, then implement it and run the relevant tests.
C’est une meilleure évaluation d’agent que de lui demander de générer une nouvelle application jouet. Le code existant force l’agent à découvrir les contraintes, à préserver le comportement, à choisir les fichiers pertinents et à vérifier son travail.
Pourquoi Pi Coding Agent est un harnais éditable
L’idée architecturale la plus importante de Pi est que l’agent de codage lui-même doit rester éditable. Le système d’extension utilise des modules TypeScript qui peuvent enregistrer des outils, s’abonner à des événements de cycle de vie, intercepter des appels d’outils, injecter ou transformer le contexte, ajouter des commandes et modifier l’interface de terminal. Les extensions locales au projet peuvent également être rechargées avec /reload, ce qui rend l’expérimentation avec le harnais surprenante et immédiate.
De manière simplifiée, Pi ressemble à ceci :
Le diagramme est simple parce que Pi essaie de garder le plan de contrôle simple. Cela vous donne une option inhabituelle : lorsque l’agent manque d’une capacité, vous n’avez pas nécessairement à attendre que les mainteneurs de Pi l’ajoutent — vous pouvez ajouter le comportement vous-même. Une extension peut créer un nouvel outil appelable par le modèle, inspecter un appel bash proposé et bloquer les commandes correspondant à votre propre politique, insérer des informations de projet dynamiques avant un tour, modifier le comportement de compaction ou exposer une commande personnalisée dans l’interface de terminal. C’est une surface d’extension beaucoup plus profonde que la modification d’une invite système.
L’intégration MCP n’est pas traitée comme une partie intégrante obligatoire du noyau minimal de Pi. Elle peut être ajoutée via le même modèle d’extensibilité, ce qui est cohérent avec la conception plus large : les intégrations spécialisées résident au-dessus du petit harnais par défaut plutôt que de l’élargir en permanence.
Le même harnais est également réutilisable en dehors du terminal interactif. Pi fournit un SDK pour intégrer la session de l’agent dans des applications Node.js, et un mode RPC (pi --mode rpc) qui parle JSON sur stdin/stdout pour les hôtes non-Node, les IDE et les interfaces utilisateur personnalisées.
L’idée des quatre outils est plus sérieuse qu’elle n’y paraît
Au début, je pensais aux outils des agents de codage en deux groupes. Le premier contient des primitives : lire un fichier, modifier un fichier et exécuter une commande. Le second contient des commodités : recherche de dépôt, lanceurs de tests, suiveurs de problèmes, outils de navigateur, outils de déploiement, assistants de base de données, intelligence du code et planificateurs spécialisés. Pi garde la couche de primitives petite et permet à la couche de commodités de rester optionnelle.
Il y a un avantage architectural à cela. Une équipe travaillant sur l’infrastructure Kubernetes peut construire un Pi très différent d’une équipe maintenant un monorepo TypeScript, sans que les deux équipes ne portent les outils de l’autre dans le même agent par défaut. C’est là que Pi cesse de ressembler à une alternative allégée de Claude Code et commence à ressembler à un framework pour construire votre propre agent de codage.
Le prix est la maintenance. Une fois que vous dépendez d’extensions personnalisées, leur comportement devient partie de votre plateforme de développement : vous devez les examiner, les versionner et occasionnellement les mettre à jour à mesure que Pi évolue. C’est l’impôt caché de Pi — vous obtenez la propriété de l’agent, et la propriété vient avec la maintenance.
Les compétences et les paquets gardent la personnalisation modulaire
Tous les comportements personnalisés n’ont pas besoin de devenir une extension. Pi prend en charge les compétences qui emballent des instructions, des scripts et du matériel de référence autour d’une capacité. Les compétences utilisent la divulgation progressive : Pi peut annoncer la compétence disponible au modèle tout en chargeant les instructions complètes uniquement lorsque la capacité est nécessaire. C’est utile pour des flux de travail tels que les revues de déploiement, les migrations de base de données, la préparation des versions ou la revue de code spécifique à un framework ; au lieu d’injecter en permanence des pages d’instructions dans chaque conversation, l’agent peut charger des conseils spécialisés à la demande. Si vous construisez déjà des Claude Skills, la mécanique vous semblera familière — voir Claude Skills et SKILL.md pour les développeurs pour la disposition de SKILL.md et le réglage des déclencheurs.
Les Pi Packages vont plus loin en regroupant des extensions, des compétences, des modèles de prompts et des thèmes. Les paquets peuvent être installés depuis npm ou des dépôts Git et peuvent être épinglés à des versions spécifiques :
pi install npm:@foo/pi-tools@1.2.3
pi list
Le modèle de paquet est puissant, mais traitez les paquets davantage comme un outillage de développement exécutable que comme des collections de prompts inoffensives. Une extension Pi peut exécuter du code avec les autorisations du processus Pi, et une compétence peut également instruire le modèle d’exécuter du code, donc l’installation d’un paquet inconnu mérite essentiellement la même suspicion que l’installation d’une dépendance de développement inconnue.
Arborescences de session dans Pi Coding Agent
Beaucoup d’assistants de codage traitent une conversation comme une transcription principalement linéaire. Pi stocke les sessions comme un arbre, ce qui signifie que vous pouvez revenir à un point antérieur, essayer une autre approche et conserver les deux chemins dans la session plutôt que de détruire un historique ou de créer une pile de chats non liés.
Les commandes principales sont simples :
/resume
/tree
/fork
/clone
/compact
/tree vous permet de naviguer dans l’arborescence de session actuelle. /fork crée une nouvelle session à partir d’un message utilisateur antérieur, tandis que /clone duplique la branche actuellement active dans une session séparée. Depuis la ligne de commande, pi -c continue la session la plus récente et pi -r parcourt les anciennes.
La distinction est devenue évidente la première fois que j’ai utilisé Pi sur un passage de débogage plutôt que sur une invite de terrain vierge. Je l’ai laissé suivre une hypothèse de couche de cache pour un test d’intégration échoué, puis j’ai fait une fourchette depuis le message où cette théorie avait été choisie et j’ai démarré une deuxième branche sur l’isolation des transactions. L’investigation échouée est restée disponible pour contraste au lieu de contaminer le nouveau chemin ou de forcer un nouveau chat, ce qui est une représentation utile de la façon dont le débogage fonctionne réellement : plusieurs explications plausibles existent souvent en même temps.
Pi persiste les sessions en JSONL et peut automatiquement compacter le contexte plus ancien à mesure que les conversations approchent des limites du modèle ; les branches peuvent également être résumées lorsque vous vous déplacez entre elles. Je classerais cela au-dessus de plusieurs fonctionnalités d’agents de codage plus visibles : une bonne gestion du contexte compte souvent plus qu’un autre bouton dans l’interface.
L’ingénierie du contexte est une capacité de premier ordre
Pi permet également de personnaliser ce qui atteint le modèle. Les extensions peuvent injecter des informations avant les tours, modifier l’historique et participer à la compaction. Le système de compaction par défaut résume le matériel plus ancien tout en conservant la conversation récente, mais le mécanisme peut être remplacé ou personnalisé.
Pour les équipes avancées, cela ouvre des possibilités intéressantes. Un grand monorepo pourrait injecter des informations de propriété uniquement pour les fichiers que l’agent touche actuellement. Un projet backend pourrait faire surface des métadonnées de schéma lorsque des fichiers de base de données entrent dans le contexte. Un agent de migration à long terme pourrait maintenir un état structuré en dehors de la conversation plutôt que de demander au modèle de le redécouvrir à répétition. C’est ce que je considère comme la véritable force à long terme de Pi : la qualité des agents de codage est de plus en plus contrainte par l’ingénierie du contexte, la conception des outils et l’orchestration plutôt que par l’intelligence brute du modèle, et Pi donne aux développeurs un accès inhabituellement direct à ces couches.
Sécurité de Pi Coding Agent : pas de bac à sable intégré
Le point négatif le plus important de cette revue est simple : Pi ne fournit pas de bac à sable de sécurité intégré. Par défaut, Pi s’exécute avec les autorisations de l’utilisateur et du processus qui l’a démarré. Ses outils peuvent lire et modifier les fichiers accessibles et exécuter des commandes shell dans ce contexte de système d’exploitation.
Pi a bien la confiance du projet, mais la confiance du projet n’est pas un bac à sable. La confiance du projet contrôle si les réglages Pi locaux au projet, les extensions, les compétences, les prompts et des ressources similaires sont chargés. Une fois que vous travaillez dans un projet, cela ne crée pas de frontière de système de fichiers, de réseau, de processus ou de certificat autour des appels d’outils dirigés par le modèle. J’apprécie en fait que la documentation de Pi soit explicite sur cette distinction : un pseudo-bac à sable faible peut être plus dangereux qu’aucun bac à sable parce que les utilisateurs peuvent faire confiance à une frontière qui n’existe pas vraiment. Pi s’attend plutôt à ce que l’isolation significative provienne de conteneurs, de machines virtuelles, de micro-VMs ou d’un autre environnement d’exécution contrôlé par politique.
Pour des projets personnels jetables, vous pouvez décider que Git et les autorisations normales du système d’exploitation sont suffisants. Pour les dépôts non fiables, les agents non surveillés, les postes de travail contenant des certificats de production ou les agents traitant du contenu fourni de manière externe, j’utiliserais une isolation plus forte. La documentation de Pi décrit trois modèles :
| Modèle | Ce qui est isolé | Où résident les certificats | Quand l’utiliser |
|---|---|---|---|
| Extension Gondolin | Outils intégrés et commandes ! dans une micro-VM Linux locale ; le processus pi reste sur l’hôte |
L’authentification du fournisseur peut rester sur l’hôte | Isolation locale lorsque vous voulez l’interface en terminal et les clés sur l’hôte |
| Docker simple | Le processus pi entier |
Les clés API entrent dans le conteneur à moins que vous ne les proxifyez | Isolation locale simple de l’agent entier |
| NVIDIA OpenShell | Le processus pi entier dans un bac à sable contrôlé par politique |
La passerelle peut garder les clés de modèle brutes en dehors du bac à sable | Politique locale ou distante sur le système de fichiers, le réseau et les certificats |
La frontière importante n’est pas seulement le répertoire source. Un agent qui peut exécuter des commandes shell peut potentiellement interagir avec la configuration SSH, les certificats cloud, les registres de paquets, les services locaux, l’état du navigateur et tout ce qui est disponible pour le processus. Une configuration de qualité de production doit donc réfléchir aux montages de système de fichiers, aux variables d’environnement, à l’accès réseau et aux certificats ensemble. Mon modèle d’évaluation préféré est :
Monter le dépôt réel en lecture/écriture dans un conteneur permet toujours à l’agent de modifier ce dépôt ; les conteneurs n’aident que dans la mesure où leurs montages, certificats, capacités et accès réseau sont réellement contraindre. Gondolin a une réserve connexe : les outils d’extension personnalisés s’exécutent toujours sur l’hôte à moins qu’ils ne délèguent également dans la VM.
Il existe une autre surface de sécurité à retenir : les extensions et les paquets. Une extension tierce est du code s’exécutant dans l’environnement de l’agent. Examinez-la avant l’installation, épinglez les dépendances importantes et évitez de traiter une galerie de paquets publique comme une revue de sécurité implicite.
Deux vérifications pratiques avant d’exécuter Pi sur une machine qui vous importe :
# Confirm the version you actually have
pi --version
# Disable startup network operations (update checks and install telemetry)
export PI_OFFLINE=1
pi
PI_OFFLINE=1 désactive toutes les opérations réseau au démarrage, y compris les vérifications de mise à jour, les vérifications de mise à jour des paquets et la télémétrie d’installation/mise à jour. Si vous souhaitez une division plus fine, PI_SKIP_VERSION_CHECK=1 désactive uniquement la vérification de version, et PI_TELEMETRY=0 désactive la télémétrie d’installation/mise à jour tout en laissant les vérifications de mise à jour activées.
Ce modèle de sécurité est la raison principale pour laquelle j’hésiterais avant de donner Pi à une grande organisation d’ingénierie en tant que réglage par défaut non géré. Pi fournit les pièces pour construire un environnement solide, mais il laisse intentionnellement beaucoup de cet environnement à votre charge.
Pi Coding Agent vs Claude Code et OpenCode
Pi a le plus de sens lorsqu’il est comparé par philosophie plutôt que par nombre de fonctionnalités. Parmi les agents en terminal, OpenHands est le frère plus proche : il s’exécute également depuis l’interface en ligne de commande, mais il fournit un bac à sable et un flux de travail intégré plus grand plutôt que de vous demander d’en assembler un. Claude Code a des autorisations intégrées, des crochets et des sous-agents de plus en plus sophistiqués. OpenCode expose des règles configurables d’autorisation, de demande et de refus ainsi que des concepts intégrés d’agent ou de sous-agent. Pi commence plus bas dans la pile.
| Capacité | Pi | Claude Code | OpenCode |
|---|---|---|---|
| Approche de base | Harnais extensible minimal | Produit d’agent de codage opinionné | Agent de codage configurable |
| Outils de codage par défaut | Petit ensemble de primitives | Surface d’outils intégrée plus grande | Surface d’outils intégrée |
| Système d’autorisation | Pas une frontière de sécurité de base | Modes et règles d’autorisation intégrés | Règles intégrées d’autorisation, de demande et de refus |
| Sous-agents intégrés | Non, ajoutez-les via la personnalisation | Sous-agents isolés avec listes d’autorisation d’outils | Agents principaux et sous-agents intégrés |
| Comportement de cycle de vie personnalisé | Extensions et événements TypeScript | Crochets, plugins et settings.json |
Configuration de l’agent et des outils |
| Branchement de session | Sessions en arbre avec /fork et /clone |
Sessions linéaires plus flux de travail de sous-agents | Continuité de session plus agents intégrés |
| Meilleure adaptation | Développeurs construisant leur propre flux de travail d’agent | Développeurs souhaitant des intégrations plus fortes | Développeurs souhaitant des agents configurables avec une politique intégrée |
C’est pourquoi appeler Pi un « clone de Claude Code » manque la partie intéressante. Si vous êtes satisfait du flux de travail de Claude Code, Pi ne l’améliore pas automatiquement : Claude Code vous donne plus de sécurité et de comportement d’orchestration d’agent sans vous obliger à assembler ces pièces vous-même. Pi devient intéressant lorsque vous voulez changer les hypothèses sous le produit. Peut-être que vous voulez le même harnais à travers Anthropic, OpenAI et les modèles locaux. Peut-être que votre organisation a son propre bac à sable. Peut-être que vous avez besoin d’un outil qui injecte des métadonnées d’architecture interne avant chaque tour. Peut-être que vous voulez que la compaction produise un état d’ingénierie structuré au lieu d’un résumé de conversation générique. C’est le territoire de Pi.
OpenCode est philosophiquement plus proche car il offre également une configuration substantielle. Même là, Pi se sent plus comme un kit pour construire le harnais lui-même, tandis qu’OpenCode expose plus de concepts d’agent et d’autorisation prêts à l’emploi.
Il n’y a pas de gagnant universel ici. Pour de nombreux développeurs, les réglages par défaut opinionnés de Claude Code sont un avantage. Pour d’autres, OpenCode peut offrir un meilleur compromis. Pi est l’option que je chercherais lorsque la phrase « je souhaite que mon agent de codage fonctionne différemment » est devenue plus importante que « je souhaite que mon agent de codage ait une autre fonctionnalité ».
Devriez-vous utiliser Pi Coding Agent ?
Pi Coding Agent est l’un des agents de codage les plus techniquement intéressants parce qu’il refuse de cacher le harnais. L’implémentation par défaut est délibérément petite, mais l’API d’extension, les compétences, les paquets, la couche fournisseur, le SDK, le mode RPC et l’arborescence de session lui donnent une surface effective beaucoup plus grande que ce que ses quatre outils par défaut suggèrent.
Je recommanderais Pi le plus fortement aux développeurs expérimentés qui aiment construire leur propre outillage. Il est particulièrement convaincant pour le travail de plateforme IA, la recherche expérimentale sur les agents de codage, les flux de travail d’ingénierie spécialisés et les équipes qui ont déjà une infrastructure d’exécution sécurisée. Il est également utile pour les développeurs qui veulent comparer les modèles sans changer tout leur environnement de codage à chaque fois. Je serais plus prudent pour les débutants et pour les organisations s’attendant à des contrôles de politique de style entreprise immédiatement après l’installation.
Le bac à sable manquant change la façon dont Pi devrait être déployé, en particulier lorsqu’un agent est autorisé à opérer non surveillé ou peut rencontrer des instructions non fiables. Traitez Pi comme un processus de développement local puissant plutôt que comme une frontière de sécurité : pour les dépôts non fiables, le fonctionnement non surveillé ou les environnements contenant des certificats précieux, utilisez un bac à sable basé sur le système d’exploitation, le conteneur, la VM ou la politique et n’exposez que les ressources nécessaires pour la tâche.
Ma note globale est de 8,4/10. C’est un verdict éditorial plutôt que la moyenne du tableau ci-dessus, et il pourrait facilement devenir plus élevée pour le bon utilisateur. La plus grande faiblesse et la plus grande force de Pi sont la même chose : il ne termine pas l’agent pour vous.
Devriez-vous passer de Claude Code ? Pas automatiquement. Utilisez Claude Code lorsque ses autorisations, sous-agents, crochets et flux de travail intégrés correspondent à la façon dont vous travaillez déjà. Évaluez Pi lorsque vous voulez une propriété plus large du harnais, de la sélection du fournisseur, de la construction du contexte et de l’architecture des outils. Pour les développeurs avancés, je ne supposerais même pas que le choix doit être exclusif : Claude Code peut rester le conducteur quotidien poli tandis que Pi devient le laboratoire d’agent programmable. Après suffisamment de personnalisation, ce laboratoire peut se transformer en l’outil que vous préférez réellement.
Licence et coût
Pi lui-même est open source et publié sous licence MIT. Cela ne rend pas la déduction du modèle gratuite : votre coût réel dépend du fournisseur de modèle, de l’utilisation de l’API, de l’authentification par abonnement prise en charge, de la puissance de calcul locale et de toute infrastructure de bac à sable que vous choisissez d’exécuter.
Références
- Dépôt Pi Coding Agent : https://github.com/earendil-works/pi
- Site web et installateur Pi : https://pi.dev
- Paquet 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
- Licence : MIT