Datadog validierte Codex anhand eigener vergangener Incidents, bevor es ausgerollt wurde

Der Incident-Replay-Testaufbau ist hier der eigentliche Test

Die meisten Erfolgsgeschichten zur Einführung von KI-Code-Reviews stützen sich auf Bauchgefühl: Ingenieure sagen, die Vorschläge wirkten klug, die Nutzung steigt, und alle machen weiter. Das AI-DevX-Team von Datadog unter der Leitung von Brad Carter ging einen Schritt, der sich schwerer fälschen lässt. Sie bauten einen Incident-Replay-Testaufbau, der Pull Requests rekonstruierte, die zu vergangenen Produktions-Incidents beigetragen hatten, ließen Codex jeden davon durchlaufen, als wäre er Teil des ursprünglichen Reviews, und fragten anschließend die Ingenieure, die für diese Incidents verantwortlich waren, ob das Feedback von Codex einen Unterschied gemacht hätte.

Das Design ist entscheidend, weil es die zwei üblichen Schlupflöcher ausschließt, die solche Auswertungen sonst aufblähen. Die Pull Requests hatten zum damaligen Zeitpunkt bereits ein menschliches Review durchlaufen, jedes von Codex aufgedeckte Risiko war also eines, das echte Reviewer übersehen hatten. Und die Beurteilenden waren die Incident-Verantwortlichen selbst, kein Benchmark und keine Vendor-Scorecard.

Das Ergebnis: Codex markierte in mehr als 10 Fällen Probleme, die relevant gewesen wären – etwa 22 % der von Datadog untersuchten Incidents – mehr als jedes andere vom Team getestete Tool. Das ist eine konkrete, überprüfbare Aussage, die an die eigene Ausfallhistorie eines Unternehmens gebunden ist, keine allgemeine Genauigkeitsangabe.

Warum linterähnliche Tools weiterhin ignoriert wurden

Datadog nennt klar, warum frühere KI-Review-Tools im eigenen Workflow scheiterten: Viele verhielten sich wie fortgeschrittene Linter, die oberflächliche Probleme markierten, aber die Nuancen des Systems übersahen. Die Ingenieure fanden die Vorschläge zu flach oder zu störend und ignorierten sie schlicht. Das ist die ehrliche Ausgangslage, die die meisten Ankündigungen auslassen.

Der Unterschied, den Datadog beschreibt, betrifft den Kontext. Laut der Quelle vergleicht Codex die Absicht eines Pull Requests mit den eingereichten Änderungen, denkt über die gesamte Codebasis und ihre Abhängigkeiten nach und führt Code sowie Tests aus, um das Verhalten zu validieren. Die konkreten Ergebnisse, die Ingenieure nannten, waren Interaktionen mit Modulen, die im Diff nicht angefasst wurden, fehlende Testabdeckung in Bereichen mit Cross-Service-Kopplung und API-Vertragsänderungen mit Risiko für nachgelagerte Systeme.

Es war das erste Tool, das den Diff tatsächlich im größeren Kontext des Programms zu berücksichtigen schien. Das war neu und augenöffnend.Montana Labs

Das ist eine eng gefasste, testbare Aussage über das Verhalten eines Tools – das Nachdenken über nicht angefasste Module – und kein allgemeines Versprechen von Intelligenz. Es erklärt auch den Verhaltenswandel: Ingenieure berichteten, dass sie Codex-Kommentare als echtes Review-Feedback behandelten statt als Rauschen, das man nur überfliegt.

Organisches Feedback über Slack statt In-Tool-Metriken

Ein operatives Detail fällt besonders auf. Datadog hat inzwischen mehr als 1.000 Ingenieure, die Codex regelmäßig nutzen, doch das Unternehmen sagt, dass Feedback größtenteils organisch entsteht und nicht über formale In-Tool-Metriken. Ingenieure posten in Slack über nützliche Erkenntnisse und Momente, in denen Codex ihnen half, anders zu denken.

Während der Pilotphase war die Messung sogar noch einfacher: Ingenieure bewerteten Codex-Kommentare mit Daumen hoch oder runter in einem großen, stark genutzten Repository, in dem jeder Pull Request automatisch überprüft wurde. Das Signal, dem Datadog am meisten vertraute, war, ob die Leute die Kommentare freiwillig lasen.

Das ist bemerkenswert, weil es dem üblichen Reflex widerspricht, zuerst ein Dashboard zu bauen. Datadog behandelte den Replay-Testaufbau als die eigentliche, rigorose Auswertung und ließ die tägliche Nutzung sich selbst beweisen – daran, ob Ingenieure die Ausgaben ihrer Aufmerksamkeit für wert hielten.

Code-Review neu gedacht: Incident-Vermeidung statt Zykluszeit

Die formulierte Konsequenz für Datadog ist eine Neudefinition dessen, wofür Code-Review überhaupt da ist. Carter macht deutlich, dass Zeitersparnis, so real sie auch ist, bei ihrer Größenordnung nicht der Punkt ist – die Vermeidung von Incidents ist es. Das Team beschreibt Codex inzwischen als zentrales Zuverlässigkeitssystem und nicht mehr als Kontrollpunkt zum Aufspüren von Fehlern oder zur Beschleunigung von Reviews.

Codex hat meine Sicht darauf verändert, was Code-Review sein sollte. Es geht nicht darum, unsere besten menschlichen Reviewer zu ersetzen. Es geht darum, kritische Fehler und Randfälle zu finden, die Menschen beim isolierten Betrachten von Änderungen schwer erkennen können.Montana Labs

Für Teams, die ähnliche Tools abwägen, ist die übertragbare Lektion die Bewertungsmethode, nicht die Wahl des Anbieters. Ein Unternehmen, das seine eigene Incident-Historie bereits kennt, kann jedes Review-Tool an tatsächlich eingetretenen Ausfällen messen und die Betroffenen fragen, ob das Tool geholfen hätte. Das führt zu einer belastbaren Entscheidung für die Einführung – und bei Datadog zu einer klaren Arbeitsteilung, bei der der Agent Cross-Service-Risiken aufdeckt und sich menschliche Reviewer auf Architektur und Design konzentrieren.