Ponytail: Weniger Code für AI-Coding-Agents

Was Ponytail ist

Ponytail ist ein Regelsatz, der einen AI-Coding-Agent dazu bringt, weniger Code zu schreiben. Das Projekt beschreibt sich selbst in einem Satz: „Macht Ihren AI-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 besitzt keine eigene Laufzeitumgebung, und nichts darin wird ausgeführt. Es handelt sich um Text, der in die Anweisungen des Agents übernommen wird. Für Hosts, die Skills laden, ist er als Skill paketiert. Für Hosts ohne Skill-Unterstützung liegt er als einfache Regeldatei 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. Am 1. August 2026 war v4.8.4 das neueste getaggte Release. Es wurde am 29. Juni 2026 veröffentlicht. Auf der Releases-Seite waren allein zwischen dem 14. und 29. Juni zehn Tags aufgeführt. Die Entwicklung hat sich nicht verlangsamt: Am 17. Oktober 2026 ist v5.3.2 das neueste Release. Es wurde am späten 16. Oktober veröffentlicht und war an diesem Tag das dritte Release nach v5.3.0 und v5.3.1. Zuvor wurde am 13. Oktober v5.2.0 veröffentlicht. Fünf Tage davor wurden am 8. Oktober sowohl v5.0.0 als auch v5.1.0 veröffentlicht. Das Repository weist inzwischen mehr als 165.000 Sterne auf. Ein Projekt mit dieser Entwicklungsgeschwindigkeit wird sich verä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

Das Grundprinzip von Ponytail ist eine Entscheidungstreppe. Der Agent arbeitet sie ab, bevor er etwas schreibt, und steigt an der ersten tragfähigen Stufe aus.

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 bereits verwendete 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 eine Zeile daraus.
7. Erst dann schreiben Sie den minimalen funktionierenden Code.

So ist die Treppe bei v4.8.4 beschrieben, und die Stufennummern im restlichen Artikel folgen dieser Einteilung. Der aktuelle Main-Branch fasst die Stufen 3 und 4 zu einer Stufe zusammen: „Standardbibliothek oder Plattformfunktion? Verwenden Sie sie, sofern das Projekt keine eigene Lösung hat.“ Außerdem ergänzt er: „Eine projektspezifische Komponente ist besser als ein natives Widget.“ Damit hat die Treppe sechs Stufen. Die Reihenfolge bleibt gleich.

Die Reihenfolge ist entscheidend, nicht eine einzelne Stufe. Wenn ein Agent nach einem Date-Picker gefragt wird, schreibt er einen Date-Picker, weil genau das seine Aufgabe ist. Die Treppe zwingt ihn, vor dem Erstellen zu prüfen, was bereits vorhanden ist: Stufe 2 fragt, ob das Repository bereits eine passende Komponente enthält, und Stufe 4 weist darauf hin, dass der Browser bereits <input type="date"> bereitstellt. Die aktuellen Benchmark-Notizen des Projekts dokumentieren genau diesen Fall: Ein Date-Picker, der ohne diese Regel 335 Zeilen umfasste, kam mit Ponytail 5 auf 10 Zeilen, weil der Agent die eigene Input-Komponente des Repositorys mit type="date" wiederverwendete und den Kalender vom Browser bereitstellen ließ. Ein Color-Picker schrumpfte weniger stark, von 135 Zeilen auf 26. Stufe 2 scheitert unauffällig, weil ein Agent, der den bereits vorhandenen Helper nicht erkennt, problemlos einen zweiten schreibt. Diese Lücke soll eine abfragbare Übersicht Ihrer Codebasis schließen.

Lazy bedeutet hier nicht nachlässig, und das sagt das Regelwerk ausdrücklich. 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 verlangt sie für jede nicht triviale Logik eine kleine ausführbare Prüfung. Die Regel reduziert Erfindungen. Sie reduziert nicht die Korrektheit.

Was das Repository tatsächlich ausliefert

• AGENTS.md, das ständig 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, ultra oder off.
• 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 bestimmt, wie streng die Regel durchgesetzt wird. lite setzt Ihre Vorgaben um und nennt in einer Zeile eine weniger strenge Option. full ist die Standardeinstellung und setzt die Stufenfolge durch. ultra ist die radikale 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 Overengineering, /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. Seit v5.3.0, veröffentlicht am 16 October 2026, zeigt Claude Code außerdem ein Band oberhalb der Eingabeaufforderung an, das Aufgabenkosten, Code-Wiederverwendung und Teststatus ausweist. Dafür ist Claude Code 2.1.290 oder neuer erforderlich. Es wird nicht im VS Code-Chatfenster, in Cloud-Sitzungen oder in claude -p angezeigt, und /ponytail band off blendet es aus. Seit v5.3.2 liest /ponytail band import Ihre bisherigen Claude Code-Sitzungen einmalig ein und fügt sie mit ihren Kosten, der Agentenlaufzeit und der Token-Anzahl zur Übersicht hinzu. So können Sie sie mit Sitzungen vergleichen, die unter der Regel ausgeführt wurden.

Wenn Sie den Quelltext prüfen möchten, bevor Sie ihm vertrauen, klonen Sie den Tag statt des Branches. Von diesem Tag stammt die oben beschriebene Stufenfolge. Ersetzen Sie ihn durch v5.3.2, den neuesten Stand vom 17 October 2026, um den aktuellen Wortlaut zu lesen:

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 der Dokumentation vom 17 October 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. Diesen Nachteil akzeptieren Sie zugunsten der bequemeren Aktualisierung per Befehl.

Warum ein zurückhaltender Agent auf einem VPS weniger kostet

Der Diff, den ein Agent schreibt, verlässt die Unterhaltung nicht. Beim nächsten Zug gehört er zusammen mit jeder Datei, die der Agent dafür geöffnet hat, erneut zu dem Kontext, den das Modell liest. Eine Änderung mit 500 Zeilen belastet deshalb jeden späteren Zug der Sitzung, bis die Komprimierung die älteren Züge durch eine Zusammenfassung ersetzt. Sie belastet nicht nur den Zug, in dem sie erstellt wurde. Deshalb wirkt ein Agent bei einer ausufernden Umstrukturierung im Verlauf der Sitzung langsamer und weniger leistungsfähig: Das Kontextfenster füllt sich mit der eigenen Ausgabe des Agents, sodass weniger Platz für Ihren eigentlichen Code bleibt. Das Kontextfenster eines Coding-Agents verwalten ist das zentrale Thema, wenn Sie dies kontrollieren möchten.

Tokens werden für Eingabe und Ausgabe abgerechnet. Ein Diff mit halber Größe ist daher doppelt günstiger: einmal beim Schreiben und erneut bei jedem Zug, in dem er wieder eingelesen wird. Ob diese Einsparung auf Ihrer Rechnung ankommt, hängt vom Abrechnungsmodell ab. Ein Pro- oder Max-Abonnement übernimmt die zusätzlichen Tokens nur bis zu seinen Nutzungslimits. Danach werden optional aktivierte Nutzungsguthaben separat berechnet. Bei einer API-Abrechnung pro Token zahlen Sie dagegen für jedes einzelne Token. Wenn Sie bei einem Self-Hosting-Setup die Kosten beobachten, ist die Anweisungsdatei ein kostenloser Stellhebel. Die Kosten eines AI-Agents kontrollieren beginnt mit dem Ausgabevolumen. Wie ein Coding-Agent seine Tokens verwendet erklärt, warum das erneute Einlesen wichtiger ist, als viele erwarten.

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 erschöpft ist. 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 die Fehler eigentlich erkennen 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, kann über Stunden auf einer fehlerhaften 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 für Zug 200. Eine Regel, die Sie im Chat eingegeben haben, gilt für Zug 3. Sie gilt außerdem für die zweite Sitzung, die Sie auf demselben Rechner starten. Diese Sitzung liest die versionierte Datei, übernimmt aber keine Eingaben aus der ersten Sitzung, auch dann nicht, wenn die beiden Sitzungen Nachrichten austauschen können.

Neue Abhängigkeiten verursachen weitere versteckte Kosten. Stufe 5 besagt, dass Sie bereits installierte Komponenten verwenden sollen. Jedes Paket, das ein Agent eigenständig hinzufügt, müssen Sie später aktualisieren. Außerdem landet es in jedem Container-Image, das Sie aus diesem Repository erstellen.

Was die eigenen Benchmark-Zahlen von Ponytail aussagen

Das Projekt hat zwei Arten von Ergebnissen veröffentlicht, die stark voneinander abweichen. Beide Zahlen stammen aus den eigenen Veröffentlichungen des Projekts. Keine davon basiert auf einem unabhängigen Test.

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

Die Grafik zeigt den aktuellen agentischen Benchmark des Projekts vom 7. Oktober 2026. Headless-Claude-Code-2.1.288-Sitzungen mit Opus 5.5 bei standardmäßigem Aufwand bearbeiteten 39 Aufgaben. Pro Aufgabe und Variante gab es fünf Durchläufe, insgesamt 585 Sitzungen mit keiner Skill, Ponytail v4.13.0 und Ponytail 5. Zwölf Aufgaben waren Feature-Tickets in tiangolos full-stack-fastapi-template, einem echten FastAPI- und React-Repository. Bewertet wurde anhand des zurückgelassenen Git-Diffs. Die übrigen Aufgaben umfassten 18 chirurgische Aufgaben mit verborgenen Prüfungen, sechs Anfragen für kleine Anwendungen und drei Anfragen nach dem Muster „Zeige mir ein Beispiel“. Bash war in allen Varianten deaktiviert. Mit Ponytail 5 sank die Zahl der Ausgabetokens um 45 Prozent.

Vergleichen Sie diese Ergebnisse mit den Einzeldurchlaufzahlen, die das Projekt im Juni 2026 veröffentlicht hat. Diese basierten auf einem unveränderten Modell, das fünf alltägliche Prompts mit und ohne die Regel beantwortete. Angegeben wurden Mediane aus wiederholten Durchläufen. Für Haiku, Sonnet und Opus ergaben sich 80 bis 94 Prozent weniger Code. Die am 17. Juni 2026 datierte Kostenprüfung kam bei Haiku auf eine Kostenersparnis von 63 Prozent. Das aktuelle agentische Ergebnis für Ponytail 5 liegt bei 53 Prozent weniger Codezeilen, 26 Prozent niedrigeren Kosten und 41 Prozent weniger Wandzeit. Das Projekt korrigierte die Einzeldurchlaufzahl schnell. Am v4.8.4, dem 29. Juni 2026, stellte die README bereits das agentische Ergebnis heraus: „~54% less code (up to 94%)“. Zusätzlich wurde erklärt, dass die früheren 80 bis 94 Prozent „the per-task ceiling, not the average“ waren. Die Einzeldurchlaufzahlen wurden in einen eingeklappten Abschnitt mit dem Titel „Older single-shot numbers“ verschoben. Dieser Abschnitt erklärte den Grund für die Abweichung offen: Die Einzeldurchlauf-Baseline basiert auf einem unveränderten Modell, das „pads its answer with prose and options“. Das ist leicht zu übertreffen. Wird stattdessen ein echter Agent bei echter Arbeit gemessen, fällt der Vorteil geringer aus. Er bleibt jedoch real. Das ist die nützlichere Aussage. Der agentische Lauf im Juni umfasste zwölf Tickets mit Haiku 4.5 und jeweils vier Durchläufen. Er lag mit 54 Prozent weniger Codezeilen nahe am heutigen Ergebnis. Die aktuelle README enthält die Einzeldurchlaufzahlen überhaupt nicht mehr.

Ein Vorbehalt stammt ebenfalls vom Projekt selbst. Er entscheidet darüber, ob diese Methode für Sie nützlich ist. Die Ersparnis ist dort am größten, wo tatsächlich die Gefahr einer übermäßig umfangreichen Implementierung besteht. Bei Code, der bereits minimal war, liegt sie dagegen nahe null. Die aufgabenbezogene Tabelle für Oktober bestätigt das. Bei mehreren chirurgischen Aufgaben war die Zeilenzahl in allen drei Varianten identisch. 39 Aufgaben mit einem Modell und auf einem Host, bei deaktiviertem Bash, lassen keine Rückschlüsse auf Ihr Repository zu. Wenn diese Zahl für Sie relevant ist, führen Sie den Vergleich mit Ihren eigenen Tickets sowie mit und ohne die Regel durch. 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 in den aktuellen Releases ist ein mit shortcut: markierter Kommentar, der das Limit und den Zeitpunkt für ein Upgrade nennt. In den Juni-Releases, einschließlich v4.8.4, war er stattdessen mit ponytail: markiert:

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

Der Kommentar erfordert zwei Zeilen Arbeit 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 den Kommentar 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 genauso wichtig wie sein Inhalt. Eine Datei, die der Agent bei jedem Lauf lädt, steuert 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 überspringt, 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 ausgelegt, in der Wiederverwendung meistens möglich und meistens richtig ist. Für ein Greenfield-Projekt passt sie weniger gut, weil es auf Ebene 2 nichts zur Wiederverwendung gibt und auf Ebene 5 nichts installiert ist. Der Agent kann weiterhin auf Ebene 1, bei der Standardbibliothek, einer Plattformfunktion oder einer Einzeile anhalten. Zwei der günstigsten Auswege entfallen jedoch, sodass mehr Aufgaben beim Schreiben neuen Codes landen. Sie passt auch schlecht zu dem Zeitpunkt, an 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. Wenn Sie die Entscheidung bereits getroffen haben und die Arbeit erledigt werden soll, verursacht das allerdings reale Kosten. 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 lautet selbst, dass der Code vor der Entscheidung verstanden werden muss. Das ist der aufwendige Teil, den Ihnen der Text nicht abnehmen kann. Ein minimaler Diff in der falschen Funktion bleibt die falsche Lösung. Nun ist es eine kleine falsche Lösung, die sich leicht genehmigen lässt.

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

FAQ

Funktioniert Ponytail auch mit Agents außer 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, übernehmen das dauerhaft aktive Regelwerk aus dem passenden Rules-Verzeichnis und erhalten keine Slash-Befehle. Der Text ist in beiden Fällen gleich. Der entscheidende Unterschied besteht darin, ob der Host diesen Text bei jeder Interaktion im Kontext behält oder nur aktiviert, wenn ein Skill ausgelöst wird.

Überspringt ein fauler Agent Tests, Validierung oder Sicherheitsprüfungen?

Nein. Das Regelwerk sagt dies ausdrücklich. Die Liste „niemals nachlässig bei“ nennt die Eingabevalidierung an Vertrauensgrenzen, eine Fehlerbehandlung zur Vermeidung von Datenverlust sowie Sicherheit und Barrierefreiheit. Außerdem fordert sie für jedes Stück nichttrivialer Logik eine kleine ausführbare Prüfung. Entfernt wird 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 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 Einzelaufrufwerte aus June 2026 wurden mit einem Basismodell verglichen, das seine Antwort mit Prosa und Optionen verlängerte. Die README bezeichnete diesen Vergleich zu diesem Zeitpunkt selbst als schwache Baseline. Die aktuellen agentischen Werte stammen aus headless Claude Code-Sitzungen mit Opus 5.5. Es wurden 39 Aufgaben jeweils fünfmal ausgeführt. Zwölf davon waren Feature-Tickets in einem FastAPI- und React-Repository. Für diese Konfiguration sind die Werte aussagekräftig. Sie sind keine Prognose für Ihre Codebasis. Die eigenen Ergebnisse pro Aufgabe zeigen, dass die Einsparung bei bereits minimalem Code auf nahezu null sinkt.

Muss ich etwas installieren, um davon zu profitieren?

Nein. Die Leiter besteht aus 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 den gepflegten Wortlaut, die Intensitätsstufen, die Review-Befehle und einen Update-Pfad. Den kopierten Block zuerst auszuprobieren, ist die Antwort von Stufe 1 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 dauerhaft aktive Anweisungsdatei statt in eine Chatnachricht. So gilt sie auch bei Interaktion 200 eines langen Laufs und nicht nur bei Interaktion 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 gemergt wird. Eine Regel für minimale Diffs reduziert den Umfang dessen, was Sie lesen müssen. Sie entscheidet nicht, was übernommen wird, und sollte das auch nicht tun.