Pi Coding Agent : créer des outils IA flexibles pour des flux de travail réels

Introduction

Le code n’est jamais gratuit. C’est l’argument central que Mario Zechner, créateur de Pi, avance lorsqu’il discute de l’état du développement assisté par IA en 2026. Bien que les agents puissent générer rapidement de grandes quantités de code, les conséquences de ce code finissent toujours par vous rattraper. Pi existe parce que Zechner a constaté que les agents de codage existants ne correspondaient pas à ses flux de travail, et plutôt que de s’adapter, il a construit un outil qui s’adapte à lui.

Cette conversation aborde les raisons pour lesquelles la stabilité du flux de travail est plus importante que la vitesse d’ajout de fonctionnalités, comment travailler efficacement avec des agents de codage sans s’épuiser, et pourquoi l’industrie pourrait répéter une erreur vieille de 30 ans avec le développement piloté par les spécifications.

Pourquoi Pi existe : la flexibilité des flux de travail plutôt que la stabilité

Lorsque Claude Code a été lancé, Zechner en était satisfait. Cependant, avec le temps, la fréquence élevée des mises à jour de l’outil est devenue un problème. Claude Code reçoit une à trois mises à jour par jour, et chaque version apporte des changements aux définitions des outils, aux invites système et au comportement sous-jacent. Pour quelqu’un qui construit des modèles d’invites personnalisés, des commandes slash et des descriptions de flux de travail, ces changements invisibles cassent tout.

Le modèle lui-même semblait se comporter différemment d’un jour à l’autre, bien que la version du modèle soit restée la même. Zechner attribue cela en partie aux changements dans le « harnais » — l’infrastructure et les invites système qui façonnent la manière dont un modèle répond. Tester les effets des changements de harnais sur la qualité de la sortie est difficile car il n’existe aucun moyen déterministe de le mesurer. Le résultat est que les développeurs comme Zechner ne peuvent pas compter sur un comportement cohérent de l’outil, ce qui annule l’intérêt de construire des flux de travail personnalisés autour de lui.

Pi est né de cette frustration. C’est un agent de codage minimal et extensible qui peut se modifier pour s’adapter à vos flux de travail au lieu de vous forcer à vous adapter à ses contraintes. L’architecture sous-jacente abstrait les fournisseurs LLM, inclut une bibliothèque d’interface utilisateur de terminal et fournit des abstractions générales de boucle d’agent. Mais la différence clé est le contrôle : Zechner dicte la conception et peut la modifier sans attendre le cycle de publication d’un fournisseur.

Comment fonctionne réellement Pi : traitement parallèle et révision manuelle

Le flux de travail quotidien de Zechner avec Pi est méthodique et délibérément peu technologique. Il ne fait pas tourner une armée d’agents en parallèle. Au lieu de cela, il utilise une approche rudimentaire : mettre en file d’attente plusieurs sessions, chacune analysant un problème différent issu du suivi, puis examiner et itérer sur chacune d’elles.

Pour les corrections de bugs et les implémentations de fonctionnalités, le processus commence par une description du problème. Zechner transmet le problème à un agent avec un modèle d’invite personnalisé qui dit : récupérez toutes les informations pertinentes, ignorez l’analyse dans le ticket, et faites votre propre analyse basée sur ce que nous voulons atteindre. Cette étape d’analyse prend environ cinq minutes par ticket. Il ouvre une deuxième session pour le problème suivant, une troisième pour un autre, créant ainsi un pipeline de pré-traitement parallèle.

Une fois que l’agent a fini d’analyser un problème, Zechner examine les suggestions, vérifie lui-même le code et reproduit les problèmes manuellement si nécessaire. Il utilise l’agent comme un « canard en plastique » — un partenaire de réflexion — jusqu’à ce qu’il soit en accord avec lui-même sur l’approche d’implémentation. Au moment où il dit à l’agent d’implémenter, le contexte contient tellement de garde-fous que l’agent sait exactement quelles interfaces modifier, quels modules toucher et comment les tests doivent fonctionner.

L’implémentation prend 10 à 30 minutes supplémentaires. Lorsque l’agent signale la fin, Zechner ouvre un visualiseur de diff et annote les lignes individuelles avec des commentaires. Il clique sur terminer, les commentaires sont automatiquement renvoyés à l’agent, et l’itération continue jusqu’à ce que le code soit bon. Pour les mécanismes de base, il examine chaque changement comme il le ferait avec un humain. Pour d’autres parties, il approuve sans inspection approfondie.

Ce flux de travail fonctionne parce que Zechner a plus de 10 ans d’expérience dans les bases de code. Il sait ce qui fonctionne et ce qui ne fonctionne pas. Pour les nouveaux développeurs ou ceux sans cette expérience, l’approche serait différente — et plus risquée.

La réalité du développement piloté par les spécifications

L’industrie répète une erreur vieille de 30 ans. Le développement en cascade (Waterfall) s’est avéré inefficace il y a des décennies, pourtant avec les agents IA, nous sommes revenus à une hyper-cascade : écrire des spécifications détaillées et demander aux agents de les implémenter. La seule différence est que maintenant, vous n’écrivez même plus la spécification vous-même — vous demandez à un agent de rédiger une spécification très détaillée, qu’un autre agent implémente ensuite.

Le problème est fondamental. Une spécification complète est essentiellement le programme lui-même. Si vous écrivez une spécification en prose en langage naturel, vous laissez des lacunes. L’agent comble ces lacunes avec les modèles qu’il a appris à partir de 20 ans de code sur Internet — dont une grande partie est médiocre. Le résultat est une base de code qui ressemble à un logiciel codé « au feeling », parce que c’est le cas.

Il existe un contre-argument : le code est désormais bon marché et l’itération est rapide. Auparavant, une spécification en cascade pouvait prendre des mois à implémenter. Maintenant, cela peut prendre une journée. Vous pouvez tester manuellement tout au long du processus. Mais Zechner n’a pas encore vu de preuves que cela fonctionne réellement pour les logiciels de production. Il soupçonne que, tôt ou tard, les développeurs se réveilleront la nuit en réalisant que tout est cassé.

Cela dit, il existe des contraintes où le développement piloté par les agents a du sens. La réécriture de Bun, passant de Zig à Rust, a fonctionné parce que le projet disposait d’une suite de tests étendue. L’agent pouvait vérifier son propre travail dans une certaine mesure. Dans ces cas-là, des outils comme celui-ci sont réellement utiles. Mais pour la plupart des logiciels, l’approche est risquée.

Gérer l’open source à grande échelle : le problème des « Clankers »

Avant les agents, un projet open source réussi pouvait recevoir une ou deux pull requests par semaine. Pi reçoit désormais 50 à 60 pull requests par jour — toutes provenant d’agents (Zechner les appelle des « clankers »). Chaque PR a une description longue comme un livre et inclut de 10 à 1 000 changements de fichiers.

La position par défaut consiste à déclarer chaque PR générée par un agent comme étant inutile et à la fermer automatiquement. Mais Zechner a trouvé une solution : exiger des gens qu’ils écrivent d’abord un ticket avec leur propre voix, pas plus long qu’un écran, expliquant exactement ce qu’ils veulent faire et pourquoi. Si le ticket est bon, il l’approuve et la personne peut envoyer une PR. Cela prouve qu’ils sont humains, qu’ils comprennent le problème et qu’ils comprennent la solution.

Une fois approuvées, des PR significatives arrivent. Les PR des « clankers » cessent d’apparaître. Les tickets continuent d’affluer, mais Zechner les trie manuellement. Il lit 30 à 60 tickets fermés par jour, identifiant ceux qui sont légitimes et ceux qui sont inutiles. Lors de son dernier tri, 50 tickets sont arrivés et 2 ont survécu. Cela prend environ 30 minutes car la plupart sont rapidement identifiés comme du bruit.

Pour des projets à l’échelle d’OpenClaw, cette approche manuelle ne fonctionne pas. La consommation de jetons de Peter Steinberger a atteint 1,3 million de dollars par mois, en partie parce que l’automatisation du filtrage des tickets et des PR à cette échelle nécessite une infrastructure sophistiquée. Zechner a écrit des outils de visualisation pour aider à regrouper les problèmes similaires, mais même cela n’a pas suffi. Le volume est des ordres de grandeur plus important.

Inférence locale et avenir des modèles plus petits

Zechner est optimiste quant à l’exécution de modèles d’IA capables localement sur du matériel grand public. Pour son projet de robot — un jouet avec un smartphone comme microcontrôleur exécutant un agent de codage — il utilise Gemma 4 et Qwen 3.6, des modèles plus petits de type « mixture-of-experts ». Ils sont plus que suffisants pour un chatbot avec contrôle moteur et caméra, et ils sont rapides.

La configuration est abordable. La conversion parole-texte avec Parakeet prend environ 10 gigaoctets de mémoire unifiée. La synthèse vocale avec Qwen TTS prend 10 gigaoctets supplémentaires. Qwen 3.6 prend 4 gigaoctets. Total : 14 gigaoctets de mémoire unifiée sur macOS ou une configuration NVIDIA équivalente sous Windows. C’est abordable pour beaucoup de gens, pas pour le monde entier, mais pour une partie significative.

Denise Asaves de DeepMind a suggéré que les modèles géants actuels n’ont pas besoin de tous leurs paramètres et peuvent être distillés en modèles beaucoup plus petits sans perdre beaucoup en qualité de sortie. L’espoir de Zechner est que l’avenir implique la distillation de grands modèles en modèles plus petits qui conservent la plupart des capacités, plutôt que l’entraînement de modèles spécialisés pour des tâches spécifiques. Antirez de Redis a commencé à travailler sur un moteur d’inférence personnalisé pour DeepSeek V4 appelé ds4, le faisant tourner sur un ordinateur portable de 128 gigaoctets. C’est un modèle vraiment capable qui pourrait gérer 60 à 70 % des problèmes que Zechner traite avec Pi.

Le coût du code et la discipline de l’artisanat

Zechner a vu des gens générer 500 000 lignes de code via des agents en une semaine. Le résultat est toujours le même : un désastre. Le code n’est jamais gratuit car les conséquences finissent par vous frapper. Si vous pensez qu’une grande quantité de code est une bonne chose maintenant, vous avez simplement retardé la punition.

Le véritable goulot d’étranglement dans le développement logiciel n’est pas la vitesse de frappe ou la génération de code. C’est la réflexion, la conception et l’exploration de l’espace des solutions. Les agents sont réellement utiles pour cette phase — vous pouvez dire à plusieurs agents d’explorer différentes approches et voir les résultats plus rapidement. Mais le résultat de ces explorations n’est pas automatiquement réutilisable. Vous devez toujours le comprendre, le refactoriser et le maintenir.

Pour Zechner, la plus grande augmentation de productivité grâce aux agents provient de la nature asynchrone du travail. Il peut donner une tâche à un agent, aller à une réunion et revenir aux résultats. Mais il ne croit pas que faire tourner 10 agents en parallèle multipliera par 10 sa production. Le changement de contexte seul est épuisant. Il l’a fait une ou deux fois par mois, traitant 30 problèmes en une journée, et son cerveau est en bouillie après cela.

L’aspect collaboratif est ce qu’il valorise le plus. Avoir un agent comme partenaire de programmation en binôme — poser des questions, proposer des options, expliquer le code — est comme un vélo pour l’esprit. Cela l’aide à mieux réfléchir aux problèmes que de rester assis seul. Mais cela demande de la discipline : ne pas tout déléguer à la machine, car chaque fois qu’il le fait, il finit coincé dans un coin à pleurer parce que rien n’est bon et que tout s’effondre.

Refactoriser Pi : construire pour l’avenir

Pi a accumulé un bagage historique. Certaines parties précèdent l’utilisation des agents par Zechner et sont solides. D’autres parties, comme l’exportation HTML, il ne les a jamais regardées et ne s’en soucie pas tant que cela fonctionne. Certaines pièces sont codées « au feeling ».

L’effort de refactorisation a plusieurs objectifs. Premièrement, s’étendre plus facilement à d’autres types d’interfaces utilisateur — web, native, peu importe — sans casser les extensions existantes. Deuxièmement, permettre la capacité à distance : exécuter une session Pi sur une machine et s’y connecter depuis une autre, avec une durabilité et une observabilité appropriées. Troisièmement, rendre le SDK de Pi déployable sur Cloudflare Workers, Vercel et d’autres environnements, pas seulement sur des ordinateurs locaux avec bash.

Zechner refactorise sur la branche principale car il ne se soucie pas de la stabilité au sens traditionnel. Il le fait pièce par pièce, en commençant par les paquets de plus bas niveau qui communiquent avec les fournisseurs LLM. L’agent de codage lui-même aura toujours la même apparence et le même fonctionnement, mais toute l’infrastructure sous-jacente sera propre et réutilisable. Il espère terminer cette phase dans une semaine ou deux, puis passer quelques semaines de plus sur le nouveau mécanisme d’extension où les extensions ont des composants côté serveur et côté interface utilisateur.

Pourquoi Pi fonctionne en mode YOLO par défaut

Pi ne demande pas la permission avant d’exécuter du code. C’est intentionnel. En disant aux gens que le mode YOLO est dangereux et qu’ils devraient y réfléchir, Zechner pousse en réalité les gens à penser à la sécurité. Il veut qu’ils cherchent en eux-mêmes une conscience de la sécurité et décident comment protéger le travail agentique dans leur propre environnement.

La réponse est généralement la conteneurisation. Si vous ne voulez pas que l’agent casse votre ordinateur, conteneurisez l’agent ou les outils qu’il utilise — lecture/écriture de fichiers, bash, peu importe. Cela résout le problème. Mais Zechner ne peut pas décider cela pour vous. Il pourrait intégrer le bac à sable d’Anthropic ou bubble wrap, mais ce sont des solutions incomplètes. Dans un environnement d’entreprise avec des contraintes d’infrastructure spécifiques, un bac à sable intégré pourrait ne pas fonctionner du tout.

Ce qui existe dans Claude Code est principalement du théâtre de sécurité. Claude Code demande maintenant à un LLM si une commande bash est sûre avant de l’exécuter en mode automatique. Zechner ne pense pas que ce soit une bonne chose. Un LLM ne peut pas déterminer de manière fiable si une commande est sûre — il ne peut que deviner en fonction de modèles.

Conclusion

Pi représente une philosophie différente : construire des outils que les développeurs peuvent posséder et modifier, et non des outils qui possèdent les développeurs. Le succès de Pi ne se mesure pas en fonctionnalités ou en benchmarks, mais dans la capacité de Zechner à maintenir une petite équipe en vie et à continuer d’explorer les applications du travail agentique — du codage à la robotique en passant par l’inférence locale.

La leçon plus large est que les flux de travail comptent plus que le battage médiatique. La stabilité, la prévisibilité et la capacité à personnaliser vos outils valent plus que la dernière fonctionnalité. Et le code n’est jamais gratuit — les conséquences de vos actions finiront par vous rattraper.