DoorDash: 45 von 50 Flags mit KI-Agenten bereinigt

DoorDash hat gezeigt, wie sich veraltete Feature Flags mit KI-Agenten kontrolliert entfernen lassen: Der Produktionswert wird aus der Experimentplattform gelesen und von einem Menschen bestätigt, jede Änderung entsteht isoliert und ein Pull Request darf erst nach festen Prüfungen geöffnet werden. Im Benchmark von DoorDash lieferte dieses Gesamtsystem für 45 von 50 bearbeiteten Flags nutzbare, zur Zusammenführung vorbereitete Pull Requests; je Bereinigung waren es im Mittel 13,8 Minuten und 4,79 US-Dollar.

„Bereinigt“ bezeichnet hier also nicht 45 autonom produktiv geschaltete Änderungen: Menschen bestätigten vorab den Zielwert und entschieden am Ende über die Zusammenführung. Die Messung umfasst die 50 zuletzt verarbeiteten veralteten „Dynamic Values“ aus mehreren Kotlin-Repositories von DoorDash. Sie belegt die Leistung dieser konkreten Konfiguration, nicht eine allgemeine Erfolgsquote für Coding-Agenten.

Was die 45 von 50 tatsächlich messen

Von den 50 Bereinigungen wurden 31 im ersten Durchlauf zusammengeführt, 14 benötigten eine kleinere Überarbeitung und fünf den Eingriff eines Entwicklers. Die Fachzusammenfassung von InfoQ ordnet dieselbe Stichprobe nach Komplexität ein: sechs einfache Fälle erreichten 100 Prozent, 18 mittlere 94 Prozent und 26 komplexe 85 Prozent.

DoorDash beobachtete bei den 50 erzeugten Änderungen keine eingeführten Fehler oder Regressionen. Das ist ein Ergebnis dieser intern geprüften Stichprobe, keine statistische Garantie für andere Systeme. Auch die Durchschnittskosten beziehen sich auf die Modellnutzung; Personalaufwand, Plattformbetrieb und Einführung sind darin nicht als übertragbare Gesamtkosten ausgewiesen.

Die belastbare Architektur beginnt vor der Codeänderung

In der ersten Phase übernimmt ein Orchestrator ein Jira-Ticket, durchsucht die betroffenen Repositories und fragt über MCP Metadaten aus DoorDashs Experimentplattform ab, darunter Rollout-Anteil und Zielwert. Anschließend prüft ein Entwickler den erzeugten Bericht und bestätigt den Wert, der nach der Entfernung im Code festgeschrieben werden soll.

Dieser Kontrollpunkt ist eine fachliche Sicherheitsgrenze. Ein Agent kann sämtliche Referenzen finden und dennoch das Verhalten verändern, wenn er aus dem Quellcode einen falschen Produktionswert ableitet oder einen unvollständigen Rollout für abgeschlossen hält. Die Lifecycle-Empfehlungen von LaunchDarkly stützen dieses Prinzip: Vor dem Archivieren sollen Code-Referenzen und der Zustand in den relevanten Umgebungen geprüft werden; das System warnt zudem, wenn ein Flag noch Varianten ausliefert.

Erst nach der Freigabe beginnt die zweite Phase. Ein spezialisierter Entfernungsagent sucht Definition, Wrapper, Aufrufstellen und Tests, ersetzt die Abfrage durch den bestätigten Zielwert, vereinfacht konstante Bedingungen und entfernt den dadurch toten Code. Damit ist der Produktionszustand eine unveränderliche Eingabe und keine Vermutung des Sprachmodells.

Worktrees begrenzen fehlgeschlagene Versuche

Jeder Entfernungsagent arbeitet in einem eigenen Git-Worktree. Die Git-Dokumentation zu Worktrees beschreibt, wie mehrere Arbeitsbäume mit getrennten Worktree-Dateien an dasselbe Repository gebunden werden können. DoorDash nutzte diese Trennung für bis zu vier parallele Agenten je Repository und konnte einen gescheiterten Versuch durch Entfernen seines Worktrees verwerfen.

Die Repository-Isolation allein genügt allerdings nicht. DoorDash setzte zusätzlich ein hartes Zeitlimit von einer Stunde pro Agent und startete Gradle ohne Daemon, nachdem frühe Versuche mit gemeinsamem Zustand zu Konflikten geführt hatten. Für eine übertragbare Architektur müssen daher auch Build-Caches, lokale Dienste und externe Testressourcen getrennt oder bewusst gegen parallele Zugriffe abgesichert werden.

Deterministische Gates entscheiden über den Pull Request

Das Sprachmodell durfte nicht selbst bestimmen, wann eine Änderung sicher genug war. Vor dem Öffnen eines Pull Requests mussten Build und Tests erfolgreich sein, Detekt die statische Analyse bestehen und JaCoCo mindestens 95 Prozent Patch-Abdeckung auf den geänderten Zeilen ausweisen. Schlug eine Prüfung fehl, folgte ein begrenzter Korrekturlauf statt eines Pull Requests.

Als nachbaubare Referenz ergibt sich daraus eine kurze, aber harte Kette:

Den bestätigten Produktionswert als feste Eingabe übernehmen.
Definitionen, Wrapper, Aufrufstellen und betroffene Tests vollständig suchen.
Für jede Bereinigung einen isolierten Branch oder Worktree erzeugen.
Build, Tests, statische Analyse und eine definierte Patch-Abdeckung fail-closed ausführen.
Nur einen Pull Request erstellen; Freigabe und Merge bleiben bei einer verantwortlichen Person.

Die konkrete Werkzeugwahl ist austauschbar. Entscheidend ist, dass ein fehlgeschlagener Test oder eine unterschrittene Abdeckung den Vorgang beendet und nicht vom Agenten als akzeptables Restrisiko umgedeutet werden kann.

Wo regelbasierte Werkzeuge besser passen

Agenten sind nicht für jedes Flag die beste Transformationsmethode. Ubers PolyglotPiranha ist ein regelbasiertes Werkzeug für großflächige Codeänderungen und wird bei Uber vor allem zur Entfernung veralteter Feature Flags eingesetzt. Es erhält Flag-Name, erwartetes Verhalten und konfigurierte Flag-APIs und refaktoriert passende Code-Muster ohne generative Interpretation.

DoorDash wählte den agentischen Ansatz, weil Definition, API-Aufruf und Geschäftslogik durch Dependency Injection und mehrschichtige Wrapper über verschiedene Dateien verteilt waren. Schon ein boolesches Flag konnte Änderungen in fünf bis 20 Dateien einschließlich Tests erfordern. Die belastbare Auswahlregel lautet deshalb: syntaktisch stabile Zugriffsmuster regelbasiert transformieren, semantisch verteilte Beziehungen agentisch verfolgen – beide Varianten aber hinter denselben Tests und Freigaben betreiben.

Die fünf Stopps markieren die eigentliche Grenze

Alle fünf Fälle, die menschliches Eingreifen erforderten, betrafen laut DoorDash tiefe Aufrufketten mit Parametern, die über mehrere Interfaces weitergereicht wurden. Der Agent entfernte einen Großteil des toten Codes, übersah jedoch einzelne Verbindungen in langen, dateiübergreifenden Ketten. Bei den 14 überarbeiteten Fällen scheiterten sechs zunächst an unzureichender Patch-Abdeckung; acht enthielten noch eine Variable oder Referenz. Alle 14 wurden nach einem weiteren Prompt korrigiert.

Die beobachtete Grenze lag damit bei der Vollständigkeit, nicht bei nachgewiesenen semantischen Fehlentscheidungen. Das spricht für eine explizite Eskalationsregel: Wenn eine Bereinigung festgelegte Grenzen für Interface-Übergänge, betroffene Repositories oder Korrekturversuche überschreitet, endet die autonome Bearbeitung und ein Entwickler übernimmt.

Übertragbar sind somit der zweiphasige Workflow, ein verlässlicher Produktionsstatus, die menschliche Bestätigung, verwerfbare Worktrees und deterministische Prüfbarrieren. Die Quote von 45 aus 50, die Laufzeit und die Kosten bleiben DoorDash-spezifische Benchmarkwerte. Andere Teams müssen sie mit einer eigenen, nach Komplexität geschichteten Stichprobe neu bestimmen.

Lesen Sie auch:

45 von 50 Flags bereinigt – wo DoorDash KI-Agenten trotzdem stoppt