Darf ein Agent in einem regulierten Projekt Code schreiben?

Ja - unter denselben Bedingungen wie ein Mensch. Entscheidend ist nicht, wer die Zeile geschrieben hat, sondern ob sie spezifiziert, geprüft, getestet und freigegeben ist. Wer diese Kette schließt, kann Agenten einsetzen. Wer sie für Agenten öffnet, hat auch für Menschen ein Problem.

Dieser Text ist die kurze Grundsatzantwort. Wie die Kette in einem produktiven Projekt tatsächlich aussieht - mit Rollentrennung, doppelter Review über den Fix-Diff und den Befunden, die eine grüne Pipeline nicht geliefert hätte - steht im Feldbericht Wie wir mit KI-Agenten entwickeln.

Welche fünf Leitplanken setzen wir?

1. Kein Commit ohne Definition of Ready. Agenten arbeiten ausschließlich auf Issues, die vorher eine Definition of Ready durchlaufen haben. Anforderung, Akzeptanzkriterien und Scope stehen vor dem ersten Commit fest. Das ist die wirksamste einzelne Maßnahme - ein unscharf formuliertes Ticket produziert bei einem Agenten schneller Unsinn als bei einem Menschen, weil niemand zwischendurch nachfragt.

2. Nichts umgeht die Pipeline. Jede agentenerzeugte Änderung durchläuft Build, Unit-, Integrations- und E2E-Tests sowie statische Analyse - dieselben Gates wie handgeschriebener Code. Es gibt keinen Schnellweg, keine Ausnahme für „nur eine Kleinigkeit".

3. Getrennter Review-Agent vor dem menschlichen Review. Implementierung und Prüfung liegen bei verschiedenen Agenten. Der Review-Agent sieht die Änderung ohne die Begründungskette, die zu ihr geführt hat - das ist derselbe Grund, aus dem Menschen ihren eigenen Code schlecht reviewen.

4. Werkzeugzugang statt Kontext-Nachreichen. Über MCP hängen die Agenten an Repository, Issue-Tracker, Dokumentation und Testumgebungen. Kontext, den ein Agent selbst holen kann, wird nicht in den Prompt kopiert - das reduziert die Fehlerquelle „veraltete Information im Prompt".

5. Der Mensch behält Architektur, Security und Release. Architekturentscheidungen, sicherheitsrelevante Änderungen und die finale Freigabe bleiben bei Personen. Nicht aus Prinzipientreue, sondern weil an diesen drei Stellen die Konsequenzen eines Fehlers nicht durch einen Testlauf abgefangen werden.

Was bedeutet das in einem regulierten Umfeld zusätzlich?

In Umgebungen mit Nachweispflicht - Medizintechnik, öffentliche Verwaltung - kommt die Frage der Traceability dazu: Jede Änderung muss auf eine Anforderung zurückführbar sein. Der ticket-getriebene Workflow liefert das ohnehin; wichtig ist, dass der Agent keinen Weg hat, daran vorbei zu committen.

Dazu kommt die Frage, die vor der Technik steht: Wo darf der Code verarbeitet werden? Das klären wir vor Projektbeginn schriftlich - Cloud-API, dediziertes Hosting oder vollständiges Self-Hosting, inklusive Trainingsdaten-Ausschluss und Aufbewahrungsfristen. Details dazu unter KI-Engineering.

Was bringt uns das?

Höherer Durchsatz bei gleichbleibender Codequalität und deutlich höhere Testabdeckung. Der Punkt, auf den es uns ankommt: Die freigewordene Kapazität geht in Testtiefe, nicht in mehr Features. Ein kleines Team liefert damit in der Geschwindigkeit eines größeren, ohne die Nachvollziehbarkeit aufzugeben - und genau die ist bei Abnahmen das, wonach gefragt wird.