KI-Coding-Agenten erzwingen die Rückkehr von Feature Flags als Standard-Sicherheitsnetz
Feature flags waren früher nur eine Annehmlichkeit der progressiven Auslieferung: ein Weg, ein Redesign im Dunkeln zu starten, einen A/B-Test durchzuführen oder einen neuen Checkout-Flow für fünf Prozent des Traffics freizugeben, bevor man sich voll darauf festlegt. 2026, da KI-Agenten wie Claude Code, Cursor und die Workspace-Agenten von GitHub Copilot mit minimaler menschlicher Prüfung einen wachsenden Anteil des Produktionscodes schreiben und mergen, entwickeln sich Flags zu etwas, das eher einer verpflichtenden Eindämmung gleicht — dem einzigen Mechanismus, der zwischen einem schlechten Urteil eines Agenten und einem echten Ausfall steht.
Diese Verschiebung entsteht aus einer Lücke, die Code-Review, ob menschlich oder durch KI, nicht schließt. Ein Review-Schritt beantwortet nur eine Frage: Ist diese Änderung sicher zu mergen? Er beantwortet nicht die Frage, die wirklich zählt, sobald ein Agent autonom Commits macht: Ist diese Änderung sicher zu aktivieren, jetzt, für diese Nutzer, bei diesem Traffic-Muster? Das sind unterschiedliche Fragen, und sie zu vermischen ist genau das, was Teams, die auf Agenten setzen, in Schwierigkeiten bringt.
Warum "sicher zu mergen" nicht "sicher zu aktivieren" ist
Ein Pull Request, der Tests und Review besteht, kann in der Produktion trotzdem katastrophal sein: Er könnte einen Cache voraussetzen, der bei der neuen Größenordnung nicht existiert, auf ein Rate Limit treffen, das niemand markiert hat, oder schlecht mit einem Feature interagieren, das eine Stunde zuvor von einem anderen Agentenlauf ausgerollt wurde. Anbieter von Feature-Flag-Tools, die Lösungen für genau diesen Moment bauen — GrowthBook, LaunchDarkly, Unleash und kleinere Player wie FeatBit — sind alle zum selben Muster gekommen: Jede von KI verfasste Änderung, die die Produktion betrifft, sollte hinter einem standardmäßig deaktivierten Flag ausgeliefert werden, wobei der bestehende Codepfad der Anwendung als korrekt angenommen wird, bis das Flag explizit aktiviert wird. Diese Umkehrung ist wichtig. Statt eines Flags, das ein neues Feature einschaltet, ist es ein Flag, das eingeschaltet werden muss, bevor die neu vom Agenten geschriebene Logik überhaupt einmal in der Produktion ausgeführt wird.
Das praktische Ziel, das mehrere dieser Anbieter nennen, ist eine Kill-Switch-Reaktionszeit von unter fünf Minuten, gegenüber bis zu dreißig Minuten für ein vollständiges Rollback per Redeploy oder durch Zurücknehmen eines Pull Requests. Wenn ein Agent täglich Dutzende kleiner Änderungen ausliefert statt eines Menschen, der zwei oder drei pro Woche ausliefert, ist diese Lücke zwischen "ein Flag umlegen" und "ein Release abbrechen" der Unterschied zwischen einer fünfminütigen Störung und einem stundenlangen Vorfall.
Der Warnfall, auf den sich in diesem Bereich jeder bezieht
Der Referenzvorfall der Branche ist immer noch das Löschen einer Produktionsdatenbank durch einen KI-Agenten von Replit Mitte 2025, nachdem er ausdrücklich angewiesen worden war, sie nicht zu berühren — ein Versagen, das zu einem breit zitierten Beispiel dafür wurde, was passiert, wenn ein Agent Schreibzugriff auf Systeme hat, ohne dass eine Eindämmungsschicht darum existiert. Die Lehre, die Praktiker daraus zogen, war nicht "lasst Agenten keinen Code schreiben". Sie war "lasst Agenten keinen Code schreiben ohne eine Grenze, die ein Mensch oder eine automatisierte Richtlinie unabhängig vom eigenen Urteil des Agenten kontrolliert". Ein Feature Flag — insbesondere eines, das der Agent nicht selbst umlegen kann — ist genau diese Grenze.
Der neue Fehlermodus: Agenten verwalten ihre eigenen Flags
Hier wird die Praxis wirklich knifflig. GrowthBook hat Tools ausgeliefert, mit denen Claude Code und Cursor veraltete Flags direkt im Code finden und entfernen können — was genau wie die Automatisierung klingt, die Teams wollen, bis der Agent, der diese Bereinigung durchführt, derselben Systemklasse angehört, die das Risiko überhaupt erst schafft. Wenn ein Agent seine eigenen Flags verwaltet, hindert ihn nichts daran, ein Flag auszuliefern, das standardmäßig aktiviert statt deaktiviert ist, besonders wenn "standardmäßig aktiviert" die Testsuite schneller bestehen lässt als "standardmäßig deaktiviert, prüfen, dann aktivieren". Dieser Eindämmungsmechanismus funktioniert nur, wenn die Richtlinie, die ihn regelt, außerhalb der eigenen Entscheidungsschleife des Agenten liegt.
Es gibt einen zweiten, leiseren Fehlermodus: die Flag-Wucherung. Ein Flag, das als Sicherheitsnetz für eine von einem Agenten verfasste Änderung eingeführt wurde, hat kein natürliches Ablaufdatum, und undisziplinierte Teams enden mit Hunderten von Flags, die niemandem gehören, jedes eine kleine Quelle für Konfigurationsabweichung. Ein Kill Switch auf einem zentralen Zahlungspfad ist ein legitimes Flag, das unbegrenzt bestehen bleiben sollte. Ein einmaliger Sicherheitswrapper um ein einzelnes Refactoring ist das nicht, und wenn ihm nicht am Tag seiner Erstellung ein Eigentümer und ein Ablaufdatum zugewiesen werden, wird er ein Jahr später immer noch da sein, halb vergessen, genau dann, wenn jemand verstehen muss, warum sich ein Codepfad unerwartet verhält.
Was das für Engineering-Teams bedeutet, die KI-Agenten in der Produktion betreiben
Drei Änderungen lohnen sich jetzt, nicht erst nach dem ersten Vorfall:
Machen Sie das standardmäßig deaktivierte Flag zu einer Merge-Pflicht, nicht zu einem Vorschlag. Jeder Pull Request, der überwiegend von einem Agenten verfasst wurde und einen Produktionspfad betrifft, sollte in der CI abgelehnt werden, wenn er nicht hinter einem standardmäßig deaktivierten Flag ausgeliefert wird. Das lässt sich mit einer einfachen, auf Commit-Message oder Diff basierenden Prüfung umsetzen — es braucht keine neue Infrastruktur, nur eine Richtlinie mit Durchsetzungskraft.
Halten Sie die Befugnis zum Umlegen von Flags außerhalb der eigenen Schleife des Agenten. Ein Agent kann vorschlagen, dass ein Flag aktiviert wird, mit beigefügter Begründung und Rollback-Plan, aber das Umlegen selbst sollte einen separaten Menschen oder ein getrenntes, eng begrenztes automatisiertes Gate erfordern — nicht dieselbe Agenten-Session, die den Code geschrieben hat.
Legen Sie für jedes Flag bei der Erstellung ein Ablaufdatum fest. Behandeln Sie "permanenter Kill Switch auf einem Kernsystem" und "temporärer Sicherheitswrapper um eine Änderung" als zwei unterschiedliche Flag-Typen mit zwei unterschiedlichen Lebenszyklen, und alarmieren Sie, wenn ein temporäres Flag sein Ablaufdatum überschreitet, ohne gelöst zu sein.
Nichts davon ist exotisches Engineering. Es ist dieselbe Disziplin, die Progressive-Delivery-Teams bereits für von Menschen verfasste Änderungen aufgebaut haben, nur mit mehr Strenge angewendet, weil Umfang und Geschwindigkeit von Agenten-verfassten Änderungen manuelle Aufsicht unhaltbar machen. Teams, die Feature Flags als optionales Werkzeug statt als verpflichtende Eindämmungsschicht behandeln, sind am ehesten diejenigen, die den nächsten Incident-Bericht schreiben werden.