Agentische Entwicklung braucht Verifikationsschleifen, nicht nur bessere Prompts

Die sinnvolle Frage zu KI-Coding-Agenten hat sich verändert.

Es geht nicht mehr nur darum, ob Claude Code, Cursor, Codex-artige Agenten, Devin, Replit oder interne Werkzeuge nützlichen Code erzeugen können. Das können sie. Sie können auch Tests starten, ein Repository untersuchen, Pull Requests vorbereiten, Build-Fehler erklären, Dokumentation aktualisieren und teilweise in CI-Workflows arbeiten.

Die bessere Frage lautet:

Was beweist, dass diese Arbeit sicher genug ist, um sie zu behalten?

Genau dort sind viele Teams noch dünn aufgestellt. Sie haben Prompts, Regeln und Begeisterung. Vielleicht haben sie sogar ein gutes Agenten-Setup. Was oft fehlt, ist eine verlässliche Schleife, die Agentenoutput in geprüfte Produktänderung verwandelt.

Agentische Entwicklung wird dann produktionsreif, wenn jede nützliche Abkürzung einen passenden Verifikationspfad hat.

Geschwindigkeit ist kein Betriebsmodell

KI-Coding senkt die Kosten der Umsetzung. Das ist wertvoll, gerade für Gründer, Produktteams und überlastete Engineering-Gruppen.

Aber niedrigere Umsetzungskosten verändern auch das Risiko. Ein Team kann in derselben Zeit mehr Änderungen, Varianten, Tests, Migrationen, Skripte und Integrationen erzeugen. Ohne Verifikationsschleife entsteht dadurch vor allem ein größerer Stapel von Entscheidungen, die niemand wirklich geprüft hat.

Das ist kein Grund, KI-Agenten zu meiden. Es ist ein Grund, sie als Teil des Delivery-Systems zu behandeln.

Ein seriöser Workflow muss praktische Fragen beantworten:

• Was sollte der Agent ändern?
• Welche Dateien, Befehle, Tools und Daten hat er berührt?
• Welche Annahmen hat er getroffen?
• Welche Tests oder Checks belegen, dass die Änderung korrekt ist?
• Welche Risiken bleiben für den menschlichen Review?
• Welche Aktionen sind automatisch erlaubt und welche brauchen Freigabe?

Wenn der Workflow diese Fragen nicht beantwortet, landen sie am Ende beim Reviewer. So wird aus “KI macht uns schneller” schnell “Review ist nicht mehr zu schaffen”.

Verifikationsschleifen sind die fehlende Schicht

Eine Verifikationsschleife ist das System um den Agenten herum, das prüft, ob die Arbeit noch zum Produkt, zur Architektur, zum Sicherheitsmodell und zum Betrieb passt.

Sie ist kein einzelnes Tool. Sie ist ein Muster.

Der Agent schlägt etwas vor oder ändert etwas. Das System sammelt Evidenz. Der Mensch oder eine Policy-Schicht entscheidet, ob diese Evidenz ausreicht. Die nächste Agentenaktion wird durch das Ergebnis begrenzt.

Bei einer einfachen Codeaufgabe kann diese Schleife so aussehen:

• gewünschtes Verhalten vor der Änderung festlegen;
• die kleinste sinnvolle Änderung machen;
• fokussierte Tests ausführen;
• Type-Checks und Linting ausführen;
• zusammenfassen, was sich geändert hat und warum;
• offene Unsicherheiten explizit für den Review notieren.

Bei risikoreicheren Aufgaben braucht die Schleife mehr Struktur:

• Änderung mit Architekturentscheidungen abgleichen;
• Authentifizierung und Autorisierung prüfen;
• Datenmigrationen und Rollback-Optionen ansehen;
• Dependency- und Konfigurationsänderungen scannen;
• Read-only-Analyse von Schreibaktionen trennen;
• menschliche Freigabe verlangen, bevor Infrastruktur, Secrets oder Produktionsdaten berührt werden.

Wichtig ist, dass die Schleife explizit ist. Das Team hofft nicht, dass der Agent alles im Kopf behält. Es gestaltet den Workflow so, dass wichtige Prüfungen schwer zu überspringen sind.

Leitplanken sollten ausführbar sein, nicht dekorativ

Viele Teams starten mit geschriebenen Regeln: Repository-Instruktionen, Prompt-Dateien, Coding-Standards und “bitte nicht tun”-Hinweisen.

Das ist ein guter Start. Es reicht nicht.

Regeln werden operativ, wenn sie mit etwas Ausführbarem verbunden sind:

• Branch-Protection, die CI vor dem Merge verlangt;
• Pfadgrenzen, die zu breite Änderungen verhindern;
• getrennte Tokens für Lesen, Schreiben und Deployment;
• Command-Allowlists für Agentensessions;
• Freigabepflicht für riskante Befehle;
• Tests für geschäftskritisches Verhalten;
• Dependency- und Config-Checks in Pull Requests;
• Logs von Agenten-Tool-Calls und generierten Entscheidungen.

Das ist wichtig, weil Agenten gut in lokaler Problemlösung sind. Sie sind nicht automatisch gut im Organisationsgedächtnis. Wenn ein System über Jahre gewachsen ist, liegen die wichtigen Einschränkungen oft außerhalb der unmittelbaren Aufgabe: ein Vertragsdetail, eine Aufbewahrungsregel, eine Legacy-Integration, ein kundenspezifischer Prozess oder eine Betriebsgewohnheit, die nie im README gelandet ist.

Ausführbare Leitplanken halten diese Einschränkungen lebendig, während das Team trotzdem KI-Geschwindigkeit nutzt.

Menschlicher Review braucht bessere Evidenz

KI nimmt Menschen nicht die Verantwortung ab. Sie verändert, was Menschen prüfen müssen.

Jede generierte Zeile so zu reviewen, als käme sie aus einem langsamen manuellen Prozess, skaliert nicht. Dem Agenten blind zu vertrauen, funktioniert aber auch nicht.

Der sinnvolle Mittelweg ist evidenzbasierter Review.

Ein Reviewer sollte sehen:

• Aufgabe und Akzeptanzkriterien;
• relevante Architektur- oder Produktgrenze;
• vom Agenten geänderte Dateien;
• vom Agenten ausgeführte Befehle;
• bestandene oder fehlgeschlagene Tests;
• Bereiche, die der Agent nicht geprüft hat;
• warum die Änderung klein genug für Review ist.

Auch hier kann KI helfen. Ein zweiter Agent kann ein Diff auf Autorisierungslücken, fehlende Tests, Migrationsrisiken oder Architekturdrift prüfen. Aber auch dieser zweite Agent braucht Grenzen. “Eine andere KI hat es angeschaut” ist keine Kontrolle, solange die Prüfung nicht spezifisch, wiederholbar und mit Evidenz verbunden ist.

Das Ziel ist nicht, Review zeremoniell zu machen. Das Ziel ist, Review schärfer zu machen.

Die Autonomie-Leiter

Nicht jede Agentenaufgabe verdient dieselbe Autorität.

Teams sollten in Stufen denken.

Auf der niedrigsten Stufe darf ein Agent Code lesen, Verhalten erklären, Tests vorschlagen und Dokumentation entwerfen. Das Risiko ist meist niedrig, solange sensible Daten ausgeschlossen sind.

Danach kann er isolierte Änderungen machen: eine kleine Komponente, einen Test, ein Refactoring innerhalb eines Moduls oder eine Dokumentationsänderung. Dafür braucht es Versionierung, fokussierte Tests und menschlichen Review.

Dann kommen Arbeiten über Grenzen hinweg: API-Änderungen, Migrationen, Authentifizierungspfade, Dependencies oder Infrastrukturkonfiguration. Das braucht stärkere Freigabe, Rollback-Denken und mehr Checks.

Auf der höchsten Stufe kann ein Agent in CI handeln, Pull Requests automatisch öffnen, Dependencies aktualisieren, Deployments auslösen oder operative Systeme berühren. Dafür braucht es getrennte Credentials, Audit-Logs, Policy-Gates und klare Ownership.

Viele Teams überspringen diese Leiter. Sie behandeln den Agenten entweder wie ein Spielzeug oder wie einen fast autonomen Entwickler. Besser ist schrittweise Autonomie, die durch Evidenz verdient wird.

Wenn der Agent eine Aufgabe wiederholt gut erledigt, mit guten Tests und wenig Review-Reibung, bekommt er etwas mehr Raum. Wenn eine Aufgabe Geld, Kundendaten, Identität, Infrastruktur, Compliance oder Produktion berührt, bleibt die Schleife enger.

Was das für Gründer und CTOs bedeutet

Für Gründer ist agentische Entwicklung ein starker Hebel, um schneller voranzukommen, bevor ein komplettes Team existiert. Aber die erste Produktbasis braucht trotzdem bewusste Struktur. Sonst wird der Prototyp aus Versehen zur Architektur.

Für CTOs geht es nicht nur darum, den besten Agenten auszuwählen. Die eigentliche Arbeit ist das Betriebsmodell darum herum: Berechtigungen, Repository-Regeln, CI-Checks, Review-Erwartungen, Dokumentation, Observability und Ownership.

Für Produktteams liegt der Nutzen nicht in “mehr Code”. Er liegt in kürzeren Feedbackschleifen zwischen Idee, Umsetzung, Evidenz und Entscheidung. Das funktioniert nur, wenn Evidenz Teil des Prozesses ist und nicht ein Nachtrag.

Für Mittelstandsteams ist das Risiko Schatten-Automation. Fachbereiche können Agenten heute schneller mit Tools, Daten, Dokumenten und Workflows verbinden, als zentrale IT es bemerkt. Die Antwort ist nicht pauschales Verbot. Die Antwort ist ein Pfad, auf dem nützliche Automation zu kontrollierter Software werden kann, bevor sie kritisch wird.

Ein praktischer Startpunkt

Die erste Version muss nicht komplex sein.

Wählen Sie einen echten Workflow, bei dem agentische Entwicklung bereits hilft. Definieren Sie, was der Agent tun darf. Definieren Sie, was er nicht berühren darf. Geben Sie ihm aktuellen Projektkontext. Verlangen Sie Tests und eine knappe Änderungszusammenfassung. Zeichnen Sie die Befehle auf, die er ausführt. Ergänzen Sie eine zweite Prüfung für sicherheitsrelevante Änderungen. Halten Sie Produktions-Credentials aus der Umgebung heraus.

Dann messen Sie die langweiligen Dinge:

• Hat sich die Durchlaufzeit verbessert?
• Wurde Review leichter oder schwerer?
• Sind Defekte zurückgegangen?
• Hat sich Testabdeckung verbessert?
• Hat Architekturdrift zugenommen?
• Hat das Team verstanden, was geändert wurde?

Diese Antworten sind nützlicher als noch eine Demo.

Agentische Entwicklung wird weiter leistungsfähiger. Am meisten profitieren nicht die Teams mit der längsten Prompt-Datei. Am meisten profitieren die Teams mit der klarsten Schleife von Absicht zu Änderung zu Evidenz zu Release.

Das ist die eigentliche Produktionsleitplanke: Agenten nicht auszubremsen, sondern ihre Geschwindigkeit überprüfbar zu machen.