Pi est un agent de codage minimaliste et auto-modifiable, créé par Mario Zner. Il est devenu le moteur de l’assistant personnel IA OpenClaw. Armen Roner, créateur de Flask, est un early adopter et contributeur de Pi.
Mario Zner a grandi dans les années 90, avec un premier PC en 1996. Il aimait les jeux vidéo mais sa famille ne pouvait pas s’offrir de console. Ses parents ont économisé pour lui acheter un 486. Il a appris la programmation graphique, puis a travaillé dans le traitement du langage naturel et le machine learning avant que le deep learning n’existe.
Après une startup à San Francisco et une autre en Suède, il a suivi les avancées en ML. Puis GPT est arrivé.
Armen Roner a eu un vieux 386 recyclé par ses parents architectes. Il a joué avec Quick Basic et Turbo Pascal, puis a découvert Python en 2002-2003. Avec des amis, il a fondé la fondation Ubuntu allemande. Pour gérer la communauté, il a créé Flask.
Il a travaillé sur des jeux vidéo à Londres, puis chez Sentry pendant 10 ans, avant de partir en avril 2024.
Mario et Armen se sont rencontrés sur Internet, puis à Vienne. Ils ont beaucoup échangé de manière constructive. En 2022, Mario a essayé GitHub Copilot sur l’insistance de Ned Friedman. Il l’a trouvé horrible. Mais après la sortie de GPT et l’introduction de l’appel de fonctions, c’est devenu intéressant. Fin 2024, les agents de codage sont devenus réellement utiles.
En 2025, Cloud Code a introduit la recherche par champ : donner à l’agent un moyen de parcourir le système de fichiers a fait toute la différence.
Armen a eu un accès anticipé à Copilot. Il a sondé le modèle pour voir s’il restituait du code GPL. Il a obtenu une licence MIT attribuée à tort. Son tweet est devenu viral.
Cela lui a fait prendre conscience des progrès réels de l’IA. Mais ce n’est qu’avec Cloud Code qu’il a senti que le monde allait changer.
L’explosion des agents de codage et ses dérives
Armen a interrogé 30 équipes d’ingénierie sur l’utilisation des agents. Beaucoup d’apprentissages ne sont pas surprenants : l’adoption a explosé après Noël. La qualité a chuté. Les PR deviennent plus volumineuses et plus psychologiques.
Les ingénieurs ont du mal à suivre le rythme
Le code est écrit d’une manière qu’un ingénieur ne ferait pas, car l’agent ne pense pas à son futur moi.
Mario compare cela à un système avec trop d’états, comme une machine à états émergente. Le code devient bien plus complexe qu’il ne devrait l’être. Les agents produisent parfois du code génial, parfois la pire horreur, mais le biais d’automatisation empêche de le remarquer.
Le syndrome de la dette technique accélérée
Les agents n’apprennent pas comme les humains
Ils ne ressentent pas la douleur. Un ingénieur senior a des cicatrices de bataille : il a été brûlé, il sait ce qui arrive quand la dette technique s’emballe. Un bon ingénieur dit souvent « non » pour maintenir la complexité basse.
Avec les agents, c’est l’inverse : on dit oui à tout car on n’a pas besoin de le taper soi-même.
Les non-ingénieurs participent désormais aux processus d’ingénierie. Un chef de produit peut essayer une fonctionnalité sans faire perdre de temps à un ingénieur. Mais il faut toujours un processus pour encadrer cela. L’intégration est la chose difficile.
Armen trouve précieux de voir une implémentation médiocre de quelque chose. Cela lui fait gagner du temps : quelqu’un a déjà essayé la version naïve et stupide. Il ferme automatiquement les PR des agents, mais elles ont de la valeur.
Je mets à jour ou crée vos articles personnellement, assisté par l'IA, avec optimisation SEO incluse.
| 📝 Mise à jour | 14 € |
| ✨ Création | 49 € |
La question de la responsabilité ne s’adapte pas de la même manière avec les machines. Une machine ne peut pas encore être responsable. On ne peut pas abstraire l’erreur humaine à ce point.
Pourquoi Mario a construit Pi
Mario a construit Pi car Cloud Code devenait instable
L’équipe ajoutait des fonctionnalités et des bugs. Les parties déterministes n’étaient plus stables. Ils injectaient des choses dans le contexte sans que l’utilisateur le voie.
Mario a fait du rétro-ingénierie sur Cloud Code. Il voulait un outil fiable, comme un marteau.
Les alternatives décevantes
Il a cherché des alternatives.
- AMP et Droid étaient chers, ne fonctionnaient pas pour le petit bricoleur.
- OpenCode faisait aussi des choses dans le contexte que Mario n’appréciait pas : il exécutait un serveur LSP après chaque modification, injectant des diagnostics alors que le modèle n’avait pas fini son travail.
Les principes de conception
Mario a donc construit son propre agent. Les principes de base :
- une abstraction sur les API des fournisseurs de LM
- une boucle d’agent généralisée avec appel d’outils et streaming
L’extensibilité vient de points d’accroche : on peut y accrocher un module TypeScript chargé dans le même processus Node. Cela permet de fournir des outils personnalisés, d’implémenter sa propre compaction, ou de refaire entièrement la TUI.
On peut demander à Pi de se modifier lui-même. Pi n’a pas de MCP. Les gens demandent à Pi de construire le support MCP dans Pi. Pi n’a pas de mode plan.
Armen voulait que l’agent puisse se valider lui-même. Pi s’est construit des outils de débogage :
- Captures d’écran
- Simulation
- Vidage d’état
Pi peut afficher des images dans la TUI. On peut revenir à un état antérieur et bifurquer.
Le futur des logiciels auto-modifiables
Mario pense que les logiciels vont devenir auto-modifiables pour répondre aux souhaits des utilisateurs. Pi est sa première incursion dans ce domaine. Le prochain plan est d’avoir une interface utilisateur web alternative à la TUI, pour ne plus être limité au rendu ligne par ligne d’un terminal.
OpenClaw et la communauté
OpenClaw utilise Pi. Peter Steinberger a d’abord cloné Pi, l’a appelé towel, puis s’est lassé de le maintenir et a utilisé le Pi de Mario. Pi n’aurait pas eu de compaction sans OpenClaw : Mario l’a construite parce que Peter en avait besoin.
Mario doit gérer les bugs d’OpenClaw qui sont attribués à Pi. Les utilisateurs d’OpenClaw envoient des issues et des PR de manière autonome. Mario ferme automatiquement chaque PR. Son workflow GitHub vérifie si le contributeur est dans un fichier.
Si ce n’est pas le cas, la PR est fermée avec un commentaire demandant d’ouvrir une issue avec une voix humaine. Les agents ne voient pas ce commentaire.
Le volume de PR a explosé de fin décembre à mi-février. Mario réparait deux choses, et cinq minutes après avoir commité, un clanker annulait ses correctifs. Il a besoin de goulots d’étranglement pour traiter le volume.
Armen pense que l’open source n’a pas fondamentalement changé. Le volume a changé, mais la quantité de projets réellement utiles et maintenus n’a pas beaucoup changé. Il y a simplement plus de projets qui meurent après deux jours. La valeur de l’open source venait de l’énergie humaine mise en commun pour résoudre des problèmes ardus.
Maintenant, l’IA produit des choses plausibles qui ressemblent à de l’énergie humaine, mais ce n’est que du volume.
| Problème | Impact humain | Impact agent IA |
|---|---|---|
| Volume de code | Limité par le temps | 10x plus, difficile à relire |
| Qualité | Expérience et discipline | Moyenne, sans conscience |
| Dette technique | Ralentit progressivement | Accélérée, exponentielle |
Qualité du code et responsabilité
Les modèles d’apprentissage automatique convergent vers la moyenne, pas vers la simplification. La moyenne, ce sont toutes les ordures sur Internet, le cargo culting, les modes du jour. C’est ce qu’on obtient quand on laisse les agents tout faire.
Armen gère mal la génération de code dans sa startup. Il a appris que s’il n’y a pas de canal de retour, la complexité augmente sans qu’on la ressente. L’agent fait plus d’erreurs à cause de la complexité qu’il a ajoutée.
Le manifeste pour ralentir
Un agent crache 10 fois plus de code par jour qu’un humain, donc 10 fois plus d’erreurs. Le rythme de dégradation de la base de code augmente. On ne peut pas relire tout ce code.
Les entreprises prétendent que tout leur code est écrit par des agents, mais la qualité est médiocre. On le ressent dans nos os quand on utilise leurs produits. C’est de la camelote.
Bien utiliser les agents
Mario pense qu’il faut utiliser les agents pour automatiser les choses qu’on déteste faire, et utiliser le temps gagné pour réfléchir à ce qu’on veut vraiment construire. Mais ce n’est pas comme ça que l’industrie travaille : on construit des armées d’agents avec des cahiers des charges.
MCP vs CLI pour les agents de codage
Sur MCP vs CLI : Mario pense que MCP est complexe, remplit rapidement le contexte, et n’est pas composable. Les CLI permettent d’enchaîner des outils. Le modèle ne voit que le résultat final et est libre de manipuler les données. MCP a des cas d’utilisation valables, notamment dans les grandes entreprises, mais pour les agents de codage, la génération de code est plus naturelle.
Sur notre blog ⇒ Et si l’outil le plus puissant pour vos agents IA n’était pas une interface sophistiquée, mais une simple ligne de commande héritée des années 70 ?
Prévisions pour 2027
Pour 2027, Mario croit en l’auto-modifiabilité des logiciels
Armen pense que l’exécution de code et la génération de code vont compter, car l’apprentissage par renforcement obtient davantage de données. Il y aura une reconnaissance de la dépendance envers deux entreprises. Des équipes d’ingénierie disent déjà qu’elles ne peuvent plus maintenir leurs bases de code sans la machine.
Comment rester à jour
- Pour rester à jour, Mario évite San Francisco, a un enfant, grimpe aux arbres, patine sur glace. Il ne lit pas ses emails.
- Armen a une addiction à Twitter mais attend trois semaines pour voir si une information persiste.
Comme livres, Mario recommande « Code » de Pet Salt. Armen recommande « Breakneck », dont il a oublié l’auteur, qui explore comment la Chine fonctionne.
A lire sur notre blog ⇒ Flatterie IA : pourquoi les LLM vous rendent surconfiant (effet GStack)
Sources ⇒ Pi agent de codage, Openclaw site officiel
🔒 À retenir : La sécurité en ligne est essentielle, ne naviguez pas sans protection. Protéger mes données avec NordVPN
