KI-News · Werkzeuge

Ponytail oder /simplify:
Vorbeugen oder Aufräumen.

13. September 2026 · Lesezeit ca. 11 Minuten

Beide Werkzeuge werben mit schlankerem Code. Nur greifen sie an verschiedenen Stellen im Arbeitsablauf ein. Ponytail ist ein Skill, der schon beim Schreiben fragt, ob der Code überhaupt nötig ist. /simplify ist ein Claude-Code-Befehl, der erst danach kommt und den fertigen Diff aufräumt. Ich habe dieselbe Aufgabe dreimal an PlantWiz gebaut, um zu sehen, was das in der Praxis unterscheidet.

Die Verwechslung liegt nahe, weil beide Werkzeuge dasselbe Wort im Mund führen: „vereinfachen“. Ponytail ist eine kurze Prüfleiter, die ein Agent vor dem Schreiben durchläuft: Gibt es das schon? Reicht eine Standardfunktion? Braucht es das überhaupt? /simplify dagegen ist ein Review-Befehl, der nach dem Schreiben auf den entstandenen Diff schaut und nach Wiederverwendung, Redundanz und unnötiger Komplexität sucht. Eine Frage steht vor dem Bauen, eine danach, und beide führen trotz desselben Ziels zu sehr unterschiedlichen Ergebnissen.

Diese Zahl allein ist irreführend. /simplify hat in meiner Messung ordentlich gearbeitet, nur an einer anderen Stelle als Ponytail, wie sich weiter unten zeigt.

Die Testaufgabe

Ticket, so knapp wie im Alltag üblich: „Sortierfunktion für die Pflanzenliste: Nutzer sollen die Pflanzen in ihrem Garten nach Name, Pflanzdatum oder Standort sortieren können.“ Bewusst eine offene Aufgabe ohne technische Vorgabe, damit beide Werkzeuge etwas zu tun haben. In PlantWiz gab es dafür noch keinen Code, aber ein bereits bestehendes Sortiermuster in derselben Datei (Sidebar.vue, die die Pflanzen eines Gartens nach Beet gruppiert auflistet) und einen bestehenden Test dafür.

Ponytail: die Frage kommt vor dem Code

An der Sortieraufgabe landete Ponytail auf Sprosse 4 („native Plattformfunktion reicht“) kombiniert mit Sprosse 2 („existiert das schon im Repository“): Ein natives <select> statt einer Dropdown-Bibliothek, und die Vergleichsfunktion des Sortierens wurde am bestehenden Array.sort-Muster der Datei ausgerichtet, statt neu zu erfinden. Ergebnis: 42 statt 173 Zeilen, kein neuer Store, keine neue Komponente, keine neue Abhängigkeit.

Die Basisvariante ohne Leiter hatte dagegen zusätzlich eine komplette zweite, parallele Darstellung gebaut: eine flache Liste über alle Pflanzen des Gartens für die neuen Sortiermodi, mit eigenem Markup, eigenen CSS-Klassen und einem eigenen Test. Fachlich richtig, nur eben mehr, als das Ticket verlangt hätte, und genau diesen Bau hat die Ponytail-Leiter verhindert, indem sie das bestehende Gruppierungs-Layout beibehielt und nur die Sortierreihenfolge innerhalb der Gruppen änderte.

Der entfallene Test für die parallele Darstellung ist dabei kein Vorteil an sich. Die Sortierfunktion hat drei neue, von außen sichtbare Fälle; sie brauchen weiterhin Tests. In diesem Fall würde ich den bestehenden Test um Name, Pflanzdatum und Standort erweitern, statt den Testaufwand pauschal zu reduzieren.

/simplify: die Frage kommt nach dem Code

Nachgemessen: derselbe Diff, ein Durchlauf danach

Um die beiden Werkzeuge fair zu vergleichen, habe ich nicht zwei unabhängige Implementierungen genommen, sondern denselben Ausgangsdiff: die 173-Zeilen-Basisvariante ohne Ponytail, in einem zweiten Worktree angewendet und dort mit /simplify bearbeitet.

/simplify fand vier reale Punkte:

• Doppelte Sortierlogik: zwei fast identische .sort()-Zweige mit demselben Fallback ließen sich zu einem Comparator zusammenfassen.
• Lineare Suche pro Zeile: die Zuordnung von Beet zu Namen lief pro gerenderter Pflanze über Array.find statt über eine vorbereitete Map.
• Doppeltes CSS: eine neue Zeilen-Klasse übernahm fast unverändert Regeln einer bereits vorhandenen Klasse.
• Der größte Befund, aber nicht angewendet: Die neue Liste war ein kompletter zweiter Render-Pfad mit dupliziertem Markup statt einer gemeinsamen Komponente mit optionalen Spalten. Der Skill hat das benannt, aber bewusst nicht umgesetzt, mit der Begründung, das sei ein strukturvoller Umbau außerhalb einer reinen Simplify-Korrektur.

Drei Fixes wurden angewendet, die Zeilenzahl sank kaum. Das liegt an der Funktionsweise von /simplify: Es macht bestehenden Code besser gelöst, ohne zu fragen, ob dieser Code überhaupt hätte gebaut werden müssen. Genau diese Frage stellt es beim übersprungenen Altitude-Befund erkennbar nicht. Ein Review-Befehl, der eigenmächtig Funktionsumfang strich, wäre bei einem echten Pull Request das größere Risiko, deshalb ist die Zurückhaltung dort sinnvoll.

Der Preis: eine echte Review-Runde statt eines Textbausteins

Ponytails Kosten sind vorhersehbar: eine feste Zahl an Tokens, die bei jedem Aufruf anfällt. /simplify kostet anders: Es stößt eine vollständige, mehrteilige Prüfung des Diffs an, in meinem Lauf entlang vier getrennter Kategorien. Das ist kein fixer Textbaustein im Kontext, sondern ein eigener Arbeitsschritt mit eigenem Tokenverbrauch, ungefähr in der Größenordnung einer kompletten weiteren Bearbeitung derselben Aufgabe. Dafür fällt dieser Aufwand nur an, wenn er bewusst ausgelöst wird, nicht bei jeder Codeaufgabe automatisch.

Direkter Vergleich

Wann welches Werkzeug

Die beiden Werkzeuge schließen sich nicht aus, sie beantworten unterschiedliche Fragen. Ponytail spart am ehesten dort, wo ein Agent sonst zu viel baut. /simplify verbessert, was bereits gebaut wurde, ändert aber nicht, ob es hätte gebaut werden sollen. Ein Team, das beides einsetzt, bekommt weniger unnötigen Code und saubereren nötigen Code, aber keines der beiden Werkzeuge ersetzt die Frage, die am Anfang eines Tickets stehen sollte: was hier eigentlich gebraucht wird.