Ponytail: minder code voor uw AI-codeagent

Wat Ponytail is

Ponytail is een regelset die een AI-codeeragent minder code laat schrijven. Het project beschrijft zichzelf in één zin: "Laat uw AI-agent denken als de luište senior developer in de ruimte. De beste code is de code die u nooit hebt geschreven." Het valt onder de MIT-licentie. Het heeft geen eigen runtime en voert zelf niets uit. Het is tekst die aan de instructies van de agent wordt toegevoegd. Het wordt verpakt als een skill voor hosts die skills laden en als gewone regelbestanden voor hosts die dat niet doen.

De repository is DietrichGebert/ponytail. Deze is gemaakt op 12 juni 2026 en had op 1 augustus 2026 meer dan 90,000 stars. De nieuwste release met een tag op 1 augustus 2026 is v4.8.4. Deze is gepubliceerd op 29 juni 2026. Op de releasespagina staan alleen al tussen 14 en 29 juni tien tags. Een project dat zich in dat tempo ontwikkelt, is mogelijk veranderd tegen de tijd dat u dit leest. Leg daarom een tag vast voordat u er iets op bouwt.

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

De kern van Ponytail is een beslisladder. De agent doorloopt deze voordat hij iets schrijft en stopt bij de eerste trede die voldoet.

1. Moet dit überhaupt bestaan? Dit is YAGNI (you are not going to need it). Als het antwoord nee is, slaat u het over.
2. Bestaat dit al in deze codebase? Gebruik de helper of het patroon dat er al is opnieuw.
3. Doet de standaardbibliotheek dit? Gebruik die.
4. Dekt een native platformfunctie dit af? Gebruik die.
5. Lost een al geïnstalleerde dependency 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 één afzonderlijke trede. Een agent aan wie om een datumkiezer wordt gevraagd, schrijft een datumkiezer, omdat dat de opdracht is. De ladder zorgt ervoor dat de agent eerst trede 4 controleert. Trede 4 geeft aan dat de browser al <input type="date"> heeft. De eigen benchmarknotities van het project beschrijven precies dit geval: een datumkiezer die zonder deze regel 404 regels omvatte, kwam met de regel uit op 23 regels, 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.

Lui zijn betekent hier niet onzorgvuldig zijn, en de regels zeggen dat rechtstreeks. De lijst met zaken waarvoor u "nooit lui" mag zijn, omvat het probleem begrijpen voordat u een beslissing neemt, invoervalidatie bij vertrouwensgrenzen, foutafhandeling die gegevensverlies voorkomt, beveiliging, toegankelijkheid en alles waar u expliciet om hebt gevraagd. Ook wordt gevraagd om voor elk onderdeel met niet-triviale logica één kleine uitvoerbare controle te maken. De regel beperkt het verzinnen. De correctheid blijft behouden.

Wat het repository daadwerkelijk levert

• AGENTS.md, de permanent actieve regelset, die het hele idee bevat in één bestand dat u in vijf minuten kunt lezen.
• skills/ponytail/SKILL.md, de skilldefinitie, met een argumentaanduiding 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 intensiteitsargument bepaalt hoe streng de regel wordt toegepast. lite bouwt wat u hebt gevraagd en noemt in één regel een minder intensieve optie. full is de standaard en dwingt de escalatieladder af. ultra is de extremistische YAGNI-instelling: deze geeft de voorkeur aan verwijderen boven toevoegen en trekt zelfs de vereiste zelf in twijfel.

Hosts die skills ondersteunen, krijgen ook slashopdrachten. /ponytail stelt het niveau in, /ponytail-review controleert een diff op overengineering, /ponytail-audit controleert een volledig repository, /ponytail-debt verzamelt de snelkoppelingen die u hebt uitgesteld en /ponytail-gain drukt het benchmarkscorecard af. Hosts die alleen regelbestanden lezen, krijgen de regelset zonder opdrachten.

Als u de broncode wilt 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

Voor Claude Code documenteert het project in plaats daarvan een plugin-installatie. Deze twee regels zijn gedocumenteerd op 1 August 2026:

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

Het pluginpad volgt de default branch in plaats van een tag. Daardoor kunnen de instructies die uw agent aansturen tussen sessies wijzigen. Dat is de afweging die u accepteert voor het gemak van een updateopdracht.

Waarom een luie agent goedkoper is op een VPS

De diff die een agent schrijft, blijft in de conversatie staan. Bij de volgende beurt is deze opnieuw context die het model leest, samen met elk bestand dat het model heeft geopend om de diff te maken. Een wijziging van 500 regels belast daarom elke latere beurt in de sessie, niet alleen de beurt waarin de wijziging is gemaakt. Daarom voelt een ontspoorde refactor steeds trager en minder intelligent aan naarmate de sessie vordert: het contextvenster vult zich met de eigen uitvoer van de agent, waardoor er minder ruimte overblijft voor uw eigen code. Het volledige onderwerp is het contextvenster van een coding agent beheren.

Tokens worden zowel voor invoer als uitvoer in rekening gebracht. Een diff die half zo groot is, is daarom twee keer goedkoper: eenmaal bij het schrijven en opnieuw bij elke beurt waarin deze opnieuw wordt gelezen. Als u de kosten op een self-hosted omgeving bewaakt, is het instructiebestand een middel dat niets kost om te gebruiken. Bepalen wat een AI-agent u kost begint met de hoeveelheid uitvoer, en hoe een coding agent zijn tokens gebruikt legt uit waarom het opnieuw lezen meer gevolgen heeft dan mensen verwachten.

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 hulpbron die het eerst opraakt. Niemand beoordeelt de vierde lange diff van de dag met dezelfde zorg als de eerste. Te veel bouwen kost dus niet alleen tijd. Het verlaagt ook ongemerkt de kwaliteit van de review die de fouten moet opsporen.

Op een server liggen de risico's anders, omdat de agent vaak zonder toezicht werkt. Een agent die in een tmux-sessie of volgens een timer werkt, heeft uren de tijd om voort te bouwen op een verkeerde beslissing voordat u dit ziet. Dat is het praktische risico van een coding agent op een VPS uitvoeren, en daarom besteden mensen die aan loop engineering doen zoveel aandacht aan de vaste instructies en niet aan afzonderlijke prompts. Een regel in het bestand dat altijd wordt ingelezen, geldt voor beurt 200. Een regel die u in de chat hebt getypt, geldt voor beurt 3.

Nieuwe afhankelijkheden vormen de andere verborgen kostenpost. Rung 5 zegt dat u gebruikt wat is geïnstalleerd. Elk pakket dat een agent op eigen initiatief toevoegt, moet u later patchen en komt terecht in elke containerimage die u vanuit die repository bouwt.

Wat de eigen benchmarkcijfers van Ponytail zeggen

Het project publiceert twee reeksen resultaten. Deze verschillen sterk van elkaar. Beide zijn eigen, gepubliceerde cijfers van het project. 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 één enkele opdracht is afkomstig van een basismodel dat een kleine reeks prompts met en zonder de regel beantwoordt. De waarden zijn medianen van herhaalde runs op 13 en 17 June 2026. De agentische kolom is afkomstig van een headless Claude Code-sessie die tiangolo's full-stack-fastapi-template bewerkt. Dit is een echte FastAPI- en React-repository. De sessie behandelt twaalf featuretickets met vier runs per ticket op Haiku 4.5. De beoordeling is gebaseerd op de git diff die daarna is achtergebleven.

Bekijk de tweede kolom. Het agentische resultaat gebruikt 54 procent minder regels code, kost 20 procent minder en neemt 27 procent minder wall-clock tijd in beslag. In de single-shotopstelling zijn deze waarden respectievelijk 93 procent en 74 procent. De README legt eerlijk uit waarom: de single-shotbaseline is een basismodel dat "met verschillende opties en commentaar antwoordt". Dat is eenvoudig te overtreffen. Wanneer u vergelijkt met een echte agent die echt werk uitvoert, wordt de winst kleiner. Het resultaat blijft echter reëel. Dat is het nuttigere feit.

Er is één kanttekening van het project zelf. Die bepaalt of dit u helpt. De besparing is het grootst waar er een reëel risico op overengineering bestaat. Bij code die al minimaal was, is de besparing vrijwel nul. Twaalf tickets in één Python- en TypeScript-repository voorspellen niet wat er in uw repository gebeurt. Als dit getal voor u belangrijk is, voert u de vergelijking uit op uw eigen tickets, met en zonder de regel, en telt u de regels zelf.

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

De ladder bestaat uit tekst. U hebt de plugin dus niet nodig om het idee toe te passen. 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 verdient afzonderlijke aandacht. De conventie van Ponytail is een opmerking met de naam van de tool:

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

De opmerking bestaat uit twee regels werk en beantwoordt een vraag die anders een beoordelingsronde zou kosten. De opmerking maakt de volgende lezer duidelijk dat de eenvoudige versie een bewuste keuze was. Ook wordt vermeld onder welke voorwaarde die keuze niet meer geldt. Zonder deze opmerking kan een reviewer niet zien of er bewust een eenvoudige oplossing is gekozen of dat de agent iets is vergeten. Daarom moet de reviewer dit navragen.

De plaats van het blok is net zo belangrijk als de inhoud. Een bestand dat de agent bij elke uitvoering inleest, stuurt elke uitvoering aan, ook de uitvoeringen die u niet controleert. Dat verschil wordt behandeld in een AGENTS.md schrijven die uw agent daadwerkelijk volgt. Daarom hoort dit patroon in een vastgelegd bestand te staan en niet in uw shellgeschiedenis.

Waar de regel niet meer opgaat

De ladder is afgestemd op featurewerk in een bestaande codebase, waarin hergebruik meestal beschikbaar en meestal correct is. Voor een greenfield-project werkt deze aanpak slecht, omdat er op trede 2 niets te hergebruiken is en er op trede 5 niets is geïnstalleerd. De agent valt daardoor elke keer door naar trede 7. De aanpak werkt ook slecht op het moment dat u de abstractie daadwerkelijk nodig hebt. 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 niveau ultra stelt uw vereisten ter discussie. Daarvoor is dit niveau bedoeld. Dat brengt wel echte kosten met zich mee wanneer u de beslissing al hebt genomen en wilt dat het werk wordt uitgevoerd. Gebruik full voor normaal werk en kies ultra wanneer u vermoedt dat een featureaanvraag het eigenlijke probleem is.

Geen enkel instructieblok beschermt u tegen een verkeerde interpretatie van het probleem. Het eerste onderdeel van de regels is zelf het begrijpen van de code voordat u een beslissing neemt. Dat is het kostbare deel, en het deel dat de tekst niet voor u kan uitvoeren. Een minimale diff in de verkeerde functie is nog steeds de verkeerde oplossing. Het is nu alleen een kleine verkeerde oplossing die gemakkelijk kan worden goedgekeurd.

De eerlijke samenvatting is dat Ponytail een zorgvuldig geschreven prompt is, goed verspreid en voorzien van cijfers. Niets daarin vereist de plugin. Wat het project u biedt, is dat iemand de lijst correct heeft opgesteld, deze tegen een echte repository heeft getest 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. Tot die hosts behoren Claude Code, Codex, OpenCode, Gemini en verschillende andere die in de README worden genoemd. Editors die rule files lezen maar geen skills laden, zoals Cursor, Windsurf, Cline en Copilot, gebruiken de always-on ruleset uit de bijbehorende rules directory en krijgen geen slash commands. 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.

Slaat een luie agent tests, validatie of beveiliging over?

Nee, en de ruleset vermeldt dit rechtstreeks. De lijst "never lazy about" noemt inputvalidatie op vertrouwensgrenzen, foutafhandeling die gegevensverlies voorkomt, beveiliging en toegankelijkheid. Ook wordt gevraagd om voor elk stuk niet-triviale logica één kleine uitvoerbare controle te maken. De regel verwijdert verzonnen structuur: abstracties waar niemand om heeft gevraagd en dependencies die niemand nodig had. Als uw agent na installatie tests begint over te slaan, wordt dit veroorzaakt door een andere instructie in uw eigen configuratie die voorrang heeft op deze instructie. Lees daarom het bestand dat de agent als laatste laadt.

Zijn de gepubliceerde snelheids- en kostenwaarden betrouwbaar?

Het zijn de eigen metingen van het project, gepubliceerd met de gebruikte methode. U moet ze ook zo interpreteren. De cijfers voor single-shot-aanvragen worden vergeleken met een kaal model dat antwoordt met opties en toelichting. De README zelf markeert dit als een zwakke referentiewaarde. De agentic-cijfers zijn afkomstig uit een headless Claude Code-sessie op één FastAPI- en React-repository, met twaalf tickets en vier runs per ticket, met Haiku 4.5. Dit zijn betrouwbare cijfers voor die configuratie. Ze zijn geen voorspelling voor uw codebase, omdat het project ook vermeldt dat de besparing vrijwel nul wordt bij code die al minimaal was.

Moet ik iets installeren om hiervan voordeel te hebben?

Nee. De ladder bestaat uit tekst. Een gelijkwaardig blok dat u toevoegt aan het instruction file dat uw agent al leest, levert het grootste deel van het effect. De plugin biedt de onderhouden formulering, de intensiteitsniveaus, de review commands en een updatepad. Eerst het gekopieerde blok proberen is het antwoord op rung 1 op de vraag of de installatie überhaupt nodig is.

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

Plaats de regel in het always-on instruction file in plaats van in een chatbericht. Dan geldt de regel ook bij turn 200 van een lange run, en niet alleen bij turn 3. Beperk de mogelijke schade vervolgens afzonderlijk. Geef de agent een checkout die mag worden beschadigd in plaats van uw enige kopie. Vereis ook een menselijke diff review voordat iets wordt gemerged. Een regel voor minimale diffs vermindert hoeveel u moet lezen. De regel bepaalt niet wat wordt opgenomen, en dat hoort ook niet zo te zijn.