oh-my-pi en détail : un agent de codage avec l'IDE intégré, et pourquoi le format d'édition décide du succès du modèle

Positionnement : un agent avec l'IDE intégré

oh-my-pi, appelé omp en ligne de commande, est maintenu par can1357 chez Stencil Labs. C'est un fork de Pi, le projet open source de Mario Zechner. Sa devise est courte : « Un agent de codage avec l'IDE intégré ». Le README donne ces chiffres : plus de 60 fournisseurs de modèles, 31 outils intégrés, 14 opérations LSP, 28 opérations DAP et environ 80 000 lignes de Rust dans le noyau. Ces chiffres viennent du projet lui-même et nous ne les avons pas tous vérifiés. Ils montrent pourtant l'intention. omp ne veut pas être un simple modèle avec un terminal. Il veut donner à l'agent l'ensemble des capacités qu'un développeur attend d'un IDE.

La pile technique réunit TypeScript, Rust et le runtime Bun. Il faut Bun 1.3.14 ou plus récent, sur macOS, Linux ou Windows. Le README mentionne aussi un essai de politique de contribution : les pull requests sont ouvertes à tous pour le moment. Auparavant, il fallait être parrainé (« vouch »). Ce système pourrait revenir selon les résultats de l'essai.

Architecture : trois couches au-dessus de Pi

Le README laisse voir trois couches. La première est la boucle d'agent et l'interface terminal héritées de Pi. La deuxième regroupe ce que omp appelle les piles incluses : de nombreux outils intégrés, l'adaptation aux modèles et le réglage des prompts. La troisième est la couche de services de langage qui correspond à un IDE, c'est-à-dire LSP et DAP.

LSP, le Language Server Protocol, fournit la navigation vers une définition, la recherche de références, les diagnostics, le renommage et d'autres opérations. Le README dit : « tout ce que votre IDE sait, l'agent le sait ». Avec 14 opérations LSP, l'agent n'a plus besoin de deviner les relations entre symboles avec grep. Il interroge le serveur de langage. DAP, le Debug Adapter Protocol, est plus rare chez les agents. Ses 28 opérations permettent de poser des points d'arrêt, d'avancer pas à pas et d'inspecter des variables. Cela remplace la méthode grossière qui consiste à ajouter des logs puis à relancer. Pour un agent automatisé, ces deux protocoles font passer d'un éditeur de texte à un environnement de développement.

Le noyau Rust prend en charge les parties sensibles à la performance. Le README insiste sur la vitesse de recherche, avec des formules comme « le plus rapide de l'Ouest » pour grep, et affirme que les recherches reviennent instantanément. Il ne publie ni détail d'implémentation ni benchmark de recherche. Nous n'avançons donc rien de plus.

Fonctionnement : le format d'édition est le goulot d'étranglement

L'argument central d'omp est que la qualité dépend du harnais, pas seulement du modèle. L'auteur a publié le 12 février 2026 un article intitulé « The Harness Problem », que le README référence. L'idée : un même modèle se comporte très différemment selon le harnais, et le format d'édition compte le plus. Si un modèle produit un diff mal formé, l'outil le rejette. L'agent entre alors dans une boucle de nouvelles tentatives. Ces tentatives consomment des tokens et polluent le contexte. omp règle les outils et les prompts pour chaque modèle afin que les modifications passent dès le premier essai. Le tableau du README donne quatre exemples :

• Grok Code Fast 1 : le taux de réussite passe de 6,7 % à 68,3 %, soit environ dix fois plus. L'auteur l'attribue à un format d'édition qui cesse de « dévorer le modèle ».
• Gemini 3 Flash : 5 points de pourcentage de plus que str_replace. L'auteur affirme que cela dépasse la meilleure tentative de Google pour ce format.
• Grok 4 Fast : 61 % de tokens de sortie en moins, car la boucle de nouvelles tentatives sur les mauvais diffs disparaît.
• MiniMax : un taux de réussite multiplié par 2,1, avec les mêmes poids et le même prompt. Une précision importante : ce sont des chiffres de l'auteur. Le jeu de test, la taille d'échantillon et les références se trouvent dans l'article de blog, pas dans le tableau du README. Mieux vaut les traiter comme des pistes à vérifier que comme des résultats établis. L'effet de fond reste plausible : la conception de l'outil d'édition peut changer l'utilité d'un modèle donné. Le README liste d'autres choix. L'outil `read` renvoie des extraits résumés au lieu de déverser des fichiers entiers, avec des valeurs par défaut réglées et un bon taux de réussite des sélecteurs. Les `prompts` sont ajustés sans relâche pour chaque modèle.

Exécution de code avec appel d'outils

La première fonction que présente le README est l'exécution de code avec appel d'outils. La plupart des harnais offrent un bac à sable Python et s'arrêtent là. omp exécute un noyau Python persistant et un worker Bun. Chacun peut rappeler les outils de l'agent, comme read, search et task, par un pont en boucle locale.

Dans l'exemple du README, l'agent charge un CSV avec tool.read depuis Python, puis le trace depuis JavaScript, sans jamais quitter la cellule. L'intérêt est net. Les données intermédiaires restent dans le noyau. Elles n'ont pas à repasser par le contexte du modèle à chaque étape. Pour les gros fichiers et les analyses en plusieurs étapes, on économise du contexte et on se rapproche du travail d'une personne dans un notebook. Le risque se trouve au même endroit. L'exécution de code avec rappels d'outils élargit la surface d'attaque. Une entreprise doit donc examiner les limites de permissions avant un large déploiement.

Installation et écosystème

Les options d'installation sont nombreuses : un script curl pour macOS et Linux, Homebrew, une installation globale avec Bun (indiquée comme recommandée), Nix, PowerShell sous Windows, et des versions épinglées via mise. Les utilisateurs de Nix disposent d'un flake avec packages, overlays, nixosModules et homeManagerModules. Une configuration Home Manager peut installer omp et gérer ses réglages de façon déclarative, par exemple `settings.startup.quiet = true`. Sous Alpine, il faut d'abord installer libstdc++ et libgcc, car le binaire musl précompilé les lie dynamiquement.

omp génère lui-même ses complétions pour bash, zsh et fish à partir des métadonnées vivantes des commandes et des options, ce qui évite toute dérive par rapport au vrai CLI. Les noms de modèles pour `--model`, `--smol`, `--slow` et `--plan` se complètent depuis le catalogue de modèles inclus. `--resume` se complète depuis les sessions présentes sur le disque. Les noms des options laissent penser qu'omp peut employer des modèles différents selon l'étape d'une tâche, mais les règles exactes sont à vérifier dans la documentation officielle.

Impact pour les développeurs et les entreprises

Pour un développeur individuel, l'attrait est un outil qui fonctionne tout de suite et reste ouvert jusqu'au bout. Avec plus de 60 fournisseurs, changer de modèle coûte peu. Le réglage par modèle compte surtout pour les équipes qui mélangent plusieurs éditeurs.

Pour une entreprise, la prise en charge de Nix et de Home Manager et l'installation à version épinglée aident à gérer des environnements reproductibles. L'intégration de LSP et de DAP permet à l'agent de réutiliser la configuration de services de langage que l'équipe possède déjà.

Limites et perspectives

Premièrement, la plupart des chiffres de performance sont auto-déclarés et n'ont pas été reproduits par des tiers. Deuxièmement, 31 outils, deux noyaux de code, LSP et DAP forment une grande surface : le coût d'apprentissage et celui de la revue de sécurité sont réels. Troisièmement, en tant que fork de Pi, omp doit suivre l'amont, ce qui représente une charge de maintenance durable. Quatrièmement, la politique de pull requests est encore à l'essai et la gouvernance de la communauté peut évoluer.

Les pistes probables sont davantage de réglages par modèle, un débogage plus poussé et un contrôle des permissions plus strict. Notre conseil est pratique. Lisez d'abord « The Harness Problem ». Lancez ensuite omp sur votre propre code avec les modèles que vous utilisez déjà, et mettez les pourcentages à l'épreuve de vos propres tâches.