Wat is Ponytail voor AI-codeeragenten?

Wat Ponytail is

Ponytail is een regelset die ervoor zorgt dat een AI-codeeragent minder code schrijft. Het project omschrijft zichzelf in één zin: "Zorgt dat uw AI-agent denkt als de meest luie senior ontwikkelaar in de ruimte. De beste code is de code die u nooit hebt geschreven." Het is uitgebracht onder de MIT-licentie. Het heeft geen eigen runtime en er wordt niets in uitgevoerd. Het is tekst die in de instructies van de agent wordt opgenomen, verpakt als een skill voor hosts die skills laden en als eenvoudige regelbestanden voor hosts die dat niet doen.

De repository is DietrichGebert/ponytail. Deze werd op 12 juni 2026 aangemaakt en passeerde op 1 augustus 2026 de 90.000 sterren. Op 1 augustus 2026 was de laatst getagde release v4.8.4, gepubliceerd op 29 juni 2026, en de releases-pagina vermeldde alleen al tussen 14 en 29 juni tien tags. Het tempo is niet afgenomen: op 17 oktober 2026 is de nieuwste release v5.3.2, gepubliceerd laat op 16 oktober, de derde release die dag na v5.3.0 en v5.3.1. Daarvoor kwam v5.2.0 op 13 oktober, vijf dagen nadat v5.0.0 en v5.1.0 beide op 8 oktober verschenen, en de repository toont meer dan 165.000 sterren. Een project dat in dit tempo beweegt, zal veranderd zijn tegen de tijd dat u dit leest; zet daarom een tag vast voordat u er iets op bouwt.

Het idee vóór de tool: stop bij de eerste trede die houdt

De kern van Ponytail is een beslissingsladder. De agent beklimt deze voordat hij iets schrijft en stopt bij de eerste trede die houdt.

1. Moet dit überhaupt bestaan? Dit is YAGNI (you are not going to need it). Als het antwoord nee is, sla het over.
2. Bestaat dit al in deze codebase? Hergebruik de helper of het patroon dat er al is.
3. Doet de standaardbibliotheek dit? Gebruik die.
4. Dekt een native platformfunctie dit af? Gebruik die.
5. Lost een reeds geïnstalleerde dependency dit op? Gebruik die.
6. Kan het één regel zijn? Maak er één regel van.
7. Schrijf pas daarna de minimale code die werkt.

Dat is de ladder zoals beschreven op v4.8.4, en de tredenummers in de rest van dit artikel volgen deze. De huidige main-branch voegt treden 3 en 4 samen tot één: "Standaardbibliotheek of een platformfunctie? Gebruik die, tenzij het project een eigen variant heeft", en voegt toe dat "een eigen component beter is dan een native widget", waardoor er zes treden overblijven. De volgorde is hetzelfde.

De volgorde doet het werk, niet een enkele trede. Een agent die wordt gevraagd om een date picker, zal een date picker schrijven, omdat hem is verteld dat hij er een moet schrijven. De ladder dwingt hem om te controleren wat er al bestaat voordat hij iets bouwt: trede 2 vraagt of de repository al een component hiervoor heeft, en trede 4 zegt dat de browser al over <input type="date"> beschikt. De huidige benchmark van het project noteert precies dit geval: een date picker die zonder de regel 335 regels code besloeg, kwam met Ponytail 5 uit op 10 regels, omdat de agent de eigen Input-component van de repository hergebruikte met type="date" en de browser de kalender liet leveren. Een kleurkiezer kromp minder, van 135 regels naar 26. Trede 2 is degene die geruisloos faalt, omdat een agent die de helper die u al heeft niet kan zien, vrolijk een tweede zal schrijven; dit is het gat dat een doorzoekbare kaart van uw codebase moet dichten.

Lui betekent hier niet slordig, en de regelset zegt dat direct. De lijst met zaken waar "nooit lui over gedaan mag worden" omvat het begrijpen van het probleem vóór de beslissing, invoervalidatie bij vertrouwensgrenzen, foutafhandeling die gegevensverlies voorkomt, beveiliging, toegankelijkheid en alles waar u specifiek om heeft gevraagd. Er wordt ook gevraagd om één kleine uitvoerbare controle per stuk niet-triviale logica. De regel beperkt uitvindingen. Hij beperkt niet de correctheid.

Wat de repository daadwerkelijk bevat

• AGENTS.md, de altijd actieve regelset; dit is het volledige concept in één bestand dat u in vijf minuten kunt lezen.
• skills/ponytail/SKILL.md, de definitie van de vaardigheid, met een argument-hint van lite, full, ultra of off.
• Regelbestanden in editor-specifieke mappen zoals .cursor/rules/ en .windsurf/rules/, voor hosts die regels inlezen maar geen vaardigheden laden.
• hooks/, benchmarks/, examples/ en scripts/.

Het intensiteitsargument bepaalt hoe strikt de regel wordt toegepast. lite bouwt wat u heeft gevraagd en benoemt in één regel een minder strikte optie. full is de standaardinstelling en dwingt de hiërarchie af. ultra is de YAGNI-extremistische instelling: deze geeft de voorkeur aan verwijderen boven toevoegen en zal de vereiste zelf ter discussie stellen.

Hosts die vaardigheden ondersteunen, krijgen ook slash-commando's. /ponytail stelt het niveau in, /ponytail-review controleert een diff op over-engineering, /ponytail-audit controleert een volledige repository, /ponytail-debt verzamelt de snelkoppelingen die u heeft uitgesteld en /ponytail-gain toont de benchmark-scorekaart. Hosts die alleen regelbestanden inlezen, krijgen de regelset zonder commando's. Sinds v5.3.0, uitgebracht op 16 oktober 2026, krijgt Claude Code ook een balk boven de prompt die de taakkosten, codehergebruik en teststatus toont. Dit vereist Claude Code 2.1.290 of nieuwer; het verschijnt niet in het VS Code-chatpaneel, cloud-sessies of claude -p, en /ponytail band off verbergt het. Sinds v5.3.2 leest /ponytail band import uw eerdere Claude Code-sessies één keer in en voegt deze toe aan het dashboard met hun kosten, agenttijd en tokens, zodat u ze kunt vergelijken met sessies die onder de regel zijn uitgevoerd.

Om de broncode te lezen voordat u deze vertrouwt, kloont u de tag in plaats van de branch. Dit is de tag waar de bovenstaande hiërarchie vandaan komt; vervang deze door v5.3.2, de nieuwste versie op 17 oktober 2026, om de huidige formulering te lezen:

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

Voor Claude Code documenteert het project in plaats daarvan een plugin-installatie, en deze twee regels zijn zoals gedocumenteerd op 17 oktober 2026:

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

Het plugin-pad volgt de standaard-branch in plaats van een tag, waardoor de instructies die uw agent aansturen tussen sessies kunnen veranderen. Dat is de afweging die u accepteert voor het gemak van een update-commando.

Waarom een 'lazy' agent goedkoper is op een VPS

Het diff dat een agent schrijft, verlaat het gesprek niet. Bij de volgende beurt is het context die het model opnieuw leest, samen met elk bestand dat het opende om het te produceren. Een wijziging van 500 regels belast daarom elke latere beurt in de sessie totdat compactie de oudere beurten vervangt door een samenvatting; dit geldt niet alleen voor de beurt die het produceerde. Dit is de reden waarom een uit de hand gelopen refactor ervoor zorgt dat een agent trager en dommer aanvoelt naarmate de sessie vordert: het venster raakt gevuld met de eigen output van de agent, waardoor de ruimte voor uw daadwerkelijke code krimpt. Dit onder controle houden is het volledige onderwerp van het beheren van het contextvenster van een coding agent.

Tokens worden zowel bij invoer als uitvoer in rekening gebracht, dus een diff dat de helft van de omvang heeft, is dubbel zo goedkoop: één keer wanneer het wordt geschreven en opnieuw bij elke beurt die het opnieuw inleest. Of die besparing zichtbaar is op uw factuur hangt af van hoe u betaalt, omdat een Pro- of Max-abonnement de extra tokens alleen opvangt tot aan de gebruikslimieten, waarna opt-in gebruikstegoeden afzonderlijk worden gefactureerd, terwijl API-facturering per token elk afzonderlijk token in rekening brengt. Als u de kosten op een self-hosted setup in de gaten houdt, is het instructiebestand een hefboom die niets kost om te gebruiken. Beheersen wat een AI-agent u kost begint bij het uitvoervolume, en hoe een coding agent zijn tokens besteedt legt uit waarom het opnieuw inlezen belangrijker is dan men verwacht.

Een mens leest het diff nog steeds. Een wijziging van 400 regels die 20 regels had moeten zijn, kost de aandacht van de reviewer, en aandacht is de bron die als eerste opraakt. Niemand beoordeelt het vierde lange diff van de dag met dezelfde zorg als het eerste, dus overmatig bouwen verspilt niet alleen tijd. Het verlaagt stilletjes de kwaliteit van de beoordeling die de fouten moet opvangen.

Op een server veranderen de belangen, omdat de agent vaak draait zonder dat iemand meekijkt. Een agent die in een tmux-sessie of op een timer werkt, heeft uren de tijd om voort te bouwen op een verkeerde beslissing voordat u deze ziet. Dat is het praktische risico bij het draaien van een coding agent op een VPS, en het is de reden waarom mensen die aan loop engineering doen, zoveel zorg besteden aan de permanente instructies in plaats van aan individuele prompts. Een regel in het altijd actieve bestand is van toepassing op beurt 200. Een regel die u in de chat typte, is van toepassing op beurt 3. Het is ook van toepassing op de tweede sessie die u op dezelfde machine start, die het gecommitteerde bestand leest maar niets erft van wat u in de eerste sessie typte, zelfs niet wanneer de twee sessies met elkaar kunnen communiceren.

Nieuwe dependencies zijn de andere stille kostenpost. Rung 5 zegt: gebruik wat is geïnstalleerd. Elk pakket dat een agent op eigen initiatief toevoegt, is iets dat u later moet patchen en iets dat uiteindelijk in elke container-image terechtkomt die u vanuit die repository bouwt.

Wat de eigen benchmarkcijfers van Ponytail zeggen

Het project heeft twee soorten resultaten gepubliceerd, en deze spreken elkaar aanzienlijk tegen. Beide zijn door het project zelf gepubliceerde cijfers. Geen van beide is een onafhankelijke test.

[
  {
    "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
  }
]

De grafiek toont de huidige agent-benchmark van het project, gedateerd 7 oktober 2026. Headless Claude Code 2.1.288-sessies op Opus 5.5 met standaard effort werkten 39 taken af, vijf runs per taak en per variant, in totaal 585 sessies verdeeld over geen skill, Ponytail v4.13.0 en Ponytail 5. Twaalf van de taken zijn feature-tickets in tiangolo's full-stack-fastapi-template, een echte FastAPI en React repository, beoordeeld op de achtergebleven git diff. De rest bestaat uit 18 chirurgische taken met verborgen controles, zes verzoeken voor kleine applicaties en drie "laat me een voorbeeld zien"-verzoeken. Bash was voor elke variant uitgeschakeld. Het aantal output-tokens daalde met 45 procent bij Ponytail 5.

Vergelijk dit met de single-shot cijfers die het project in juni 2026 publiceerde. Deze waren afkomstig van een kaal model dat vijf alledaagse prompts beantwoordde, met en zonder de regel, gerapporteerd als medianen over herhaalde runs. Ze toonden 80 tot 94 procent minder code bij Haiku, Sonnet en Opus, en de kostenverificatie van 17 juni 2026 stelde dat Haiku 63 procent goedkoper was. Het huidige agent-resultaat voor Ponytail 5 is 53 procent minder regels code, 26 procent lagere kosten en 41 procent minder doorlooptijd. Het project corrigeerde het single-shot cijfer snel. Tegen v4.8.4, op 29 juni 2026, kopte de README al met het agent-resultaat, "~54% minder code (tot 94%)", met de kanttekening dat de eerdere 80 tot 94 procent "het plafond per taak was, niet het gemiddelde", en het had de single-shot cijfers verplaatst naar een ingeklapte sectie genaamd "Oudere single-shot cijfers". Die sectie was eerlijk over de reden voor het verschil: de single-shot baseline is een kaal model dat "zijn antwoord opvult met proza en opties", wat eenvoudig te verbeteren is. Meet het af tegen een echte agent die echt werk verricht en de winst wordt kleiner. Het blijft echter wel reëel, wat het nuttigere gegeven is. Die agent-run van juni, twaalf tickets op Haiku 4.5 met vier runs per stuk, kwam dicht in de buurt van het huidige cijfer met 54 procent minder regels, en de huidige README bevat de single-shot cijfers inmiddels helemaal niet meer.

Eén kanttekening is van het project zelf, en deze bepaalt of dit voor u nuttig is. De besparing is het grootst waar sprake is van een echte valkuil van over-engineering en is vrijwel nihil bij code die al minimaal was. De tabel per taak van oktober bevestigt dit, waarbij verschillende chirurgische taken op hetzelfde aantal regels uitkwamen in alle drie de varianten. Negenendertig taken op één model en één host, met Bash uitgeschakeld, zijn geen voorspelling voor uw repository. Als het getal voor u van belang is, voer de vergelijking dan uit op uw eigen tickets, met en zonder de regel, en tel de regels zelf.

Het patroon dat u vandaag kunt kopiëren zonder iets te installeren

De ladder is tekst, dus u heeft de plugin niet nodig om het idee te gebruiken. Plak een blok zoals dit in het instructiebestand dat uw agent al leest, of dat nu AGENTS.md, CLAUDE.md of het regelsbestand van uw editor is.

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

Die laatste regel is het waard om apart te bekijken. De conventie van Ponytail in de huidige releases is een commentaar gemarkeerd met shortcut: dat de limiet benoemt en aangeeft wanneer er geüpgraded moet worden (de juni-releases, inclusief v4.8.4, markeerden dit in plaats daarvan met ponytail:):

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

Het commentaar kost twee regels werk en lost een vraag op die anders een reviewcyclus zou kosten. Het vertelt de volgende lezer dat de eenvoudige versie een bewuste keuze was, en het benoemt de voorwaarde waaronder die beslissing niet langer geldt. Zonder dit commentaar kan een reviewer een weloverwogen kortere weg niet onderscheiden van iets dat de agent is vergeten, waardoor zij genoodzaakt zijn dit na te vragen.

Waar u het blok plaatst is net zo belangrijk als wat er staat. Een bestand dat de agent bij elke uitvoering laadt, stuurt elke uitvoering aan, inclusief degene die u niet in de gaten houdt. Dat verschil is het onderwerp van het schrijven van een AGENTS.md die uw agent daadwerkelijk volgt, en het is de reden waarom dit patroon in een gecommit bestand thuishoort in plaats van in uw shell-geschiedenis. In een monorepo hoort het in meer dan één gecommit bestand thuis, omdat een AGENTS.md per pakket de regels van elke map kort houdt in plaats van de agent bij elke uitvoering de conventies van de gehele boomstructuur te laten lezen. Plaatsing is echter geen garantie, en het is de moeite waard om te weten waarom een agent een regel negeert die hij al heeft geladen voordat u concludeert dat de ladder sterkere bewoordingen nodig heeft.

Waar de regel niet langer volstaat

De ladder is afgestemd op het uitvoeren van taken in een bestaande codebase, waar hergebruik doorgaans mogelijk en correct is. Voor een greenfield-project is deze minder geschikt, omdat trede 2 niets biedt om te hergebruiken en trede 5 nog niets geïnstalleerd heeft. De agent kan nog steeds stoppen bij trede 1, de standard library, een platformfunctie of een one-liner, maar twee van de goedkoopste uitwegen zijn verdwenen. Hierdoor vallen meer taken terug op het schrijven van nieuwe code. Het past ook slecht op het moment dat u daadwerkelijk behoefte heeft aan abstractie. Als u op het punt staat de vierde aanroeper van hetzelfde gekopieerde blok toe te voegen, levert "shortest diff" u een vijfde kopie op.

Het ultra-niveau zal uw vereisten uitdagen. Dat is waar dit niveau voor bedoeld is, en het brengt reële kosten met zich mee wanneer u het besluit al heeft genomen en de taak uitgevoerd wilt hebben. Gebruik full voor regulier werk en grijp naar ultra wanneer u vermoedt dat een feature request het eigenlijke probleem is.

Geen enkele instructieblok behoedt u voor een verkeerde interpretatie van het probleem. Het eerste punt van de regelset is het begrijpen van de code voordat u een besluit neemt; dit is het kostbare onderdeel en het deel dat de tekst niet voor u kan doen. Een minimale diff in de verkeerde functie blijft een onjuiste oplossing, en het is nu een kleine, onjuiste oplossing die eenvoudig goed te keuren is.

De eerlijke samenvatting is dat Ponytail een zorgvuldig geschreven prompt is, goed gedistribueerd, voorzien van nummers. Niets hierin vereist de plugin. Wat het project u biedt, is dat iemand de lijst correct heeft opgesteld, deze heeft getest tegen een echte repository en de methode naast het resultaat heeft gepubliceerd.

FAQ

Werkt Ponytail met andere agents dan Claude Code?

Ja. Het wordt geleverd als een skill voor hosts die skills laden; een lijst die Claude Code, Codex, OpenCode, Gemini en diverse anderen bevat die in de README worden genoemd. Editors die regelbestanden lezen maar geen skills laden, zoals Cursor, Windsurf, Cline en Copilot, gebruiken de altijd actieve regelset uit de bijbehorende map met regels en ondersteunen geen slash-commando's. De tekst is in beide gevallen identiek; het werkelijke verschil is of uw host die tekst bij elke beurt in de context houdt of alleen wanneer een skill wordt geactiveerd.

Slaat een luie agent tests, validatie of beveiliging over?

Nee, en de regelset stelt dit expliciet. De lijst "nooit lui over" noemt invoervalidatie bij vertrouwensgrenzen, foutafhandeling die gegevensverlies voorkomt, beveiliging en toegankelijkheid. Daarnaast wordt gevraagd om één kleine uitvoerbare controle voor elk stuk niet-triviale logica. Wat de regel verwijdert, is verzonnen structuur: abstracties waar niemand om vroeg en dependencies die niemand nodig had. Als uw agent na installatie tests begint weg te laten, is de oorzaak een andere instructie in uw eigen configuratie die voorrang heeft op deze; controleer daarom het bestand dat de agent als laatste laadt.

Zijn de gepubliceerde snelheids- en kostencijfers betrouwbaar?

Dit zijn de eigen metingen van het project, gepubliceerd inclusief de gehanteerde methode, en ze dienen als zodanig te worden gelezen. De single-shot cijfers van juni 2026 werden vergeleken met een kaal model dat zijn antwoord opvulde met proza en opties, wat de README destijds zelf al als een zwakke baseline markeerde. De huidige agent-cijfers zijn afkomstig van headless Claude Code-sessies op Opus 5.5, 39 taken met elk vijf runs, waarvan twaalf feature-tickets in één FastAPI en React repository. Dat zijn eerlijke cijfers voor die opstelling. Het is geen voorspelling voor uw eigen codebase, aangezien de resultaten per taak van het project zelf laten zien dat de besparing bijna nul wordt bij code die al minimaal was.

Moet ik iets installeren om het voordeel te behalen?

Nee. De ladder is tekst, en een equivalent blok dat in het instructiebestand wordt geplakt dat uw agent al leest, geeft u het grootste deel van het effect. De plugin biedt u de onderhouden bewoordingen, de intensiteitsniveaus, de review-commando's en een update-pad. Het kopiëren van het blok als eerste test is het antwoord op trede 1 van de vraag of de installatie überhaupt nodig is.

Hoe voorkom ik dat een onbeheerde agent 's nachts te veel bouwt?

Plaats de regel in het altijd actieve instructiebestand in plaats van in een chatbericht, zodat deze ook van toepassing is op beurt 200 van een lange run en niet alleen op beurt 3. Begrens de schade vervolgens afzonderlijk: geef de agent een checkout die hij mag verpesten in plaats van uw enige kopie, en vereis een menselijke diff-review voordat er iets wordt samengevoegd. Een regel voor minimale diffs vermindert de hoeveelheid tekst die u moet lezen. Het bepaalt niet wat er wordt doorgevoerd, en dat hoort ook niet zo te zijn.