Claude schreibt, Gemini reviewt, ChatGPT ist die Quietscheente

Single-Vendor-KI sieht auf dem Papier einfacher aus und liefert in der Praxis Brüchigkeit. RakuAI wird von einer Multi-Vendor-Agentenschleife gebaut — und so gebaut, dass es das Modell jedes Anbieters steuern kann. Der Entwicklungsprozess spiegelt die Produktthese.

Samstagmorgen, Kaffee, und der Workflow, bevor er sich wieder ändert. Wenn ich Leuten erzähle, dass ich eine Engine zusammen mit autonomen Coding-Agenten baue, ist die erste Frage „welcher Agent”. Die ehrliche Antwort ist „mehrere, in unterschiedlichen Rollen, und die Arbeitsteilung zählt”. Dieser Beitrag ist die längere Antwort.

Gerade jetzt involviert der Entwicklungsworkflow mindestens drei verschiedene KI-Anbieter, die verschiedene Teile der Schleife spielen. Der Grund ist nicht Loyalität oder Wählerei. Es ist, dass jedes Modell tatsächlich besser bei einer anderen Art von Arbeit ist, und der Versuch, ein Modell alles machen zu lassen, produziert messbar schlechteren Code.

Die Rollen, heute

Claude schreibt den Großteil des Runtime-Codes. Langkontext-Reasoning über eine große Codebasis, Planung vor der Bearbeitung, viel Zustand in einem Kopf halten. Das ist das Modell, das ich für substanzielle Subsystem-Arbeit auf der Issue-Warteschlange laufen lasse. Wenn ein Issue sagt „einen OpenXR-Composition-Layer-Manager und Action-Spaces implementieren”, ist Claude derjenige, der den PR landet.

Gemini reviewt die meisten PRs. Anderes Training, andere blinde Flecken. Wenn Claude einen PR landet, liest Gemini den Diff und widerspricht. Die Art von Kommentaren, die Gemini zutage fördert, unterscheidet sich von der Art, die ich manuell zutage fördern würde. Manche sind Rauschen. Manche sind nützlich. Das Signal-Rausch-Verhältnis ist gut genug, dass ich Gemini als ersten Review-Durchgang bei jedem Diff vertraue.

ChatGPT ist, wo ich die Quietscheente mache. Wenn ich bei einer architektonischen Entscheidung feststecke und noch nicht weiß, in welche Richtung sie gehen soll, denke ich laut mit ChatGPT. Das Modell schreibt in dieser Rolle keinen Code. Es stößt mich auf Annahmen, schlägt drei alternative Rahmungen vor und lässt mich mit ihm streiten. Es ist die Rolle, die ein erfahrener Kollege spielen würde, wenn ich einen hätte. Ich habe derzeit keinen. ChatGPT ist die Simulation.

Copilot ist im Editor. Das ist die Autovervollständigungsrolle. Wenn ich Code von Hand schreibe (was seltener vorkommt, als Leute denken, aber es passiert), ist Copilot das Modell, dessen Vorschläge ich in der IDE sehe. Es ist gut bei der lokalen Kontext-Arbeit, den nächsten vier Zeilen.

Das ist der Workflow. Vier Modelle, vier Rollen. Jedes ist in seiner Rolle besser als die anderen es wären.

Warum Multi-Vendor wichtig ist

Drei Gründe.

Die Fähigkeitsobergrenze ist je Anbieter unterschiedlich. Würde ich ein Modell für jede Rolle laufen lassen, würde jede Schwäche dieses Modells als Schwäche im Entwicklungsprozess auftauchen. Claude ist exzellent im Schreiben. Weniger exzellent darin, Fehler in der eigenen Schrift zu finden. Gemini ist exzellent darin, Fehler zu finden, aber es ist nicht das Modell, das ich unbeaufsichtigt ein Refactoring planen lassen würde. ChatGPT denkt gut über offene architektonische Fragen nach, aber sein Code in echten Subsystemen ist nicht das, was ich ausliefern möchte. Jedes ist das beste Werkzeug für einen Platz.

Unabhängigkeit im Review ist strukturell. Die mit Abstand wichtigste Regel, auf die ich gekommen bin, ist, dass das Modell, das einen PR schreibt, nicht das Modell sein kann, das ihn reviewt. Selbst-Review ist kein Review. Ein Modell eines anderen Anbieters den ersten Review-Durchgang machen zu lassen, erzeugt Unabhängigkeit von Architektur, von Trainingsdaten, von Fehlermodi. Die Fehler, die Gemini in Claudes Code findet, sind echte Fehler, die sonst gelandet wären.

Keine Bindung an einen einzelnen Anbieter. Die Engine wird so gebaut, dass sie Anweisungen von jedem Cloud-LLM entgegennimmt (letzten Monat in der XRAssistantService-Arbeit behandelt). Der Entwicklungsworkflow, der die Engine baut, sollte zu dieser Haltung passen. Ich will nicht, dass das Engineering dieser Runtime davon abhängt, dass ein Anbieter für die nächsten fünf Jahre wettbewerbsfähig bleibt. Keiner von ihnen wird das. Die, die jetzt gut sind, werden später auf andere Weise gut sein. Einen Multi-Vendor-Workflow auf der Entwicklungsebene zu betreiben hält das Engineering portabel.

Die ehrlichen Kosten

Ein paar.

Koordinationsaufwand ist real. Zwischen Anbietern mitten in einer Aufgabe zu wechseln bringt kognitiven Mehraufwand mit sich. Die Lösung ist, jede Aufgabe innerhalb der Spur eines Anbieters zu halten und die Übergabe zwischen Aufgaben stattfinden zu lassen, nicht innerhalb von ihnen.

Die Rechnungen summieren sich. Vier Modell-Abonnements laufen zu lassen ist nicht kostenlos. Die Kosten sind spürbar, und ich trage sie derzeit persönlich. Der Ertrag daraus ist messbar in ausgelieferten Subsystemen, also geht die Rechnung in dieser Phase auf. Das wird nicht immer so sein.

Qualitätsdrift zwischen Anbietern ist ein echtes Thema. Wenn Gemini bei einer Art von Aufgabe besser wird, die Claude bisher erledigt hat, ist die richtige Antwort, diese Aufgabe zu Gemini zu verschieben. Die falsche Antwort ist, es weiter auf die alte Weise zu machen, weil das Workflow-Dokument das so sagt. Das Workflow-Dokument muss alle paar Wochen überarbeitet werden, weil sich die Modelllandschaft unter dem Workflow bewegt.

Die Anbieter wissen nichts voneinander. Wenn Claude ein Stück Code schreibt, das von Gemini reviewt werden wird, weiß Claude das nicht. Wenn ChatGPT mit mir eine architektonische Entscheidung diskutiert, sieht die spätere Implementierung durch Claude diese Diskussion nicht. Die Integration zwischen den Anbietern findet in meinem Kopf statt. Das ist ein fragiler Ort für Integration, und es ist eines der Dinge, die ich beheben würde, wenn ich Infrastruktur bauen würde, um anderen zu helfen, diesen Workflow zu betreiben.

Was ist mit der Runtime-Seite?

Das ist der Teil, an dem die Entwicklungsworkflow-Geschichte und die Engine-Geschichte zusammenlaufen.

Der XRAssistantService, der vor zwei Wochen in der Runtime landete, ist von Grund auf modellagnostisch. Der Grund ist genau derselbe wie der Grund, warum dieser Entwicklungsworkflow Multi-Vendor ist. Die Schnittstelle ist so gebaut, dass jedes Modell dieser Labore eine AR-Erfahrung durch die Runtime steuern kann. Das Labor, dessen Modell bei einer bestimmten Aufgabe am besten ist, darf den Intent für diese Aufgabe in jeder gegebenen Erfahrung liefern.

Das ist die breitere Wette: Die Ära von „dieses Produkt wird auf diesem Modell von diesem Anbieter gebaut” ist kurz. Die Ära, in die wir eintreten, ist „dieses Produkt wird um modellförmige Fähigkeiten herum gebaut, und welches konkrete Modell welchen Fähigkeitsplatz zu einem gegebenen Zeitpunkt füllt, ist eine Konfigurationsentscheidung.” Die Engine muss dafür bereit sein. Der Entwicklungsworkflow, der die Engine baut, sollte das widerspiegeln.

Was ich Buildern und Laboren mitgeben möchte

Wenn Sie ein Anbieter von Coding-Agenten sind und das hier lesen: Die Metrik, für die ich optimieren würde, ist „wie oft übersteht der PR dieses Agenten das Review durch einen Agenten eines konkurrierenden Anbieters.” Selbstkonsistenz ist nicht die Messlatte. Das Überstehen anbieterübergreifenden Reviews ist die Messlatte. Die Agenten, die auf dieser Metrik gut abschneiden, werden die sein, die für ernsthafte Arbeit eingesetzt werden.

Wenn Sie Entwickler sind und überlegen, einen KI-unterstützten Workflow für eine ernsthafte Codebasis einzuführen: Wählen Sie nicht ein Modell und hören dann auf. Wählen Sie eines zum Schreiben. Wählen Sie ein anderes zum Reviewen. Nutzen Sie ein drittes, um die offenen architektonischen Fragen als Quietscheente durchzugehen. Der Kostenaufschlag ist real, und der Qualitätsunterschied ist größer.

Wenn Sie eine Führungskraft in einem Unternehmen sind und über KI in Ihrer Entwicklungsorganisation nachdenken: Das Multi-Vendor-Muster ist das, das skalieren wird. Single-Vendor-Adoption sieht auf dem Papier einfacher aus. In der Praxis produziert sie Brüchigkeit, sowohl technisch als auch strategisch.

Ruhiger Samstag. Die Engine bekam ein Fünfunddreißig-Commit-Wochenende. Die meisten dieser Commits werden in sechs Monaten unsichtbar sein. Der Workflow, der sie produziert hat, wird es nicht sein.