Cockroach Labs: Fünf Monate lang Fehler wie Patienten und Coding-Agenten wie ein Ärzteteam behandelt

An einem Mittwochabend im April konnte MOLT, das Werkzeug, mit dem Cockroach Labs Datenbanken nach CockroachDB migriert, noch nicht aus IBM Db2 lesen. Am Freitagnachmittag konnte es das. Db2 gehört zu den ersten kommerziell verfügbaren relationalen Datenbanken. Es hat einen reichen SQL-Dialekt, ein komplexes Typsystem und ein natives Wire-Protokoll. Die Unterstützung erforderte einen neuen Schema-Konverter, einen neuen Fetch-Pfad, der Zeilen herauszieht und in CockroachDB lädt, einen neuen Verify-Pfad, der sie nach dem Laden vergleicht, eine mitgelieferte ANTLR-Grammatik, ein Docker-Image für die CI und mehr als zehntausend Zeilen Testdaten. Als das Team 2024 die Oracle-Unterstützung in MOLT ergänzte, dauerte die gleichwertige Arbeit neun Monate und kostete rund 160.000 Dollar Entwicklungszeit. Die Db2-Arbeit dauerte weniger als zwei Tage, und kein Mensch schrieb Code. Die Token-Rechnung betrug 4.172 Dollar. Das ist 164-mal schneller und 38-mal günstiger.

Am Anfang stand ein einziges GitHub-Issue, das den Wunsch beschrieb. Ein Planungsagent las es, hielt es für zu groß, um es auf einmal zu bearbeiten, und zerlegte es in fünfzehn Unter-Issues mit einem expliziten Abhängigkeitsgraphen: zuerst das Fundament, dann das Typsystem, der Zeilen-Iterator, Fetch, Verify und Convert, zuletzt CI und Testdaten. Zwei Unter-Issues galten in ihrer eigenen Analyse als zu groß und wurden erneut zerlegt. Unterwegs eröffneten die Agenten rund ein Dutzend weitere Issues zu ihrer eigenen Arbeit: Lücken bei den Testdaten, einen Fehler in der Typzuordnung und eine Korrektur der Isolationsstufe. Kein Mensch fand diese Probleme. Die Pipeline fand sie, hielt sie fest und reihte sie in die Warteschlange ein. Die Arbeit zu zerlegen und ihre Abhängigkeiten sichtbar zu machen, ist der erste Grund, warum eine Aufgabe dieser Größe in zwei Tagen fertig werden konnte.

Der zweite Grund ist die Organisation der Pipeline. Cockroach Labs wählte ein Lehrkrankenhaus als leitende Metapher. Jeder Fehler ist ein Patient, und jeder Coding-Agent spielt eine Rolle im medizinischen Team. Die Triage-Pflegekräfte nehmen Aufgaben entgegen und sichten sie. Sie entscheiden, was das Problem ist, wie groß es ist und wer es bearbeiten soll. Die Fellows übernehmen die eigentliche Behandlung, also das Schreiben der Korrektur. Die Review-Oberärzte führen eine strenge Prüfung durch und wachen über die Qualität. Die Entlassungspflegekräfte schließen den Fall ab und prüfen, dass vor dem Merge alle Kontrollen und alle Aufzeichnungen vorhanden sind. Die Metapher ist keine Dekoration. Sie nimmt eine Arbeitsteilung und ein System von Gegenkontrollen, die Softwareteams ohnehin brauchen, und verankert sie in einem Ablauf, den jeder versteht. Ein Krankenhaus lässt nicht denjenigen, der behandelt hat, die eigene Behandlung allein abzeichnen. Eine Agenten-Pipeline hält diese Regel nur ein, wenn jemand sie bewusst einbaut.

Der dritte Grund ist eine kurze Liste harter Disziplinen. Die Agenten müssen planen, bevor sie Code schreiben, und der Plan selbst wird geprüft, damit eine falsche Richtung gestoppt wird, bevor Tokens für tausende Zeilen verbraucht sind. Strenge Testabdeckung ist Bedingung für den Merge und keine nachträgliche Ergänzung. Sorgfältige Dokumentation bedeutet, dass jede Entscheidung und jede Änderung eine Spur hinterlässt, wie eine Patientenakte, und diese Spur ist der einzige Weg, später zu verstehen, warum etwas zurückgenommen wurde. Sicherheitsleitplanken stehen vor dem Merge. Diese Regeln wirken schlicht. Sie zielen aber genau auf die Stellen, an denen Agenten am häufigsten scheitern: ein falsch verstandenes Ziel, unverdientes Selbstvertrauen und ein Ergebnis, für das niemand verantwortlich ist.

Das überzeugendste Maß für die Zuverlässigkeit eines solchen Systems ist die Zahl der Reverts. In fünf Monaten verarbeitete die Pipeline mehr als eine Million Codezeilen und verursachte nur sieben Reverts. Diese Zahl legt nahe, dass autonome Ergebnisse und Zuverlässigkeit auf Unternehmensniveau sich nicht ausschließen müssen, sofern die Zuverlässigkeit in die Struktur des Systems eingebaut ist und nicht auf der Hoffnung beruht, ein einzelnes Modell sei klug genug. Dieselben Mechanismen tragen Funktionen wie den Migration Assistant. Wenn komplexe Datenbankmigrationen von Agenten gebaut und gepflegt werden, sind Planungsprüfung, Testabdeckung und lückenlose Aufzeichnungen die wichtigste Verteidigung gegen teure Regressionen. Eine faire Lesart braucht auch Vorsicht: Die Zahlen stammen von Cockroach Labs selbst, und der Vergleich mit dem Oracle-Projekt, neun Monate und rund 160.000 Dollar, ist eine Schätzung des Unternehmens. Das ist eine starke Fallstudie, aber kein allgemeiner Maßstab.

Für die Branche ändert der Beitrag die Frage. Lange fragte man, welches Modell den besten Code schreibt. Dieser Fall verweist auf eine nützlichere Frage: Wie organisiert man eine Gruppe von Agenten, damit sie die Arbeit teilen, einander prüfen, Spuren hinterlassen und im Fehlerfall eine klare Verantwortungskette haben? Wenn die Kosten von neun Monaten auf zwei Tage und von 160.000 Dollar auf gut 4.000 Dollar sinken, verlagert sich der Engpass weg vom Programmieren. Er wandert zur Beschreibung der Anforderung, zur Zerlegung der Aufgabe und zur Abnahme des Ergebnisses. Teams, die Ähnliches erreichen wollen, sollten zuerst in Zerlegungskompetenz, Prüfprozess und Testinfrastruktur investieren. Das Jagen nach einem stärkeren Modell kommt danach. Die Krankenhaus-Metapher bleibt im Gedächtnis, doch die Lehre darunter ist gewöhnliche Ingenieurskunst: Jeder Schritt bekommt einen Verantwortlichen, alles wird aufgeschrieben, und nichts wird gemergt, bevor die Prüfungen bestehen.