KI-Agenten brauchen Gates, keine Guidelines

Veröffentlicht am 5. Juli 2026

Ein Strom leuchtender Datenpakete prallt in einem dunklen Korridor auf eine gleißende cyanfarbene Lichtschranke; ein einzelnes bernsteinfarben glühendes Paket wird unter Funkenflug gestoppt

Abbildung 1. Das Gate schlägt zu: Ein Arbeitspaket wird gestoppt, bevor es ungeprüft weiterkommt

Wer mit KI-Agenten Software baut, schreibt irgendwann Regeln auf. Eine Projektdatei mit Konventionen, Prozessbeschreibungen für wiederkehrende Abläufe, Erinnerungen an das, was beim letzten Mal schiefging. Und dann macht man eine Erfahrung, die jeden Teamleiter vertraut anmuten wird: Die Regeln stehen da, und sie werden trotzdem nicht befolgt.

In 43 Sprints an meinem Nebenprojekt Calculoria, einer Mathe-Lern-App, die größtenteils mit Claude als Entwicklungspartner entstand, habe ich dazu unfreiwillig eine Messreihe produziert. Drei Befunde daraus.

Befund 1: Aufgeschriebene Vorsätze verrotten messbar

Jede Sprint-Retrospektive erzeugte Verbesserungspunkte, sauber dokumentiert, mit Nummer und Priorität. Nach zwei Sprints stand die Bilanz: Retro 15 hatte acht Punkte erzeugt, umgesetzt null. Retro 16 sechs Punkte, umgesetzt null. Vierzehn offene Vorsätze, an denen niemand arbeitete, auch die KI nicht, denn kein Prozessschritt hat sie je wieder angefasst.

Editorial-Illustration: Eine verstaubte Pinnwand mit vierzehn ordentlich angeordneten Notizkarten, alle mit leerer Checkbox, darunter läuft ein Förderband mit Arbeitspaketen unbeachtet vorbei

Abbildung 2. Vierzehn Vorsätze, sauber dokumentiert — und die Arbeit rauscht vorbei

Die Lösung war unspektakulär: Die Sprintplanung bekam eine Pflichtphase Null, die vor allem anderen die offenen Punkte der letzten Retro durchgeht. Nicht als Empfehlung, sondern als erster Schritt, ohne den es nicht weitergeht. Danach: fünf Sprints in Folge mit hundert Prozent umgesetzten Verbesserungspunkten. Dieselben Vorsätze, dieselbe KI, derselbe Mensch. Der einzige Unterschied: Ein Prüfschritt erzwang, was vorher nur dokumentiert war.

Befund 2: Auch die vierte Wiederholung einer Regel bewirkt nichts

Eine simple Formatregel für Dokumente wurde vom selben Prozessbaustein über fünf Retrospektiven hinweg verletzt, obwohl sie nach jedem Verstoß deutlicher formuliert wurde. Beendet hat es erst eine Konsequenz statt einer Formulierung: Nach dem fünften Verstoß wurde der Baustein gesperrt, mit einem Warnbanner direkt in seiner Prozessbeschreibung, dokumentierten Alternativen für seine Aufgaben und einem festen Termin für die Wiedervorlage. Zwei Tage später wurde er für eine konkrete Aufgabe wieder entsperrt, die verletzte Regel steht seitdem als erste Zeile in seiner Beschreibung. Ein neuer Verstoß ist danach nicht mehr dokumentiert. Vier Ermahnungen hatten nichts bewirkt; eine Sperre mit sichtbarer Narbe wirkte.

Dasselbe Muster anderswo: Eine bekannte Stolperfalle beim Aufräumen von Git-Worktrees stand ausdrücklich im Projektgedächtnis und wurde trotzdem übergangen. Und mein Release-Prozess sah vor, jede Version mit einem Git-Tag zu versehen; das Changelog listet brav alle Versionen, das Tag-Verzeichnis ist leer. Kein einziges Release hat je eines bekommen, und es ist niemandem aufgefallen, weil nichts danach fragte.

Das Muster ist immer dasselbe: Eine Regel, deren Einhaltung nicht geprüft wird, ist keine Regel. Sie ist eine Hoffnung. Das war schon immer so, auch in reinen Menschen-Teams. Aber ein KI-Agent, der ein Vielfaches eines einzelnen Entwicklers produziert, führt es einem im Zeitraffer vor.

Flussdiagramm mit zwei Zweigen: Links dreht sich eine dokumentierte Regel wirkungslos zwischen Verstoß und Ermahnung im Kreis, rechts erzwingt ein Gate eine Prüfung, die Arbeit bei Verstoß stoppt und erst nach Nachbesserung weiterlässt

Abbildung 3. Zwei Schicksale derselben Regel: Als Dokument kreist sie im Ermahnungs-Loop, als Gate stoppt sie die Arbeit

Befund 3: Ohne Zaun wandert die Arbeit

Mehrfach passierte es, dass mitten im Sprint an Dingen gearbeitet wurde, die gar nicht im Sprint waren. Nicht aus Böswilligkeit, sondern weil beim Lesen des Backlogs etwas Interessantes auffiel und der Weg dorthin kurz ist. Auch hier half keine Ermahnung, sondern ein Gate: Der Implementierungsprozess beginnt seither zwingend mit einem Scope-Check. Steht das Item nicht im Sprint, wird es abgelehnt, und zwar sofort, bevor irgendeine Analyse beginnt. Der Wortlaut der Regel verbietet ausdrücklich das „nur mal kurz Reinschauen", denn genau dort beginnt die Abweichung.

Dasselbe Prinzip heilte ein chronisches Leiden: Statusangaben, die in Übersichten und Detaildokumenten auseinanderliefen. Monatelang stand die Regel „Status synchron halten" in der Projektdatei, und monatelang passierte es trotzdem. Erst ein expliziter Abgleichschritt im Release-Prozess, der die Dokumente gegeneinander prüft, hat es beendet.

Was das für Teams heißt, mit und ohne KI

Man kann diese Befunde als KI-Schwäche lesen. Ich lese sie anders: Die KI hat sich exakt so verhalten wie jedes Team unter Termindruck. Sie hat getan, was der Prozess erzwang, und gelassen, was er nur empfahl. Der Unterschied ist die Geschwindigkeit, mit der das sichtbar wird, und die Vollständigkeit der Daten: Jeder Schritt ist protokolliert, und niemand muss im Rückblick sein Gesicht wahren.

Praktisch heißt das: Jede Regel, die mir wichtig ist, bekommt einen Ort, an dem sie erzwungen wird. Ein Gate im Build, eine Pflichtphase im Prozess, ein Abgleichschritt vor dem Release. In meinen Projekten tragen viele dieser Regeln inzwischen die Nummer des Fehlers, aus dem sie entstanden sind. Das hält die Regelmenge klein und jede einzelne Regel begründbar, denn eine Regel ohne Geschichte ist meist auch eine ohne Wirkung.

Und die Guidelines? Die braucht es weiterhin, als Erklärung, warum die Gates existieren. Nur verwechseln sollte man beides nicht: Das Dokument erklärt. Erzwingen muss etwas anderes.

Klingt nach deinem Thema? Schreib mir. Im Erstgespräch klären wir unverbindlich, ob und wie ich helfen kann.