Vom Kostenvorteil zur Frage der Kontrolle

Dass sich mit Coding-Agenten Software billiger und schneller erzeugen lässt als in menschlicher Handarbeit, ist die Prämisse dieser Serie (siehe Auftakt) und ein schlichtes Marktgesetz: Ein günstigeres Produktionsverfahren setzt sich durch, sofern Qualität und Verlässlichkeit stimmen. Die eigentliche Frage lautet deshalb nicht, ob die KI Code erzeugen kann, sondern wie man sie den Code erzeugen lässt, ohne die Kontrolle über das Ergebnis zu verlieren.

Wie gibt man die Kontrolle über den Code ab?

Wenn Menschen Programmcode nicht mehr Zeile für Zeile schreiben und lesen, muss auf andere Weise sichergestellt werden, dass das erzeugte Programm auch das tut, was es tun soll, und zwar verlässlich, prüfbar und nachvollziehbar. Doch woran macht man Korrektheit fest, wenn nicht mehr am gelesenen Quelltext? Was muss erfüllt sein, damit man dem erzeugten Code trauen kann, ohne ihn vollständig nachzuvollziehen?

In der klassischen Entwicklung ist der Quellcode das zentrale Artefakt. Er wird geschrieben, gelesen, diskutiert, verbessert, getestet und in Reviews abgesichert. Auch wenn niemand jede Zeile perfekt versteht, bleibt der Code die Basis für die eigentliche Kontrolle. Wer etwas wissen will, schaut in den Code.

Bei agentischer Entwicklung funktioniert dieses Vorgehensmodell nicht mehr. Der Agent erzeugt Code in einer Geschwindigkeit und Menge, die nicht mehr sinnvoll durch vollständiges menschliches Lesen kontrolliert werden kann. Der Versuch, jeden erzeugten Code weiterhin so zu behandeln wie handgeschriebenen Code, nimmt dem Verfahren genau den wirtschaftlichen Vorteil, den es eigentlich bringen soll.

Wer die Kostenreduzierung nutzen will, muss also Kontrolle abgeben können, aber nicht unkontrolliert. Wie kann eine Organisation Code von einem Agenten erzeugen lassen, ohne ihn vollständig manuell zu prüfen und trotzdem sicherstellen, dass er die vereinbarte Funktion erfüllt? Das ist die erste Überlebensfrage.

Wie behält man die Kontrolle über die Funktion?

Wer die Kontrolle über den Code abgibt, darf nicht die Kontrolle über die Funktion verlieren. Anforderungen, Entwurf und Entscheidungen müssen in einer Form vorliegen, die ein Agent zuverlässig in Code übersetzen kann, und die zugleich für den Menschen die verbindliche Quelle bleibt. Es reicht nicht aus, dem Agenten ein Ziel in natürlicher Sprache zu beschreiben und zu hoffen, dass er daraus das richtige System generiert. Es muss einen Ort geben, an dem Absicht, Grenzen und Zusicherungen dokumentiert und geprüft werden.

Andernfalls entsteht ein neues Risiko: Der Code ist schnell da, aber die Absicht gerät in Vergessenheit. Eine Funktion funktioniert im Demo-Fall, aber niemand weiß mehr genau, welche Annahmen der Agent getroffen hat. Ein Test prüft das Naheliegende, aber nicht den fachlich entscheidenden Grenzfall. Eine Architekturentscheidung steckt irgendwo im erzeugten Code, aber nicht dort, wo sie geprüft, diskutiert und weiterentwickelt werden kann. Dann ist zwar Software entstanden, aber ihre Entwicklung ist nicht beherrschbar.

Das ist das Spannungsfeld: Kontrolle über den Code abgeben heißt loslassen, sie über die Funktion behalten heißt festhalten. Beides zugleich muss eine Methode für die Entwicklung mit Hilfe der KI leisten.

Die Antwort: Die Spezifikation prüfen, nicht den Code

Die Spannung zwischen den beiden Fragen lässt sich nicht durch geschicktere Anweisungen an die KI auflösen. Bessere Prompts können einzelne Ergebnisse verbessern, ersetzen aber keine Entwicklungsorganisation, keine Prüfpunkte, keine Verantwortlichkeiten und keine nachvollziehbare Kette von der fachlichen Absicht zum erzeugten Code. Wenn die agentische Entwicklung wirtschaftlich eingesetzt werden soll, braucht sie eine Methodik.

Diese Methodik muss drei Dinge leisten: Erstens muss sie dem Agenten genügend Struktur geben, um zuverlässige Software zu bauen. Zweitens muss sie dem Menschen einen Ort geben, an dem er Anforderungen, Entwurf und Entscheidungen prüfen kann. Drittens muss sie eine Verbindung herstellen zwischen dem, was fachlich gewollt ist, und dem, was technisch entsteht.

Genau das ist der Kern von AIND, der KI-nativen Entwicklungsmethodik von PROSTEP. AIND verschiebt den Prüfpunkt vom erzeugten Code zur Spezifikation. Der Mensch beschreibt und prüft Bedarf, Anforderungen, Entwurf und Zusicherungen; der Agent erzeugt daraus Code und Tests. Damit wird nicht blind dem Code vertraut, sondern die Kette kontrollierbar gemacht, aus der er entsteht.

Das klingt zunächst wie eine Verlagerung des Problems vom schwer zu prüfenden Code zur schwer prüfbaren Spezifikation. Der Unterschied ist jedoch entscheidend. Eine gute Spezifikation ist deutlich kleiner als der Code, den sie erzeugt. Sie ist auf der Ebene der fachlichen Absicht formuliert, nicht in technischen Details. Und sie bleibt stabil, während der Code sich ändert.

Die AIND-Kette: Bedarf, Anforderung, Zusicherung, Code

AIND macht das über eine Kette, in der jedes Glied einen eigenen Zweck hat:

Bedarf → Anforderung → Zusicherung → Code.

Der Bedarf ist die fachliche Absicht: Was soll das System für wen leisten? Die Anforderung macht daraus eine überprüfbare Aussage. Die Zusicherung ist die technische Zusage, die der Code einlösen muss, präzise genug, dass sich ihre Erfüllung feststellen lässt. Der Code ist das, was der Agent daraus erzeugt. Die Zusicherung ist damit die Brücke zwischen fachlicher Anforderung und technischem Verhalten.

Entlang dieser Kette verteilt sich die Arbeit neu: Der Mensch spezifiziert, was gelten soll, und entwirft die Struktur, während der Agent umsetzt. Damit verlässt der Mensch die Ebene des Codes; er arbeitet auf der Ebene der Absicht und prüft, ob die Zusicherung korrekt ist und die Anforderung erfüllt.

Was Werkzeuge prüfen und was Menschen prüfen

Der Vorteil dieser Vorgehensweise liegt darin, dass die Übergänge zwischen diesen vier Phasen jeweils von demjenigen geprüft werden, der sie am besten beurteilen kann.

Die erste Prüfung setzt zwischen Zusicherung und Code an. Werkzeuge lesen den tatsächlichen Code aus: Klassen, Methoden, Signaturen, Abhängigkeiten. Sie raten nicht, ob der Code zur Zusicherung passt, sondern prüfen faktisch, was im Code vorhanden ist. Strukturelle Abweichungen fallen eindeutig auf. Wo eine Zusicherung Verhalten beschreibt, prüft die KI gezielt diese Stelle gegen die Zusage. Das Ergebnis ist kein mathematischer Korrektheitsbeweis, sondern ein wiederholbarer Abweichungsbericht.

Die zweite Prüfung setzt eine Ebene höher an: Decken die Zusicherungen wirklich ab, was fachlich gefordert war? Sie folgt demselben Prinzip wie der Abgleich zwischen Zusicherung und Code, nur auf der Ebene zwischen Anforderung und Zusicherung.

Damit ist die Arbeitsteilung klar:

1. Der Mensch prüft Absicht, Anforderungen und Zusicherungen, d.h. die Ebene, auf der Urteilskraft zählt.
2. Werkzeuge prüfen Struktur und decken Abweichungen zwischen Zusicherung und Code auf.
3. Die KI prüft gezielt die Verhaltensfragen, die sich nicht rein strukturell entscheiden lassen.
4. Der Agent erzeugt den Code.

Der eigentliche Wert liegt darin, dass dieser Abgleich auf realen Code-Fakten basiert, wiederholbar ist und günstig genug, um ständig mitzulaufen. Abweichungen tauchen hier auf, nicht erst beim Kunden.

Schneller werden, ohne unkontrolliert schneller zu werden

Über den Geschwindigkeitsvorteil des KI-gestützten Programmierens kursieren Zahlen von Faktor 5, 10, manchmal mehr. Die belastbare Empirie ist nüchterner: Kontrollierte Studien zu allgemeiner Programmierarbeit zeigen deutlich niedrigere Nutzeneffekte und in bestimmten reifen Code-Basen sogar negative Effekte: Die Entwickler*innen fühlten sich schneller, waren es aber nicht.¹ Entscheidend ist der Kontext: In großen, reifen Code-Basen fällt der Effekt zunächst gering aus, in der Neuentwicklung auf der grünen Wiese sind dagegen hohe Faktoren realistisch. Für viele unspezifische Szenarien liegt der Hebel eher beim Zwei- bis Dreifachen des wirtschaftlich Relevanten, aber kein pauschaler Faktor 10.

Entscheidend ist aber nicht der Hebelfaktor selbst, sondern wie er entsteht und warum der gemessene Nachteil in reifen Code-Basen kein Gegenargument ist. Die Studie misst einen eng umrissenen Fall: Erfahrene Entwickler*innen, die ihren eigenen, reifen Code bereits genau kannten. Das ist über die Lebensdauer eines Projekts die Ausnahme, nicht die Regel. Teams wechseln, Module altern, und kaum jemand kennt fremden oder lange nicht angefassten Code auswendig. Wie die Entwickler*innen die KI im Detail einsetzten, protokolliert die Studie zwar nicht vollständig. Sie nennt aber ausgerechnet die Art der Nutzung als eine der Ursachen der Verlangsamung: Zu einfache Prompts und geringe Vertrautheit mit dem Werkzeug. Genau hier liegt eine der Stärken von AIND.

Statt eine Aufgabe einfach in eine Session zu prompten, erarbeitet man mit AIND zuerst eine Landkarte des Codes mit Komponenten, Zusicherungen, gespeicherten Beschreibungen und steuert damit den Kontext jeder Coding-Session präzise. Der Agent durchsucht die Code-Basis nicht jedes Mal neu mit wechselnden Ergebnissen, sondern arbeitet sich gezielt zum relevanten Ausschnitt vor. Das spart Arbeit am falschen Ausschnitt und damit Korrekturschleifen. Ist die Landkarte einmal da, geht auch die Arbeit an Bestands-Code deutlich schneller, sobald man ihn ein zweites Mal bearbeitet. Der eigentliche Hebel aber besteht darin, dass dieser Wissensstand nicht im Kopf eines einzelnen Menschen steckt, sondern persistent externalisiert wird und damit dem ganzen Team zur Verfügung steht: Jede weitere Session profitiert davon. AIND ist also nicht schneller, weil die KI schneller Code produziert, sondern weil ein kontrollierter, wieder