Wenn nicht mehr der Code, sondern die Spezifikation im Mittelpunkt steht, stellt sich sofort die Frage, wie eine solche Spezifikation aussehen muss, damit ein Agent verlässlich daraus Code baut und ein Mensch sie prüfen kann. Ein Fließtext, der ein Ziel umschreibt, ist zwar bequem zu lesen, aber zu vage, um daraus zuverlässig Code zu erzeugen oder Prüfungen abzuleiten. Ein rein formales Maschinenmodell wäre das andere Extrem: Präzise, aber schwergewichtig und für viele Beteiligte kaum noch als Arbeitsmittel geeignet. AIND setzt bewusst dazwischen an: Eine strukturierte Sprache, die ein Agent zuverlässig umsetzt und ein Mensch noch versteht.
Spezifikation mit Struktur, statt Prosa
AIND gibt der Spezifikation eine feste Struktur. Ein System wird in Komponenten gegliedert, und jede Komponente hält vier Dinge zusammen:
- Anforderungen: Was die Komponente leisten soll, als überprüfbare Aussagen.
- Zusicherungen: Welche technischen Eigenschaften der erzeugte Code einlösen muss.
- Entscheidungen: Welche Optionen erwogen wurden und warum eine gewählt wurde.
- Ergänzende Artefakte zur Absicht: Zweck, Grenzen und Fachwissen zum Anwendungsbereich, Entwurfsdokumente wie UI-Designs, Ablaufdiagramme, Datenmodelle, Schnittstellen.
Diese Bausteine sind nach Aspekten geordnet und werden jeweils einem Verantwortlichen zugewiesen. Die Spezifikation gehört also jemandem; sie ist kein herrenloser Fließtext. Und sie ist prüfbar, nach demselben Prinzip wie der Abgleich zwischen Zusicherung und Code, nur eine Ebene höher: Decken Anforderungen und Zusicherungen noch ab, was gewollt war?
Damit bekommt die Kette vom Bedarf über die Anforderung und die Zusicherung bis zum Code aus dem vorigen Beitrag ihren festen Ort: Es ist die Struktur aus Anforderungen, Zusicherungen und Entscheidungen, die in der diese Kette gepflegt wird. Die Spezifikation dient nicht der Dokumentation, sondern wird zum Arbeitsmittel der Entwicklung selbst.
Lesbar für Mensch und Maschine
Eine AIND-Spezifikation hat zwei Konsumenten. Der eine ist der Agent, der daraus Code erzeugt, Kontext auswählt oder Prüfungen vorbereitet. Der andere ist der Mensch, der verstehen muss, was gewollt war, warum eine Entscheidung getroffen wurde und ob die Zusicherungen noch zur fachlichen Absicht passen. Daraus folgt eine doppelte Anforderung: Die Spezifikation muss präzise genug sein für den Agenten und verständlich genug für den Menschen.
Die Stärke der KI liegt genau darin, dass sie uns nicht zwingt, alles in ein schwer lesbares Maschinenformat zu übersetzen. Ein Agent kann mit strukturierter Sprache arbeiten, d.h. mit Anforderungen, Zusicherungen, Entscheidungen und Erläuterungen. Aber diese Sprache darf nicht beliebig sein. Sie braucht Ordnung, Verantwortlichkeiten und klare Bezüge.
AIND nutzt genau diesen Spielraum. Die Spezifikation bleibt durch Menschen prüfbar, wird aber so strukturiert, dass ein Agent sie verarbeiten kann. Sie ist der gemeinsame Nenner für die menschliche Absicht und die maschinelle Umsetzung. Das ist ein entscheidender Unterschied zu früheren Automatisierungsansätzen, bei denen man oft zwischen einer Dokumentation, die für den Menschen lesbar ist, und einem formalisierten Modell wählen musste. Mit KI entsteht eine Mischform, die vorher kaum tragfähig war: Strukturierte menschliche Sprache wird zu einem produktiven Entwicklungsartefakt.
Das Warum bekommt ein Zuhause
Der eigentliche Nutzen steckt aber tiefer. Mit dieser Struktur bekommt das Warum eines Systems einen festen, versionierten Ort. Der Code sagt immer nur, was ein System tut, aber nie, warum das System so und nicht anders gebaut ist. Diese Absicht steckt sonst in den Köpfen der Entwickler*innen, in Chatverläufen, in E-Mails oder in einer Dokumentation, die niemandem gehört und deshalb aus dem Ruder läuft: Veraltet, unvollständig, irgendwann ignoriert.
Solange Menschen den Code schrieben, ließ sich das notdürftig überbrücken, indem man den Code las und die Absicht dahinter rekonstruierte. Das war mühsam, aber möglich. Wenn aber der Agent den Code schreibt, dreht sich das Verhältnis um: Die Absicht ist dann das Wertvollste, was der Mensch besitzt und der Teil, den er nicht delegiert. Genau sie muss deshalb gepflegt werden. Anforderungen, Entscheidungen, Grenzen, Begründungen und Zusicherungen bekommen in der strukturierten Spezifikation ein Zuhause: Geordnet, versioniert, geprüft und an den Code gebunden. Das Warum ist damit kein flüchtiges Wissen mehr, sondern ein gepflegtes Artefakt.
Das hilft nicht nur dem Menschen, sondern auch dem Agenten. Je klarer Zweck, Grenzen und Entscheidungen beschrieben sind, desto besser kann er den richtigen Kontext auswählen, passende Umsetzungsvorschläge erzeugen und vermeiden, am eigentlichen Ziel vorbeizuarbeiten.
Warum kein Anforderungsmanagement-System?
Wenn Anforderungen, Entscheidungen und Nachverfolgbarkeit so wichtig sind, warum speichert man sie dann nicht einfach in einem Anforderungsmanagement-System? Das ist gerade aus Sicht der PLM-Welt, in der solche Systeme längst existieren, eine naheliegende Frage. Dagegen spricht, dass ein solches System für kleine Teams oft überdimensioniert ist. Statt ein weiteres Werkzeug lizenzieren, bedienen und pflegen zu müssen, sorgt AIND für die strukturierte und geprüfte Nachvollziehbarkeit mit weniger Aufwand und unmittelbar dort, wo entwickelt wird. Für das Entwickeln mit KI ist es entscheidend, dass Warum während des Entwicklungsprozesses im direkten Zugriff zu haben, um das Auseinanderdriften von Anforderungen und Code zu vermeiden. Das ist mit AIND einfacher als mit einem externen Anforderungs-Management-System. Wer bereits ein solches System einsetzt, braucht es nicht aufzugeben, sondern kann es über einen Konnektor in AIND integrieren.
Schnittstelle zwischen Absicht und Umsetzung
Warum die Kontrolle beim Programmieren mit Agenten auf die Spezifikation übergeht, war Thema des vorigen Beitrags. Dieser Beitrag hat gezeigt, wie diese Spezifikation beschaffen sein muss: Zugleich maschinell verarbeitbar und menschlich prüfbar, eng genug am Code, um nicht zu veralten, und reich genug an Kontext, um das Warum festzuhalten.
Eine agententaugliche Spezifikation beschreibt also nicht nur, was gebaut werden soll. Sie hält auch fest, warum es gebaut werden soll, welche Zusicherungen der Code einlösen muss und welche Entscheidungen zu dieser Form geführt haben. Mit AIND wird die Spezifikation zur Schnittstelle zwischen menschlicher Absicht und maschineller Umsetzung.
Der nächste Teil dieses Kapitels verlässt die innere Struktur der Spezifikation und fragt, wie sie sich in bestehende Entwicklungsumgebungen einfügt, dort, wo Code, Anforderungen, Modelle und Produktdaten heute bereits entstehen.
