Wird Agentic AI vor allem durch bessere generative Modelle zuverlässiger? Oder liegt der größere Hebel woanders? Dieser Artikel nutzt die Analogie einer gelenkten Rakete, um zu zeigen, warum die Fähigkeit zur automatisierten Überprüfung wichtiger sein könnte als die nächste Verbesserung des Modells, und warum Softwareentwicklung dafür ungewöhnlich gute Voraussetzungen für Agentic AI mitbringt.
Von der ungelenkten zur gelenkten Rakete#
Stellen wir uns vor, wir wollen mit einer ungelenkten Rakete ein bestimmtes Ziel treffen. Selbst wenn wir sorgfältig zielen, treffen wir nicht jedes Mal genau denselben Punkt. Vielleicht liegen die Treffer systematisch etwas zu weit links. Zusätzlich gibt es eine zufällige Streuung: Unter scheinbar gleichen Bedingungen landen die Treffer an unterschiedlichen Stellen.
Wir können versuchen, genauer zu zielen. Aber das allein beseitigt weder die systematische Abweichung noch die Streuung.
Ändern wir nun das Bild: Statt einer ungelenkten Rakete verwenden wir eine gelenkte. Sie muss nicht schon beim Start perfekt ausgerichtet sein. Entscheidend ist, dass sie ihr Ziel kennt, ihre Position und Flugbahn beobachten und ihren Kurs während des Fluges korrigieren kann.
Dafür braucht sie drei Dinge:
- Wissen, wohin: Welches Ziel soll überhaupt erreicht werden?
- Richtig zielen: Wie wird die Zielvorgabe an das System übermittelt und in eine geeignete Steuerung übersetzt?
- Nachjustieren: Wie erkennt das System Abweichungen und korrigiert seinen Kurs?
Das ist natürlich nur eine Analogie, oder wie der Statistiker George E. P. Box es treffend formulierte: “All models are wrong, but some are useful.” Ihr Wert liegt nicht in der Übereinstimmung jedes Details, sondern in dem Gedanken, den sie sichtbar macht:
Ein leistungsfähiges System ist nicht unbedingt eines, das auf Anhieb trifft. Es ist eines, das zuverlässig erkennen und korrigieren kann, wenn es danebenliegt.
Von der Rakete zum KI-Agenten#
Bei Agentic AI ist das Ziel keine Koordinate, sondern ein gewünschtes Ergebnis. Ein Agent soll beispielsweise eine Softwarefunktion implementieren, einen Fehler beheben oder ein bestehendes System erweitern.
Die drei Schritte bleiben dieselben.
Zunächst müssen wir wissen, was wir erreichen wollen. Unklare, widersprüchliche oder fachlich falsche Anforderungen kann selbst ein sehr leistungsfähiger Agent nicht zuverlässig in die richtige Lösung verwandeln.
Dann müssen wir das Ziel so ausdrücken, dass der Agent damit arbeiten kann: mit Anforderungen, Kontext, Randbedingungen und möglichst konkreten Beispielen. Das ist mehr als die Suche nach einem besonders geschickten Prompt. Es ist die Übersetzung einer Absicht in eine handhabbare Spezifikation.
Und schließlich braucht die KI eine Möglichkeit, ihre Arbeit zu überprüfen. Sie braucht Rückmeldungen, an denen sie erkennt, dass etwas noch nicht stimmt, und auf deren Grundlage sie einen neuen Versuch unternehmen kann.
Genau hier liegt eine oft unterschätzte Grenze generativer KI:
Etwas erzeugen zu können ist nicht dasselbe, wie feststellen zu können, ob das Erzeugte richtig ist.
Warum Softwareentwicklung dafür besonders geeignet ist#
Die Kernaufgabe der Softwareentwicklung besteht darin, Anforderungen in ausführbaren Code zu übersetzen, der diese Anforderungen erfüllt. Dafür verfügen wir bereits über eine ungewöhnlich umfangreiche Infrastruktur zur automatischen Überprüfung.
Ein Compiler erkennt Fehler, bevor ein Programm überhaupt startet. Tests prüfen Verhalten gegen erwartete Ergebnisse. Statische Analysen und Architekturregeln decken unerwünschte Konstruktionen auf. Mutationstests machen Schwächen der Tests selbst sichtbar. Metriken liefern Hinweise auf übermäßige Komplexität und Kopplung. Sicherheitsanalysen zeigen zusätzliche Risiken auf.
Keines dieser Verfahren beweist allein, dass eine Software insgesamt richtig ist. Aber gemeinsam liefern sie zahlreiche Rückmeldesignale, die ein Agent für die nächste Kurskorrektur verwenden kann.
Das unterscheidet Softwareentwicklung von Aufgaben, bei denen zwar ebenfalls Ergebnisse erzeugt werden, deren Qualität sich aber kaum eigenständig und zuverlässig maschinell beurteilen lässt.
Erste Frage: Haben wir das richtige Ziel?#
In der Softwaretechnik gibt es eine wichtige Unterscheidung zwischen Validierung und Verifikation. Vereinfacht gesagt:
- Validierung: Bauen wir überhaupt das Richtige?
- Verifikation: Bauen wir das Spezifizierte richtig?
Die Unterscheidung wird unter anderem in den Leitlinien der NASA zur Produktverifikation und -validierung erläutert.
Für unsere Analogie heißt das: Es nützt nichts, wenn die Rakete ihre vorgegebenen Koordinaten exakt erreicht, die Koordinaten aber zum falschen Ziel gehören.
Bei Software muss deshalb zunächst geklärt werden, ob die beschriebenen Anforderungen dem entsprechen, was Nutzer und andere Beteiligte tatsächlich benötigen. Eine KI kann diese Klärung unterstützen, aber erfolgreich durchlaufende Tests können sie nicht ersetzen.
Ein besonders nützlicher Ansatz ist Behavior-Driven Development (BDD). Dabei klären fachliche und technische Beteiligte das erwartete Verhalten anhand konkreter Beispiele. Diese Beispiele lassen sich als BDD-Szenariotests beziehungsweise ausführbare Spezifikationen formulieren, etwa in Gherkin mit Given, When, Then.
Das Interessante daran ist ihre doppelte Rolle: Die gemeinsame Verständigung über die Szenarien unterstützt die Validierung. Ihre spätere automatisierte Ausführung unterstützt die Verifikation. Die BDD-Dokumentation von Cucumber beschreibt diese Abfolge aus gemeinsamer Klärung, Formulierung und Automatisierung ausdrücklich.
Allerdings wird eine fachlich falsche Annahme nicht dadurch richtig, dass sie als ausführbarer Test formuliert wurde. Deshalb sollten die Akzeptanzkriterien möglichst unabhängig von der späteren Implementierung festgelegt werden, und der Coding-Agent darf sie nicht nach Belieben verändern können.
Zweite Frage: Welche Fehler können wir automatisch ausschließen?#
Noch bevor ein einziger Test läuft, kann uns die Programmiersprache helfen.
Compiler prüfen Syntax und, je nach Sprache, statische Typen sowie weitere Regeln.
Bei Java werden beispielsweise zahlreiche Typfehler schon vor der Ausführung erkannt.
Besonders anschaulich ist Rust:
Ownership und Borrow Checking erlauben es dem Compiler, bestimmte Speicherfehler bereits beim Übersetzen auszuschließen.
Diese Garantien gelten für Safe Rust; falsch verwendetes unsafe kann sie unterlaufen.
Die Rust-Dokumentation
erläutert das Ownership-Modell und die Rolle des Compilers.
Auch C und C++ kennen Typprüfungen. Der Unterschied besteht darin, welche Fehlerklassen ein Sprach- und Laufzeitsystem tatsächlich verhindern kann. Genau deshalb ist die Wahl der Sprache für agentische Softwareentwicklung nicht nebensächlich.
Daraus folgt keineswegs, dass künftig jede Anwendung in Rust geschrieben werden sollte. Rust ist gerade für systemnahe Aufgaben interessant; in anderen Bereichen können etwa Java und die JVM die sinnvollere Wahl sein. Entscheidend ist das Prinzip:
Was ein Compiler zuverlässig ausschließt, muss nicht erst durch zufällig passende Tests entdeckt werden.
Neben der statischen Prüfung spielt die Testbarkeit eine große Rolle. Reine Funktionen liefern bei gleichem Input denselben Output und haben keine Seiteneffekte. Sie lassen sich meist sehr viel einfacher testen als Code, der für jeden Test erst komplexe Zustände, Datenbanken oder externe Dienste benötigt.
Funktionale Programmierung begünstigt diese Eigenschaften, ohne auf sie beschränkt zu sein: Zwar kann man auch in Java reine Funktionen schreiben, die Sprache erzwingt es aber nicht. Vielleicht erleben also funktionale Sprachen wie Scala oder OCaml durch die Anforderungen agentischer Entwicklung eine Renaissance?
Dritte Frage: Wie gut sind unsere Tests?#
Ein grüner Test sagt zunächst nur, dass genau die geprüften Bedingungen erfüllt sind. Er sagt nicht, dass alle wichtigen Bedingungen geprüft wurden.
Auch eine hohe Code-Coverage bedeutet lediglich, dass beim Testen viel Code ausgeführt wurde. Ob alle Pfade abgedeckt sind und die Assertions überhaupt geeignet sind, Fehler zu bemerken, ist eine andere Frage.
Hier setzen Mutationstests an. Sie verändern gezielt kleine Teile des Programms: Ein Vergleichsoperator wird vertauscht, ein Rückgabewert verändert oder eine Bedingung manipuliert. Schlägt daraufhin ein Test fehl, wurde der Mutant getötet. Überleben viele Mutanten, deutet das auf schwache oder fehlende Tests hin. Werkzeuge wie PIT für Java setzen dieses Verfahren praktisch um.
Mutationstests sind allerdings kein Korrektheitsbeweis. Sie prüfen die Empfindlichkeit einer Testsuite gegenüber ausgewählten Veränderungen, nicht, ob die ursprüngliche fachliche Anforderung richtig verstanden wurde. Aber sie ergänzen die ausführbaren Spezifikationen um eine wichtige zweite Perspektive.
Gerade bei KI-generiertem Code ist das wertvoll: Ein Agent könnte sonst eine große Menge an Tests erzeugen, die beeindruckend aussehen, aber kaum relevante Fehler entdecken.
Nicht eine Kennzahl, sondern mehrere unabhängige Blickwinkel#
Wenn der Agent seine Arbeit anhand von Prüfungen korrigieren soll, dürfen diese Prüfungen nicht zu leicht auszutricksen sein.
Eine Komplexitätsmetrik allein könnte beispielsweise dazu verleiten, komplizierte Logik schlicht auf viele Klassen zu verteilen. Die Zahl verbessert sich, die Wartbarkeit möglicherweise nicht. Das ist ein Beispiel für das allgemeinere Problem des Specification Gaming: Ein System optimiert den messbaren Ersatz für ein Ziel statt des eigentlichen Ziels.
Deshalb halte ich eine Triangulation unterschiedlicher Prüfungen für besonders wirkungsvoll:
- Ausführbare Spezifikationen kontrollieren das fachlich erwartete Verhalten.
- Mutationstests kontrollieren, ob die Tests auf relevante Codeänderungen reagieren.
- Ein Größenbudget, geschätzt aus Umfang und Komplexität der fachlichen Szenarien, begrenzt unnötig umfangreiche Implementierungen und Testmengen.
Dieses Budget kann eine Expertenschätzung oder eine heuristisch ableitbare Sollgröße sein. Es dient als Plausibilitätskontrolle: Wenn aus wenigen überschaubaren Szenarien eine erstaunlich große Implementierung oder eine Flut von Tests entsteht, sollte das auffallen.
Diese drei Prüfungen ergänzen sich. Eine KI, die Tests weglässt, riskiert schwache Mutationsergebnisse. Eine KI, die überdimensionierte Lösungen baut oder viele sinnlose Tests hinzufügt, verbraucht ihr Budget. Und eine KI, die fachliche Funktionalität verletzt, scheitert an den ausführbaren Spezifikationen.
Weitere Signale können hinzukommen: zyklomatische Komplexität, Kopplung und Kohäsion von Modulen, afferente und efferente Kopplung, CRAP-Metrik, Architekturregeln, Linter, Sicherheitsanalysen und automatisierte Code-Reviews. Risikobasierte Bewertungen können außerdem auffällige Umgehungskonstruktionen erkennen, etwa den missbräuchlichen Einsatz von Reflection, um Abhängigkeiten vor einfachen statischen Metriken zu verstecken.
Wichtig ist dabei die Unterscheidung: Manche Prüfungen schließen bestimmte Fehler unter klaren Voraussetzungen aus. Tests liefern Nachweise für konkrete beobachtete Fälle. Metriken und KI-Reviews liefern oft nur heuristische Hinweise.
Keine dieser Ebenen sollte mehr Sicherheit versprechen, als sie tatsächlich bieten kann.
Warum Agenten besonders strenge Kontrollen vertragen#
Hier zeigt sich ein weiterer Vorteil gegenüber rein manueller Softwareentwicklung.
Menschen ermüden. Bei langen Checklisten wächst die Versuchung, Abkürzungen zu nehmen. Und wer bereits viel Arbeit in eine Implementierung investiert hat, verwirft sie oft nur widerwillig, selbst wenn klar wird, dass sie in die falsche Richtung führt.
Ein KI-Agent empfindet keine Langeweile bei der hundertsten Prüfung und keinen Frust darüber, eine umfangreiche Implementierung verwerfen und neu aufbauen zu müssen. Das bedeutet nicht, dass er Regeln zuverlässig befolgt. Er kann sie missverstehen, übersehen oder auf unerwünschte Weise umgehen.
Gerade deshalb gehören wichtige Kontrollen in eine unabhängig ausgeführte CI-Pipeline. Dort kann der Agent die Regeln nicht einfach durch eine passende Erklärung ersetzen. Scheitert eine Prüfung, erhält er das Ergebnis als Feedback und muss nachbessern.
Agentic AI ermöglicht damit nicht nur, bekannte Qualitätssicherungsverfahren häufiger anzuwenden. Sie macht auch Entwicklungsprozesse praktikabel, die bei manueller Durchführung wegen ihres Aufwands und ihrer ständigen Wiederholung kaum durchzuhalten wären.
Und dieselben Prüfergebnisse können noch mehr leisten: Sie liefern die Grundlage für die Entscheidung, ob eine Änderung automatisch freigegeben werden kann oder ob ein Mensch die Änderung überprüfen sollte. Genau das ist die Idee hinter der Gray Software Factory.
Warum das nicht überall gleich gut funktioniert#
Dieses Prinzip ist nicht auf Softwareentwicklung beschränkt. In der Mathematik lassen sich formal formulierte Beweise durch Beweisprüfer kontrollieren. Auch andere technische Disziplinen verfügen für bestimmte Aufgaben über Simulationen, Messverfahren oder formale Prüfungen.
Aber es funktioniert eben nicht in allen Disziplinen gleichermaßen gut.
Nehmen wir ein Logo, das besonders originell wirken und bestimmte Gefühle auslösen soll. Ein Agent kann Farben, Formate, Kontrastwerte oder die Einhaltung eines Corporate Designs überprüfen. Aber woran soll er automatisch und zuverlässig erkennen, ob Menschen das Logo tatsächlich als außergewöhnlich, vertrauenswürdig oder berührend empfinden?
Man kann Menschen befragen und Reaktionen untersuchen. Das sind wertvolle Rückmeldungen, aber kein mit einem Compiler vergleichbarer, jederzeit reproduzierbarer Prüfmechanismus. Bei einer Gestaltung, deren Qualität wesentlich in ihrer subjektiven Wirkung liegt, bleibt das Messproblem schwierig.
Die entscheidende Grenze verläuft daher nicht zwischen Softwareentwicklung und allen anderen Disziplinen, stattdessen verläuft sie zwischen Aufgaben, für die wir verlässliche Rückmeldungen automatisieren können, und Aufgaben, bei denen genau das nur eingeschränkt möglich ist.
Fazit: Die eigentliche Stärke liegt in der Rückkopplung#
Kehren wir zur gelenkten Rakete zurück.
Ein besserer Antrieb hilft wenig, wenn das Ziel falsch gewählt wurde. Eine präzisere Steuerung hilft wenig, wenn das System nicht erkennen kann, dass es vom Kurs abweicht. Erst Zielklarheit, geeignete Zielvorgabe und zuverlässige Rückkopplung ergeben zusammen eine robuste Navigation.
Dasselbe gilt für Agentic AI.
Wir werden weiterhin leistungsfähigere generative Modelle bekommen. Aber für zuverlässige autonome Arbeit ist die nächste Modellgeneration nur ein Teil der Antwort. Ebenso entscheidend ist, wie gut wir gewünschte Ergebnisse spezifizieren, automatisch überprüfen und aus festgestellten Abweichungen neue Korrekturschritte ableiten können.
In der Softwareentwicklung haben wir dafür bemerkenswert gute Voraussetzungen; wir müssen sie nur konsequent nutzen.
Die eigentliche Stärke von Agentic AI liegt nicht allein darin, Ergebnisse zu generieren, sondern darin, sie überprüfbar zu machen und so lange nachzujustieren, bis sie den Anforderungen mit hinreichender Sicherheit entsprechen.
Quellen und weiterführende Literatur#
- NASA: Distinctions between Product Verification and Product Validation
- Cucumber: Behaviour-Driven Development und Gherkin Reference
- PIT: Mutation Testing for Java
- DeepMind: Specification gaming: the flip side of AI ingenuity
- Rust: The Rust Programming Language – What Is Ownership? und Unsafe Rust
- George E. P. Box: Hintergrund zum Zitat “All models are wrong, but some are useful”
Dieser Artikel ist mit Unterstützung von KI entstanden.