Wat is Ponytail voor AI-codeeragenten?

Wat Ponytail is

Ponytail is een regelset die een AI-codeeragent dwingt minder code te schrijven. Het project omschrijft zichzelf in één zin: "Zorgt dat uw AI-agent denkt als de luiste senior developer 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. Het werd opgericht op 12 juni 2026 en passeerde de 90.000 sterren op 1 augustus 2026. De laatst getagde release op 1 augustus 2026 is v4.8.4, gepubliceerd op 29 juni 2026, en de releases-pagina vermeldt alleen al tussen 14 en 29 juni tien tags. Een project dat in dit tempo beweegt, zal veranderd zijn tegen de tijd dat u dit leest; pin 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 dan over.
2. Bestaat het 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 afhankelijkheid dit op? Gebruik die.
6. Kan het in één regel? Maak er één regel van.
7. Schrijf pas daarna de minimale code die werkt.

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 eerst trede 4 te controleren, en trede 4 zegt dat de browser al beschikt over <input type="date">. De eigen benchmark van het project noteert precies dit geval: een date picker die zonder de regel 404 regels code besloeg, kwam uit op 23 regels met de regel, omdat de agent de native input gebruikte in plaats van een component te bouwen. Een kleurkiezer ging om dezelfde reden van 287 regels naar 23. Trede 2 is degene die stilletjes 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 onzorgvuldig, en de regelset zegt dat direct. De lijst met zaken waar de agent "nooit lui over mag zijn" omvat het begrijpen van het probleem vóór de besluitvorming, 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 doorlezen.
• skills/ponytail/SKILL.md, de definitie van de skill, met een argument-hint van lite, full of ultra.
• Regelbestanden in editor-specifieke mappen zoals .cursor/rules/ en .windsurf/rules/, voor hosts die regels inlezen maar geen skills laden.
• hooks/, benchmarks/, examples/ en scripts/.

Het intensity-argument bepaalt hoe dwingend de regel is. 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 zelfs de vereiste zelf ter discussie stellen.

Hosts die skills 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.

Om de broncode te lezen voordat u deze vertrouwt, kloont u de tag in plaats van de branch:

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

Bij Claude Code documenteert het project in plaats daarvan een plugin-installatie, en deze twee regels zijn zoals gedocumenteerd op 1 augustus 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 maakt voor het gemak van een update-commando.

Waarom een 'lazy agent' goedkoper is op een VPS

De diff die een agent schrijft, verlaat het gesprek niet. Bij de volgende beurt is dit context die het model opnieuw leest, samen met elk bestand dat het opende om de wijziging te produceren. Een wijziging van 500 regels belast daarom elke latere beurt in de sessie, niet alleen de beurt waarin deze werd geproduceerd. Dit is de reden waarom een ongecontroleerde refactor ervoor zorgt dat een agent trager en minder slim aanvoelt naarmate de sessie vordert: het venster raakt gevuld met de output van de agent zelf, waardoor de ruimte voor uw eigenlijke code afneemt. Het beheersen hiervan 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 die de helft kleiner is, is dubbel zo goedkoop: eenmaal wanneer deze wordt geschreven en opnieuw bij elke beurt waarin deze opnieuw wordt gelezen. Of die besparing daadwerkelijk op uw factuur terechtkomt, hangt af van uw betaalmethode, omdat een vast Pro- of Max-abonnement de extra tokens opvangt, terwijl bij API-facturatie per token elk token in rekening wordt gebracht. Als u de kosten van een self-hosted setup in de gaten houdt, is het instructiebestand een hefboom die niets kost om te gebruiken. Het beheersen van de kosten van een AI-agent begint bij het uitvoervolume, en hoe een coding agent zijn tokens besteedt legt uit waarom het opnieuw lezen belangrijker is dan men verwacht.

Een mens leest de 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 de vierde lange diff van de dag met dezelfde zorg als de eerste, dus overmatig bouwen verspilt niet alleen tijd. Het verlaagt stilletjes de kwaliteit van de review 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 slechte beslissing voordat u deze ziet. Dat is het praktische risico van 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 typt, is van toepassing op beurt 3. Deze is ook van toepassing op de tweede sessie die u op dezelfde machine start; deze leest het vastgelegde bestand, maar erft niets 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. Regel 5 stelt dat u moet gebruiken wat er al 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 publiceert twee sets resultaten, 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",
    "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
  }
]

De kolom 'single shot' is afkomstig van een kaal model dat een kleine set prompts beantwoordt met en zonder de regel, genomen als medianen over herhaalde runs gedateerd 13 en 17 juni 2026. De 'agentic' kolom is afkomstig van een headless Claude Code-sessie die tiangolo's full-stack-fastapi-template bewerkt, een echte FastAPI- en React-repository, over twaalf feature-tickets met vier runs per stuk op Haiku 4.5, gescoord op basis van de achtergebleven git diff.

Lees de tweede kolom. Het agentic-resultaat is 54 procent minder regels code, 20 procent lagere kosten en 27 procent minder doorlooptijd, tegenover 93 procent en 74 procent voor dezelfde maatstaven in de single shot-opstelling. De README is eerlijk over de reden: de single shot-baseline is een kaal model dat "antwoordt met verschillende opties plus commentaar", wat eenvoudig te verslaan 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.

Eén kanttekening is van het project zelf, en dit is de factor die bepaalt of dit u helpt. De besparing is het grootst waar er sprake is van een echte valkuil van over-engineering en bijna nul bij code die al minimaal was. Twaalf tickets in één Python- en TypeScript-repository 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 gebruiken. De conventie van Ponytail is een commentaar dat is getagd met de naam van de tool:

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

Het commentaar beslaat 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 benoemt de voorwaarde waaronder die beslissing niet langer geldt. Zonder dit commentaar kan een reviewer een weloverwogen snelkoppeling 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 gecommitteerd bestand thuishoort in plaats van in uw shell-geschiedenis. In een monorepo hoort het in meer dan één gecommitteerd 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 een krachtigere formulering nodig heeft.

Waar de regel niet langer voldoet

De ladder is afgestemd op het uitvoeren van taken in een bestaande codebase, waar hergebruik meestal mogelijk en correct is. Voor een greenfield-project is deze minder geschikt, omdat trede 2 niets te hergebruiken heeft en trede 5 nog niets geïnstalleerd heeft, waardoor de agent telkens terugvalt naar trede 7. Het werkt ook minder goed 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 "kortste diff" u een vijfde kopie op.

Het ultra-niveau zal uw vereisten uitdagen. Dat is het doel van dit niveau, 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-verzoek 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 onder andere Claude Code, Codex, OpenCode, Gemini en diverse andere in de README genoemde opties bevat. 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 "never lazy about" benoemt expliciet 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 krijgt 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 vergelijken met een kaal model dat antwoordt met opties en commentaar, wat de README zelf markeert als een zwakke baseline. De agent-cijfers zijn afkomstig van een headless Claude Code-sessie op één FastAPI- en React-repository, twaalf tickets, vier runs per stuk, op Haiku 4.5. Dit zijn eerlijke cijfers voor die specifieke opstelling. Het is geen voorspelling voor uw eigen codebase, aangezien het project ook aangeeft dat de besparing bijna nul is 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 updatepad. Het kopiëren van het blok als eerste stap is het antwoord op de vraag of de installatie überhaupt noodzakelijk 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 bij beurt 200 van een lange run van toepassing is en niet alleen bij beurt 3. Beperk 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 gemerged. Een minimale diff-regel vermindert de hoeveelheid tekst die u moet lezen. Het bepaalt niet wat er wordt doorgevoerd, en dat hoort ook niet zo te zijn.