Two desk lamps facing each other over a sheet of paper marked in red pencil
Back to blog
EngineeringAI Automation

2.481 Gegenprüfungen: Claude Code und Codex kontrollieren einander

Zwei Monate lang ließen wir Claude Code und Codex vor jeder Veröffentlichung die Arbeit des jeweils anderen prüfen. Nach 2.481 Prüfungen zeigen die Zahlen, was dabei herauskam und welche Regel wir ergänzen mussten.

S
Sno AI Team
September 22, 2026
|
6 min read
|
39 views
Share:

Claude Code erledigt die Arbeit, und Codex liest sie vor der Veröffentlichung. Wenn Codex schreibt, liest Claude.

Bei einer Bank läuft es genauso. Niemand genehmigt seinen eigenen Kredit. Jemand schreibt den Antrag, jemand anders unterschreibt, und niemand nimmt es persönlich. Wir nennen unsere Variante Dual Brain: zwei KI-Agents arbeiten als Paar an derselben Aufgabe, einer führt sie aus, der andere prüft sie. Das ist in Sno Station eingebaut, und wir arbeiten seit Mitte Juli so.

Jede Prüfung hinterlässt eine Zeile in einer Protokolldatei auf unserem Build-Rechner. Vor einer Weile wurde ich neugierig und zählte sie.

Die Zahlen

Vom 19. Juli bis zum 21. September prüften sich die beiden KI-Agents 2.481 Mal gegenseitig. An 63 dieser Tage arbeiteten sie, also etwa 39 Prüfungen pro Tag. Sie lasen 3,2 Millionen Zeilen in 9.452 Dateien.

Eine Prüfung dauert ungefähr zwei Minuten. Der Median liegt bei 141 Sekunden, und neun von zehn sind in weniger als sechs Minuten fertig. Diese Zahl ist wichtiger, als sie aussieht. Eine menschliche Prüfung dauert einen Tag, der größtenteils mit Warten auf den Menschen vergeht. Bei zwei Minuten fragst du nicht mehr, ob sich eine Prüfung lohnt. Alles wird geprüft.

Ich dachte, die meiste Arbeit würde durchgehen.

Von den Prüfungen mit einem Urteil wurden 431 freigegeben. Bei 1.953 hieß es: nachbessern. In vier von fünf Fällen schickte der zweite KI-Agent die Arbeit also zurück.

Vier von fünf. Das sind keine schlampigen Erstentwürfe eines müden Praktikanten. Das Modell hatte seine Tests bereits ausgeführt und die Arbeit für erledigt erklärt.

Code und Pläne

Dann zählte ich die Prüfungen von Code und Plänen getrennt.

Code bestand in 27 Prozent der Fälle. 398 Freigaben bei 1.475 Prüfungen. Nicht toll, aber damit kann man leben.

Pläne bestanden in 3,6 Prozent der Fälle. 33 von 907.

Da musste ich zweimal hinsehen. Ein Plan ist ein Dokument. Er sagt, was wir bauen wollen und warum. Man könnte meinen, ein Dokument sei leichter richtig hinzubekommen als Code, weil es nicht kompilieren muss. Es ist umgekehrt. Code wird jedes Mal von der Wirklichkeit korrigiert, wenn du ihn ausführst. In einem Plan kann stehen, die Datenbank habe eine Spalte, die gar nicht existiert. Der Satz sieht völlig vernünftig aus, bis jemand darauf aufbaut.

Deshalb geben wir der prüfenden Person jetzt die Fakten zusammen mit dem Plan. Vor der Planprüfung führt der schreibende KI-Agent die Befehle aus, zählt die Zeilen, gibt das Schema aus und hängt die Rohausgabe an. So kann der prüfende Agent die Aussagen mit etwas abgleichen. Ohne das ist es eine Prüfung ohne Hilfsmittel. Widersprüche im Dokument findet er, aber nicht den Widerspruch zwischen Dokument und Wirklichkeit.

Die meisten schwerwiegenden Funde entstehen genau aus dieser Lücke. Im selben Zeitraum markierten die Prüfer 4.277 schwerwiegende Probleme in 1.395 Prüfungen. Ich habe nicht jedes einzelne kontrolliert, und nicht alle sind echt. Die echten Fälle waren aber meist von derselben Art: Etwas wurde voller Überzeugung behauptet, ohne dass jemand tatsächlich nachgesehen hatte.

Wo es schiefging

Wenn ich hier aufhörte, wäre das eine schöne Geschichte. Ich würde gern glauben, dass all diese Prüfungen die Arbeit verbessert haben.

So einfach ist es nicht. Ein Prüfer findet nämlich immer etwas.

Schau dir die späteren Runden an. Nachdem der schreibende Agent die Befunde behoben und erneut um Prüfung gebeten hatte, bestand die Arbeit in 21 Prozent der Fälle. In der ersten Runde waren es 17 Prozent. Jeden Befund zu beheben änderte die Chancen kaum. Ein Arbeitsstück durchlief fünfzehn Runden.

Das heißt nicht, dass der schreibende Agent fünfzehnmal versagt hat. Der Prüfer tut nur, was Prüfer tun. Wenn du ein fähiges Modell bittest, Probleme zu finden, findet es welche. Ist der normale Ablauf sauber, sucht es in den Ecken. Zwei Anfragen treffen in derselben Millisekunde ein. Ein Schreibvorgang wird mittendrin abgebrochen. Fälle, die irgendwie möglich sind, so wie ein Meteoriteneinschlag möglich ist.

Und der schreibende Agent ist gefällig und behebt jeden davon, indem er etwas hinzufügt.

Anfang dieses Monats hatten wir einen kleinen Fehler. Die Behebung durchlief sechs Prüfrunden. In jeder Runde brachte der Prüfer eine neue Sorge vor, und in jeder Runde baute der schreibende Agent eine neue Absicherung ein. Eine Obergrenze für die Tokenzahl. Eine Sperre pro Sitzung. Eine eigene Tabelle, die erfasst, was bereits ausgegeben wurde. Eine Zuordnung für Aliasnamen. Am Ende war der Patch eine kleine Festung.

Keiner dieser Mechanismen kam je in der Produktion zum Einsatz. Darunter steckte im eigentlichen Fix immer noch ein Identitätsfehler in einer einzigen Zeile, den niemand sah, weil er unter den Schutzwällen begraben lag. Das war, als würde man die Verstärkung aufdrehen, um ein leises Instrument zu hören, und bekäme vor allem Rauschen.

Die Regel, die wir eingeführt haben

Also schrieben wir eine Regel auf. Sie ist das Nützlichste, was aus dem ganzen Experiment hervorging.

Ein Befund ist kein Auftrag, Code hinzuzufügen.

Die Prüfung liefert jetzt zwei Gruppen von Befunden. Die erste enthält Probleme, auf die echte Nutzer an einem normalen Tag stoßen würden und deren kleinste Behebung nichts Neues hinzufügt. Die beheben wir. Die zweite enthält alles andere: exotische Fälle und Dinge, für die eine neue Sperre, ein neuer Wiederholungsversuch oder eine neue Tabelle nötig wäre. Wir halten sie fest und melden sie. Zu Code werden sie nur, wenn ein Mensch das entscheidet.

Außerdem lassen wir den Prüfer zuerst nach Überflüssigem suchen und erst dann nach Fehlendem. Eine Sperre, die niemand brauchte. Ein Schalter mit nur einer Aufrufstelle. Ein Test, der bloß den Code wiederholt. Auch eine Löschung zählt jetzt als Befund.

Und es gibt eine Obergrenze. Drei Runden für Code. Eine für Tests. Danach geht die Diskussion an einen Menschen, wo sie vermutlich ohnehin hingehörte.

Was es wert ist

Ich kann dir keinen eindeutigen Wert nennen. Das würde ich gern. Ich habe keine Kontrollgruppe, kein zweites Unternehmen, das dieselbe Arbeit ohne Prüfung veröffentlicht hat.

Was ich habe, ist dies: In vier von fünf Fällen wollte ein anderes Modell etwas an einer Arbeit ändern, die das erste Modell für fertig erklärt hatte. Ein Teil davon ist Rauschen. Aber ein einzelner KI-Agent schickt seine eigene Arbeit bei der Prüfung fast nie zurück, weil er bereits glaubt, was er geschrieben hat. Die zweite Meinung muss von anderswo kommen. Von einem anderen Modell, das andere Menschen trainiert haben und das nicht dabei war, als das erste entschied, dass alles in Ordnung sei.

Zwei Köpfe sind besser als einer. Das gilt offenbar auch, wenn keiner der Köpfe menschlich ist.

Sno Station ist Open Source, und die Gegenprüfung gehört dazu. Du findest es auf sno.ai.

S

Written by Sno AI Team

Contributing writer at Sno.ai, sharing insights about AI, productivity, and knowledge management.

Related Articles

Comments

Comments coming soon. Configure Giscus at giscus.app

2.481 Gegenprüfungen: Claude Code und Codex prüfen sich