Dieser Post ist das Begleitstück zur Claude-Code-Agents-Fallstudie. Jenes Stück geht die Architektur durch, wie die Agents strukturiert sind, was sie durchsetzen, warum sie so geformt sind, wie sie sind. Dieses Stück ist das Post-Mortem darüber, welche den Kontakt mit Engineers überlebt haben und welche innerhalb eines Monats im Papierkorb landeten.
Ich habe in den letzten zwölf Monaten rund dreißig Claude-Code-Agents in Produktionscodebasen ausgeliefert. Etwa ein Drittel wurde zu Infrastruktur, über die sich Leute beschwerten, wenn sie brach. Etwa ein Drittel tat seinen Job und verschwand im Hintergrund. Das letzte Drittel habe ich gelöscht. Das hier ist, was ich beim Sortieren gelernt habe.
Die Agents, die sich ausgezahlt haben
Das Muster war in jedem Fall dasselbe: möglichst deterministische Programme, die irgendwo in der Mitte zufälligerweise ein LLM aufrufen. Nicht „bitte das Modell, es herauszufinden". Enger Scope, maschinenlesbarer Output, ein klarer Failure-Mode.
Der PR-Description-Writer bleibt. Engineers müssen keine Descriptions mehr entwerfen; sie pushen einfach, und CI lässt einen Agent laufen, der den Diff, das verlinkte Ticket und den Conventional-Commits-Style-Guide liest, dann eine Description schreibt und sie auf den PR editiert. Der Diff ist die Wahrheit, das Ticket ist das Warum, der Style-Guide ist der Constraint. Einfach. Der Agent erledigt das in zwanzig Sekunden; Engineers haben vorher fünf bis zehn Minuten pro Stück gebraucht.
Der Schema-Drift-Monitor bleibt. Während eines viermonatigen
Parallel-Builds von v2 entwickelte sich das Schema von v1 ständig weiter,
dienstags kamen Felder dazu, freitags wurden Typen umbenannt, niemand
koordinierte das. Der Monitor introspektiert stündlich das Live-Schema
von v1, difft gegen die rootSchema.graphql von v2 und postet bei Drift
nach Slack. Eine separate PR-Time-Variante blockiert Merges, die Breaking
Changes oder gefährliche Changes einführen. Es sind hundert Zeilen um
einen einzelnen Anthropic-Call, der darüber nachdenkt, welche
Schema-Deltas wichtig sind. Engineers mussten es sich nicht mehr merken;
der Monitor merkte es sich.
Der SQL-Safety-Enforcer bleibt. Ich habe in der NL-SQL-Fallstudie ausführlich darüber geschrieben, aber die Kurzversion: Es ist ein Pre-Merge-Agent, der jeden neuen SQL-String in einem Diff statisch analysiert und sich weigert zu mergen, wenn der Query der Tenant-Filter fehlt, sie einen Write enthält oder unbegrenzt ausfächern könnte. Er fand im ersten Monat drei echte Bugs. Keiner davon wurde im Review gefunden.
Was diese Agents gemeinsam haben: Sie haben einen Prozess ersetzt, keine Person. Einen Prozess, den Menschen inkonsistent, langsam und mit verzeihlichen, aber teuren Fehlern erledigt haben. Sobald der Agent zuverlässig war, gaben die Menschen ihn gerne ab.
Die Agents, die es nicht taten
Eine Handvoll der Agents, die ich ausgeliefert habe, war die Wartung ehrlicherweise nicht wert.
Der „review meinen PR für mich"-Agent ist der offensichtliche. Ich habe einen gebaut, ausgeliefert, zugesehen, wie er auf drei PRs in Folge smart klingende, aber falsche Kommentare hinterließ, und ihn innerhalb von zwei Wochen gelöscht. Das grundlegende Problem ist, dass PR-Review high-context und low-tolerance ist: Ein Kommentar, der plausibel klingt, aber falsch ist, verschwendet mehr Zeit, als der Kommentar spart, weil die Engineer:in jetzt erklären muss, warum der Bot falsch lag, statt einfach zu mergen. Einen engen Review-Agent würde ich bauen, ändert dieser Diff eine öffentliche API ohne CHANGELOG-Eintrag, diese Art von Ding, aber das „Reviewer"-Framing war eine Falle.
Den Flake-Hunter habe ich zurückgefahren. Ich hatte einen Agent, der auf roten CI-Builds lief, sich den Test ansah und entschied, ob es ein Flake war. Er lag in etwa 70 % der Fälle richtig, was gut klingt, bis man realisiert, dass die 30 % der „nein, das ist ein echter Fehler"-Fälle genau die waren, über die Engineers am dringendsten Bescheid wissen mussten. Inzwischen postet er nur noch eine Empfehlung und handelt nie, und die Empfehlung liegt oft genug richtig, um als Hinweis nützlich zu sein.
Den „erklär mir diesen alten Code"-Agent habe ich gelöscht. Er generierte Textwände, die selbstsicher klangen, manchmal korrekt waren und nie geprüft wurden. Das Heilmittel für Code, den niemand versteht, ist, dass eine Senior-Engineer:in ihn liest, die Erklärung schreibt und sie ins Repo legt. Ich habe versucht, das abzukürzen. Hätte ich nicht tun sollen.
Die eine Regel, die ich nicht mehr brechen werde
Jeder Agent hat einen Exit-Code, einen Kill-Switch und ein Eval-Set.
Der Exit-Code ist nicht verhandelbar: Wenn der Agent in CI läuft, muss er eine Entscheidung treffen, und diese Entscheidung muss eine Zahl sein. „Pass" und „Fail". Vielleicht „Skip mit Begründung". Kein „das Modell hat etwas gesagt".
Der Kill-Switch ist die Env-Variable, die den Agent in fünf Sekunden abschaltet, wenn er sich danebenbenimmt. Es ist keine Code-Änderung, es ist kein Deploy, es ist ein Flag. Jeder Agent bekommt einen, bevor ich ausliefere. Ich musste mir diese Regel in Großbuchstaben aufschreiben, nachdem ich zum zweiten Mal einen Agent zurückgerollt hatte, indem ich einen PR öffnete.
Das Eval-Set ist im Tagesgeschäft die kleinere Sache, aber es ist die, die dich rettet, wenn du Claude upgradest. Als Sonnet 4.6 herauskam, konnte ich an einem Nachmittag auf jedem Agent das Modell tauschen, weil jeder Agent einen Ordner mit kanonischen Inputs und erwarteten Outputs hatte, den ich gegen das neue Modell erneut laufen lassen konnte. Die Agents, bei deren Evals ich faul gewesen war? Ich habe Tage damit verbracht herauszufinden, dass zwei von ihnen wegen einer Eigenheit des neuen Prompt-Templates jetzt aggressiver halluzinierten.
Woran ich als Nächstes arbeite
Die Frontier, die ich gerade erkunde, sind Agents, die sich selbst warten. Die meisten meiner aktuellen Agents sind statisch: ein Prompt, eine Tool-Allowlist, ein Eval-Set. Die nächste interessante Schicht sind Agents, die ihr eigenes Produktionsverhalten beobachten (False Positives, False Negatives, Latenz-Drift) und Updates für ihre eigenen Prompts vorschlagen, wenn sie degradieren. Ich habe zwei davon im frühen Prototyp. Sie werden entweder das Nützlichste sein, was ich je gebaut habe, oder eine Self-Licking Ice Cream Cone. Ich schreibe auf, welches von beiden.
Wenn du Agents in Production auslieferst, würde ich gerne Notizen vergleichen. Die Kontaktseite ist der einfachste Weg.