Spec-Driven AI Operating Model: Was der Geschäftsprozess nicht abdeckt

Spec-Driven AI Operating Model heißt der Geschäftsprozess, nach dem ich in regulierten Vorhaben arbeite. Auf Deutsch: Es gibt eine Beschreibung dessen, was die Software tun soll, sie liegt nicht im Code, und alles wird gegen sie geprüft.

Dieser Text beschreibt es von der unangenehmen Seite. Was es nicht kann, was es kostet, und was beim Versuch schiefgegangen ist.

Die Asymmetrie, aus der das Ganze folgt

Die Werkzeuge, die ein Haus zur Qualitätssicherung hat, suchen nach kaputt. Statische Analyse, Tests, Monitoring, alle sind darauf gebaut, Fehlfunktion zu finden.

Eine Maschine produziert etwas anderes. Sie produziert funktionsfähig und falsch.

Ich hatte einen Fehler auf dem Tisch, der technisch einwandfrei war. Sauberer Code, grüne Tests, korrektes Verhalten. Fachlich war die Entscheidung dahinter falsch. Kein Werkzeug dieser Welt hätte den gefunden, weil kein Werkzeug weiß, was in dieser Domäne richtig ist.

Solange ein Mensch den Code schreibt, ist diese Lücke klein. Er trifft die fachliche Entscheidung beim Tippen und kann sie hinterher erklären. Schreibt eine Maschine den Code, bleibt von der Entscheidung nichts übrig außer dem Ergebnis.

Was im Code steht, ist dann das Ergebnis eines Modells und nicht die Spur einer überprüfbaren menschlichen Entscheidung. Deshalb ist „steht im Code" keine Antwort mehr.

Drei Artefakte und eine Sperre

Der Geschäftsprozess besteht aus wenig.

Die Spezifikation. Eine Beschreibung des Soll-Verhaltens, strukturiert, versioniert, im Repository. Nicht in einem Wiki, weil ein Wiki für Menschen formatiert ist, über Seiten verteilt und redundant. Eine Maschine liest es schlecht und jedes Mal neu.

Das Abweichungsregister. Wenn bei der Umsetzung auffällt, dass etwas nicht gedeckt oder widersprüchlich ist, wird es nummeriert erfasst, aus dem Code heraus zitiert und in einem Durchgang mit dem Fachbereich geklärt.

Drei Prüfschichten. Maschinell, Code-Review, fachlicher Test. Die dritte ist die, auf die es ankommt, und die teuerste.

Dazu kommt eine Regel, die wie eine Formalie aussieht und den Geschäftsprozess trägt oder bricht:

Der Code kann die Spezifikation nicht ändern. Auch dann nicht, wenn er offensichtlich etwas anderes tut.

Das ist der Satz, der im Alltag am häufigsten unter Druck gerät. Es ist Freitag, das Ticket ist fast fertig, die Beschreibung passt nicht ganz, und die Beschreibung anzupassen dauert zwei Minuten. Jedes Mal, wenn das passiert, gibt es wieder zwei Wahrheiten.

Woran man erkennt, dass eine Anforderung nicht prüfbar ist

Eine Spezifikation abzuweisen, bevor gebaut wird, klingt nach Erfahrung und Fingerspitzengefühl. Ist es nicht. Es gibt einen mechanischen Test:

Lässt sich für eine Anforderung kein Szenario in der Form Gegeben / Wenn / Dann schreiben, ist sie nicht prüfbar.

Gegeben   ein Vertrag ist ausgewählt
Wenn      der Nachname geändert wird
Dann      ist Speichern aktiviert
Und       die Änderung wird unmittelbar übernommen

Der Test verlangt kein Fachwissen. Wer ihn anwendet, muss nur versuchen, die drei Zeilen zu schreiben. Geht es nicht, fehlt der Ausgangszustand, die auslösende Handlung oder das erwartete Ergebnis. Jede dieser drei Lücken ist später ein Streitfall im fachlichen Test, nur teurer.

„Das System soll sicher sein" ergibt kein Szenario. „Komfortabel" auch nicht.

Was der Geschäftsprozess nicht abdeckt

Hier wird es unbequem, und deshalb steht es in diesem Text.

Wer in einem regulierten Umfeld Nachweise führt, hat üblicherweise sechs Bereiche zu belegen: Asset-Inventar, Zugangskontrolle, Updates, Schwachstellen, Protokollierung, Incident Handling.

Der Geschäftsprozess berührt davon zwei, und die halb. Bei Updates entsteht eine Freigabespur, weil der Automat Vorgänge nur bis zum Code-Review bewegen darf. Bei Schwachstellen gibt es einen wöchentlichen Abgleich, aber für Rechtsänderungen und nicht für Sicherheitslücken. Asset-Inventar, Zugangskontrolle, Protokollierung und Incident Handling: gar nicht.

Das ist kein Mangel. Es ist die Abgrenzung.

Die üblichen Nachweise belegen, wie ein System betrieben wird. Dieser Geschäftsprozess belegt, warum es sich so verhält.

Die sechs Bereiche kann ein Haus mit Werkzeugen erschlagen, und dafür gibt es einen Markt mit guten Produkten. Den siebten nicht, weil keine Software weiß, welche fachliche Entscheidung hinter einer Codezeile stand. Wer also schon Compliance-Werkzeuge im Haus hat, hat damit nichts gelöst, was dieser Geschäftsprozess löst, und umgekehrt genauso.

Was beim Aufbau nicht funktioniert hat

Vier Sackgassen aus einem laufenden Vorhaben.

Fehler beheben und weitermachen. Bei einer übernommenen Codebasis lösten fünf behobene Fehler drei bis vier neue aus. Der Umfang wuchs schneller als der Fortschritt. Die Wende kam nicht durch mehr Sorgfalt, sondern durch eine rekonstruierte Spezifikation, gegen die sich prüfen ließ.

Die Spezifikation als PDF ablegen. Hat funktioniert und schlecht. Formatierung, Redundanz und verteilte Inhalte blieben erhalten. Erst strukturiertes Markdown mit entfernten Dopplungen hat den Unterschied gemacht.

Zwei fachliche Quellen nebeneinander pflegen. Eine technisch geprägte, eine fachlich geprägte, beide aktuell gehalten, in Teilen widersprüchlich. Für Menschen mühsam, für eine Maschine unbrauchbar. Die Frage „was gilt" war über Monate ungeklärt.

Altlasten einzeln abarbeiten. Bei 776 offenen Vorgängen aus der Vorgeschichte ist einer nach dem anderen die naheliegende Reihenfolge. Sie funktioniert und ist falsch, weil niemand weiß, welche Vorgänge sich widersprechen, veraltet sind oder zusammenhängen. Erst das Gruppieren nach Fachgebiet hat den Stau aufgelöst.

Was es kostet

Geld. Ein intensiver Arbeitstag mit Modellen liegt im dreistelligen Eurobereich, und zwar pro Person. Die Antwort darauf ist keine Sparsamkeit, sondern eine Aufteilung: günstige Modelle für mechanische Arbeit, teure nur dort, wo Urteilsvermögen zählt.

Zeit vorne. Eine Spezifikation zu rekonstruieren, bevor gebaut wird, fühlt sich an wie Stillstand. Zwei Wochen Umbau der Codestruktur nach Fachgebieten sehen in keinem Statusbericht gut aus.

Disziplin an einer Stelle. Siehe die Sperre oben. Sie kostet jeden Freitag zwei Minuten mehr als die Alternative.

Der Befund, der am meisten überrascht hat

Wenn Entwicklung billig wird, staut sich nichts mehr in der Entwicklung.

Zwei technische Verantwortliche, dazu eine große Zahl parallel arbeitender Agenten, die zuverlässig tun, was verlangt wird. Und eine einzige Person mit dem fachlichen Wissen, um zu beurteilen, ob das Ergebnis richtig ist. Die Vorgänge stauen sich im fachlichen Test.

Das ist kein Personalproblem, es folgt aus der Mechanik. Wird das Bauen billiger, wird die fachliche Entscheidung zum teuersten Teil des Systems.

Was dagegen hilft, in dieser Reihenfolge: fachliches Wissen aus Köpfen in die Spezifikation holen, damit mehr als eine Person urteilen kann. Die Oberfläche maschinell bedienbar bauen, damit ein Teil der Prüfung vorbereitet werden kann. Vorher-Nachher-Belege automatisch erzeugen, damit die Prüfung nicht beim Suchen anfängt.

Was nicht hilft: mehr Entwickler. Das war schon vorher nicht der Engpass.

Was am Ende dasteht

Ich übernehme laufende Vorhaben, bis sie stehen, dann bin ich raus. Was bleibt, ist eine Spezifikation, gegen die weitergebaut wird, eine Prüfarchitektur, und eine benannte Person im Haus, die eine Anforderung abweisen darf, bevor gebaut wird.

Das Letzte ist der Teil, an dem sich entscheidet, ob es ein Geschäftsprozess war oder nur eine Zeit lang gut gelaufen ist.