Ponytail : faire coder une IA avec moins de code

Ce qu’est Ponytail

Ponytail est un ensemble de règles qui incite un agent de codage IA à écrire moins de code. Le projet se décrit en une phrase : « Incite votre agent IA à réfléchir comme le développeur senior le plus paresseux de l’équipe. Le meilleur code est celui que vous n’avez jamais écrit. » Il est distribué sous licence MIT. Il n’a pas de runtime propre et rien dans celui-ci ne s’exécute. Il s’agit de texte intégré aux instructions de l’agent, fourni sous forme de skill pour les hôtes qui chargent des skills et sous forme de fichiers de règles simples pour les hôtes qui ne le font pas.

Le dépôt est DietrichGebert/ponytail. Il a été créé le 12 juin 2026 et a dépassé 90,000 stars au 1er août 2026. La dernière release taguée au 1er août 2026 est v4.8.4, publiée le 29 juin 2026, et la page des releases répertorie dix tags entre le 14 et le 29 juin seulement. Un projet qui évolue à ce rythme aura changé au moment où vous lirez ceci. Épinglez donc un tag avant de construire quoi que ce soit dessus.

L’idée avant l’outil : s’arrêter au premier échelon qui tient

Le principe central de Ponytail est une échelle de décision. L’agent la parcourt avant d’écrire quoi que ce soit et s’arrête au premier échelon qui s’applique.

1. Cela doit-il vraiment exister ? C’est le principe YAGNI (vous n’en aurez pas besoin). Si la réponse est non, ne l’ajoutez pas.
2. Cela existe-t-il déjà dans cette codebase ? Réutilisez le helper ou le pattern déjà présent.
3. La standard library sait-elle le faire ? Utilisez-la.
4. Une fonctionnalité native de la plateforme couvre-t-elle ce besoin ? Utilisez-la.
5. Une dependency déjà installée permet-elle de résoudre le problème ? Utilisez-la.
6. Cela peut-il tenir sur une ligne ? Faites-en une seule ligne.
7. Écrivez seulement ensuite le minimum de code fonctionnel.

C’est l’ordre qui produit le résultat, et non un échelon particulier. Si vous demandez à un agent d’écrire un date picker, il en écrira un, parce que c’est ce que vous lui avez demandé. L’échelle l’oblige d’abord à vérifier l’échelon 4, qui indique que le navigateur dispose déjà de <input type="date">. Les notes de benchmark du projet décrivent précisément ce cas : un date picker qui comptait 404 lignes sans cette règle n’en comptait plus que 23 avec elle, car l’agent avait utilisé l’input natif au lieu de créer un component. Un colour picker est passé de 287 lignes à 23 pour la même raison.

Ici, être lazy ne signifie pas être négligent, et le ruleset le précise directement. Sa liste « ne soyez jamais lazy pour » couvre la compréhension du problème avant toute décision, la validation des entrées aux trust boundaries, la gestion des erreurs qui empêche les pertes de données, la sécurité, l’accessibilité et tout ce que vous avez explicitement demandé. Elle demande également un petit check exécutable pour chaque élément de logique non trivial. Cette règle limite les inventions. Elle ne compromet pas la correction.

Ce que le dépôt contient réellement

• AGENTS.md, le ruleset toujours actif, qui résume toute l’idée dans un seul fichier lisible en cinq minutes.
• skills/ponytail/SKILL.md, la définition de la skill, avec un argument hint de lite, full ou ultra.
• Les fichiers de règles dans des répertoires propres à chaque éditeur, comme .cursor/rules/ et .windsurf/rules/, pour les hôtes qui lisent les règles mais ne chargent pas les skills.
• hooks/, benchmarks/, examples/ et scripts/.

L’argument d’intensité modifie la force avec laquelle la règle s’applique. lite construit ce que vous avez demandé et indique en une ligne une option plus permissive. full est la valeur par défaut et impose la progression. ultra correspond au réglage YAGNI le plus strict : il préfère supprimer plutôt qu’ajouter et remet même l’exigence en question.

Les hôtes compatibles avec les skills disposent également de slash commands. /ponytail définit le niveau, /ponytail-review vérifie qu’un diff ne contient pas de sur-ingénierie, /ponytail-audit vérifie un dépôt entier, /ponytail-debt collecte les raccourcis que vous avez reportés et /ponytail-gain affiche le scorecard de benchmark. Les hôtes qui lisent uniquement les fichiers de règles reçoivent le ruleset sans les commandes.

Pour lire le code source avant de lui faire confiance, clonez le tag plutôt que la branche :

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

Sur Claude Code, le projet documente plutôt une installation de plugin. Ces deux lignes correspondent à la documentation au 1 août 2026 :

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Le chemin du plugin suit la branche par défaut plutôt qu’un tag. Les instructions qui pilotent votre agent peuvent donc changer entre deux sessions. C’est le compromis lié à la commodité d’une commande de mise à jour.

Pourquoi un agent peu actif coûte moins cher sur un VPS

Le diff produit par un agent ne quitte pas la conversation. Au tour suivant, le modèle le relit dans le contexte, avec chaque fichier qu’il a ouvert pour le produire. Une modification de 500 lignes pèse donc sur tous les tours suivants de la session, pas seulement sur celui qui l’a produite. C’est pourquoi une refactorisation qui s’emballe donne l’impression que l’agent devient plus lent et moins pertinent au fil de la session : la fenêtre se remplit de la propre sortie de l’agent, et l’espace restant pour votre code réel diminue. La gestion de ce point constitue tout le sujet de la gestion de la fenêtre de contexte d’un agent de programmation.

Les tokens sont facturés en entrée et en sortie. Un diff deux fois plus petit coûte donc deux fois moins cher : une fois lors de sa production, puis à chaque tour où il est relu. Si vous surveillez la facture sur une installation auto-hébergée, le fichier d’instructions est un levier qui ne coûte rien à utiliser. La maîtrise du coût d’un agent IA commence par le volume de sortie, et la façon dont un agent de programmation dépense ses tokens explique pourquoi la relecture coûte plus que prévu.

Un humain doit toujours lire le diff. Une modification de 400 lignes qui aurait dû en compter 20 mobilise l’attention du reviewer, et l’attention est la ressource qui s’épuise en premier. Personne ne relit le quatrième long diff de la journée avec le même soin que le premier. La surconception ne fait donc pas que faire perdre du temps. Elle réduit discrètement la qualité de la revue censée détecter les erreurs.

Sur un serveur, les enjeux changent, car l’agent s’exécute souvent sans surveillance. Un agent qui travaille dans une session tmux ou sur un timer dispose de plusieurs heures pour aggraver une mauvaise décision avant que vous ne la découvriez. C’est le risque concret décrit dans l’exécution d’un agent de programmation sur un VPS, et c’est pourquoi les personnes qui pratiquent l’ingénierie en boucle consacrent autant d’attention aux instructions permanentes plutôt qu’aux prompts individuels. Une règle du fichier toujours actif s’applique au tour 200. Une règle saisie dans le chat s’applique au tour 3.

Les nouvelles dépendances représentent un autre coût discret. La règle 5 recommande d’utiliser ce qui est installé. Chaque package ajouté de sa propre initiative par un agent est un élément que vous devrez ensuite mettre à jour et qui se retrouvera dans chaque image de container construite à partir de ce repository.

Ce que disent les propres chiffres de benchmark de Ponytail

Le projet publie deux séries de résultats, qui diffèrent largement. Ces deux séries correspondent aux chiffres publiés par le projet. Aucune ne provient d’un test indépendant.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

La colonne « single shot » provient d’un modèle brut qui répond à un petit ensemble de prompts, avec et sans la règle. Les valeurs sont calculées comme médianes sur des exécutions répétées les 13 et 17 juin 2026. La colonne « agentic » provient d’une session headless de Claude Code qui modifie le full-stack-fastapi-template de tiangolo, un véritable dépôt FastAPI et React, pour douze tickets de fonctionnalités, avec quatre exécutions par ticket sur Haiku 4.5. L’évaluation porte sur le git diff laissé par la session.

Consultez la deuxième colonne. Le résultat agentic produit 54 % de lignes de code en moins, coûte 20 % de moins et nécessite 27 % de temps réel en moins, contre 93 % et 74 % pour les mêmes mesures dans la configuration single shot. Le README explique honnêtement pourquoi : la référence single shot est un modèle brut qui « répond avec plusieurs options et des commentaires », ce qui est facile à dépasser. Avec un véritable agent qui effectue un vrai travail, le gain diminue. Il reste toutefois réel, ce qui est le fait le plus utile.

Le projet signale lui-même une réserve, et c’est elle qui détermine si cette méthode vous aidera. L’économie est maximale lorsqu’il existe un véritable risque de sur-implémentation, et presque nulle lorsque le code était déjà minimal. Douze tickets dans un seul dépôt Python et TypeScript ne permettent pas de prédire les résultats dans votre dépôt. Si ce chiffre est important pour vous, exécutez la comparaison sur vos propres tickets, avec et sans la règle, puis comptez vous-même les lignes.

Le modèle que vous pouvez copier aujourd’hui sans rien installer

La règle est du texte. Vous n’avez donc pas besoin du plugin pour utiliser l’idée. Collez un bloc comme celui-ci dans le fichier d’instructions que votre agent lit déjà, qu’il s’agisse de AGENTS.md, de CLAUDE.md ou du fichier de règles de votre éditeur.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

Cette dernière règle mérite d’être examinée séparément. La convention de Ponytail consiste à utiliser un commentaire associé au nom de l’outil :

# ponytail: global lock, per-account locks if throughput matters

Ce commentaire représente deux lignes de travail et règle une question qui coûterait autrement un cycle de review. Il indique au prochain lecteur que la version simple était un choix et précise dans quelles conditions ce choix cesse de s’appliquer. Sans lui, un reviewer ne peut pas distinguer un raccourci réfléchi d’un oubli de l’agent. Il doit donc poser la question.

L’emplacement du bloc est aussi important que son contenu. Un fichier que l’agent charge à chaque exécution influence chaque exécution, y compris celles que vous ne surveillez pas. Cette différence est le sujet de écrire un AGENTS.md que votre agent suit réellement, et c’est pourquoi ce modèle doit figurer dans un fichier versionné plutôt que dans l’historique de votre shell.

Là où la règle cesse d'être pertinente

Cette échelle est conçue pour les évolutions fonctionnelles dans une base de code existante, où la réutilisation est généralement possible et correcte. Elle convient mal à un projet greenfield, car le niveau 2 n'a rien à réutiliser et le niveau 5 ne dispose de rien d'installé. L'agent passe donc systématiquement au niveau 7. Elle convient également mal au moment où vous avez réellement besoin de l'abstraction. Si vous êtes sur le point d'ajouter le quatrième appelant du même bloc copié, « plus petit diff » vous donne une cinquième copie.

Le niveau ultra remettra vos exigences en question. C'est précisément le rôle de ce niveau, et son coût est réel lorsque vous avez déjà pris la décision et que vous voulez que le travail soit effectué. Utilisez full pour le travail courant et choisissez ultra lorsque vous soupçonnez que la demande de fonctionnalité est le problème.

Aucun bloc d'instructions ne vous protège d'une mauvaise compréhension du problème. Le premier élément du ruleset consiste lui-même à comprendre le code avant de décider. C'est la partie coûteuse, et celle que le texte ne peut pas faire à votre place. Un diff minimal dans la mauvaise fonction reste une mauvaise correction. Il s'agit désormais d'une petite mauvaise correction, facile à approuver.

La synthèse honnête est que Ponytail est un prompt soigneusement rédigé, bien distribué, avec des chiffres associés. Rien ne nécessite le plugin. Ce que fournit le projet, c'est une liste correctement rédigée, testée sur un dépôt réel, avec la méthode publiée à côté du résultat.

FAQ

Ponytail fonctionne-t-il avec des agents autres que Claude Code ?

Oui. Il est fourni sous forme de skill pour les hôtes qui chargent des skills, notamment Claude Code, Codex, OpenCode, Gemini et plusieurs autres cités dans le README. Les éditeurs qui lisent des fichiers de règles sans charger de skills, comme Cursor, Windsurf, Cline et Copilot, utilisent le ruleset toujours actif du répertoire de règles correspondant et n’ont pas de slash commands. Le texte est identique dans les deux cas. La différence réelle est de savoir si votre hôte conserve ce texte dans le contexte à chaque tour ou uniquement lorsqu’un skill est déclenché.

Un agent lazy peut-il ignorer les tests, la validation ou la sécurité ?

Non, et le ruleset l’indique explicitement. Sa liste des éléments pour lesquels il ne faut « jamais être lazy » cite la validation des entrées aux trust boundaries, la gestion des erreurs qui empêche la perte de données, la sécurité et l’accessibilité. Elle demande aussi un petit contrôle exécutable pour chaque élément de logique non trivial. La règle supprime les structures inventées : les abstractions que personne n’a demandées et les dépendances dont personne n’a besoin. Si votre agent commence à supprimer des tests après l’installation, une autre instruction de votre propre configuration passe avant celle-ci. Lisez donc le fichier que l’agent charge en dernier.

Les chiffres publiés sur la vitesse et le coût sont-ils fiables ?

Il s’agit des propres mesures du projet, publiées avec leur méthode. Il faut les interpréter comme telles. Les chiffres single shot sont comparés à un modèle nu qui répond avec des options et des commentaires, une référence que le README lui-même qualifie de faible. Les chiffres agentic proviennent d’une session Claude Code headless sur un dépôt FastAPI et React, avec douze tickets et quatre exécutions par ticket, sur Haiku 4.5. Ces chiffres sont valables pour cette configuration. Ils ne constituent pas une prévision pour votre codebase, car le projet indique également que l’économie devient presque nulle pour du code déjà minimal.

Dois-je installer quelque chose pour en tirer parti ?

Non. Le ladder est du texte. Un bloc équivalent collé dans le fichier d’instructions que votre agent lit déjà produit la majeure partie de l’effet. Le plugin fournit le texte maintenu, les niveaux d’intensité, les commandes de review et un mécanisme de mise à jour. Commencer par le bloc copié est la réponse du rung 1 à la question de savoir si l’installation est réellement nécessaire.

Comment empêcher un agent sans supervision de surdimensionner le travail pendant la nuit ?

Placez la règle dans le fichier d’instructions toujours actif plutôt que dans un message de chat. Elle s’appliquera ainsi au tour 200 d’une longue exécution, et pas seulement au tour 3. Limitez ensuite séparément les dommages : donnez à l’agent un checkout qu’il peut détériorer au lieu de votre seule copie, et exigez une review humaine du diff avant toute merge. Une règle de diff minimal réduit la quantité de code que vous devez lire. Elle ne décide pas de ce qui est intégré, et ne doit pas le faire.