Ponytail: Weniger Code mit einem KI-Coding-Agenten

Was Ponytail ist

Ponytail ist ein Regelsatz, der einen KI-Coding-Agent dazu bringt, weniger Code zu schreiben. Das Projekt beschreibt sich selbst in einem Satz: „Bringt Ihren KI-Agenten dazu, wie der faulste Senior-Entwickler im Raum zu denken. Der beste Code ist der Code, den Sie nie geschrieben haben.“ Es steht unter der MIT-Lizenz. Es hat keine eigene Laufzeitumgebung, und nichts darin wird ausgeführt. Es handelt sich um Text, der in die Anweisungen des Agenten aufgenommen wird. Für Hosts, die Skills laden, ist dieser Text als Skill paketiert. Für Hosts, die das nicht tun, liegt er als einfache Regeldateien vor.

Das Repository ist DietrichGebert/ponytail. Es wurde am 12. Juni 2026 erstellt und hatte bis zum 1. August 2026 mehr als 90,000 Sterne. Das neueste getaggte Release am 1. August 2026 ist v4.8.4. Es wurde am 29. Juni 2026 veröffentlicht. Die Releases-Seite listet allein zwischen dem 14. und 29. Juni zehn Tags auf. Ein Projekt, das sich so schnell weiterentwickelt, wird sich geändert haben, wenn Sie dies lesen. Legen Sie daher einen Tag fest, bevor Sie darauf aufbauen.

Die Idee vor dem Werkzeug: Steigen Sie an der ersten tragfähigen Stufe aus

Der Kern von Ponytail ist eine Entscheidungskaskade. Der Agent arbeitet sie durch, bevor er etwas schreibt, und stoppt an der ersten passenden Stufe.

1. Muss das überhaupt vorhanden sein? Das ist YAGNI (you are not going to need it). Wenn die Antwort nein lautet, lassen Sie es weg.
2. Ist es in dieser Codebasis bereits vorhanden? Verwenden Sie den vorhandenen Helper oder das vorhandene Muster erneut.
3. Erledigt die Standardbibliothek diese Aufgabe? Verwenden Sie sie.
4. Deckt eine native Plattformfunktion die Aufgabe ab? Verwenden Sie sie.
5. Löst eine bereits installierte Abhängigkeit das Problem? Verwenden Sie sie.
6. Kann es in einer Zeile stehen? Schreiben Sie es in einer Zeile.
7. Erst dann schreiben Sie den minimalen funktionierenden Code.

Die Reihenfolge erledigt die Arbeit, nicht eine einzelne Stufe. Ein Agent, der um einen Date-Picker gebeten wird, schreibt einen Date-Picker, weil genau das seine Aufgabe ist. Die Kaskade zwingt ihn, zuerst Stufe 4 zu prüfen. Dort steht, dass der Browser bereits <input type="date"> bereitstellt. Die eigenen Benchmark-Notizen des Projekts dokumentieren genau diesen Fall: Ein Date-Picker umfasste ohne diese Regel 404 Zeilen, mit der Regel dagegen 23 Zeilen, weil der Agent das native Eingabefeld verwendete, statt eine Komponente zu erstellen. Ein Color-Picker schrumpfte aus demselben Grund von 287 Zeilen auf 23 Zeilen. Stufe 2 versagt unauffällig, weil ein Agent, der den bereits vorhandenen Helper nicht sehen kann, bereitwillig einen zweiten schreibt. Genau diese Lücke soll eine abfragbare Übersicht Ihrer Codebasis schließen.

Faul bedeutet hier nicht nachlässig, und das Regelwerk sagt das ausdrücklich. Die Liste der Dinge, bei denen man „never lazy about“ sein soll, umfasst das Verständnis des Problems vor der Entscheidung, die Validierung von Eingaben an Vertrauensgrenzen, eine Fehlerbehandlung zur Vermeidung von Datenverlust, Sicherheit, Barrierefreiheit und alles, was Sie ausdrücklich verlangt haben. Außerdem soll für jedes Stück nichttrivialer Logik eine kleine ausführbare Prüfung vorhanden sein. Die Regel begrenzt Erfindungen. Sie beeinträchtigt nicht die Korrektheit.

Was das Repository tatsächlich ausliefert

• AGENTS.md, das dauerhaft aktive Regelwerk, das die gesamte Idee in einer Datei zusammenfasst, die Sie in fünf Minuten lesen können.
• skills/ponytail/SKILL.md, die Skill-Definition, mit einem Argument-Hinweis auf lite, full oder ultra.
• Regeldateien in editorspezifischen Verzeichnissen wie .cursor/rules/ und .windsurf/rules/ für Hosts, die Regeln lesen, aber keine Skills laden.
• hooks/, benchmarks/, examples/ und scripts/.

Das Intensitätsargument legt fest, wie stark die Regel durchgesetzt wird. lite erstellt, was Sie angefordert haben, und nennt in einer Zeile eine weniger strenge Option. full ist die Standardeinstellung und setzt die Stufenfolge durch. ultra ist die extreme YAGNI-Einstellung: Sie bevorzugt das Löschen gegenüber dem Hinzufügen und stellt sogar die Anforderung selbst infrage.

Hosts mit Skill-Unterstützung erhalten außerdem Slash-Befehle. /ponytail legt die Stufe fest, /ponytail-review prüft einen Diff auf Over-Engineering, /ponytail-audit prüft ein vollständiges Repository, /ponytail-debt sammelt die zurückgestellten Abkürzungen, und /ponytail-gain gibt die Benchmark-Bewertung aus. Hosts, die nur Regeldateien lesen, erhalten das Regelwerk ohne Befehle.

Wenn Sie den Quelltext prüfen möchten, bevor Sie ihm vertrauen, klonen Sie den Tag statt des Branches:

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

Für Claude Code dokumentiert das Projekt stattdessen die Installation als Plugin. Diese beiden Zeilen entsprechen dem Dokumentationsstand vom 1. August 2026:

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

Der Plugin-Pfad folgt dem Default-Branch statt einem Tag. Dadurch können sich die Anweisungen für Ihren Agenten zwischen Sitzungen ändern. Das ist der Nachteil für den Komfort eines Update-Befehls.

Warum ein zurückhaltender Agent auf einem VPS günstiger ist

Der Diff, den ein Agent schreibt, verlässt die Konversation nicht. Im nächsten Turn ist er wieder Kontext, den das Modell einliest, zusammen mit jeder Datei, die es dafür geöffnet hat. Eine Änderung mit 500 Zeilen belastet daher jeden späteren Turn in der Sitzung und nicht nur den Turn, in dem sie erstellt wurde. Deshalb wirkt ein ausuferndes Refactoring im weiteren Verlauf einer Sitzung immer langsamer und unzuverlässiger: Das Kontextfenster füllt sich mit der eigenen Ausgabe des Agents, sodass weniger Platz für Ihren eigentlichen Code bleibt. Genau darum geht es beim Verwalten des Kontextfensters eines Coding-Agents.

Tokens werden für Eingabe und Ausgabe abgerechnet. Ein Diff mit halber Größe ist daher doppelt günstiger: einmal beim Schreiben und danach bei jedem Turn, in dem er erneut eingelesen wird. Ob diese Einsparung überhaupt auf Ihrer Rechnung ankommt, hängt von Ihrem Abrechnungsmodell ab. Ein pauschales Pro- oder Max-Abonnement fängt zusätzliche Tokens ab, während eine tokenbasierte API-Abrechnung jeden einzelnen Token berechnet. Wenn Sie bei einem Self-Hosted-Setup die Kosten überwachen, ist die Anweisungsdatei ein kostenloser Stellhebel. Die Kosten eines AI-Agents zu kontrollieren beginnt bei der Ausgabemenge. Wie ein Coding-Agent seine Tokens verwendet erklärt, warum das erneute Einlesen stärker ins Gewicht fällt als erwartet.

Ein Mensch liest den Diff weiterhin. Eine Änderung mit 400 Zeilen, die 20 Zeilen hätte umfassen sollen, beansprucht die Aufmerksamkeit des Reviewers. Diese Aufmerksamkeit ist die Ressource, die zuerst knapp wird. Niemand prüft den vierten langen Diff des Tages mit derselben Sorgfalt wie den ersten. Übermäßig umfangreiche Änderungen kosten daher nicht nur Zeit. Sie verringern unbemerkt die Qualität des Reviews, das eigentlich die Fehler finden soll.

Auf einem Server ändern sich die Risiken, weil der Agent oft unbeaufsichtigt läuft. Ein Agent, der in einer tmux-Sitzung oder per Timer arbeitet, kann stundenlang auf einer falschen Entscheidung aufbauen, bevor Sie sie bemerken. Das ist das praktische Risiko beim Ausführen eines Coding-Agents auf einem VPS. Deshalb verwenden Personen, die Loop Engineering betreiben, so viel Sorgfalt auf die dauerhaften Anweisungen und nicht nur auf einzelne Prompts. Eine Regel in der dauerhaft geladenen Datei gilt auch für Turn 200. Eine Regel, die Sie im Chat eingegeben haben, gilt nur für Turn 3. Sie gilt außerdem für die zweite Sitzung, die Sie auf demselben System starten. Diese Sitzung liest die versionierte Datei, übernimmt aber nichts, was Sie in die erste Sitzung eingegeben haben, selbst wenn die beiden Sitzungen Nachrichten austauschen können.

Neue Abhängigkeiten verursachen weitere unauffällige Kosten. Regel 5 besagt, dass vorhandene Software verwendet werden soll. Jedes Paket, das ein Agent eigenständig hinzufügt, muss später von Ihnen aktualisiert werden. Außerdem landet es in jedem Container-Image, das Sie aus diesem Repository erstellen.

Was die eigenen Benchmark-Zahlen von Ponytail aussagen

Das Projekt veröffentlicht zwei Ergebnissätze, die deutlich voneinander abweichen. Beide Zahlen stammen aus den eigenen veröffentlichten Angaben des Projekts. Keine der beiden Auswertungen ist ein unabhängiger 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
  }
]

Die Spalte „Single Shot“ stammt von einem unveränderten Modell, das eine kleine Gruppe von Prompts mit und ohne die Regel beantwortet hat. Die Werte sind Mediane aus wiederholten Durchläufen vom 13. und 17. Juni 2026. Die Spalte „Agentic“ stammt aus einer Headless-Claude-Code-Sitzung, die tiangolos full-stack-fastapi-template bearbeitet hat. Dabei handelt es sich um ein echtes FastAPI- und React-Repository mit zwölf Feature-Tickets und jeweils vier Durchläufen mit Haiku 4.5. Bewertet wurde der zurückgebliebene Git-Diff.

Betrachten Sie die zweite Spalte. Das agentische Ergebnis verwendet 54 Prozent weniger Codezeilen, verursacht 20 Prozent geringere Kosten und benötigt 27 Prozent weniger Wandzeit. Im Single-Shot-Setup liegen die entsprechenden Werte bei 93 Prozent und 74 Prozent. Die README erklärt den Grund offen: Die Single-Shot-Baseline ist ein unverändertes Modell, das „mit mehreren Optionen und zusätzlichen Erläuterungen antwortet“. Das lässt sich leicht übertreffen. Vergleicht man stattdessen mit einem echten Agenten, der echte Aufgaben erledigt, fällt der Vorteil kleiner aus. Er bleibt jedoch real. Das ist die nützlichere Information.

Ein Vorbehalt stammt ebenfalls aus dem Projekt selbst. Er entscheidet darüber, ob dieser Ansatz für Sie hilfreich ist. Die Einsparung ist dort am größten, wo tatsächlich die Gefahr einer unnötig umfangreichen Implementierung besteht. Bei Code, der bereits minimal ist, liegt sie dagegen nahe null. Zwölf Tickets in einem Python- und TypeScript-Repository lassen keine verlässlichen Rückschlüsse auf Ihr Repository zu. Wenn diese Zahl für Sie relevant ist, führen Sie den Vergleich mit Ihren eigenen Tickets, mit und ohne die Regel, durch und zählen Sie die Zeilen selbst.

Das Muster, das Sie heute ohne Installation übernehmen können

Die Leiter besteht aus Text. Sie benötigen das Plugin daher nicht, um die Idee zu verwenden. Fügen Sie einen Block wie diesen in die Anweisungsdatei ein, die Ihr Agent bereits liest, unabhängig davon, ob es sich um AGENTS.md, CLAUDE.md oder die Regeldatei Ihres Editors handelt.

## 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 letzte Regel verdient eine eigene Betrachtung. Ponytails Konvention ist ein Kommentar, der mit dem Namen des Tools gekennzeichnet ist:

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

Der Kommentar erledigt zwei Arbeitsschritte und klärt eine Frage, die sonst einen Review-Zyklus kosten würde. Er teilt dem nächsten Leser mit, dass die einfache Version eine bewusste Entscheidung war, und nennt die Bedingung, unter der diese Entscheidung nicht mehr gilt. Ohne diesen Hinweis kann ein Reviewer nicht erkennen, ob es sich um eine überlegte Vereinfachung oder um etwas handelt, das der Agent vergessen hat. Daher muss er nachfragen.

Wo Sie den Block platzieren, ist ebenso wichtig wie sein Inhalt. Eine Datei, die der Agent bei jedem Lauf lädt, beeinflusst jeden Lauf, auch die Läufe, die Sie nicht überwachen. Dieser Unterschied ist das Thema von eine AGENTS.md schreiben, die Ihr Agent tatsächlich befolgt. Deshalb gehört dieses Muster in eine versionierte Datei und nicht in Ihre Shell-History. In einem Monorepo gehört es in mehr als eine versionierte Datei, weil eine AGENTS.md pro Paket die Regeln jedes Verzeichnisses kurz hält, statt den Agenten bei jedem Lauf die Konventionen des gesamten Verzeichnisbaums lesen zu lassen. Die Platzierung ist jedoch keine Garantie. Daher sollten Sie wissen, warum ein Agent eine bereits geladene Regel ignoriert, bevor Sie zu dem Schluss kommen, dass die Leiter eine strengere Formulierung benötigt.

Wo die Regel nicht mehr passt

Die Leiter ist auf Feature-Arbeit in einer bereits bestehenden Codebasis zugeschnitten. Dort ist Wiederverwendung normalerweise möglich und normalerweise korrekt. Für ein Greenfield-Projekt passt sie schlecht, weil es auf Stufe 2 nichts wiederzuverwenden und auf Stufe 5 nichts Installiertes gibt. Der Agent fällt daher jedes Mal auf Stufe 7 zurück. Sie passt auch in dem Moment schlecht, in dem Sie die Abstraktion tatsächlich benötigen. Wenn Sie gerade den vierten Aufrufer desselben kopierten Blocks hinzufügen wollen, liefert „kürzester Diff“ eine fünfte Kopie.

Die Ebene ultra stellt Ihre Anforderungen infrage. Dafür ist diese Ebene gedacht. Das verursacht reale Kosten, wenn Sie die Entscheidung bereits getroffen haben und die Arbeit erledigt werden soll. Verwenden Sie full für gewöhnliche Aufgaben. Greifen Sie zu ultra, wenn Sie vermuten, dass die Feature-Anforderung selbst das Problem ist.

Kein Anweisungsblock bewahrt Sie vor einem falschen Verständnis des Problems. Der erste Punkt des Regelwerks besteht selbst darin, den Code vor der Entscheidung zu verstehen. Das ist der aufwendige Teil, den der Text nicht für Sie erledigen kann. Ein minimaler Diff in der falschen Funktion ist weiterhin die falsche Korrektur. Jetzt ist es lediglich eine kleine falsche Korrektur, die sich leicht genehmigen lässt.

Die ehrliche Zusammenfassung lautet: Ponytail ist ein sorgfältig formulierter Prompt, der gut verteilt und mit Zahlen versehen wurde. Nichts daran erfordert das Plugin. Das Projekt bietet Ihnen, dass jemand die Liste korrekt geschrieben, an einem echten Repository getestet und die Methode zusammen mit dem Ergebnis veröffentlicht hat.

FAQ

Funktioniert Ponytail mit anderen Agents als Claude Code?

Ja. Ponytail wird als Skill für Hosts bereitgestellt, die Skills laden. Dazu gehören Claude Code, Codex, OpenCode, Gemini und mehrere weitere, die in der README genannt werden. Editoren, die Regeldateien lesen, aber keine Skills laden, beispielsweise Cursor, Windsurf, Cline und Copilot, verwenden das Always-on-Regelwerk aus dem passenden Regelverzeichnis und erhalten keine Slash-Befehle. Der Text ist in beiden Fällen identisch. Der tatsächliche Unterschied besteht darin, ob Ihr Host diesen Text bei jedem Durchlauf im Kontext behält oder nur dann lädt, wenn ein Skill ausgelöst wird.

Überspringt ein lazy Agent Tests, Validierung oder Security?

Nein. Das Regelwerk stellt dies ausdrücklich klar. Die Liste der Punkte, bei denen der Agent „nie lazy“ sein soll, nennt die Eingabevalidierung an Vertrauensgrenzen, eine Fehlerbehandlung zur Vermeidung von Datenverlust sowie Security und Barrierefreiheit. Außerdem fordert sie für jedes Stück nichttrivialer Logik eine kleine, ausführbare Prüfung. Entfernt wird durch die Regel lediglich erfundene Struktur: Abstraktionen, die niemand angefordert hat, und Abhängigkeiten, die niemand benötigt. Wenn Ihr Agent nach der Installation Tests auslässt, hat eine andere Anweisung in Ihrer eigenen Konfiguration Vorrang vor dieser Regel. Lesen Sie daher die Datei, die der Agent zuletzt lädt.

Sind die veröffentlichten Angaben zu Geschwindigkeit und Kosten vertrauenswürdig?

Es handelt sich um die eigenen Messungen des Projekts, die zusammen mit der verwendeten Methode veröffentlicht wurden. Sie sollten entsprechend eingeordnet werden. Die Werte für einzelne Durchläufe vergleichen das Ergebnis mit einem einfachen Modell, das mit Optionen und Kommentaren antwortet. Die README weist selbst darauf hin, dass dies eine schwache Vergleichsbasis ist. Die agentischen Werte stammen aus einer Headless-Claude-Code-Sitzung mit einem FastAPI- und React-Repository, zwölf Tickets und jeweils vier Durchläufen mit Haiku 4.5. Für diese Konfiguration sind die Zahlen aussagekräftig. Sie sind jedoch keine Prognose für Ihre Codebasis, da das Projekt ebenfalls angibt, dass die Einsparung bei Code, der bereits minimal gehalten wurde, auf nahezu null sinkt.

Muss ich etwas installieren, um den Vorteil zu erhalten?

Nein. Das Regelwerk besteht aus Text. Ein gleichwertiger Block, den Sie in die von Ihrem Agent bereits gelesene Anweisungsdatei einfügen, liefert den größten Teil des Effekts. Das Plugin stellt den gepflegten Wortlaut, die Intensitätsstufen, die Review-Befehle und einen Aktualisierungspfad bereit. Den kopierten Block zuerst auszuprobieren, ist auf rung 1 die Antwort auf die Frage, ob die Installation überhaupt erforderlich ist.

Wie verhindere ich, dass ein unbeaufsichtigter Agent über Nacht zu viel baut?

Legen Sie die Regel in die Always-on-Anweisungsdatei statt in eine Chatnachricht. Dadurch gilt sie auch bei Durchlauf 200 eines langen Runs und nicht nur bei Durchlauf 3. Begrenzen Sie den möglichen Schaden zusätzlich: Geben Sie dem Agent einen Checkout, den er beschädigen darf, statt Ihrer einzigen Kopie. Verlangen Sie außerdem eine manuelle Diff-Prüfung, bevor etwas zusammengeführt wird. Eine Regel für minimale Diffs reduziert den Umfang, den Sie lesen müssen. Sie entscheidet nicht, was übernommen wird, und sollte das auch nicht tun.