Gemini reviewte Claudes PR. Sechsunddreißig Kommentare später war sie besser.

Ein Reviewer, der dem Autor immer zustimmt, ist kein Reviewer. Lass den Code deiner KI an einer rivalisierenden KI vorbeilaufen, und die blinden Flecken werden sichtbar — einschließlich der Thread-Safety-Bugs, die sonst in Produktion gelandet wären.

Das Muster, zu dem ich immer wieder zurückkomme, ist das, bei dem Claude den Code schreibt und Gemini ihn reviewt. Anderes Training. Andere blinde Flecken. Andere Meinungen darüber, was ein vertretbares Muster ist und was ein Geruch. Dieser Samstag war die konkreteste Demonstration dafür, warum ich dieses Muster für das richtige halte.

Ein Batch von Phase-2-Endpoint-Erweiterungs-PRs war über die vorherige Woche verteilt über die gesamte API-Oberfläche gelandet. Acht separate Subsysteme bekamen jeweils ihre öffentliche Oberfläche erweitert. Claude hatte den Großteil der Implementierung geschrieben. Bevor ich irgendeinen davon gemergt habe, habe ich sie durch Gemini als Review-Durchgang laufen lassen. Gemini kam mit sechsunddreißig konkreten Kommentaren über den gesamten Batch zurück.

Ich habe jeden einzelnen durchgearbeitet. Dieser Post handelt davon, was Gemini gefunden hat und was es bedeutet, dass die Funde von der Art waren, die sie waren.

Was die acht Subsysteme waren

Die PRs deckten die acht API-Router-Module ab, die eine Phase-2-Erweiterung brauchten: Animation, Netzwerk, Audio, KI-Wahrnehmung, Szenen-Constructive-Solid-Geometry, Input-Action- und Gamepad-Bindings, XR-Anker-Pose-Typen und die Lebenszyklus-Verwaltung der Lua-Scripting-VM. Jeder PR fügte zwischen einem Dutzend und vierzig Endpoints hinzu, mit vollständigen Request-/Response-Schemata, Helfern und Tests.

Die PRs waren nicht subtil. Jeder einzelne war eine substantielle Erweiterung der öffentlichen Oberfläche. Zusammen repräsentierten sie mehrere Wochen Design-Arbeit, die die Agenten über etwa zwei Wochenenden implementiert hatten.

Was Gemini gefunden hat

Ich möchte konkret sein, weil die Kategorien wichtig sind.

Animation und Netzwerk: Blend-Tree-Referenzen und Helfer. Gemini bemerkte, dass die Blend-Tree-Helfer in der Animation-API und die Topologie-Helfer in der Netzwerk-API subtil unterschiedliche Konventionen dafür hatten, wie sie mit fehlenden Referenzen umgingen. Animation gab ein None-Äquivalent zurück und überließ dem Aufrufer die Entscheidung. Netzwerk warf eine Exception. Beides sind valide Muster. Sie waren nur inkonsistent über zwei PRs hinweg, die innerhalb eines Tages voneinander gelandet waren. Der Fix war, sie anzugleichen; wir haben uns für den expliziten Exception-Pfad entschieden, weil er die fehlende Referenz an der API-Grenze sichtbar macht, statt sie als stillen Null-Wert weiterzureichen.

Audio: Standardwerte und Helfer der Response-Modelle. Gemini fand heraus, dass mehrere Audio-Response-Modelle inkonsistente Standardwerte für optionale Felder hatten. Manche defaulteten auf leere Strings, manche auf None, manche auf ein explizites null. Die Inkonsistenz hätte auf der Client-Binding-Ebene verwirrendes Verhalten erzeugt (wo verschiedene Sprachen jede Option unterschiedlich serialisieren). Der Fix war, eine einzige Konvention zu wählen (None in den Python-Typen, null auf der Leitung) und sie konsequent anzuwenden.

KI-Wahrnehmung: Handle-Maps und Bindings. Gemini markierte ein Thread-Safety-Problem im Handle-Map des Wahrnehmungs-Subsystems: Die Map wurde von einem Hintergrund-Thread verändert, während sie gleichzeitig vom API-Request-Thread gelesen wurde, ohne Sperre. Unter Last hätte das intermittierende Map-Korruptionsfehler erzeugt, die sehr schwer zu diagnostizieren gewesen wären. Der Fix war eine Reader-Writer-Sperre, mit dem Lesepfad optimiert für den Normalfall (Lookups übertreffen Inserts bei Weitem).

Szene: Handle-Maps und CSG-Responses. Derselbe Bug-Typ wie beim Fund bei der KI-Wahrnehmung. Gemini fand dasselbe Thread-Safety-Problem in der CSG-Handle-Map des Szenen-Subsystems. Der Fix hatte dieselbe Form: eine Reader-Writer-Sperre. Das ist die Art von Bug, die ein einmal geschultes Augenpaar überall markiert, weil es das Muster schon gesehen hat; Claude hatte dasselbe Muster an zwei Stellen geschrieben, ohne es zu bemerken.

Input: Action- und Gamepad-Bindings. Gemini fand heraus, dass die Action-Binding-API eine Magic-Number-Konvention für ungültige Action-IDs verwendete (-1), während die Gamepad-Binding-API einen Sentinel-Struct-Wert nutzte. Die Inkonsistenz hätte subtile Bugs erzeugt, wenn ein Entwickler, der mit beiden APIs arbeitet, versehentlich den falschen Ungültig-Marker verwendet. Der Fix war, eine typisierte ActionId::Invalid-Konstante in beiden APIs einzuführen und alle Magic Numbers dorthin zu migrieren.

XR: Anker-Pose-Typen und Wiederverwendung von Handlern. Gemini fing ab, dass die XR-API in verschiedenen Endpoints zwei subtil unterschiedliche Pose-Typen offenlegte: einen in Weltkoordinaten und einen in ankerlokalen Koordinaten. Der Unterschied ist real und für den Konsumenten wichtig, aber die Endpoints dokumentierten den Unterschied nicht klar. Gemini schlug vor, die Typen zu trennen, damit das Typsystem die Unterscheidung erzwingt. Der Fix war, WorldPose und AnchorPose als eigenständige Typen ohne implizite Umwandlung zwischen ihnen einzuführen.

Scripting: Lebenszyklus der Lua-VM und Lecks. Gemini fand heraus, dass die Lua-VM pro Request allokiert wurde, ohne klaren Abbaupfad. Unter anhaltender Last hätte das VM-Zustand in den Adressraum lecken lassen, bis der API-Server zusammenbricht. Der Fix war, einen VM-Pool pro Server-Thread mit expliziter Acquire- und Release-Semantik einzuführen sowie einen Abbaupfad hinzuzufügen, der bei Abschluss des Requests läuft, unabhängig von Erfolg oder Fehlschlag.

Was mir an den Funden als Kategorie aufgefallen ist

Drei Beobachtungen.

Die meisten Funde waren Konsistenz-Funde. Zwei Drittel von Geminis Kommentaren waren „diese Konvention weicht von der Konvention ab, die in einem anderen Subsystem verwendet wird, das du gerade gelandet hast.” Das ist genau die Art von Fund, bei der ein einzelnes Modell schlecht ist, weil jeder PR isoliert landete und das Modell, das ihn schrieb, die anderen PRs nicht im Kontext hatte. Ein Reviewer, der über den gesamten Batch hinweg arbeitet, sieht die Inkonsistenzen, die der Autor nicht im Kopf hatte.

Ein paar Funde waren echte Bugs. Die Thread-Safety-Funde bei den Handle-Maps waren echte Bugs. Sie wären ausgeliefert worden. Sie wären intermittierend und schwer zu diagnostizieren gewesen. Gemini fing beide Instanzen im Batch ab (eine in der KI-Wahrnehmung, eine in der Szenen-CSG), weil es die Mustererkennung für „gemeinsam genutzte veränderliche Map ohne Sperre = Thread-Safety-Bedenken” hatte. Anderes Modell, anderes Training, andere Dinge, auf die es kalibriert wurde zu achten.

Ein paar waren stilistisch und wurden diskutiert. Nicht jeder Gemini-Kommentar war richtig. Eine Handvoll waren stilistische Präferenzen, gegen die ich entweder Einspruch erhoben oder um menschliches Urteil gebeten habe. Die Tatsache, dass manche Kommentare abgelehnt wurden, schwächt das Muster nicht; sie stärkt es. Ein Reviewer, der dem Autor immer zustimmt, ist kein Reviewer.

Was das leistet und was nicht

Was es leistet: eine Klasse von Bugs abfangen, die Einzelmodell-Review verpasst. Konkret die PR-übergreifenden Konsistenzbugs und die Mustererkennungs-Funde, bei denen ein anders trainierter Reviewer etwas markiert, das das Training des Autors nicht gesehen hat.

Was es nicht leistet: menschliches Review ersetzen. Die Gemini-Kommentare waren ein erster Durchgang. Ich habe jeden einzelnen gelesen. Ich habe manche abgelehnt. Ich habe die meisten akzeptiert. Die endgültige Merge-Entscheidung lag bei mir. Das Muster ist „Claude schreibt, Gemini reviewt, der Mensch entscheidet.” Nicht „Gemini entscheidet.”

Was das für KI-Labore nahelegt: die Metrik, die es zu optimieren gilt, ist nicht „besteht der eigene Code des Modells das eigene Review des Modells.” Sie ist „besteht der Code des Modells das Review durch das Modell eines anderen Anbieters.” Die Agenten, die bei der vendor-übergreifenden Metrik gut abschneiden, sind die, denen ich bei ernsthafter Arbeit vertraue.

Was Partner und Entwickler daraus mitnehmen sollten

Wenn du einen agentengesteuerten Workflow betreibst und noch kein PR-Review durch das Modell eines anderen Anbieters laufen lässt, probiere es beim nächsten Batch aus. Die Einrichtungskosten sind gering. Die Fundrate ist nicht trivial. Der heutige Batch hat zwei echte Thread-Safety-Bugs gefunden, die sonst ausgeliefert worden wären.

Wenn du ein KI-Labor bist und deinen Coding-Agenten noch nicht auf „PR-Review gegen das Modell eines anderen Anbieters” als Ziel optimiert hast, erwäge es. Die Metrik ist ehrlich. Das Signal ist real. Die Agenten, die dabei gut abschneiden, sind die, die ernsthafte Teams übernehmen werden.

Wenn du eine Engine für eine Partnerschaft evaluierst: Das vendor-übergreifende Review-Muster ist eines der Disziplin-Signale, nach denen ich fragen würde. Ein Team, das bei jedem bedeutenden PR ein vendor-übergreifendes Review durchführt, ist ein anderes Team als eines, das das nicht tut. Die Codebasis spiegelt den Unterschied wider.

Sechsunddreißig Kommentare, acht Subsysteme, ein Samstag. Der Batch ist besser als heute Morgen. Das Muster zahlt sich wieder aus.

Zurück ans Bauen.