Prüfgates statt Vertrauen

Wenn KI-Agenten Code in Stunden erzeugen, verschiebt sich der Engpass der Softwareentwicklung von der Generierung zur Prüfung. KI-generierter Code ist nicht automatisch sicher, und ein Agent, der seine eigene Arbeit bewertet, ist kein Prüfer. Dieser Beitrag beschreibt, wie wir im agentischen Software Development Lifecycle Vertrauen durch Evidenz ersetzen: mit getrennten Prüfagenten, vier Gates, an denen Menschen entscheiden, Sicherheitsprüfungen im Prozess und Abnahmetests gegen die Spezifikation.

Warum Vertrauen keine Qualitätsstrategie ist

Im ersten Beitrag dieser Serie habe ich beschrieben, was sich ändert, wenn koordinierte Agenten die ausführende Arbeit über alle Phasen übernehmen: Menschen definieren das Ziel, treffen Entscheidungen und verantworten jede Freigabe. Die Kehrseite dieser Arbeitsteilung wird oft unterschätzt. Wenn die Generierung billig wird, wächst das Volumen an Code, Tests und Dokumentation, das geprüft werden muss, und die Prüfkapazität einer Organisation wächst nicht mit. Genau das ist einer der häufigsten Gründe, aus denen agentische Transformationen scheitern: Verifikation als Nachgedanke. Die Generierung skaliert, die Prüfung nicht, und Qualität und Vertrauen erodieren mit dem Volumen.

Dass diese Sorge nicht theoretisch ist, zeigen Untersuchungen zur Sicherheit KI-generierten Codes seit Jahren. Eine der ersten systematischen Analysen des GitHub Copilot fand bereits in rund 40 Prozent der untersuchten Programme sicherheitsrelevante Schwachstellen (Pearce et al. 2022, arXiv:2108.09293). Eine Untersuchung der Stanford University fügte kurz darauf einen zweiten, unbequemeren Befund hinzu: Teilnehmerinnen und Teilnehmer, die mit KI-Assistenz programmierten, schrieben nicht nur häufiger unsicheren Code, sondern hielten ihn auch häufiger für sicher (Perry et al. 2023, ACM CCS, arXiv:2211.03622). Die Modelle sind seither deutlich besser geworden, das Grundproblem ist geblieben: Ein Sprachmodell erzeugt plausiblen Code, nicht bewiesenen Code. Es kennt weder die Sicherheitsrichtlinien Ihres Hauses noch die Abhängigkeiten, die in Ihrer Landschaft nicht zulässig sind, solange niemand sie ihm als prüfbare Regel vorgibt. Und die Überzeugung, der Code sei geprüft, wächst schneller als die Prüfung selbst.

Daraus folgt für mich eine einfache Konsequenz: Vertrauen ist keine Qualitätsstrategie. Weder Vertrauen in ein Modell noch Vertrauen in einen Anbieter, der versichert, sein Agent teste ausreichend. An die Stelle des Vertrauens tritt Evidenz: nachvollziehbare Prüfergebnisse an definierten Punkten des Lebenszyklus, über die ein Mensch entscheidet.

Wenn Generierung billig wird, wird Verifikation zum Engpass – und zum Qualitätsversprechen.

Prinzip eins: Kein Agent prüft die eigene Arbeit

Das erste Prinzip ist die Trennung von Generatoren und Verifikatoren. Ein Agent, der Code erzeugt, hat denselben blinden Fleck wie die Person, die ihn geschrieben hat: Er testet gegen sein eigenes Verständnis der Aufgabe, nicht gegen die Anforderung. Deshalb prüfen im agentischen Software Development Lifecycle unabhängige Prüfagenten mit eigenem Kontext und eigenem Auftrag. Sie testen gegen die Spezifikation, scannen Sicherheit und Abhängigkeiten und messen die Testabdeckung. Bei der Abnahme bewertet ein zweites, unabhängiges Prüfmodell jeden Testfall; Generierung und Bewertung bleiben getrennt.

Das zweite Element dieses Prinzips ist Test-first. Prüffälle entstehen aus der Spezifikation, bevor Code generiert wird. Das klingt nach einer Selbstverständlichkeit, ist in der Praxis aber die Ausnahme: In vielen Organisationen werden Tests nach dem Code geschrieben, von denselben Personen und unter Zeitdruck. Wenn die Prüffälle vor dem Code stehen, definieren sie, was „fertig“ bedeutet, und der Generator arbeitet gegen ein Ziel, das er nicht selbst verschieben kann.

Beides setzt voraus, dass die Spezifikation prüfbar ist. Eine Anforderung wie „das System soll schnell antworten“ lässt sich weder in einen Testfall übersetzen noch objektiv abnehmen. Deshalb beginnt Verifikation bei uns nicht beim Code, sondern bei der Anforderung: Mit reqChecker prüfen wir Formulierungen nach IREB und ISO/IEC/IEEE 29148 auf Eindeutigkeit, Verifizierbarkeit und Singularität, bevor sie zur Grundlage von Testfällen und maschinenlesbaren Bauaufträgen werden.

Prinzip zwei: Vier Gates, an denen Menschen entscheiden

Das zweite Prinzip sind verbindliche Quality Gates entlang des Lebenszyklus, von der prüfbaren Anforderung bis zur Betreibbarkeit. Wir arbeiten mit vier Gates: Definition of Ready, Definition of Done, Definition of Deploy und Definition of Operability. Jedes Gate ist durch drei Dinge definiert: eine Leitfrage, die Evidenz, die diese Frage beantwortet, und die Person, die auf dieser Grundlage entscheidet. Agenten generieren, Agenten verifizieren, Menschen entscheiden; jede Freigabe bleibt eine menschliche Entscheidung, jeder Agentenschritt dahinter ist protokolliert.

Entscheidend ist, was an den Gates nicht passiert: Es wird nicht verhandelt. Ein Gate, das unter Termindruck geöffnet wird, ist kein Gate, sondern eine Formalität, und bei agentischem Volumen eine, die sich hundertfach wiederholt. Deshalb sind die Gate-Kriterien maschinenlesbar hinterlegt, sodass ein Agent gar nicht erst übergeben kann, was die Kriterien nicht erfüllt. Was beim Menschen ankommt, ist ein verifiziertes Ergebnis mit Prüfprotokoll, keine Bitte um Vertrauen.

Menschliche Validierung heißt dabei nicht, dass jemand jede generierte Zeile liest. Bei agentischem Volumen wäre das weder möglich noch sinnvoll, und eine Prüfung, die aus Überforderung zum Durchwinken wird, ist gefährlicher als gar keine, weil sie Sicherheit vortäuscht. Menschen prüfen dort, wo Urteil gefragt ist: im Architektur- und Fach-Review jedes Inkrements, bei der Frage, ob eine Lösung fachlich richtig und angemessen ist, bei der Bewertung von Risiko und technischen Schulden. Alles, was sich als Regel formulieren lässt, prüfen Verifikatoren vorher, vollständig und jedes Mal.

Die Zeitgewinne entstehen dabei nicht trotz, sondern wegen der Gates. Weil die Prüfung systematisch statt stichprobenhaft erfolgt, werden Fehler dort gefunden, wo sie am wenigsten kosten: in der Spezifikation statt im Betrieb. In unseren Projekten steigt die Softwarequalität dadurch um rund 30 Prozent (Erfahrungswerte aus ReqPOOL-Projekten seit 2023, projektspezifisch validierbar, keine wissenschaftliche Evidenz). Und die bis zu fünffach schnellere Delivery im agentisch orchestrierten Umsetzungsmodell gilt nur unter der Bedingung, dass die Leitplanken stabil bleiben: Change Failure Rate, Produktionsstörungen, Defektrate und Testabdeckung dürfen sich nicht verschlechtern. Geschwindigkeit ohne diese Bedingung ist keine Kennzahl, sondern eine Wette.

Sicherheitsgates: Schwachstellen dort finden, wo sie am wenigsten kosten

Sicherheit ist im agentischen Lebenszyklus kein eigener Schritt am Ende, sondern Teil der Definition of Done und der Definition of Deploy. Konkret heißt das für uns drei Dinge.

• Security-Scans und Abhängigkeitsprüfung vor jedem Merge. Unabhängige Prüfagenten scannen den generierten Code und seine Abhängigkeiten; Bibliotheken mit bekannten Schwachstellen oder unzulässigen Lizenzen blockieren das Gate, und zwar ohne Diskussion.
• Compliance as Code. Sicherheitsrichtlinien, Architekturvorgaben und regulatorische Anforderungen werden maschinenlesbar formuliert und in der Pipeline erzwungen, statt in Dokumenten erinnert zu werden. Eine Richtlinie, die ein Agent nicht lesen kann, existiert für ihn nicht.
• Security-Review vor dem Go-live. Vor der Produktionsfreigabe prüfen unsere Expertinnen und Experten das Gesamtsystem in einem Security-Review; getestete Rollbacks sind Teil der Go/No-Go-Entscheidung.

Dazu kommt der lückenlose Audit-Trail: Jede Agentenaktion, jeder verwendete Kontext und jede Freigabe werden protokolliert und sind rekonstruierbar. Für regulierte Branchen ist das kein Zusatz, sondern die Voraussetzung, um überhaupt produktiv gehen zu dürfen. Die KI-Verordnung (EU) 2024/1689 verlangt menschliche Aufsicht, Transparenz und Risikomanagement für KI-Systeme; die Verordnung (EU) 2022/2554 (DORA) verlangt von Finanzunternehmen belastbares IKT-Risikomanagement und operative Resilienz. Menschliche Gates, protokollierte Agentenschritte und eine Nachweiskette von der Vorschrift über die Anforderung und den Code bis zum Release beantworten genau diese Anforderungen.

Abnahmetests gegen die Spezifikation

Die letzte Frage vor dem Produktivgang lautet nicht, ob der Code gut aussieht, sondern ob die Software nachweislich die Spezifikation erfüllt. Deshalb ist die Abnahme bei uns ein eigenes Gate mit eigener Evidenz. Mit Signoff zerlegen wir die Spezifikation in atomare, prüfbare Anforderungen, jede mit eindeutiger Kennung und wörtlicher Referenz auf die Quellklausel. Zu jeder Anforderung entstehen Testfälle inklusive Testdaten, Rand- und Negativfällen, verknüpft in einer Traceability-Matrix. Ein Agent führt die Tests gegen das laufende System aus und sammelt Evidenz in Form von Screenshots und Logs; ein unabhängiges Prüfmodell bewertet jeden Testfall als erfüllt, nicht erfüllt oder nicht prüfbar. Das Ergebnis ist ein revisionssicherer Abnahmebericht mit vollständiger Traceability von der Spezifikationsklausel bis zum Testergebnis.

Auch hier bleibt der Mensch in der Verantwortung: Testfälle und Testläufe werden vor der Ausführung freigegeben, die finale Abnahme erteilt der Kunde selbst. Das gilt unabhängig davon, ob die Software von Agenten, vom eigenen Team oder von einem Lieferanten gebaut wurde. Genau diese Neutralität macht die Abnahme gegen die Spezifikation zum Steuerungsinstrument: Beauftragt, abgenommen und gewährleistet wird das spezifizierte Ergebnis, nicht die aufgewendete Zeit.

In reqCoder, dem vollständigen agentischen Software Development Lifecycle von ReqPOOL, der bei uns intern im Einsatz ist, sind diese Prüfungen als Evidenzkette über vier Stages verankert: Scope-Nachweis und Schätzung nach dem Prototyp, reqChecker-Prüfung und Security-Scan in der Beta, Signoff-Abnahme und Audit-Trail vor dem Go-live in der Deployment-Stage, vollständiger Übergang des geistigen Eigentums in der Produktion. Jede Stage wird einzeln beauftragt, und die Entscheidung über die nächste fällt auf Basis der Evidenz am Gate. Das ist der praktische Sinn des Titels dieses Beitrags: Der Vertrauensvorschuss, den klassische Projekte über Monate voraussetzen, wird durch Prüfergebnisse ersetzt, die Sie sehen, bevor Sie weiterbeauftragen.

Was das für Ihre Organisation bedeutet

Aus unseren Projekten lassen sich fünf Konsequenzen ableiten, die unabhängig vom eingesetzten Modell und Werkzeug gelten.

• Gates vor Werkzeugen definieren. Wer Lizenzen verteilt, ohne Gate-Kriterien festzulegen, erhält mehr Code bei gleicher Prüfkapazität. Definition of Ready, Done und Deploy sind Organisationsentscheidungen, keine Werkzeugkonfiguration.
• Prüffälle aus der Spezifikation ableiten, bevor gebaut wird. Das setzt Anforderungen in prüfbarer Qualität voraus und ist der Punkt, an dem die meisten Organisationen zuerst nachbessern müssen.
• Generierung und Prüfung trennen. Unabhängige Prüfagenten mit eigenem Kontext, ein zweites Modell für die Bewertung, menschliche Review-Hoheit über jeden Merge.
• Sicherheit und Compliance als Code hinterlegen. Was nicht maschinenlesbar ist, wird von Agenten nicht eingehalten; was maschinenlesbar ist, wird an jedem Gate automatisch geprüft.
• Leitplanken messen, nicht nur Geschwindigkeit. Change Failure Rate, Produktionsstörungen, Defektrate und Testabdeckung gehören neben die Effizienzkennzahl; die vier Kennzahlen der Delivery-Forschung (Forsgren, Humble, Kim 2018) liefern dafür den Standard.

Ich halte dieses Thema für das wichtigste der Serie, weil es über die Glaubwürdigkeit des gesamten Ansatzes entscheidet. Die bis zu fünffach schnellere Delivery ist ein Ergebnis, das sich nur mit nicht verhandelbarer Verifikation verantworten lässt. Ohne sie ist agentische Softwareentwicklung ein Experiment; mit ihr ist sie ein abnahmefähiges System, auch für Banken, den öffentlichen Sektor und regulierte Branchen.

Der nächste Schritt

Wie wir Quality Gates, getrennte Prüfagenten und Compliance as Code in Ihrer Delivery-Organisation verankern, lesen Sie auf der Seite Agentic Software Development Lifecycle. Wie die Evidenzkette über die vier Stages in unserer eigenen agentischen Pipeline aussieht, beschreibt die Seite reqCoder. In einem Expertengespräch prüfen wir gemeinsam, welche Gates in Ihrer Organisation heute existieren und welche vor dem ersten agentischen Piloten noch fehlen.