Wir geben Coding-Agenten jeden Tag echte Tickets, und sie liefern fast immer etwas ab, das funktioniert. Das war nie die Sorge. Die Sorge ist, wie sie arbeiten: ein neuer Helper neben drei, die den Job schon erledigen, eine frische Abstraktion für einen einzigen Aufrufer, ein Fix, der den einen im Ticket genannten Pfad patcht und vier Geschwister kaputt zurücklässt, ein Fund, der „wahrscheinlich ein Bug" ist, ohne Beleg in die eine oder andere Richtung. Jede Änderung ist lokal vernünftig. In der Summe sind sie Entropie.
TL;DR: Über fünf Tier-3-Pull-Requests an unserem Agent-Orchestrierungs-Kern entfernten drei kombinierbare Skills –
ponytail(subtrahieren),grain(ausrichten) undreview-proof(beweisen) – 821 Zeilen, während fünf Features ausgeliefert wurden, fingen einen stillen Vertragsbruch ab, den reine Plausibilität gemergt hätte, und hielten jede Änderung im Fluss der bestehenden Architektur. Hier steht, was jeder einzelne tut – mit den echten Diffs als Beleg.
Nimm die Leitplanken weg, und ein Coding-Agent ist ein sehr schneller Generator plausibel aussehender Altlasten. Deshalb setzen wir auf drei kleine Skills, die in die andere Richtung drücken – je einen Instinkt: subtrahieren, ausrichten, beweisen.
ponytail— schreibe das faulste Ding, das tatsächlich funktioniert. Lösche, bevor du hinzufügst. (Diesen haben wir nicht geschrieben – es ist ein Open-Source-Skill von Dietrich Gebert , den wir für unseren Stack angepasst haben.)grain/grain-review— platziere es dort, wo die Codebasis bereits entschieden hat, dass es hingehört. Erfinde keinen zweiten Weg.review-proof— glaube einem Fund erst, wenn er als fehlschlagender Test reproduzierbar ist.
grain und review-proof haben wir im selben Geist wie ponytail gebaut, zugeschnitten auf unsere Architektur. Jeder der fünf PRs unten berührt unseren Agent-Orchestrierungs-Kern – die teuerste Stelle im Repo, um schlampig zu werden – und jeder ist als Tier 3 eingestuft: zusätzliche Testabdeckung und menschliches Review obendrauf auf den automatisierten Reviewer, ohne Ausnahmen.
Die drei Skills auf einen Blick: ponytail subtrahiert, grain richtet aus, review-proof beweist.
Teil 1 · WAS — Entropie ist der Standard
Hier ist die Sache, vor der dich niemand warnt, wenn du einem KI-Agenten ein Repo übergibst: Jeder Agent optimiert lokal und erinnert sich an nichts. Er sieht das Ticket, nicht die Monate an Konventionen, auf die sich dein Team eingeschworen hat. Er hat keinen Grund, deinen bestehenden E-Mail-Service einem neuen vorzuziehen, keine Erinnerung daran, dass das Redirect-Status-Set schon drei Dateien weiter definiert ist, keinen Instinkt dafür, dass „der Fix in die gemeinsame Funktion gehört, nicht in diesen einen Aufrufer". Lässt man sie laufen, produzieren N Agenten N leicht unterschiedliche Wege, dasselbe zu tun. Das ist kein Codequalitätsproblem, das man weglinten kann – es ist eine strukturelle Drift, die sich aufsummiert.
Die drei Skills zielen jeweils auf eine Achse dieser Drift.
ponytail — das faulste Ding, das funktioniert
Ponytail ist ein Senior-Entwickler, der um 3 Uhr morgens wegen der cleveren Abstraktion von jemand anderem aus dem Bett geklingelt wurde und sich weigert, die nächste zu schreiben. Er läuft eine Leiter ab und stoppt auf der ersten Sprosse, die hält: Muss das überhaupt existieren (YAGNI) → gibt es das schon in dieser Codebasis → macht es die Standardbibliothek → native Plattformfunktion → bereits installierte Abhängigkeit → geht es in einer Zeile → erst dann: der minimale Code, der funktioniert.
Die Sprosse, die für Agenten am wichtigsten ist, ist „gibt es das schon in dieser Codebasis?" Neu zu implementieren, was ein paar Dateien weiter liegt, ist die häufigste Form von Agent-Slop. Und ponytails Bugfix-Regel hält Diffs ehrlich: Behebe die Ursache, nicht das Symptom. Greppe jeden Aufrufer der Funktion, die du anfassen willst; ein Guard in der gemeinsamen Funktion ist ein kleinerer Diff als ein Guard in jedem Aufrufer – und er lässt die Geschwister nicht kaputt zurück.
grain / grain-review — mit dem Fluss gehen
Wenn ponytail regelt, wie wenig du schreibst, regelt grain, wohin es geht und welche Form es annimmt. Seine eine Regel: Finde das nächstgelegene bestehende Beispiel, kopiere seine Form, benenne, was du kopiert hast. Neuer Code sollte sich lesen, als hätte ihn dieselbe Person geschrieben, die die Datei daneben geschrieben hat.
Grain ist auch der Ort, an dem Architektur durchgesetzt wird. Unser Backend ist ein ziemlich standardmäßiges Vertical-Slice-+-Hexagonal-Layout – Presentation ruft Application ruft Domain, Infrastruktur hängt nach innen, und die Domain greift nie zurück nach außen. Ein Fund wie „diese Route überspringt ihren Controller und zieht den Service direkt" ist keine Pedanterie – er ist der Unterschied zwischen einer Codebasis, in der ein Agent nächsten Monat navigieren kann, und einer, in der er es nicht kann. grain-review jagt genau das: duplizierte Helper, überschrittene Schichtgrenzen, Zugriffe in die Interna eines anderen Features, eine zweite Konvention für etwas, das schon auf eine Weise erledigt wird.
review-proof — den Fund verdienen
Standard-KI-Code-Review produziert plausible Funde. Manche sind echt; manche sind selbstsicherer Unsinn; von außen sehen sie identisch aus. review-proof weigert sich, sich selbst zu vertrauen: Es reviewt und zwingt dann jeden Korrektheits-Fund, als echter fehlschlagender Test oder lauffähiges Repro zu reproduzieren, und lässt alles fallen, was das nicht schafft. Es schließt mit einem grain-review-Durchgang für die strukturelle Passung ab. Was ausgeliefert wird, ist ein Review, bei dem jeder Punkt mit ausführbarem Beleg kommt – nicht mit einem Bauchgefühl.
Was wir sehen sollten, wenn das funktioniert
- H1 — Löschungen tauchen in Feature-PRs auf. Wenn ponytail + grain funktionieren, sollte das Hinzufügen eines Features häufig netto Struktur entfernen, nicht nur hinzufügen.
- H2 — Fixes landen einmal, an der gemeinsamen Stelle. Ursachen-Fixes sollten viele Aufrufstellen auf einen Guard zusammenfalten, statt Guards pro Aufrufer zu verstreuen.
- H3 — Das Review fängt Vertragsbrüche, über die ein Mensch hinwegliest. Belegbasiertes Review sollte Bugs aufdecken, die ein „sieht gut aus"-Review übersieht – besonders die stillen.
Teil 2 · NA UND — fünf PRs, je ein Instinkt
Fünf echte Änderungen an unserem Agent-Kern. Wir halten die Interna bewusst vage – das Repo ist privat – aber die Zahlen sind aus den tatsächlichen Diffs berechnet, und die Lehren sind der übertragbare Teil.
Subtrahieren: ein Guard für ein Dutzend Fetch-Stellen
Eine Familie von Flow-Steps holte nutzergelieferte URLs ohne DNS-auflösende Sicherheitsprüfung, sodass ein Hostname, der auf eine interne Adresse auflöste, aus dem Backend heraus Cloud-Metadaten erreichen konnte. Der verlockende Fix fügt an jeder der gut zwanzig Fetch-Stellen eine Prüfung hinzu. Ponytails Antwort war das Gegenteil: ein gemeinsamer, abgesicherter Fetch-Helper, überall verwendet – und wir löschten eine handgeschriebene Private-Network-Tabelle, an der ein Wildcard-DNS-Trick einfach vorbeilief, plus drei duplizierte Redirect-Loops und eine Netzwerkprüfung, die in mehrere Dateien kopiert worden war.
Der Diff fügte den gemeinsamen Helper hinzu und entfernte ~90 Zeilen Duplikation über 22 Dateien. Diese Löschung ist die Geschichte: Hier zeigt sich H2 in Fleisch und Blut – der Ursachen-Fix leitete jeden Aufrufer durch einen Guard, statt den einen im Ticket genannten Pfad zu patchen.
Der Ursachen-Fix: ein Dutzend Ad-hoc-Fetch-Stellen kollabieren auf einen gemeinsamen, abgesicherten Helper. Der faule Fix und der sichere Fix sind derselbe Fix.
Subtrahieren + beweisen: ein Shape-Guard, bewiesen auf der echten Runtime
Unsere Worker-Runtime persistiert das Ergebnis eines Runs als serialisierten String, manchmal in eine Ein-Element-Liste verpackt. Consumer, die ein einfaches Objekt erwarteten, stürzten daran ab. Der falsche Fix verstreut defensive Typprüfungen bei jedem Consumer. Stattdessen: ein kleiner form-normalisierender Helper, und jeder Consumer wird darauf umgelenkt – eine fast reine Addition von einem Guard, die die N Ad-hoc-Guards ersetzt, die ein weniger disziplinierter Agent geschrieben hätte (+558 / −24, 7 Dateien).
Der Teil, der daraus eine review-proof-Geschichte macht, ist der Test. Statt gegen eine angenommene Serialisierungsform zu asserten, ließen wir einen echten Workflow durch die tatsächliche Runtime und den tatsächlichen Storage laufen – keine Mocks – und bewiesen die Form, die die Runtime tatsächlich persistiert. Die offene Frage im Ticket war buchstäblich was serialisiert die Runtime hier? – und die einzige ehrliche Antwort ist eine, die man laufen lassen kann.
Beweisen: das Review fing einen stillen Vertragsbruch
Feature: ein Fallback-Modell pro Node, damit ein Flow, der an einen Anbieter gebunden ist, bei einem Ausfall anmutig degradiert. Der naheliegende erste Wurf packte das Modell in den eingebauten Fallback-Kombinator des Frameworks.
Er funktionierte im Happy Path. Er schaltete auch still zwei Anbieter-Features ab, die über isinstance am konkreten Modelltyp hängen – ein gewrapptes Objekt ist nicht mehr dieser Typ, also schalteten sich natives Structured Output und Prompt-Caching beide lautlos ab. Kein Fehler. Kein fehlschlagender Happy-Path-Test. Genau die Sorte Sache, über die ein menschliches Review hinwegliest und die ein „sieht gut aus"-Agent durchwinkt.
review-proof hat es nicht durchgewunken – es reproduzierte beide Brüche als fehlschlagende Tests, was das Redesign erzwang: den Fallback tiefer ansetzen, zur Ausführungszeit, sodass jedes Modell sein konkreter Typ bleibt und die typgesteuerten Features weiter funktionieren. H3, entschieden bestätigt: Der Beweis fing einen Bug, den Plausibilität ausgeliefert hätte.
Ausrichten: ein Picker, nicht zwei Kopien
Ein zweiter Benachrichtigungskanal bedeutete, dass die Kanal-Picker-UI nun zwei Zuhause hatte – einen Create-Wizard und ein Settings-Modal. Der Standard-Agent-Move fügt den neuen Zweig beiden hinzu und lässt zwei Kopien derselben State Machine wachsen. grain sagte: Es gibt schon eine Art, wie das geformt sein sollte – mach es gemeinsam. Wir extrahierten einen einzigen Picker-Hook und trieben beide Screens darüber, steckten den neuen Kanal in die bestehende Config-Union und verwendeten den bestehenden E-Mail-Service weiter, statt neue Versandmaschinerie hinzuzufügen.
+1.735 / −340 über 24 Dateien. Ein Feature dieser Größe, das 340 Zeilen entfernt, ist H1 sichtbar gemacht: Die Deduplizierung zweier Picker-Kopien zu einer bezahlte einen guten Teil des neuen Kanals.
Ausrichten + beweisen: den Endpoint wiederverwenden, den Pfad spiegeln
Nutzern zu erlauben, Dateien beim Anlegen eines Issues anzuhängen, hätte einen neuen Upload-Endpoint, einen neuen Dispatch-Mechanismus und einen neuen Prompt-Pfad bedeuten können. grain leitete fast alles davon auf bestehende Schienen: den bestehenden Upload-Endpoint, eine Frontend-Accept-Liste, die genau die Backend-Whitelist spiegelt, und einen Deferred-Dispatch-Fix, der den Eligibility-Mechanismus wiederverwendete, den geplante Arbeit bereits nutzte. Ausgeliefert wurde es mit belegbasierten Fixes, darunter ein echter Transaction-Isolation-Bug, der bei parallelen Uploads Daten verloren hätte. +1.776 / −218 über 27 Dateien – ein großes Feature, das trotzdem 218 Zeilen zum Löschen fand, indem es bestehenden Slices beitrat, statt neue zu erfinden.
Die Anzeigetafel
Fünf Tier-3-PRs: was jeder hinzugefügt hat, was er entfernt hat und der Instinkt dahinter.
Fünf Feature- und Fix-PRs am Agent-Kern entfernten 821 Zeilen – nicht, indem sie weniger taten, sondern indem sie sich weigerten, zu duplizieren, was bereits existierte, und Symptom-Patches zu behalten, die ein Ursachen-Fix überflüssig machte.
Vollständige Offenlegung
- Das sind Skills, keine Studie. Das ist kein kontrolliertes Experiment mit einer Baseline-Gruppe; es sind fünf echte PRs, bei denen die Disziplin angewendet wurde. Der Kontrafakt – was derselbe Agent ohne die Skills ausgeliefert hätte – ist eine informierte Schätzung, keine Messung. Die Geschichte vom stillen Vertragsbruch ist der sauberste Beleg, weil wir beobachtet haben, wie das Review den Bug vor dem Redesign reproduzierte.
- Zeilenzahlen sind Näherungswerte. Die −821 ist eine echte Zahl aus den Diffs, aber „entfernte Zeilen" steht für „vermiedene Duplikation und tote Flexibilität". Ein Skill, der einem Agenten 200 spekulative Zeilen ausredet, hinterlässt überhaupt keine Spur in einem Diff – die größten Gewinne sind hier unsichtbar.
- Token-Einsparungen sind richtungsweisend. Kleinere Diffs, weniger berührte Dateien und wiederverwendete Strukturen bedeuten weniger Tokens fürs Generieren, Reviewen und erneute Reviewen – aber wir zitieren kein hartes Token-Delta pro PR.
ponytailist nicht von uns. Es ist ein Open-Source-Skill von Dietrich Gebert ; wir haben ihn angepasst.grainundreview-proofsind unsere, im selben Geist gebaut. Alle drei laufen als lokale Projekt-Skills auf Claude Code – Prompt und Prozedur, keine Binary, die du installierst.
Bereit, Ihr Geschäft zu erweitern?
Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.
Teil 3 · UND JETZT
Was ausgeliefert wurde. Drei kombinierbare Skills. ponytail und grain laufen beim Schreiben; ponytail-review, grain-review und review-proof laufen auf einem Diff. review-proof kettet grain-review als letzte Phase an, sodass ein einzelnes belegtes Review auch kostenlos einen strukturellen Durchgang bekommt.
Was du am Montag tun kannst – du brauchst nicht unsere exakten Skills:
- Mach „wiederverwenden" zu Sprosse zwei, nicht Sprosse zehn. Bevor ein Agent einen Helper schreibt, lass ihn nach einem existierenden greppen. „Gibt es das schon in dieser Codebasis?" gehört über „kann ich es sauber schreiben?"
- Fixe an der Wurzel, beweise es mit der Aufruferliste. Verlange, dass jeder Bugfix jeden Aufrufer der angefassten Funktion nennt. Ein Guard in der gemeinsamen Funktion schlägt einen Guard pro Aufrufer – und es ist ein kleinerer Diff.
- Gib neuem Code ein nächstes Geschwister zum Kopieren. „Finde das nächstgelegene bestehende Beispiel und spiegle seine Form" macht Architektur von einem Doc, das niemand liest, zu einem Standard, dem der Agent folgt.
- Erzwinge Schichtgrenzen in CI, nicht per Bauchgefühl. Eine Ratsche, die nur bei neuen schichtübergreifenden Imports fehlschlägt, lässt dich die Linie halten, ohne das Meer der bestehenden Schulden aufzukochen.
- Liefere keinen Fund aus, den du nicht reproduzieren kannst. Lass den Agenten zuerst den fehlschlagenden Test schreiben. Wenn er den Bug nicht reproduzierbar machen kann, ist es kein Bug – es ist eine Meinung. Lass ihn fallen.
- Lass das Review löschen. Richte einen Review-Durchgang gezielt auf Über-Engineering – „was können wir wegschneiden" – getrennt von Korrektheit. Das beste Ergebnis eines Diffs ist, dass er kürzer wird.
Probier es aus, besonders wenn es bei dir fehlschlägt. Wenn du Coding-Agenten auf einer echten Codebasis laufen lässt, passiert die Entropie bereits – du hast sie nur nicht gemessen. Mach eine dieser Regeln zu einem Review-Durchgang für deine nächsten zehn Agent-PRs und zähle die Löschungen. Wenn subtrahieren-ausrichten-beweisen deine Diffs nicht verkleinert oder einen stillen Bruch abfängt, würden wir das wirklich gern hören. Korrekturen und Gegenbeispiele sind besonders willkommen.
Ein Agent fügt hinzu. Die Aufgabe ist, den Agenten jede Zeile verdienen zu lassen.
