Ponytail : réduire le code écrit par votre agent IA

Ce qu’est Ponytail

Ponytail est un ensemble de règles qui incite un agent de développement assisté par IA à écrire moins de code. Le projet se décrit en une phrase : « Fait réfléchir votre agent IA 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 ne possède aucun runtime et rien n’y est exécuté. Il s’agit de texte ajouté aux instructions de l’agent, empaqueté sous forme de skill pour les hôtes qui chargent des skills et sous forme de fichiers de règles pour ceux 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. Le 1er août 2026, la dernière release taguée était v4.8.4, publiée le 29 juin 2026, et la page des releases listait dix tags entre le 14 et le 29 juin inclus. Le rythme ne ralentit pas : le 17 octobre 2026, la dernière release est v5.3.2, publiée tard le 16 octobre, la troisième release de cette journée après v5.3.0 et v5.3.1. Avant cela, v5.2.0 était arrivée le 13 octobre, cinq jours après la publication simultanée de v5.0.0 et v5.1.0 le 8 octobre, et le dépôt affiche plus de 165,000 stars. 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 convient

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 convient.

1. Est-ce nécessaire ? C’est le principe YAGNI (you are not going to need it). Si la réponse est non, ignorez-le.
2. Cela existe-t-il déjà dans cette base de code ? Réutilisez l’aide ou le modèle déjà présent.
3. La bibliothèque standard sait-elle le faire ? Utilisez-la.
4. Une fonctionnalité native de la plate-forme suffit-elle ? Utilisez-la.
5. Une dépendance déjà installée répond-elle au besoin ? Utilisez-la.
6. Cela peut-il tenir sur une ligne ? Faites-en une seule ligne.
7. Ce n’est qu’ensuite qu’il faut écrire le minimum de code fonctionnel.

C’est l’échelle telle qu’elle est définie dans v4.8.4, et les numéros des échelons utilisés dans la suite de cet article suivent cette définition. La branche main actuelle regroupe les échelons 3 et 4 en un seul : « Bibliothèque standard ou fonctionnalité de la plate-forme ? Utilisez-la, sauf si le projet dispose de sa propre solution », et ajoute que « le composant interne du projet passe avant le widget natif », ce qui donne six échelons. L’ordre reste le même.

C’est l’ordre qui produit le résultat, et non un échelon particulier. Si vous demandez à un agent d’écrire un sélecteur de date, il en écrira un, puisque c’est ce que vous lui avez demandé. L’échelle l’oblige à vérifier ce qui existe déjà avant de construire quoi que ce soit : l’échelon 2 demande si le dépôt contient déjà un composant adapté, et l’échelon 4 indique que le navigateur fournit déjà <input type="date">. Les notes du benchmark actuel du projet décrivent précisément ce cas : un sélecteur de date qui comptait 335 lignes sans cette règle n’en compte plus que 10 avec Ponytail 5, car l’agent a réutilisé le composant Input propre au dépôt avec type="date" et a laissé le navigateur fournir le calendrier. Un sélecteur de couleur est passé de 135 lignes à 26. L’échelon 2 est celui qui échoue discrètement, car un agent qui ne voit pas l’aide déjà disponible écrira volontiers une seconde version. C’est précisément la lacune que une carte interrogeable de votre base de code doit combler.

Ici, « paresseux » ne signifie pas négligent, et le jeu de règles le précise directement. Sa liste des points pour lesquels il ne faut « jamais être paresseux » couvre la compréhension du problème avant toute décision, la validation des entrées aux limites de confiance, la gestion des erreurs qui empêche les pertes de données, la sécurité, l’accessibilité et tout ce que vous avez demandé explicitement. Elle demande également une petite vérification exécutable pour chaque élément de logique non trivial. La règle limite les inventions. Elle ne compromet pas la correction.

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

• AGENTS.md, l’ensemble de règles toujours actif, qui résume toute l’idée dans un fichier lisible en cinq minutes.
• skills/ponytail/SKILL.md, la définition du skill, avec un argument hint de lite, full, ultra ou off.
• Des fichiers de règles dans des répertoires propres à certains éditeurs, tels que .cursor/rules/ et .windsurf/rules/, pour les hôtes qui lisent les règles sans charger 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 paresseuse. full est le réglage par défaut et impose la progression. ultra est le réglage YAGNI maximal : il préfère supprimer plutôt qu’ajouter et remet en question l’exigence elle-même.

Les hôtes compatibles avec les skills proposent également des slash commands. /ponytail définit le niveau, /ponytail-review vérifie qu’un diff n’est pas surconçu, /ponytail-audit vérifie un dépôt entier, /ponytail-debt rassemble les raccourcis que vous avez reportés et /ponytail-gain affiche le tableau de résultats du benchmark. Les hôtes qui lisent uniquement les fichiers de règles obtiennent l’ensemble de règles sans commandes. Depuis v5.3.0, publiée le 16 octobre 2026, Claude Code affiche également une barre au-dessus du prompt avec le coût de la tâche, la réutilisation du code et l’état des tests. Cette fonction nécessite Claude Code 2.1.290 ou une version ultérieure. Elle n’apparaît pas dans le panneau de chat de VS Code, les sessions cloud ou claude -p, et /ponytail band off la masque. Depuis v5.3.2, /ponytail band import lit une fois vos anciennes sessions Claude Code et les ajoute au tableau avec leur coût, le temps d’exécution de l’agent et le nombre de tokens. Vous pouvez ainsi les comparer aux sessions exécutées avec la règle.

Pour lire le code source avant de lui faire confiance, clonez le tag plutôt que la branche. Il s’agit du tag utilisé pour la progression présentée plus haut. Remplacez-le par v5.3.2, le dernier tag au 17 octobre 2026, pour lire le texte actuel :

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

Dans Claude Code, le projet documente plutôt l’installation d’un plugin. Ces deux lignes correspondent à la documentation du 17 octobre 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 d’une session à l’autre. C’est le compromis que vous acceptez en échange de la simplicité d’une commande de mise à jour.

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

Le diff généré par un agent ne quitte pas la conversation. Au tour suivant, le modèle le relit dans son 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, jusqu’à ce que la compaction remplace les anciens tours par un résumé, et pas seulement sur le tour qui l’a produite. C’est pourquoi un refactoring 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 avec les propres sorties de l’agent, et il reste donc moins de place pour votre code. La gestion de ce point est tout le sujet de la gestion de la fenêtre de contexte d’un agent de programmation.

Les tokens sont facturés à l’entrée comme à la sortie. Un diff deux fois moins volumineux coûte donc deux fois moins cher : une fois lors de sa génération, puis à chaque tour où il est relu. L’impact sur votre facture dépend de votre mode de paiement, car un abonnement Pro ou Max absorbe les tokens supplémentaires jusqu’à ses limites d’utilisation. Au-delà, les crédits d’utilisation activés volontairement sont facturés séparément. Avec une facturation API au token, chaque token est facturé. Si vous surveillez les coûts sur une installation auto-hébergée, le fichier d’instructions est un levier gratuit. 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 compte davantage qu’on ne le pense.

Un humain doit toujours relire le diff. Une modification de 400 lignes qui aurait dû en faire 20 mobilise l’attention de la personne chargée de la revue, 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 seulement perdre du temps. Elle réduit discrètement la qualité de la revue censée détecter les erreurs.

Sur un serveur, les enjeux sont différents, car l’agent fonctionne souvent sans personne pour le surveiller. Un agent exécuté dans une session tmux ou par un timer dispose de plusieurs heures pour aggraver une mauvaise décision avant que vous ne la découvriez. C’est le risque concret de l’exécution d’un agent de programmation sur un VPS. C’est aussi pourquoi les personnes qui pratiquent l’ingénierie en boucle accordent autant d’importance 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. Elle s’applique également à la deuxième session lancée sur le même serveur : celle-ci lit le fichier versionné, mais n’hérite d’aucune instruction saisie dans la première, même lorsque les deux sessions peuvent s’envoyer des messages.

Les nouvelles dépendances constituent l’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 devra être mis à jour ultérieurement et se retrouvera dans chaque image de conteneur construite à partir de ce dépôt.

Ce que disent les propres chiffres de référence de Ponytail

Le projet a publié deux types de résultats, qui diffèrent fortement. Ces deux chiffres proviennent des résultats publiés par le projet lui-même. Aucun ne correspond à un test indépendant.

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

Le graphique présente le benchmark agentique actuel du projet, daté du 7 October 2026. Des sessions Claude Code 2.1.288 sans interface, exécutées avec Opus 5.5 et l’effort par défaut, ont traité 39 tâches, avec cinq exécutions par tâche et par configuration, soit 585 sessions au total pour aucune skill, Ponytail v4.13.0 et Ponytail 5. Douze tâches sont des tickets fonctionnels dans le dépôt full-stack-fastapi-template de tiangolo, un véritable dépôt FastAPI et React, évalués à partir du git diff laissé sur place. Le reste comprend 18 tâches chirurgicales avec des vérifications masquées, six demandes de petites applications et trois demandes « montrez-moi un exemple ». Bash était désactivé pour toutes les configurations. Les tokens de sortie ont diminué de 45 pour cent avec Ponytail 5.

Comparez ce résultat aux chiffres obtenus en une seule passe que le projet a publiés en June 2026. Ils provenaient d’un modèle nu répondant à cinq demandes courantes, avec et sans la règle, et étaient présentés comme des médianes sur des exécutions répétées. Ils indiquaient 80 à 94 pour cent de code en moins avec Haiku, Sonnet et Opus. La vérification du coût datée du 17 June 2026 indiquait également une baisse de 63 pour cent avec Haiku. Le résultat agentique actuel de Ponytail 5 est de 53 pour cent de lignes de code en moins, de 26 pour cent de coût en moins et de 41 pour cent de temps d’exécution en moins. Le projet a rapidement corrigé le chiffre obtenu en une seule passe. Dès v4.8.4, le 29 June 2026, le README mettait déjà en avant le résultat agentique, « ~54% less code (up to 94%) », avec une note précisant que les 80 à 94 pour cent précédents correspondaient au « plafond par tâche, pas à la moyenne ». Les chiffres obtenus en une seule passe avaient été déplacés dans une section repliée intitulée « Older single-shot numbers ». Cette section expliquait clairement l’origine de l’écart : la référence en une seule passe est un modèle nu qui « pads its answer with prose and options », ce qui est facile à dépasser. Si vous mesurez le résultat avec un véritable agent effectuant un véritable travail, le gain diminue. Il reste toutefois réel, ce qui est le fait le plus utile. Cette exécution agentique de June, portant sur douze tickets avec Haiku 4.5 et quatre exécutions par ticket, était proche du chiffre actuel, avec 54 pour cent de lignes en moins. Le README actuel ne contient plus les chiffres obtenus en une seule passe.

Le projet fournit lui-même une réserve, et c’est elle qui détermine si cette approche vous aidera. L’économie est maximale lorsqu’il existe un véritable risque de surconception, et presque nulle lorsque le code était déjà minimal. Le tableau par tâche d’octobre le confirme : plusieurs tâches chirurgicales aboutissent au même nombre de lignes dans les trois configurations. Trente-neuf tâches, sur un seul modèle et un seul hôte, avec Bash désactivé, ne permettent pas de prédire le comportement dans votre dépôt. Si ce chiffre compte 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 reprendre dès aujourd’hui sans rien installer

Cette échelle 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. Dans ses versions actuelles, la convention de Ponytail consiste à utiliser un commentaire marqué shortcut:, qui indique la limite et le moment où il faut passer à la version suivante (les versions de juin, dont v4.8.4, utilisaient plutôt le marqueur ponytail:) :

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

Ce commentaire demande deux lignes de travail et règle une question qui coûterait autrement un cycle de revue. Il indique au lecteur suivant que la version simple était un choix, et précise dans quel cas ce choix cesse d’être valable. Sans ce commentaire, un reviewer ne peut pas distinguer un raccourci réfléchi d’un élément oublié par l’agent. Il doit donc poser la question.

L’emplacement du bloc compte autant que son contenu. Un fichier chargé par l’agent à chaque exécution influence toutes les exécutions, y compris celles que vous ne surveillez pas. Cette différence est le sujet de la rédaction d’un AGENTS.md que votre agent respecte réellement, et c’est pourquoi ce modèle doit figurer dans un fichier versionné plutôt que dans l’historique de votre shell. Dans un monorepo, il doit figurer dans plusieurs fichiers versionnés, car un AGENTS.md par package permet de conserver des règles courtes pour chaque répertoire au lieu d’obliger l’agent à lire les conventions de toute l’arborescence à chaque exécution. L’emplacement ne garantit toutefois rien, et il est utile de savoir pourquoi un agent ignore une règle qu’il a déjà chargée avant de conclure que l’échelle doit être formulée plus fermement.

Quand la règle cesse d’être pertinente

La grille est conçue pour intervenir dans une base de code existante, où la réutilisation est généralement possible et correcte. Elle convient moins bien à un projet greenfield, car le niveau 2 n’a rien à réutiliser et le niveau 5 ne dispose d’aucun élément installé. L’agent peut toujours s’arrêter au niveau 1, utiliser la standard library, une fonctionnalité de la plateforme ou une commande d’une seule ligne, mais deux des solutions les moins coûteuses disparaissent. Davantage de tâches débouchent donc sur l’écriture de nouveau code. La grille convient également mal lorsque vous souhaitez réellement introduire l’abstraction. Si vous êtes sur le point d’ajouter le quatrième appelant du même bloc copié, « diff le plus court » vous donne une cinquième copie.

Le niveau ultra remettra vos exigences en question. C’est précisément son rôle, et cela représente un coût réel lorsque votre décision est déjà prise et que vous voulez simplement faire réaliser le travail. Utilisez full pour les tâches courantes et choisissez ultra lorsque vous soupçonnez que la demande de fonctionnalité est le problème.

Aucun bloc d’instructions ne vous protège contre une mauvaise compréhension du problème. Le premier élément du ruleset consiste lui-même à comprendre le code avant de décider, ce qui 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 maintenant d’une petite mauvaise correction, facile à approuver.

En résumé, Ponytail est un prompt soigneusement rédigé, bien distribué et accompagné de chiffres. Rien ne vous oblige à utiliser le plugin. Ce que le projet vous apporte, c’est une liste correctement rédigée, testée sur un dépôt réel, ainsi qu’une 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 indiqué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 commandes slash. Le texte est identique dans les deux cas. La différence réelle tient donc au fait que votre hôte conserve ce texte dans le contexte à chaque tour ou seulement lorsqu’un skill est déclenché.

Un agent paresseux va-t-il ignorer les tests, la validation ou la sécurité ?

Non, et le ruleset le précise directement. Sa liste « ne jamais être paresseux sur » mentionne la validation des entrées aux limites de confiance, la gestion des erreurs qui évite les pertes 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 les tests après son installation, la cause est une autre instruction de votre propre configuration qui a priorité sur 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 ?

Ce sont les propres mesures du projet, publiées avec leur méthode. Il faut les interpréter comme telles. Les chiffres en exécution unique de juin 2026 comparaient le système à un modèle nu qui remplissait sa réponse de prose et d’options. Le README de l’époque signalait lui-même qu’il s’agissait d’une référence faible. Les chiffres agentiques actuels proviennent de sessions Claude Code sans interface sur Opus 5.5 : 39 tâches exécutées cinq fois chacune, dont douze tickets de fonctionnalités dans un même dépôt FastAPI et React. Ces chiffres sont fiables pour cette configuration. Ils ne constituent pas une prévision pour votre codebase, car les résultats du projet par tâche montrent que le gain devient presque nul sur du code déjà minimal.

Dois-je installer quelque chose pour en tirer parti ?

Non. La ladder est du texte, et 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 la formulation maintenue, les niveaux d’intensité, les commandes de revue et un mécanisme de mise à jour. Commencer par coller le bloc est la réponse de rung 1 à la question de savoir si l’installation est réellement nécessaire.

Comment empêcher un agent sans surveillance de trop développer 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 dégâts : donnez à l’agent un checkout qu’il peut détériorer au lieu de votre seule copie, et exigez une revue humaine du diff avant toute fusion. Une règle imposant un diff minimal réduit la quantité de code à lire. Elle ne décide pas de ce qui est intégré, et ne doit pas le faire.