Ponytail : faire coder un agent IA avec moins de code

Ce qu’est Ponytail

Ponytail est un ensemble de règles qui demande à un agent de code utilisant l’IA d’é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 la salle. 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 ne s’y exécute. Il s’agit de texte ajouté aux instructions de l’agent, fourni sous forme de skill pour les hôtes qui chargent des skills et sous forme de simples fichiers de règles pour les hôtes qui ne le font pas.

Le dépôt est DietrichGebert/ponytail. Il a été créé le 12 June 2026 et a dépassé 90,000 stars au 1 August 2026. La dernière release taguée au 1 August 2026 est v4.8.4, publiée le 29 June 2026, et la page des releases recense dix tags entre le 14 et le 29 June uniquement. Un projet qui évolue à ce rythme aura changé lorsque vous lirez ce texte. Épinglez donc un tag avant de construire quoi que ce soit dessus.

L’idée avant l’outil : s’arrêter au premier niveau 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 niveau 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, 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 bibliothèque standard peut-elle s’en charger ? Utilisez-la.
4. Une fonctionnalité native de la plateforme couvre-t-elle le besoin ? Utilisez-la.
5. Une dependency déjà installée peut-elle résoudre le problème ? Utilisez-la.
6. Est-il possible de tenir sur une ligne ? Faites-le tenir sur une ligne.
7. Seulement ensuite, écrivez le minimum de code fonctionnel.

C’est l’ordre qui produit le résultat, et non un niveau particulier. Si vous demandez à un agent d’ajouter un sélecteur de date, il écrira un sélecteur de date, puisque c’est ce qu’on lui a demandé. L’échelle l’oblige d’abord à vérifier le niveau 4, qui indique que le navigateur fournit déjà <input type="date">. Les notes de benchmark du projet décrivent exactement ce cas : un sélecteur de date comptait 404 lignes sans cette règle, contre 23 lignes avec celle-ci, car l’agent a utilisé l’input natif au lieu de créer un composant. Un sélecteur de couleur est passé de 287 lignes à 23 pour la même raison. Le niveau 2 est celui qui échoue discrètement : si un agent ne voit pas le helper que vous avez déjà, il en écrira volontiers un second. C’est précisément l’écart que une cartographie interrogeable de votre codebase doit combler.

Ici, être paresseux ne signifie pas être négligent, et le ruleset le précise directement. Sa liste « ne jamais être paresseux concernant » 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 évite les pertes de données, la sécurité, l’accessibilité et tout ce que vous avez demandé explicitement. Elle demande également un petit contrôle 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 fournit 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 pouvant prendre la valeur lite, full ou ultra.
• Les fichiers de règles dans des répertoires propres à l’é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é détermine la force avec laquelle la règle s’applique. lite construit ce que vous avez demandé et indique en une ligne une option moins stricte. full est la valeur par défaut et impose la progression. ultra correspond au réglage YAGNI le plus radical : il privilégie la suppression à l’ajout et remet même l’exigence en question.

Les hôtes compatibles avec les skills disposent également de commandes slash. /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 la fiche de score du benchmark. Les hôtes qui lisent uniquement les fichiers de règles obtiennent 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

Dans Claude Code, le projet documente plutôt l’installation d’un 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 d’une session à l’autre. C’est le compromis accepté en échange de la commodité d’une commande de mise à jour.

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

Le diff produit par un agent ne disparaît pas de la conversation. Au tour suivant, le modèle le relit comme 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, et pas seulement sur celui qui l’a générée. 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 de la propre sortie de l’agent, et il reste moins de place pour votre code. Le sujet de la gestion de la fenêtre de contexte d’un agent de programmation consiste entièrement à garder ce volume sous contrôle.

Les tokens sont facturés à l’entrée et à la sortie. Un diff deux fois plus court coûte donc deux fois moins cher : une première fois lorsqu’il est écrit, puis à chaque tour où il est relu. La réduction apparaît ou non sur votre facture selon votre mode de paiement. Un abonnement Pro ou Max forfaitaire absorbe les tokens supplémentaires, tandis que la facturation API au token vous facture chacun d’eux. Si vous surveillez la facture d’une installation auto-hébergée, le fichier d’instructions est un levier qui ne coûte rien à actionner. Maîtriser le coût d’un agent IA commence par le volume de sortie, et la manière dont un agent de programmation dépense ses tokens explique pourquoi la relecture compte davantage qu’on ne le pense.

Un humain doit toujours lire le diff. Une modification de 400 lignes qui aurait dû en compter 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 surenchère 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 s’exécute souvent sans surveillance. Un agent qui travaille dans une session tmux ou selon 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 faire fonctionner 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. Elle s’applique également à la deuxième session que vous démarrez sur la même machine. Cette session lit le fichier commité, mais n’hérite de rien de ce que vous avez saisi dans la première, même lorsque les deux sessions peuvent s’envoyer des messages.

Les nouvelles dépendances représentent un autre coût discret. Le niveau 5 indique d’utiliser ce qui est installé. Chaque package ajouté de sa propre initiative par un agent est un élément que vous devrez mettre à jour plus tard et qui finira dans chaque image de conteneur construite à partir de ce repository.

Ce que montrent les propres chiffres de benchmark de Ponytail

Le projet publie deux séries de résultats, qui présentent un écart important. Ces deux séries proviennent des chiffres publiés par le projet lui-même. Aucune ne correspond à 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 seul qui répond à un petit ensemble de prompts, avec et sans la règle. Les résultats sont calculés comme des médianes sur des exécutions répétées les 13 et 17 June 2026. La colonne « agentic » provient d’une session Claude Code headless qui modifie le full-stack-fastapi-template de tiangolo, un dépôt FastAPI et React réel, 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 correspond à 54 pour cent de lignes de code en moins, à un coût inférieur de 20 pour cent et à un temps d’exécution inférieur de 27 pour cent, contre 93 pour cent et 74 pour cent 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 seul qui « répond avec plusieurs options et des commentaires », ce qui est facile à battre. Avec une mesure effectuée sur un agent réel qui réalise un travail réel, le gain diminue. Il reste toutefois réel, ce qui est le fait le plus utile.

Le projet fournit lui-même une réserve, et c’est elle qui détermine si cette approche vous sera utile. L’économie est maximale lorsqu’il existe un véritable risque de surdéveloppement, et presque nulle lorsque le code était déjà minimal. Douze tickets dans un même dépôt Python et TypeScript ne permettent pas de prédire les résultats 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 utiliser dès aujourd’hui sans rien installer

Cette échelle est du texte. Vous n’avez donc pas besoin du plugin pour utiliser cette 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 comportant le nom de l’outil :

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

Ce commentaire demande deux lignes de travail et tranche une question qui coûterait sinon un cycle de revue. Il indique au prochain lecteur que la version simple était un choix délibéré et précise dans quelles conditions ce choix cesse d’être valable. Sans ce commentaire, 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 compte autant 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 au cœur de la rédaction d’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 votre historique 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. Il est donc utile de comprendre 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 précisément.

Quand la règle cesse d’être pertinente

La méthode est conçue pour ajouter des fonctionnalités dans une base de code existante, où la réutilisation est généralement possible et généralement correcte. Elle convient mal à un projet greenfield, car le niveau 2 n’a rien à réutiliser et le niveau 5 n’a rien d’installé : l’agent passe donc au niveau 7 à chaque fois. Elle convient aussi mal lorsque vous souhaitez réellement introduire une abstraction. Si vous êtes sur le point d’ajouter le quatrième appelant du même bloc copié, « shortest diff » 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 vous avez déjà pris la décision et que vous voulez que le travail soit effectué. Utilisez full pour les tâches courantes et utilisez ultra lorsque vous pensez 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, ce qui constitue 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, qui est maintenant une petite mauvaise correction facile à approuver.

En résumé, Ponytail est un prompt soigneusement rédigé, correctement distribué et accompagné de chiffres. Rien dans celui-ci ne nécessite 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, avec la méthode publiée à côté du résultat.

FAQ

Ponytail fonctionne-t-il avec d’autres agents 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 permanent du répertoire de règles correspondant et ne disposent d’aucune slash command. Le texte est identique dans les deux cas. La différence réelle tient 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 peut-il ignorer les tests, la validation ou la sécurité ?

Non, et le ruleset l’indique 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 une vérification exécutable et de petite taille 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 l’installation, la cause est une autre instruction de votre propre configuration qui a priorité sur celle-ci. Lisez donc le dernier fichier chargé par l’agent.

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 comparent les résultats à un modèle nu qui répond avec des options et des commentaires. Le README indique lui-même qu’il s’agit d’une référence faible. Les chiffres agentiques proviennent d’une session Claude Code headless sur un dépôt FastAPI et React, avec douze tickets et quatre exécutions par ticket, avec Haiku 4.5. Ces chiffres sont fiables pour cette configuration. Ils ne constituent pas une prévision pour votre base de code, car le projet indique également que l’économie tombe presque à zéro pour du code déjà minimal.

Dois-je installer quelque chose pour bénéficier de ces effets ?

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

Comment empêcher un agent sans surveillance de trop construire pendant la nuit ?

Placez la règle dans le fichier d’instructions permanent 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 contenu à lire. Elle ne décide pas ce qui est intégré, et elle ne doit pas le faire.