Wat is Ponytail voor AI-codeeragenten?

Wat Ponytail is

Ponytail is een set regels die ervoor zorgt dat een AI-codeeragent minder code schrijft. Het project omschrijft zichzelf in één zin: "Zorgt ervoor dat uw AI-agent denkt als de meest luie senior developer in de kamer. De beste code is de code die u nooit hebt geschreven." Het is uitgebracht onder de MIT-licentie. Het heeft geen eigen runtime en niets erin wordt 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, dus zet een tag vast voordat u er iets op bouwt.

Het idee achter de tool: stop bij de eerste trede die standhoudt

De kern van Ponytail is een beslissingsladder. De agent doorloopt deze ladder voordat er iets wordt geschreven en stopt bij de eerste trede die standhoudt.

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 dit al in deze codebase? Hergebruik de helper of het patroon dat al aanwezig is.
3. Biedt de standaardbibliotheek dit aan? Gebruik deze.
4. Wordt dit gedekt door een native platformfunctie? Gebruik deze.
5. Lost een reeds geïnstalleerde dependency dit op? Gebruik deze.
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 te maken, zal een date picker schrijven, omdat hem is opgedragen er een te maken. De ladder dwingt de agent 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 koos voor de native input in plaats van een component te bouwen. Een colour picker ging van 287 regels naar 23 om dezelfde reden.

Luiheid betekent hier niet onzorgvuldigheid, en de regelset stelt dit direct vast. De lijst met zaken waar "nooit lui over gedaan mag worden" omvat het begrijpen van het probleem vóór de besluitvorming, inputvalidatie bij vertrouwensgrenzen, foutafhandeling die dataverlies 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. Het 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 argumenthint van lite, full of ultra.
• Regelbestanden in editor-specifieke mappen zoals .cursor/rules/ en .windsurf/rules/, voor hosts die regels lezen maar geen skills laden.
• hooks/, benchmarks/, examples/ en scripts/.

Het intensity-argument 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 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 lezen, ontvangen de regelset zonder commando's.

Om de broncode te lezen voordat u deze vertrouwt, kunt u beter de tag klonen 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 luie 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, niet alleen 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 vult zich met de eigen output van de agent, waardoor de ruimte voor uw eigenlijke code krimpt. Het beheersen hiervan is het volledige onderwerp van het beheren van het contextvenster van een coding agent.

Tokens worden bij in- en uitvoer in rekening gebracht, dus een diff dat de helft kleiner is, is dubbel zo goedkoop: één keer wanneer het wordt geschreven en opnieuw bij elke beurt die het opnieuw inleest. 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 outputvolume, 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 slechte 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 zich bezighouden met loop engineering 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.

Nieuwe dependencies zijn de andere stille kostenpost. Rung 5 zegt: gebruik wat er is geïnstalleerd. Elk pakket dat een agent op eigen initiatief toevoegt, is iets wat 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 voor eenmalige uitvoering (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 van 13 en 17 juni 2026. De agent-kolom is afkomstig van een headless Claude Code-sessie die de full-stack-fastapi-template van tiangolo bewerkt, een echte FastAPI- en React-repository, over twaalf feature-tickets met elk vier runs op Haiku 4.5, gescoord op basis van de achtergebleven git diff.

Lees de tweede kolom. Het resultaat voor de agent 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 deze bepaalt of dit u helpt. De besparing is het grootst waar er sprake is van een echte valkuil van over-engineering en is 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 configuratiebestand 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 op zichzelf 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 bestaat uit 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 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 de runs 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.

Waar de regel niet langer voldoet

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 geen herbruikbare onderdelen bevat en trede 5 nog niets geïnstalleerd heeft; de agent valt hierdoor telkens terug naar trede 7. De methode is ook minder effectief 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 de functie van dit niveau, en het brengt reële kosten met zich mee wanneer u het besluit al heeft genomen en de taak wilt afronden. Gebruik full voor reguliere werkzaamheden en schakel over naar ultra wanneer u vermoedt dat een feature request de kern van het probleem is.

Geen enkele instructie voorkomt 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 waar de tekst u niet bij kan helpen. Een minimale diff in de verkeerde functie blijft een onjuiste oplossing, en het is nu een kleine, onjuiste oplossing die eenvoudig kan worden goedgekeurd.

De eerlijke samenvatting is dat Ponytail een zorgvuldig geschreven prompt is, goed verspreid en voorzien van nummers. Niets in de methode 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 hetzelfde; het werkelijke verschil is of uw host die tekst bij elke beurt in de context houdt of alleen wanneer een skill wordt geactiveerd.

Zal een luie agent tests, validatie of beveiliging overslaan?

Nee, en de regelset stelt dit expliciet. De lijst met zaken waar "nooit laks over gedaan mag worden" omvat 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 afhankelijkheden 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 cijfers over snelheid en kosten betrouwbaar?

Dit zijn de eigen metingen van het project, gepubliceerd inclusief de gehanteerde methode, en ze dienen als zodanig te worden gelezen. De cijfers voor een enkele poging (single shot) worden vergeleken met een basismodel dat antwoordt met opties en commentaar, wat in de README zelf als een zwakke referentiewaarde wordt aangemerkt. 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. Dat zijn eerlijke cijfers voor die specifieke opstelling. Het is geen voorspelling voor uw eigen codebase, omdat 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 is de eerste stap om te bepalen of een 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 bij beurt 200 van een lange sessie geldt en niet alleen bij 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 (merge). 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.