Kontext
Die Führungsebene wollte "KI überall bis Q4". Die Pilot-Squad hatte drei Claude-Code-Agenten am Laufen, einen Build-Doctor, einen PR-Review-Assistenten und einen RBAC-Validator. Andere Squads fragten nach Zugang. Zwei Engineers hatten bereits in ihrer eigenen Zeit Agenten gebaut, am Prozess vorbei.
Der Pull war real, der Druck war real, und das Risiko war das Offensichtliche: Demos zu shippen, die in Produktion nicht überleben.
Die Entscheidung
Jeder Agent musste ein 30-Tage-Trial-Gate innerhalb der Pilot-Squad bestehen, bevor irgendein zweites Squad ihn übernehmen durfte. Das Gate waren drei Zahlen:
| Kriterium | Zielwert |
|---|---|
| Eval-Set-Trefferquote | ≥ 90 % auf einem festgeschriebenen Ground-Truth-Set |
| Incident-zurechenbare Rate | < 1 Incident / Quartal |
| False-Positive-Rate (wo sinnvoll) | < 5 % |
Wenn ein Agent eines der drei am Tag 30 verfehlte, wurde er gekillt. Nicht iteriert, nicht in einer "v0.5"-Branch geparkt, gekillt, mit den Learnings in einem Einseiter dokumentiert und geteilt.
Das Eval-Set war das wichtigste Artefakt. Wir nahmen 200 historische PRs aus der Codebase, labelten das korrekte Outcome für jeden per Hand, und ließen jeden Kandidaten-Agent wöchentlich dagegen laufen.
Was eingetreten ist
Drei Agenten verfehlten das Gate.
- Ein Migrations-Suggester kam auf 78 % Eval-Trefferquote, zu aggressiv, schlug ständig technisch korrekte, aber sozial falsche Refactorings vor (Dateien drei Teams entfernt vom PR-Autor).
- Ein PR-Review-Agent hatte eine 12-prozentige False-Rejection-Rate auf legitime Refactorings. Er lernte Muster, die nicht generalisierten. Wir killten ihn; die Learnings wurden zum Einseiter Warum "sieht aus wie Refactoring" die falsche Heuristik für Review-Approval ist.
- Ein On-Call-Summariser überstand das Eval, riss aber in Woche drei den Incident-Bar (stiller Fehler, als die Upstream-API rate-limitete). Wir bauten einen Watchdog ein und gingen erneut ins Gate; beim zweiten Mal bestand er.
Zwei Agenten bestanden sauber und gingen team-weit. Beide noch in Produktion.
Was ich anders machen würde
Ich würde die Gate-Kriterien als interne RFC am Tag eins veröffentlichen. Wir machten es informell, das Gate war ein Doc in meinen Notizen, dann eine Slide, dann ein Doc, geteilt mit drei Teams. Als der dritte Agent gekillt wurde, fühlte es sich für das Team wie ein bewegliches Ziel an, kein veröffentlichter Vertrag. Es bewegte sich nicht, aber die Wahrnehmung war dieselbe, als hätte es das.
Der Fix ist günstig: das Gate vor dem ersten Agent veröffentlichen, das Eval-Set in einem versionierten Repo pinnen, ein öffentliches Scoreboard führen.
Ich würde auch ein Budget für die Kill-Writeups von Anfang an reservieren. Sie sind das wertvollste Artefakt des Programms, und sie werden nur geschrieben, wenn jemand Zeit dafür hat. Wir bekamen zwei von drei; der dritte lebte drei Monate als tribal knowledge, bevor ich ihn in ein Doc zwang.