Kann ein KI-Anbieter glaubwürdig seinen eigenen Code prüfen?

Teilweise. Ein separater Review-Durchgang findet echte Fehler, auch auf demselben Modell – ein frischer Kontext ohne die Generierungs-Historie liest den Diff anders. Was er nicht glaubwürdig leisten kann: die systematischen blinden Flecken des eigenen Modells finden. Die Forschung zeigt, dass LLM-Evaluatoren eigene Ausgaben erkennen und bevorzugen und vertraut wirkenden Text höher bewerten. Glaubwürdigkeit wächst mit Distanz – anderer Durchgang, anderes Modell, anderer Anbieter, andere Referenz.

Reviewt Cursor Bugbot Code, den Cursor selbst geschrieben hat?

Oft ja – genau dafür ist der Workflow gebaut: Der Agent schreibt, Bugbot reviewt den PR. Bugbot ist ein fähiger Reviewer, und Praktiker berichten von echten Funden, auch in PRs anderer Anbieter-Agenten. Die Unabhängigkeitsfrage zielt nicht auf Bugbots Qualität, sondern darauf, wie viel Distanz zwischen Generator und Reviewer liegt, wenn beide Frontier-LLMs sind – unter der Haube womöglich dasselbe.

Reicht ein anderes Modell fürs Review als Unabhängigkeit?

Es ist eine echte Verbesserung – ein anders trainiertes Modell hat andere Defaults und markiert, was das Autoren-Modell für normal hält. Aber auch Cross-Model-Review teilt eine strukturelle Grenze: Der Diff bleibt die einzige Referenz. Ist die Änderung sauber gebaut, tut aber das Falsche, sieht es kein Reviewer – der Auftrag steht nicht im Diff. Volle Unabhängigkeit braucht die zweite Dimension: Prüfung gegen den schriftlichen Auftrag, nicht nur gegen den Code.

Ist KI-Selbstprüfung also nutzlos?

Nein – das wäre die Überkorrektur in die Gegenrichtung. Ein Review-Durchgang desselben Modells im frischen Kontext findet echte Defekte und ist deutlich besser als gar kein Maschinen-Durchgang. Die ehrliche Einordnung heißt Restrisiko: Selbstprüfung reduziert zufällige Fehler, nicht systematische. Teams, die das verstanden haben, nutzen Selbstprüfung fürs Tempo und ergänzen unabhängige Checks – anderes Modell, deterministische Tools, Auftragsabgleich – wo Korrektheit zählt.

Wie ergänzt ein Team Unabhängigkeit, ohne eine weitere Plattform zu kaufen?

Drei Schritte, die wenig kosten: das Review mit einem anderen Modell fahren als die Generierung (viele Tools lassen die Wahl); deterministische Checks – Typen, Tests, Linter – vorschalten, denn die haben gar keine Modell-Bias; und den Auftrag vor dem Run aufschreiben, damit die Verifikation eine Referenz hat, die das generierende Modell nicht geprägt haben kann. Der letzte Schritt ist der billigste und der meistvernachlässigte.

Vergleich

Warum Selbstprüfung nicht reicht

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 4 Min.

Unabhängige Verifikation heißt: Die Instanz, die KI-generierten Code prüft, ist nicht die Instanz, die ihn erzeugt hat – nicht dieselbe Session, möglichst nicht dasselbe Modell, und nicht der Code als seine eigene Referenz. Das Problem ist gemessen, nicht hypothetisch: LLM-Evaluatoren erkennen und bevorzugen eigene Ausgaben. Ein Modell, das seinen eigenen Code reviewt, prüft seine blinden Flecken mit denselben blinden Flecken.

Inhalt

Der bequeme Default: Der Assistent prüft sich selbst

Die Tool-Landschaft 2026 macht Selbstprüfung zum Weg des geringsten Widerstands. Claude Code schreibt eine Änderung und reviewt sie auf Zuruf; Cursors Agent schreibt einen PR und Bugbot reviewt ihn; Copilot generiert Code und Copilot Code Review kommentiert ihn. Der Fairness halber: Diese Reviewer sind gut, und ein zweiter Durchgang im frischen Kontext findet echte Defekte, selbst auf demselben Modell – Praktiker berichten solide Ergebnisse aus solchen Pipelines, besonders anbieter-übergreifend.

Die Frage dieser Seite ist enger und härter: Was passiert mit den Fehlern, die das generierende Modell systematisch macht – den Mustern, die es immer schreibt, den Annahmen, die es immer trifft? Genau diese Befunde wird ein Reviewer, der das Training des Generators teilt, nicht markieren – für ihn sehen sie normal aus.

Was die Forschung zeigt: Modelle bevorzugen eigene Ausgaben

Das ist gemessen, keine Folklore. Panickssery, Bowman und Feng (2024) zeigten, dass LLM-Evaluatoren ihre eigenen Ausgaben mit deutlicher Trefferquote erkennen – und dass die Fähigkeit zur Selbst-Erkennung linear mit der Stärke der Selbst-Bevorzugung korreliert. Die Bias tritt out of the box auf, ohne jedes Fine-Tuning in diese Richtung.

Wataoka, Takahashi und Ri (2024) fanden den Mechanismus: Modelle bewerten niedrig-perplexen Text – Text, der ihnen vertraut vorkommt – höher als menschliche Juroren; GPT-4 zeigte in ihren Messungen signifikante Self-Preference. Auf Code-Review übertragen ist die Konsequenz unbequem: Die Konstrukte, zu denen ein Modell standardmäßig greift, sind ihm per Definition am vertrautesten. Ein Praktiker brachte es auf den Punkt: dasselbe Modell zweimal heißt dieselben blinden Flecken zweimal.

Die Unabhängigkeits-Leiter

Stufe	Setup	Was sie ergänzt	Was bleibt
0	Dieselbe Session prüft sich selbst	Fast nichts – der Kontext, der den Fehler machte, liest ihn erneut	Alles
1	Dasselbe Modell, frischer Durchgang	Fängt Ausrutscher, die der Generierungs-Kontext verdeckte	Alle modell-systematischen Muster
2	Anderes Modell / anderer Anbieter reviewt	Anderes Training, andere Defaults – markiert die Gewohnheiten des Autoren-Modells	Der Diff bleibt seine eigene Referenz
3	Deterministische Checks (Typen, Tests, Linter)	Null Modell-Bias auf der mechanischen Ebene	Können Absicht und Semantik nicht beurteilen
4	Verifikation gegen den schriftlichen Auftrag	Eine Referenz, die der Generator nicht verfasst hat – fängt „richtiger Code, falsches Ding“	Setzt voraus, dass der Auftrag aufgeschrieben ist

Unabhängigkeit bei der KI-Code-Prüfung ist eine Leiter, kein Schalter – jede Sprosse entfernt eine Klasse geteilter blinder Flecken, und die letzte wechselt die Referenz, nicht nur den Reviewer.

Die meisten Teams bleiben auf Stufe 1 stehen, weil ihr Tooling sie als Default mitliefert. Der Sprung, der das Spiel ändert, ist nicht 1→2, sondern 2→4: Solange der Diff die einzige Referenz ist, kann auch ein perfekt unabhängiger Reviewer nur fragen „ist das guter Code?“ – nie „ist das die richtige Änderung?“

Wie ein unabhängiges Setup praktisch aussieht

Den Auftrag vor dem Run aufschreiben. Ziel, Grenzen, prüfbare Kriterien – das schafft die eine Referenz, die das generierende Modell nicht geprägt haben kann.
Deterministische Checks vorlassen. Typen, Tests, Linter kennen keine Perplexitäts-Vorliebe; sie räumen die mechanische Ebene bias-frei ab.
Mit Distanz reviewen. Ein anderes Modell als der Generator, wo euer Tooling die Wahl lässt – die Forschung sagt: Die Verschiedenheit kauft die Erkennung.
Die Merge-Entscheidung menschlich halten. Unabhängigkeit endet bei jemandem, der verantwortlich die Belege liest und entscheidet – das ersetzt kein noch so unvoreingenommener Reviewer.

Wo Reality Graph ansetzt

Unabhängigkeit ist bei Reality Graph Designachse, kein Feature: Es verifiziert jeden Run gegen den schriftlichen Auftrag – eine Referenz, die der Coding-Agent nicht verfasst hat –, mit Validierung getrennt von der generierenden Session, und hält das Ergebnis in einem Prüfbericht fest. Es arbeitet neben Claude Code, Cursor, Copilot und deren eingebauten Reviewern – als zweite, unabhängige Meinung, nicht als Ersatz für die erste.

Unabhängige Verifikation ergänzt

Eine Referenz, die das generierende Modell nicht geprägt hat
Erkennung von Autoren-Modell-Gewohnheiten, die ein Same-Model-Durchgang normalisiert
Bias-freie mechanische Checks vor jeder Urteilsfrage
Belege, die Reviewer und Auditor lesen können

Sie behauptet nicht

Dass Selbstprüfung oder Bugbot-artige Tools nutzlos sind – sie finden echte Bugs
Dass ein anderes Modell alle Bias entfernt – es entfernt geteilte Bias
Dass irgendein automatischer Check die menschliche Merge-Entscheidung ersetzt
Dass Anbieter böswillig handeln – das ist Architektur, nicht Ethik

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Kann ein KI-Anbieter glaubwürdig seinen eigenen Code prüfen?: Teilweise. Ein separater Review-Durchgang findet echte Fehler, auch auf demselben Modell – ein frischer Kontext ohne die Generierungs-Historie liest den Diff anders. Was er nicht glaubwürdig leisten kann: die systematischen blinden Flecken des eigenen Modells finden. Die Forschung zeigt, dass LLM-Evaluatoren eigene Ausgaben erkennen und bevorzugen und vertraut wirkenden Text höher bewerten. Glaubwürdigkeit wächst mit Distanz – anderer Durchgang, anderes Modell, anderer Anbieter, andere Referenz.
Reviewt Cursor Bugbot Code, den Cursor selbst geschrieben hat?: Oft ja – genau dafür ist der Workflow gebaut: Der Agent schreibt, Bugbot reviewt den PR. Bugbot ist ein fähiger Reviewer, und Praktiker berichten von echten Funden, auch in PRs anderer Anbieter-Agenten. Die Unabhängigkeitsfrage zielt nicht auf Bugbots Qualität, sondern darauf, wie viel Distanz zwischen Generator und Reviewer liegt, wenn beide Frontier-LLMs sind – unter der Haube womöglich dasselbe.
Reicht ein anderes Modell fürs Review als Unabhängigkeit?: Es ist eine echte Verbesserung – ein anders trainiertes Modell hat andere Defaults und markiert, was das Autoren-Modell für normal hält. Aber auch Cross-Model-Review teilt eine strukturelle Grenze: Der Diff bleibt die einzige Referenz. Ist die Änderung sauber gebaut, tut aber das Falsche, sieht es kein Reviewer – der Auftrag steht nicht im Diff. Volle Unabhängigkeit braucht die zweite Dimension: Prüfung gegen den schriftlichen Auftrag, nicht nur gegen den Code.
Was zeigt die Forschung konkret zur Self-Preference-Bias?: Zwei Befunde tragen die Seite. Panickssery, Bowman und Feng (2024) zeigten, dass LLM-Evaluatoren eigene Ausgaben mit deutlicher Trefferquote erkennen – und dass Selbst-Erkennung linear mit Selbst-Bevorzugung korreliert. Wataoka, Takahashi und Ri (2024) fanden den Mechanismus: Modelle bewerten vertrauten (niedrig-perplexen) Text höher als menschliche Juroren; GPT-4 zeigte signifikante Self-Preference. Auf Code übertragen: Was ein Modell standardmäßig schreibt, wirkt auf dieses Modell per Konstruktion korrekt.
Ist KI-Selbstprüfung also nutzlos?: Nein – das wäre die Überkorrektur in die Gegenrichtung. Ein Review-Durchgang desselben Modells im frischen Kontext findet echte Defekte und ist deutlich besser als gar kein Maschinen-Durchgang. Die ehrliche Einordnung heißt Restrisiko: Selbstprüfung reduziert zufällige Fehler, nicht systematische. Teams, die das verstanden haben, nutzen Selbstprüfung fürs Tempo und ergänzen unabhängige Checks – anderes Modell, deterministische Tools, Auftragsabgleich – wo Korrektheit zählt.
Wie ergänzt ein Team Unabhängigkeit, ohne eine weitere Plattform zu kaufen?: Drei Schritte, die wenig kosten: das Review mit einem anderen Modell fahren als die Generierung (viele Tools lassen die Wahl); deterministische Checks – Typen, Tests, Linter – vorschalten, denn die haben gar keine Modell-Bias; und den Auftrag vor dem Run aufschreiben, damit die Verifikation eine Referenz hat, die das generierende Modell nicht geprägt haben kann. Der letzte Schritt ist der billigste und der meistvernachlässigte.

Weiterlesen

VergleichGreptile vs. lokale VerifikationGreptiles Codebasis-Index ist seine ehrliche Stärke und zugleich seine größte Datenfrage. Stärken, dokumentierter Datenpfad, VPC-Self-Hosting – und wann eine lokale Verifikationsschicht besser passt.VergleichSonarQube AI Code Assurance vs. VerifikationStrengere statische Quality Gates für KI-Code – deterministisch, on-prem-fähig – teilen sich die fünf KI-Fehlerklassen mit der Verifikation: Das Gate besitzt Code-Muster, Verifikation die Auftragstreue.Alle ArtikelDie ganze Sammlung – 45 belegte, datierte Guides zur Prüfung von KI-generiertem Code.