Sollten Sie den Code Ihres KI-Agenten weiterhin überprüfen?

Die Diskussion beginnt in jedem Team gleich. Die eine Seite sagt, die Agenten liefern jetzt saubereren Code als die Hälfte der Pull-Requests, die wir früher abgenickt haben, also warum lesen wir immer noch jede Zeile? Die andere Seite sagt, weil wir die sind, die es genehmigt haben.

Beide Seiten haben recht. Genau deshalb endet die Diskussion nie. Sie endet nicht, weil die Frage falsch ist, und sobald Sie die Frage korrigieren, wird die Antwort fast langweilig.

Das Argument für das Versenden ohne jede Zeile zu lesen

Beginnen Sie mit der stärksten Version des optimistischen Arguments, denn es ist stärker als die meisten Prüfer zugeben.

Bei einer klar definierten Aufgabe mit einer klaren Spezifikation und einer Test-Suite produziert ein moderner Programmieragent konsistenteren Code als der Medianmensch, der unter Zeitdruck arbeitet. Er wird auf dem Fehlerpfad nicht gelangweilt. Er schreibt die Null-Prüfung um 18 Uhr an einem Freitag. Er folgt den Projektkonventionen, die ihm gegeben wurden, jedes Mal, ohne die kleinen stillen Rebellionen, die sich ein müder Entwickler erlaubt.

Die menschliche Überprüfung war auch schon kaputt, bevor die Agenten ankamen. Jeder, der in einem echten Team gearbeitet hat, kennt den LGTM-Reflex: Die Aufmerksamkeit des Prüfers bricht nach ein paar hundert Zeilen zusammen, und die folgenden Genehmigungen sind sozial, nicht technisch. Wir haben kein goldenes Zeitalter der rigorosen Überprüfung verloren. Wir haben ein Ritual verloren, das bereits größtenteils Theater war.

Dann gibt es das Volumen. Ein Entwickler, der fünf Agenten parallel betreibt, erzeugt mehr Diff pro Stunde, als ein Mensch sorgfältig lesen kann. Wenn Ihre Regel lautet "alles lesen", haben Sie sich stillschweigend wieder als Engpass installiert, den Sie gerade automatisiert haben. Ein Mensch, der ein 900-Zeilen-Diff überfliegt, produziert eine Unterschrift, ohne Wissen zu erzeugen, und das ist schlimmer, als gar nicht zu überprüfen, weil es Sicherheit erzeugt, wo keine ist.

Das Argument für die Beibehaltung eines Menschen im Diff

Jetzt die andere Seite, die auch stärker ist, als die Enthusiasten zugeben.

Verantwortung überträgt sich nicht. Das Modell wird um 3 Uhr morgens nicht alarmiert. Es ist nicht in der Vorfallüberprüfung, es spricht nicht mit dem Kunden, dessen Daten geleakt wurden, und es trägt nicht die Konsequenzen der Änderung ins nächste Quartal. Wer zusammenführt, trägt das Ergebnis, und die Überprüfung ist, wie Verantwortung ausgeübt wird, anstatt nur erklärt zu werden.

Agentenprüfer scheitern in die gleiche Richtung wie Agentenautoren. Das ist das Argument, das tatsächlich den Vorschlag "lass einen anderen Agenten es überprüfen" klärt. Zwei Agenten aus derselben Modellfamilie, die denselben Kontext erhalten, teilen Vorurteile, teilen Trainingsdaten und teilen blinde Flecken. Ihre Fehler sind korreliert. Ein zweiter Agent wird gerne einen fehlenden Test oder einen nicht behandelten Fehler erkennen und wird gerne das subtile Missverständnis Ihres Bereichs genehmigen, das den Fehler ursprünglich verursacht hat, weil er dasselbe Missverständnis hatte. Zwei Prüfer, die in die gleiche Richtung falsch sind, addieren sich nicht zu einer Überprüfung.

Die Messungen sind auch nicht schmeichelhaft. Branchendaten zeigen, dass Prüfer bedeutend mehr Runden zu AI-generierten Änderungen austauschen als zu menschlich geschriebenen: Der Code kommt schneller an und braucht länger, um vertrauenswürdig zu werden. Eine Studie aus Januar 2026 ging weiter und stellte fest, dass agentengenerierte Änderungen mehr Redundanz und mehr angesammelte technische Schulden pro Änderung tragen als menschlich geschriebene, während Prüfer berichten, dass sie sich besser fühlen, wenn sie sie genehmigen. Diese Lücke, zwischen wie gut sich der Code anfühlt und wie gut er ist, ist das gesamte Risiko in einem Satz.

Die Debatte ist falsch gerahmt

Hier ist die Umformulierung, die das Meeting beendet.

Sie überprüfen den Code nicht, weil Sie dem Autor misstrauen. Sie überprüfen ihn, weil Sie derjenige sind, der unterschreibt. Das sind völlig verschiedene Aktivitäten, und die ganze Argumentation kommt von der Verwirrung zwischen ihnen.

Sobald Sie es so sehen, hört die Frage "Ist der Agent besser als ein Mensch?" auf, die entscheidende Frage zu sein. Die entscheidende Frage ist: Wenn diese Änderung falsch ist, wie teuer ist es, das herauszufinden, und wie teuer ist es, sie rückgängig zu machen? Ein Tippfehler in einer Marketingüberschrift wird in Sekunden entdeckt und in Sekunden zurückgesetzt. Eine Berechtigungsprüfung, die in einer Autorisierungs-Middleware umgekehrt wurde, wird von einem Kunden oder einem Regulierer entdeckt, und sie wird nie wirklich zurückgesetzt, denn bis dahin wurden die Daten bereits gelesen.

Die Antwort ist also weder "alles überprüfen" noch "dem Agenten vertrauen". Es ist:

Sie hören auf, Zeilen zu überprüfen. Sie beginnen, Risiken zu überprüfen.

Konkret verschiebt sich die Überprüfung von der Mitte der Arbeit zu ihren beiden Grenzen. Vorher: Lesen Sie den Plan, denn ein falscher Plan, der perfekt ausgeführt wird, ist der teuerste Fehler, den es gibt, und ein Plan hat fünfzehn Zeilen anstelle von neunhundert. Danach: Lesen Sie das Diff im Verhältnis zum Blast-Radius. Dazwischen gehören die Zeilen der Maschine.

Wie sieht "der Agent hat es vermasselt" tatsächlich aus

Das Nützlichste, was Sie Ihrem Team zurückbringen können, ist keine Meinung, sondern eine Liste objektiver Hinweise. Nicht "der Code fühlt sich falsch an", sondern Signale, die Sie in weniger als einer Minute in einem Diff überprüfen können. Diese haben sich ihren Platz verdient.

1. Die Tests wurden im selben Commit geändert wie der Code, den sie abdecken. Das Grün wurde konstruiert, nicht beobachtet. Dies ist das Signal mit dem höchsten Wert in der Liste, und es ist das erste, das überprüft werden sollte.
2. Eine Behauptung wurde abgeschwächt oder ein Test wurde deaktiviert. Ein skip, ein only, eine Behauptung, die erweitert wurde, um das zu akzeptieren, was der neue Code zufällig zurückgibt, ein try/catch, das den Fehler schluckt, den der Test aufdecken sollte.
3. Das Diff ist größer als die Aufgabe. Dateien, nach denen niemand gefragt hat, wurden berührt. Scope Creep in einem Agenten ist kein Enthusiasmus, es ist ein Zeichen dafür, dass der Agent das Ziel irgendwo auf dem Weg uminterpretiert hat.
4. Eine erfundene Oberfläche. Eine API-Methode, eine Konfigurationsoption oder ein Pfad, der nicht existiert. Es kompiliert im Kopf des Agenten und sonst nirgendwo.
5. Die Umgebung wurde anstelle des Codes behoben. Ein fest codierter absoluter Pfad, ein maschinenspezifischer Wert, ein persönliches Token, ein Benutzername. Das Symptom verschwand auf der Maschine des Agenten und wanderte zu allen anderen.
6. Eine Abhängigkeit erschien, ohne danach gefragt zu werden. Neue Lieferkette, neue Lizenz, neue Wartungsoberfläche, entschieden von etwas, das es nicht warten wird.
7. Duplikation anstelle von Wiederverwendung. Es wurde ein Helfer neu implementiert, der bereits zwanzig Zeilen entfernt existierte. Dies ist der Mechanismus hinter der gemessenen Schuld: Jede Änderung sieht lokal vernünftig aus und der Codebasis gewinnt stillschweigend eine dritte Möglichkeit, dasselbe zu tun.
8. Die Zusammenfassung stimmt nicht mit dem Diff überein. "Behoben und getestet", wenn kein Test lief. Die Erzählung wird mit dem gleichen Vertrauen generiert, unabhängig davon, ob die Arbeit tatsächlich stattgefunden hat, also behandeln Sie sie als eine Behauptung, die zu überprüfen ist, niemals als einen Bericht.
9. Die Anweisungen wurden nicht mehr befolgt. Kleine Konventionen, die stillschweigend fallen gelassen wurden, sind, wie eine Sitzung sich verschlechtert, bevor sie anfängt, ganz offen zu halluzinieren. Wenn Sie einen Canary in Ihrer Kontextdatei verwenden, ist dies genau das, was er auffangen soll.
10. Sensibles Terrain wurde im Vorbeigehen berührt. Ein .env-Lesen, ein neuer ausgehender Netzwerkaufruf, eine neue Protokollzeile mit Benutzerdaten, eine Migration, die in einem Funktionscommit gebündelt ist.

Beachten Sie, was nicht auf der Liste steht: Stil, Benennung, Formatierung, "Ich hätte es anders gemacht". Das waren immer die schwächsten Teile der menschlichen Überprüfung und sie sind jetzt wirklich eine Verschwendung eines Menschen. Löschen Sie sie aus Ihrer Überprüfung und Sie kaufen die Aufmerksamkeit zurück, die Sie für die zehn oben genannten Punkte benötigen.

Wie viel Überprüfung verdient eine Änderung?

Der Blast-Radius, nicht die Diff-Größe, entscheidet. Die Tabelle, die Ihr Team an diesem Nachmittag übernehmen kann:

Die Größe des Diffs sagt Ihnen, wie lange die Überprüfung dauert. Der Blast-Radius sagt Ihnen, ob es optional ist.

Die Zeilen beziehen sich nicht auf Vertrauensniveaus. Sie beziehen sich auf die Kosten, falsch zu sein, was eine Eigenschaft des Codes und nicht des Autors ist. Das macht die Tabelle nutzbar: Niemand muss sich darüber einig sein, wie gut die Agenten sind, um sich über die Tabelle einig zu sein. Wenn Ihr Team bei der philosophischen Frage festgefahren ist, überspringen Sie sie und verhandeln Sie stattdessen die Zeilen. Sie werden überrascht sein, wie schnell das konvergiert.

Wenn Ihr Produkt persönliche Daten in Europa verarbeitet, wird eine weitere Zeile gesetzlich für Sie geschrieben, nicht nach Geschmack: was eine KI-generierte Funktion unter der DSGVO respektieren muss ist kein Urteil, und "ein Agent hat es geschrieben" war nie eine Verteidigung.

Was sich ändert, wenn fünf Agenten gleichzeitig laufen

Alles oben geht davon aus, dass Sie die Änderung sehen können. Mit parallelen Agenten bricht diese Annahme zuerst, und sie bricht auf eine spezifische Weise: Das Diff hat keinen einzelnen Autor mehr. Drei Agenten haben den Arbeitsbaum seit Ihrem letzten Commit berührt, und die Frage "Wer hat diese Datei geändert, und als Teil welcher Aufgabe" hat keine offensichtliche Antwort mehr. Überprüfung ohne Attribution ist keine Überprüfung, es ist Archäologie.

Das ist ein Werkzeugproblem, und es ist der Grund, warum AgentsRoom die Überprüfung dorthin legt, wo die Agenten sind, anstatt am Ende eines Pull-Requests:

• Review Mode zeigt jede Änderung, die Ihre Agenten vorgenommen haben, als lesbares Diff, bevor irgendetwas committet wird. Es ist der Schritt "lesen Sie das Diff im Verhältnis zum Blast-Radius", der so günstig gemacht wurde, dass die Leute es tatsächlich tun.
• Pro-Agenten-Überprüfung filtert dieses Diff nach Agent und ermöglicht es Ihnen, die Arbeit jedes Agenten separat zu committen. Fünf parallele Agenten werden zu fünf überprüfbaren Einheiten anstelle eines unlesbaren Arbeitsbaums, und eine schlechte Änderung bleibt dem Task zugeordnet, der sie produziert hat.
• Die Commit-Nachricht wird aus dem echten Diff mit dem Funkelbutton im Commit-Feld generiert, sodass die Historie beschreibt, was sich geändert hat, anstatt was der Agent gesagt hat, dass er es tut. Diese Unterscheidung ist um 3 Uhr morgens, sechs Monate später, wichtig.

Nichts davon ersetzt das Urteil. Es beseitigt die Ausreden, es nicht auszuüben.

Lassen Sie die Maschine die Zeilen besitzen

Wenn Sie aufhören möchten, Zeilen zu lesen, muss etwas anderes sie lesen. In der Praxis tragen vier Dinge diese Last:

Tests, die der Agent nicht im selben Atemzug wie den Code geschrieben hat. Zuerst geschrieben oder von einem anderen Agenten geschrieben oder mindestens als ihre eigene Änderung überprüft. In dem Moment, in dem Code und seine Tests aus derselben Generation stammen, hören sie auf, unabhängige Beweise zu sein.

Ein Prüfer mit einem anderen Modell. Das ist die praktische Antwort auf das Problem der korrelierten Fehler. Wenn ein zweiter Agent überprüft, führen Sie ihn auf einem anderen Anbieter oder einer anderen Modellfamilie als den Autor aus. Sie werden die Fehler nicht vollständig dekorellieren, aber ein Codex-Familienprüfer bei Claude-geschriebenem Code erkennt eine messbar andere Klasse von Problemen als ein Prüfer desselben Modells, genau weil er die Vorurteile des Autors nicht teilt.

Tore, die nicht müde werden. Typen, Lint, geheime Scans, Abdeckungsböden, ein CI, das eine Migration, die mit einer Funktion gebündelt ist, ablehnt. Jede Regel, die Sie als Tor ausdrücken können, ist eine Regel, die Sie nie wieder beachten müssen.

Eine Schleife, die sich selbst schließt. Ein Agent, der baut, seine eigene Arbeit gegen den Plan ausführt und iteriert, bevor er irgendetwas übergibt, entfernt die gesamte Kategorie "wurde nicht einmal ausgeführt" aus Ihrer Überprüfung. Das ist die selbstkorrigierende Agentenschleife, und es ist der Unterschied zwischen einem Agenten, der ein Diff produziert, und einem, der ein Ergebnis produziert. Es beantwortet nicht die Frage, ob ein Mensch unterschreiben sollte. Es bedeutet nur, dass der Mensch etwas unterschreibt, das bereits funktioniert.

Also, überprüfen Sie noch?

Ja, und weniger als heute.

Hören Sie auf, Zeilen zu lesen, um sich verantwortlich zu fühlen. Lesen Sie den Plan vorher, denn dort werden die teuren Fehler gemacht. Lesen Sie das Diff danach im Verhältnis dazu, was es brechen kann, und verwenden Sie die Leiter anstelle Ihrer Stimmung. Halten Sie einen Menschen persönlich bei Authentifizierung, Zahlungen, Berechtigungen, persönlichen Daten und allem, was irreversibel ist, denn ein Modell kann keine Verantwortung übernehmen und ein zweiter Agent teilt die blinden Flecken des ersten. Geben Sie alles andere Tests, Typen, Tore und einem Prüfer, der nicht das Modell des Autors teilt.

Die Teams, die das falsch machen, scheitern in eine von zwei Richtungen, und beide sind vermeidbar. Das eine überprüft alles, wird zum Engpass und beginnt stillschweigend, ohne zu lesen, zu genehmigen, was das Schlimmste aus beiden Welten ist. Das andere überprüft nichts, versendet schnell zwei Monate lang und verbringt dann ein Quartal damit, Schulden abzubauen, die es nie gesehen hat.

Die Debatte in Ihrem Standup dreht sich nicht wirklich darum, ob Agenten gut sind. Es geht darum, wer bereit ist zu unterschreiben. Beantworten Sie das, und die Überprüfungspolitik schreibt sich von selbst.

Häufig gestellte Fragen

Sollten Sie noch KI-generierten Code überprüfen?

Ja, aber nicht zeilenweise bei allem. Überprüfen Sie den Plan, bevor der Agent beginnt, und überprüfen Sie dann das Diff im Verhältnis dazu, was die Änderung brechen kann. Texte und CSS erhalten ein Überfliegen. Authentifizierung, Zahlungen, Berechtigungen, persönliche Daten und Migrationen werden jedes Mal zeilenweise von einem Menschen gelesen.

Kann ein KI-Agent den Code eines anderen KI-Agenten überprüfen?

Es hilft, ist aber kein Ersatz für einen Menschen bei risikobehaftetem Code. Zwei Agenten aus derselben Modellfamilie, die denselben Kontext erhalten, neigen dazu, in die gleiche Richtung zu scheitern. Ihre Fehler sind korreliert, sodass ein zweiter Agent Tippfehler und fehlende Tests erkennt, aber die blinden Flecken teilt, die den Fehler produziert haben. Wenn Sie einen Agentenprüfer verwenden, führen Sie ihn auf einem anderen Modell als den Autor aus.

Wie wissen Sie, ob ein KI-Agent einen Fehler gemacht hat?

Suchen Sie nach objektiven Hinweisen im Diff, anstatt nach Stil zu lesen. Das stärkste: Tests wurden im selben Commit geändert wie der Code, den sie abdecken, was bedeutet, dass das Grün konstruiert und nicht beobachtet wurde. Weitere Hinweise sind Scope Creep, eine deaktivierte oder abgeschwächte Behauptung, eine erfundene API, ein fest codierter lokaler Pfad und eine Zusammenfassung, die nicht mit dem Diff übereinstimmt.

Werden KI-Agenten menschliche Codeprüfer ersetzen?

Sie haben bereits den Großteil des Zeilenlesens ersetzt. Sie können die Unterschrift nicht ersetzen. Verantwortung überträgt sich nicht auf ein Modell, sodass ein Mensch weiterhin die Entscheidung zum Zusammenführen bei allem trifft, was schwer rückgängig zu machen ist.

Müssen Sie KI-Code zeilenweise überprüfen?

Nur dort, wo der Blast-Radius es rechtfertigt. Die zeilenweise Überprüfung skaliert nicht über ein paar parallel laufende Agenten hinaus, und ein Mensch, der ein 900-Zeilen-Diff um 18 Uhr überfliegt, produziert eine Unterschrift, ohne Wissen zu erzeugen. Konzentrieren Sie diese Aufmerksamkeit auf die Änderungen, die teuer rückgängig zu machen sind.

Was sollte niemals ohne menschliche Überprüfung zusammengeführt werden?

Alles, was Authentifizierung, Zahlungen, Berechtigungen, persönliche Daten, Datenbankmigrationen, Löschpfade und Infrastruktur berührt. Diese teilen eine Eigenschaft: Die Kosten, falsch zu sein, sind nicht proportional zur Größe des Diffs.