Ponytail: Weniger Code für KI-Coding-Agenten

Was Ponytail ist

Ponytail ist ein Regelsatz, der einen KI-Coding-Agenten dazu bringt, weniger Code zu schreiben. Das Projekt beschreibt sich selbst in einem Satz: „Macht Ihren KI-Agenten zum faulsten Senior-Entwickler im Raum. 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 übernommen wird. Für Hosts, die Skills laden, ist er 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. Die neueste getaggte Version am 1. August 2026 ist v4.8.4. Sie wurde am 29. Juni 2026 veröffentlicht. Die Releases-Seite führt allein zwischen dem 14. und 29. Juni zehn Tags auf. Ein Projekt, das sich in diesem Tempo weiterentwickelt, wird sich bis zum Zeitpunkt Ihrer Lektüre geändert haben. Legen Sie daher einen Tag fest, bevor Sie darauf aufbauen.

Die Idee vor dem Werkzeug: Bei der ersten tragfähigen Stufe anhalten

Der Kern von Ponytail ist eine Entscheidungskaskade. Der Agent arbeitet sie durch, bevor er etwas schreibt, und hält bei der ersten zutreffenden Stufe an.

1. Muss das überhaupt existieren? Das ist YAGNI (you are not going to need it). Wenn die Antwort nein lautet, überspringen Sie es.
2. Existiert es bereits in dieser Codebasis? 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 eine Zeile sein? Machen Sie daraus eine Zeile.
7. Erst dann schreiben Sie den minimalen funktionierenden Code.

Die Reihenfolge bewirkt die Änderung, 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 veranlasst ihn, zuerst Stufe 4 zu prüfen. Stufe 4 zeigt, dass der Browser bereits <input type="date"> enthält. 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 input verwendete, statt eine Komponente zu entwickeln. Ein Colour Picker schrumpfte aus demselben Grund von 287 Zeilen auf 23 Zeilen.

„Lazy“ bedeutet hier nicht nachlässig, und das Regelwerk sagt dies direkt. Die Liste „never lazy about“ umfasst das Verständnis des Problems vor der Entscheidung, die Validierung von Eingaben an Vertrauensgrenzen, eine Fehlerbehandlung, die Datenverlust verhindert, Sicherheit, Barrierefreiheit und alles, was Sie ausdrücklich angefordert haben. Außerdem wird für jedes Stück nichttrivialer Logik eine kleine ausführbare Prüfung verlangt. Die Regel reduziert eigene Erfindungen. Sie reduziert nicht die Korrektheit.

Was das Repository tatsächlich veröffentlicht

• 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 Argumenthinweis 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 aufwendige Option. full ist die Standardeinstellung und setzt die Abstufung durch. ultra ist die kompromisslose 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 Überkomplexität, /ponytail-audit prüft ein gesamtes Repository, /ponytail-debt sammelt die zurückgestellten Abkürzungen, und /ponytail-gain gibt die Benchmark-Auswertung aus. Hosts, die nur Regeldateien lesen, erhalten das Regelwerk ohne Befehle.

Wenn Sie den Quellcode 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 eine Plugin-Installation. Diese beiden Zeilen entsprechen dem Stand der Dokumentation vom 1. August 2026:

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

Der Plugin-Pfad folgt dem Standard-Branch statt einem Tag. Dadurch können sich die Anweisungen, die Ihren Agenten steuern, zwischen Sitzungen ändern. Das ist der Preis für die Bequemlichkeit eines Update-Befehls.

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

Der Diff, den ein Agent schreibt, verlässt die Unterhaltung nicht. Im nächsten Turn ist er wieder Teil des Kontexts, den das Modell liest, 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, nicht nur den Turn, in dem sie erstellt wurde. Deshalb wirkt ein außer Kontrolle geratener Refactor im Verlauf der Sitzung immer langsamer und weniger leistungsfähig: Das Kontextfenster füllt sich mit der eigenen Ausgabe des Agents, sodass weniger Platz für Ihren tatsächlichen Code bleibt. Dies zu kontrollieren, ist das zentrale Thema von der Verwaltung des Kontextfensters eines Coding-Agents.

Tokens werden für Eingabe und Ausgabe berechnet. Ein Diff, der halb so groß ist, kostet daher zweimal weniger: einmal beim Schreiben und erneut bei jedem Turn, in dem er wieder gelesen wird. Wenn Sie bei einem selbst gehosteten Setup die Kosten überwachen, ist die Instruktionsdatei ein kostenloser Stellhebel. Die Kosten eines AI-Agents kontrollieren beginnt mit dem Ausgabevolumen, und wie ein Coding-Agent seine Tokens verwendet erklärt, warum das erneute Lesen wichtiger ist als erwartet.

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

Auf einem Server ändern sich die Risiken, weil der Agent häufig unbeaufsichtigt läuft. Ein Agent, der in einer tmux-Sitzung oder nach einem Zeitplan arbeitet, hat Stunden, um eine Fehlentscheidung weiter auszubauen, bevor Sie sie bemerken. Das ist das praktische Risiko beim Ausführen eines Coding-Agents auf einem VPS. Deshalb legen Personen, die Loop Engineering betreiben, so viel Wert auf die dauerhaften Instruktionen und nicht nur auf einzelne Prompts. Eine Regel in der ständig geladenen Datei gilt für Turn 200. Eine Regel, die Sie im Chat eingegeben haben, gilt für Turn 3.

Neue Abhängigkeiten verursachen weitere versteckte Kosten. Rung 5 bedeutet, dass die vorhandenen Komponenten verwendet werden sollen. Jedes Paket, das ein Agent eigenständig hinzufügt, müssen Sie später patchen. 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. Diese weichen stark voneinander ab. Beide Zahlen stammen aus den eigenen Veröffentlichungen des Projekts. Keine davon basiert auf einem unabhängigen 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 „Einzelantwort“ stammt von einem Basismodell, das eine kleine Gruppe von Prompts mit und ohne die Regel beantwortet. Angegeben sind Mediane aus wiederholten Durchläufen vom 13. und 17. Juni 2026. Die Spalte „Agent“ stammt aus einer zustandslosen 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 Agent-Ergebnis benötigt 54 Prozent weniger Codezeilen, verursacht 20 Prozent geringere Kosten und benötigt 27 Prozent weniger Zeit. In der Einzelantwort-Konfiguration betragen die entsprechenden Werte 93 Prozent und 74 Prozent. Die README erklärt den Grund offen: Die Einzelantwort-Baseline ist ein Basismodell, das „mit mehreren Optionen und zusätzlichen Erläuterungen antwortet“. Das lässt sich leicht übertreffen. Vergleicht man das Ergebnis mit einem echten Agenten, der echte Aufgaben bearbeitet, fällt der Vorteil kleiner aus. Er bleibt jedoch real. Das ist die nützlichere Aussage.

Ein Vorbehalt stammt ebenfalls aus dem Projekt selbst. Er entscheidet darüber, ob dies für Sie hilfreich ist. Die Einsparung ist dort am größten, wo tatsächlich die Gefahr einer übermäßig umfangreichen Implementierung besteht. Bei Code, der bereits minimal ist, liegt sie nahezu bei null. Zwölf Tickets in einem einzelnen Python- und TypeScript-Repository lassen keine verlässliche Aussage über Ihr Repository zu. Wenn die Zahl für Sie wichtig ist, führen Sie den Vergleich mit Ihren eigenen Tickets, mit und ohne die Regel, durch. Zählen Sie die Zeilen selbst.

Das Muster, das Sie heute ohne Installation kopieren können

Die Leiter ist Text. Sie benötigen daher kein Plugin, 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. Ponytail verwendet dafür einen Kommentar, der mit dem Namen des Tools gekennzeichnet ist:

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

Der Kommentar umfasst zwei Arbeitszeilen. Er 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. Außerdem nennt er die Bedingung, unter der diese Entscheidung nicht mehr gilt. Ohne diesen Hinweis kann ein Reviewer eine bewusst gewählte Vereinfachung nicht von etwas unterscheiden, das der Agent vergessen hat. Daher muss er nachfragen.

Es ist ebenso wichtig, wo Sie den Block platzieren, wie was darin steht. Eine Datei, die der Agent bei jedem Lauf lädt, beeinflusst jeden Lauf, auch die Läufe, die Sie nicht überwachen. Dieser Unterschied wird unter eine AGENTS.md schreiben, die Ihr Agent tatsächlich befolgt behandelt. Deshalb gehört dieses Muster in eine versionierte Datei und nicht in Ihre Shell-History.

Wo die Regel nicht mehr gilt

Die Abstufung ist auf Feature-Arbeiten in einer bereits vorhandenen Codebasis ausgelegt, in der Wiederverwendung meist möglich und meist korrekt ist. Für ein Greenfield-Projekt passt sie schlecht, weil es auf Stufe 2 nichts wiederzuverwenden gibt und auf Stufe 5 nichts installiert ist. Der Agent fällt daher jedes Mal auf Stufe 7 zurück. Sie passt auch schlecht, wenn Sie die Abstraktion tatsächlich benötigen. Wenn Sie gerade den vierten Aufrufer desselben kopierten Blocks hinzufügen wollen, führt „kürzester Diff“ zu einer fünften Kopie.

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

Kein Anweisungsblock schützt Sie vor einer falschen Einschätzung 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 Ihnen nicht abnehmen kann. Ein minimaler Diff in der falschen Funktion ist weiterhin die falsche Korrektur. Jetzt ist es 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 liefert Ihnen, dass jemand die Liste ordnungsgemäß erstellt, 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, etwa 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 gleich. Der tatsächliche Unterschied besteht darin, ob der Host diesen Text bei jedem Durchlauf im Kontext behält oder nur ausführt, wenn ein Skill ausgelöst wird.

Überspringt ein nachlässiger Agent Tests, Validierung oder Sicherheitsprüfungen?

Nein. Das Regelwerk stellt dies ausdrücklich fest. Die Liste der Punkte, bei denen der Agent „niemals nachlässig“ sein soll, nennt die Eingabevalidierung an Vertrauensgrenzen, eine Fehlerbehandlung, die Datenverlust verhindert, Sicherheit und Barrierefreiheit. Außerdem wird für jede nicht triviale Logik mindestens eine kleine ausführbare Prüfung verlangt. Entfernt wird durch die Regel nur eine 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 Werte für Geschwindigkeit und Kosten zuverlässig?

Es handelt sich um eigene Messungen des Projekts, die zusammen mit der Messmethode veröffentlicht wurden. Sie sollten entsprechend eingeordnet werden. Die Werte für einzelne Durchläufe vergleichen das Ergebnis mit einem unveränderten Modell, das mit Optionen und Kommentaren antwortet. Die README kennzeichnet dies selbst als schwache Vergleichsbasis. Die Agentenwerte stammen aus einer zustandslosen Claude Code-Sitzung in einem FastAPI- und React-Repository mit zwölf Tickets und jeweils vier Durchläufen unter Haiku 4.5. Für diese Konfiguration sind die Werte aussagekräftig. Sie sind jedoch keine Prognose für Ihre Codebasis. Das Projekt weist ebenfalls darauf hin, dass die Einsparung bei Code, der bereits minimal war, auf nahezu null sinkt.

Muss ich etwas installieren, um den Vorteil zu erhalten?

Nein. Die Grundlage ist Text. Ein gleichwertiger Block, der in die Anweisungsdatei eingefügt wird, die Ihr Agent bereits liest, erzielt den größten Teil der Wirkung. Das Plugin bietet die gepflegte Formulierung, die Intensitätsstufen, die Review-Befehle und einen Aktualisierungspfad. Den kopierten Block zuerst zu testen, 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 Chat-Nachricht. Dann gilt sie auch bei Durchlauf 200 eines langen Laufs und nicht nur bei Durchlauf 3. Begrenzen Sie den möglichen Schaden zusätzlich: Geben Sie dem Agenten ein Checkout, das 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 verringert den Umfang, den Sie lesen müssen. Sie entscheidet nicht, was übernommen wird, und sollte das auch nicht tun.