Technik-Demontage 001｜ponytail: Der „faule Senior-Entwickler“, der KI dazu bringt, halb so viel Code zu schreiben

一、Was ist das?

ponytail ist ein Regelsatz (Ruleset / Skill) für KI-Programmieragenten. Es tut nur eines: Es bringt die KI dazu, „minimalen, funktionierenden Code“ zu schreiben.

Es ahmt jenen alten Programmierer nach, den es in jedem Unternehmen gibt – mit Pferdeschwanz, ovaler Brille, und der schon länger im Unternehmen ist als das Versionskontrollsystem. Du zeigst ihm 50 Zeilen Code, er wirft einen Blick darauf, sagt nichts, und ersetzt sie durch eine einzige Zeile.

Einige wichtige Fakten:

GitHub-Projekt DietrichGebert/ponytail, ca. 129.000 Sterne, gegründet im Juni 2026, in 3 Monaten auf diese Größenordnung angewachsen, MIT-Lizenz
Unterstützt 20 gängige KI-Programmierwerkzeuge: Claude Code, Codex, Copilot CLI, Gemini CLI, OpenCode, Cursor, Windsurf, Cline, Kiro, Zed usw.
Im Grunde handelt es sich um einen Regeltext: Es wird kein Geschäftscode geschrieben, sondern ein Satz von Einschränkungsprinzipien in den Agenten eingespeist.

Sein Kernanspruch ist nur ein Satz: Der beste Code ist der, den du nie geschrieben hast.

Einfach ausgedrückt: Es schreibt das Gewissen, das in deinem Kopf „nicht überdesignen“ sagt, zu etwas um, das der Agent vor jedem Handeln durchgeht.

二、Kernmechanismus: Die siebenstufige „Leiter“

Der Kern von ponytail ist eine Entscheidungsleiter (the ladder). Bevor die KI einen Codeabschnitt schreibt, durchläuft sie diese sieben Fragen nacheinander – beginnend bei der ersten Stufe, und hält dort an, wo es ausreicht:

Muss dieses Ding wirklich existieren? Spekulative Anforderungen werden direkt übersprungen (YAGNI)
Gibt es das schon in der Codebasis? Wiederverwendung vorhandener Helper, Utils, Patterns
Kann die Standardbibliothek das? Nutze die Standardbibliothek, erfinde das Rad nicht neu
Decken native Plattformfunktionen das ab? Zum Beispiel reicht <input type="date">, installiere keine Datumsauswahlbibliothek
Können bereits installierte Abhängigkeiten das lösen? Wenn ja, füge keine neuen Abhängigkeiten hinzu
Geht das in einer Zeile? Dann eine Zeile
Erst wenn du hier ankommst, schreibe minimalen, funktionierenden Code

Diese Reihenfolge ist nicht willkürlich: Sie stellt „nichts schreiben“ an erste Stelle, „Vorhandenes wiederverwenden“ an zweite, und „neuen Code schreiben“ an letzte. Im Grunde nimmt es das Allgemeinwissen von Ingenieuren – YAGNI, DRY, Standardbibliothek zuerst – und macht es zu einer Checkliste, die der Agent vor jedem Handeln abarbeitet.

Es gibt drei Intensitätsstufen:

lite (Standard): Baut wie gewohnt, weist aber mit einem Satz auf „sparsamere“ Alternativen hin – du entscheidest
full: Erzwingt das Durchlaufen der gesamten Leiter, Standardbibliothek und native Funktionen haben Vorrang
ultra: YAGNI-Extremismus, schreibe eine Zeile und stelle gleichzeitig die Anforderung selbst in Frage

三、Technische Bewertung: Daten sprechen

Der Autor von ponytail hat einen relativ ehrlichen Benchmark-Test durchgeführt. Nicht indem das Modell isoliert einen Codeabschnitt generiert (das lässt sich leicht aufblähen), sondern indem eine echte headless-Claude-Code-Sitzung ein echtes Open-Source-Repository (FastAPI + React Fullstack-Vorlage) bearbeitet, 12 Feature-Aufgaben durchläuft, derselbe Agent mit/ohne diesen Skill jeweils 4 Mal läuft und anhand des hinterlassenen Git-Diffs bewertet wird.

Ergebnisse (relativ zur „Basislinie ohne Skill“):

Lösung	Code-Menge	Tokens	Kosten	Zeit	Sicherheit
ponytail	-54%	-22%	-20%	-27%	100%
caveman (Vergleich mit knapper Formulierung)	-20%	+7%	+3%	+2%	100%
„YAGNI + eine Zeile“ nackter Prompt	-33%	-14%	-21%	-30%	95%

Drei bemerkenswerte Punkte:

ponytail ist die einzige Lösung, bei der alle vier Indikatoren sinken und die Sicherheit bei 100 % bleibt. Andere Lösungen sinken entweder weniger (bei caveman steigen Tokens, Kosten und Zeit statt zu sinken) oder sie sinken, aber die Sicherheit fällt ab (bei dem nackten „schreibe eine Zeile“-Prompt sinkt die Sicherheit auf 95 %).
Am stärksten wird dort gekürzt, wo KI am leichtesten „überbaut“. Bei einem Datumsauswahlfeld würde der Agent standardmäßig flatpickr installieren, eine Wrapper-Komponente schreiben, Stylesheets hinzufügen und über Zeitzonen diskutieren; ponytail lässt es mit einer Zeile <input type="date"> lösen – von 404 auf 23 Zeilen gekürzt. Bei einem Farbauswahlfeld von 287 auf 23 Zeilen.
In diesen Daten steckt die Ehrlichkeit des Autors. ponytail bewirbt sich anfangs mit „80-94 % weniger Code“, dann wies jemand (Issue #126) darauf hin, dass das Basismodell selbst aufbläht – der Autor stellte den Bench auf den agentischen Modus um und korrigierte die Zahl auf das realistischere „durchschnittlich -54 %“. Ein Open-Source-Projekt, das bereit ist, seine eigene Werbezahl aktiv nach unten zu korrigieren, ist selten.

四、Werturteil: Wann man es nutzen sollte und wann nicht

Das echte Problem, das ponytail löst, ist eine weitverbreitete Schwäche von KI-Programmieragenten: Überbauung. Du bittest die KI, eine kleine Funktion hinzuzufügen, und sie installiert dir eine Bibliothek, schreibt einen Haufen Abstraktionen und führt eine Struktur ein, die du nicht brauchst. Je mehr Code, desto höher die Wartungskosten – und je länger die Generierung, desto teurer, langsamer und fehleranfälliger ist sie oft.

Es eignet sich am besten für drei Szenarien:

Kleine Funktionen und Änderungen mit KI durchführen (Felder hinzufügen, Validierungen schreiben, kleine Schnittstellen anbinden)
Kosten und Tokens kontrollieren, wenn man günstige/schnelle Modelle (wie Haiku 4.5) für alltägliche Aufgaben nutzt
Teams wollen den „Stil von KI-generiertem Code“ vereinheitlichen und vermeiden, dass verschiedene Personen völlig unterschiedlichen Code produzieren

Seine Grenzen müssen auch klar genannt werden:

Bei „ohnehin schlankem Code“ ist sein Effekt nahe Null – es ist kein Allheilmittel zum Abnehmen
Es drückt die „Code-Menge“, nicht die „Korrektheit“ – wenn die Aufgabe selbst komplex ist und Struktur braucht, schadet es, hart auf eine Zeile zu drücken (deshalb gibt es lite/full/ultra, nicht je extremer desto besser)
Im Grunde ist es „Regelinjektion“, es garantiert nicht, dass die KI sich jedes Mal daran hält – ein Review als Absicherung ist nötig (deshalb gibt es eingebaute Prüfbefehle wie /ponytail-review, /ponytail-audit)
Wenn im Team jemand ohnehin einen „technischen Reinlichkeitswahn“ hat, und man dazu noch die ultra-Stufe legt, kann es ins andere Extrem kippen – übermäßige Kürzung bis zur Unlesbarkeit

Ein Satz zur Beurteilung: Es ist ein kluges Werkzeug, das technisches Allgemeinwissen in einen KI-Agenten packt, geeignet für alltägliche kleine Aufgaben und kostensensitive Szenarien; aber es ist keine Silberkugel – bei komplexen Systemen darf keine der notwendigen Strukturen fehlen.

五、Wie man es umsetzt

Die Installation sind nur zwei Zeilen (am Beispiel von Claude Code):

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

Andere Werkzeuge funktionieren grundsätzlich gleich: Bei Codex nutzt man codex plugin marketplace add DietrichGebert/ponytail, bei Copilot CLI copilot plugin install ponytail@ponytail, bei Gemini CLI gemini extensions install github.com/DietrichGebert/ponytail. In der README gibt es die vollständige Liste für 20 Werkzeuge.

Alltägliche Nutzung (Befehle direkt im Agenten senden):

/ponytail lite|full|ultra|off — Intensität wechseln oder abschalten
/ponytail-review — Überprüfung auf Überengineering im aktuellen Diff
/ponytail-audit — Scannen des gesamten Repositorys nach „Überflüssigem“
/ponytail-debt — Temporäre Lösungen, die man aus Bequemlichkeit „faulerweise“ gewählt hat, in ein Buch eintragen, um sie später gemeinsam abzuarbeiten
/ponytail-gain — Anzeigen, wie viel man in dieser Runde gespart hat

Empfehlung für die Auswahl:

Für den Alltag reicht standardmäßig lite (es „schlägt nur vor“, du entscheidest)
Wenn das Team den Stil vereinheitlichen und Konsistenz anstrebt, nimm full
Für persönliche Extremherausforderungen oder schnelle Prototypen kann man ultra ausprobieren, aber nicht in produktiven Kernlogiken verwenden

六、Wie man selbst ein ähnliches System erstellt

Im Grunde ist ponytail letztendlich nur ein Regeltext. Du musst es nicht installieren – schreib dir selbst einen, das funktioniert genauso – und du kannst ihn noch besser an dein eigenes Team anpassen.

Die Vorgehensweise ist einfach: Schreibe die „Grundregeln zum Codieren“, die dein Team akzeptiert, in eine Regeldatei und speise sie in deinen KI-Agenten ein. Bei Claude Code schreibst du es in CLAUDE.md, bei Cursor in .cursorrules, bei anderen Werkzeugen in den System-Prompt oder einen Skill.

Der Inhalt muss nicht eins zu eins abgeschrieben werden, aber jene „Leiter“ ist ein gutes Gerüst. Schreib einfach vier Sätze danach:

Bevor du loslegst, frag zuerst: Wird diese Anforderung wirklich gebraucht? Wenn du dir unsicher bist, frag erst, rate nicht selbst herum
Gibt es das schon in der Codebasis? Wenn ja, wiederverwende es, baue es nicht neu
Können Standardbibliothek oder native Funktionen das lösen? Wenn ja, führe keine Abhängigkeiten ein
Wenn du unbedingt neuen Code schreiben musst, schreibe minimalen, funktionierenden Code, überdesign nicht

Dann füge die eigenen Regeln deines Teams hinzu. Zum Beispiel: Externe Schnittstellen müssen Autorisierung haben, Felder mit Geldbeträgen nutzen Decimal statt float, welche Bibliotheken tabu sind, Protokoll- und Namenskonventionen. Das sind die Dinge, die wirklich wertvoll sind – ponytail liefert nur „allgemein minimalsten Code“, geschäftsspezifische Einschränkungen musst du selbst ergänzen.

Eines ist zu beachten: Regeln müssen kurz, konkret und ausführbar sein. Wenn du eine Seite A4-Papier reintust, liest die KI das gar nicht; schreibe drei bis fünf Punkte, die sie sich merken kann – dann wird sie sie auch wirklich befolgen.

Zum Schluss noch ein Hinweis: Nach der Regelinjektion muss unbedingt ein Mensch das Review durchführen. Sogar ponytail selbst hat /ponytail-review und /ponytail-audit als Absicherung – denn so regelkonform die KI auch ist, sie kann an einer Stelle „selbstbewusst faulenzen“. Regeln regeln das untere Niveau der KI, dein Review wacht über das obere.

Fazit

Der Wert von ponytail liegt nicht im „weniger Code schreiben“ an sich, sondern darin, dass es einen richtigen, aber inhaltsleeren Satz – „der beste Code ist der, der nie geschrieben wurde“ – zu einer Checkliste macht, die der Agent vor jedem Handeln abarbeitet. Mit einem Satz von Regeln bekämpft es die lästigste Eigenschaft von KI-Programmieragenten: Ein Problem, das eine Zeile braucht, mit 50 Zeilen zu lösen.

Aber für Nutzer ist das wirklich Lernenswerte nicht „dieses Plugin installieren“, sondern jene siebenstufige Leiter selbst: Bevor du irgendeinen Code schreibst, frag zuerst „muss das wirklich existieren?“. Diese Urteilskraft passt in einen Agenten – und sollte auch in deinen eigenen Kopf.

Referenzquellen

Offizielle ponytail-Website: https://ponytail.dev
GitHub-Repository: https://github.com/DietrichGebert/ponytail
Vollständiger Benchmark-Bericht: Im Repository unter benchmarks/results/2026-06-18-agentic.md