Fünf Regeln für den Agentenbau, gegen 24.560 Pull Requests gehalten

Wer sucht, wie man KI-Agenten baut, bekommt fünfmal denselben Artikel. Die Ratschläge sind sich einig, und das spricht normalerweise dafür, dass sie stimmen. Aufgefallen ist mir etwas anderes: Gemessen ist fast keiner davon. Sie werden behauptet, wiederholt und nie geprüft.

Eines vorweg, weil es geändert hat, wie ich das hier schreibe: Die Originalquellen sind vorsichtig. Anthropic trennt Workflows, bei denen der Codepfad feststeht, von Agenten, die sich selbst steuern, und rät, das Einfachste zu nehmen, das funktioniert, notfalls gar keinen Agenten. OpenAI verwendet die meiste Länge darauf, wann man eben keinen bauen sollte, und auf Guardrails. Chip Huyen, referiert von Simon Willison, teilt Werkzeuge in nur lesende Sensoren und schreibende Aktuatoren: eine Unterscheidung mit Folgen.

Der Rat verschleißt beim Weiterreichen. In der fünften Hand kommt die Regel ohne ihren Vorbehalt an, und der Vorbehalt war der nützliche Teil. Ich prüfe also die selbstsichere Fassung, und wo die Quelle vorsichtiger war als ihr Echo, sage ich es.

Ich habe zwei Dinge, gegen die ich sie halten kann: eine Untersuchung von 24.560 Pull Requests aus 447 Repositories und ein eigenes Versagen, das vierzehn Releases lang gelaufen ist. Also fünf der meistwiederholten Regeln, und was meine Daten dazu sagen. Jede bekommt eines von vier Urteilen, und die definiere ich, bevor ich sie benutze. Bestätigt: die Daten stützen sie. Widerlegt: die Daten widersprechen ihr. Geschärft: die Regel stimmt und ist unvollständig, und meine Daten liefern die fehlende Bedingung. Keine Daten: Ich habe nichts gemessen, also schulde ich dir kein Urteil.

Bestätigt ist keine geworden, und das sage ich lieber, als es zu verstecken. Nicht weil der Rat schlecht wäre. Sondern weil eine Regel, der ich einfach zustimme, keinen Abschnitt ergibt, den jemand lesen muss. Es sind also nicht die fünf, die ich ausgesucht hätte.

1. Zerlege die Arbeit in kleine Aufgaben: widerlegt

Zerlegen ist echter Rat, Prompt Chaining ist eines der benannten Muster und funktioniert, indem es eine Aufgabe in feste Schritte teilt. Die selbstsichere Fassung, die bei dir ankommt, ist eine andere: Kleiner ist sicherer, also schneide alles klein. Der widersprechen meine Daten.

KI-geschriebene Pull Requests unter 55 Zeilen fielen in der CI mit dem 2,12-fachen der menschlichen Rate aus. Zwischen 200 und 400 Zeilen schrumpft der Abstand auf etwa 1,1. Über 400 Zeilen verschwindet er: rund 0,95, KI also gleich gut oder leicht besser als Mensch.

Der Ratschlag zeigt in die falsche Richtung. Klein ist die Größe, bei der Agenten am unzuverlässigsten sind, nicht die zuverlässigste.

Was das zeigt und was nicht, will ich sauber trennen. Gemessen sind CI-Ausfälle, nicht Korrektheit. Eine ebenso plausible Erklärung hat mit Größe nichts zu tun: Kleine Änderungen schreibt man dort, wo es heikel ist, also sammeln sich im kleinen Bereich die schwierigen Stellen. Beides kann ich mit diesen Daten nicht trennen, und ich möchte die 2,12 nirgends zitiert sehen, als hätte ich es getan.

Was bei beiden Lesarten übrig bleibt, ist enger und trotzdem brauchbar: Ein kleiner Diff ist kein Beleg für einen sicheren. Wer Arbeit klein schneidet, weil sich Kleines prüfbar anfühlt, sollte nachsehen, ob er tatsächlich prüft.

2. Niemals ohne Mensch in der Schleife ausliefern: geschärft

Dieser Regel widerspricht niemand, und ich habe sie gebrochen, ohne es zu merken.

Ich hatte für zwei Starter-Kits die vollständige Kette durchgezogen. Anforderungen, Design, Plan, Umsetzung. Vierzehn Releases gingen raus, mit typecheck, lint, knip, test, test:boundaries, build, Playwright und axe durchgehend grün. Ein frischer Klon startete nicht. Jede Seite hinter /app stürzte ab. Das Anmeldeformular schrieb das Passwort im Klartext in die URL. Jede Schreiboperation des Onboardings starb an einem Fremdschlüssel.

Bei keinem davon war ein Mensch in der Schleife. Ich habe die nächste Runde angestoßen, die Gates kamen grün zurück, und ich habe die nächste angestoßen.

Genau das lässt die Regel weg. Automatisierung verdrängt den Menschen nicht, indem sie ihn überstimmt. Sie nimmt ihm den Anlass, hinzusehen. Vierzehn Mal hintereinander hatte ich ein Signal, das sagte, alles sei in Ordnung, und ein Signal, das das sagt, ist nicht davon zu unterscheiden, dass ihm die falsche Frage gestellt wurde.

In der Untersuchung steht eine Zahl derselben Form. Fällt ein menschlicher PR in der CI durch, wird er in 23,4 Prozent der Fälle repariert. Bei einem KI-PR sind es 9,3 Prozent. Die übrigen 91 Prozent werden aufgegeben. Was auch immer das misst: eine genau beobachtete Menge ist es nicht.

3. Schreib das Eval vor dem Code: geschärft

Guter Rat, und ich hatte ihn befolgt. Die Kits hatten eine Eval-Suite, bevor sie Funktionen hatten. Playwright und axe, bei jedem Commit, durchgehend grün.

Die Suite besuchte Routen und prüfte, ob Überschriften da waren. Sie hat sich nie angemeldet. Sie lief grün, während die Anmeldung stillschweigend nichts tat: eine Anmeldeseite zu rendern und eine zu benutzen sind zwei verschiedene Vorgänge, und geprüft wurde nur einer.

Die Regel gilt also und ist unvollständig. Ein Eval, das vor dem Code entsteht, prüft das Produkt, das du dir vorgestellt hast. Der fehlende Halbsatz: Es muss die Arbeit des Nutzers ausführen und ein Ergebnis behaupten, eine Zeile existiert, die Weiterleitung ist angekommen, statt zu behaupten, dass eine Seite gerendert hat.

Davon gibt es eine zweite Stufe, die ich inzwischen ernst nehme. Zwei Anläufe für eine Lint-Regel in demselben Repository waren wirkungslos: einer schema-ungültig, der andere außerhalb des Config-Aufrufs. Beide liefen wochenlang grün und fingen nichts. Ein Gate, das du nie hast fehlschlagen sehen, ist ungetestet: also schreibe ich den verbotenen Code als Fixture und sehe der Regel beim Auslösen zu, bevor ich ihr glaube.

4. Werkzeuge zählen so viel wie Modelle: keine Daten

Ich glaube das, und gemessen habe ich dazu nichts. Das zu sagen kostet mich einen Abschnitt und ist die einzige ehrliche Möglichkeit: Eine Meinung im Gewand eines Befundes ist genau das, was einen Text wie diesen unlesbar macht. Ich habe einem Review-Agenten dabei zugesehen, und die erfundene Behauptung war die überzeugendste in der Datei.

5. Multi-Agenten-Systeme sind die Zukunft: keine Daten

Dieselbe Antwort. Ich fahre Multi-Agenten-Abläufe und habe Meinungen dazu, wo sie helfen. Ich habe keinen gegen eine Einzelagenten-Grundlinie bei derselben Aufgabe gemessen, also habe ich nichts beizutragen, was du nachprüfen könntest.

Bemerkenswert ist, dass hier der Abstand zwischen Quelle und Echo am größten ist. Die Zweitartikel nennen Multi-Agent die Zukunft. Anthropic argumentiert stattdessen für das einfachste System, das funktioniert, und behandelt zusätzliche Autonomie als Preis, den man aus einem Grund zahlt. Das sind nicht dieselben Aussagen, und wiederholt wird nur eine.

Was ich behalten würde

• Größe ist keine Sicherheit. Ein kleiner Diff verdient kein Vertrauen, das er sich nicht anderweitig verdient hat.
• Benenne die Frage, die jedes Gate beantwortet. Meine beantworteten „übersetzt das?" auf acht Arten und „funktioniert das?" auf keiner.
• Ein Eval muss die Sache bedienen. Rendern ist nicht Benutzen.
• Sieh dein Gate einmal fehlschlagen, bevor du dich darauf verlässt.

Nichts davon widerspricht dem Konsens. Es ist, wie der Konsens aussieht, nachdem unter ihm etwas schiefgegangen ist, und das ist die Fassung, die ich zuerst gelesen hätte haben wollen.

Next

Die naheliegende Anschlussfrage kann ich mit diesen Daten nicht beantworten: ob der Effekt bei kleinen PRs überhaupt an der Größe liegt oder daran, wofür Menschen kleine PRs benutzen. Dafür müssten die Diffs danach klassifiziert werden, was sie anfassen, nicht bloß gezählt, das ist eine andere Untersuchung, keine weitere Grafik.

Falls du agentengeschriebenen Code in nennenswertem Umfang ausgeliefert hast: Passt der Größeneffekt zu dem, was du siehst, oder ist deine Erfahrung die umgekehrte? Ein Widerspruch interessiert mich hier mehr als Zustimmung: ein Repository bleibt ein Repository, so viele Pull Requests es auch enthält.