Rund zwanzig Jahre lang waren die meisten IT-Organisationen um drei Wörter herum gebaut: Plan, Build, Run. Das war ein gutes Modell. Es hat jedem einen Platz gegeben. Plan hatte das Budget und die Roadmap. Build hatte den Code. Run hatte die Server und den Pager.

Mit KI-Agenten und Spec-Driven Development passt dieses Modell nicht mehr. Was ich in echten Projekten sehe, sind vier Phasen: Specify, Generate, Verify, Operate.

Das Interessante sind nicht die neuen Namen. Es ist die Zahl. Aus drei wird vier.

Was am alten Modell falsch war

Lange Zeit gar nichts. Aber es hatte eine schwache Stelle, mit der wir alle gelernt haben zu leben.

Die Spezifikation war ein Nebenprodukt. Jemand hat ein Dokument geschrieben, das Team hat es einmal gelesen, der Code wurde geschrieben, und nach dem Release hat das Dokument niemand mehr angefasst. Ein halbes Jahr später war die einzige ehrliche Beschreibung des Systems der Quellcode selbst.

Das haben wir akzeptiert. Wir haben sogar eine Tugend daraus gemacht. „Der Code ist die Wahrheit.“ Und in einer Welt, in der Menschen jede Zeile schreiben, ist das eine vernünftige Haltung. Wer den Code schreibt, hat die Absicht im Kopf.

Ein Agent hat nichts im Kopf. Er weiss nur, was du ihm gibst. In dem Moment, in dem ein Agent Code schreibt, wird aus der schwachen Stelle also das Hauptproblem.

Specify

Specify wandert aus Build heraus und wird eine eigene Phase mit einem eigenen Ergebnis.

Das ist eine grössere Verschiebung, als es klingt. Bei Plan-Build-Run war „Plan“ Portfolio, Budget und Roadmap. Das war Managementarbeit. Die eigentliche Spezifikation ist irgendwo in Build passiert, oft in einem Ticket, oft in einem Gespräch, oft nirgends.

Jetzt ist die Spezifikation der Input für die Maschine. Sie muss präzis genug sein, dass ein Agent damit arbeiten kann. Sie muss versioniert, reviewt und gepflegt werden wie Code, denn sie ist jetzt das, was bleibt.

Ich verwende dafür System Use Cases im Stil von Alistair Cockburn. Hauptablauf, Alternativabläufe, Vorbedingungen, Nachbedingungen. Nicht weil das Format magisch wäre, sondern weil es präzis ist, klein bleibt und testbar ist. Ein Use Case sagt dir, was das System tut und was danach wahr sein muss. Genau das braucht ein Agent, und genau das braucht ein Test.

Und noch etwas ändert sich: Fachleute können einen Use Case lesen. Eine Prompt-Historie können sie nicht lesen.

Generate

Generate klingt nach Knopfdruck. In einer Greenfield-Demo ist es das fast auch. In einem Unternehmenssystem mit fünfzehn Jahren Geschichte ist es das nicht.

Wenn du einen Agenten auf eine grosse bestehende Codebasis loslässt und ihm nur eine Spezifikation gibst, bekommst du schnelleres Chaos. Der Agent kennt deine Modulgrenzen nicht. Er weiss nicht, dass der OrderService derjenige ist, den niemand anfassen darf. Er weiss nicht, dass ihr jOOQ verwendet und nicht Hibernate, oder dass es bei euch eine Regel gibt, wo Transaktionen beginnen.

Die Arbeit steckt im Harness. Also in den Regeln, im Kontext, in der Projektstruktur, im Build, in den Lintern, in den Architekturtests, in der Nachvollziehbarkeit vom Use Case bis zum Code, der ihn umsetzt. Das Harness ist das, was aus einem allgemeinen Modell etwas macht, das in deinem System arbeiten kann.

Da geht der grösste Teil des Aufwands hin, und das ist der Teil, den niemand auf eine Folie schreibt. Generate ist billig. Das Harness ist es nicht.

Auch das gehört gesagt: Generate heisst nicht, dass die Entwicklerin verschwindet. Es heisst, dass sie eine Ebene höher rückt. Du reviewst, du entscheidest, und du korrigierst die Spezifikation, wenn der generierte Code zeigt, dass die Spezifikation falsch war. Das passiert öfter, als man denkt, und es ist keine Schwäche, sondern der Sinn der Sache.

Verify

Verify ist die wirklich neue Phase, und ich halte sie für die wichtigste.

Getestet haben wir immer. Aber Testen war in Build versteckt. Es hat sich das Budget mit der Feature-Arbeit geteilt, es hat sich den Termin mit der Feature-Arbeit geteilt, und wenn es eng wurde, war es das Erste, was gestrichen wurde. Das hat jeder von uns erlebt.

Wenn Code schnell entsteht, geht diese Anordnung kaputt. Der Output steigt, die Review-Kapazität bleibt gleich. Wenn du das Testen als Unteraufgabe von Build lässt, hast du eine Maschine gebaut, die plausiblen Code schneller produziert, als ihn irgendjemand prüfen kann. Das ist kein Produktivitätsgewinn. Das ist ein Risiko, das du noch nicht gemessen hast.

Also wird Verify eine eigene Phase mit eigenem Budget und eigenem Owner. Und es ist mehr als Unit Tests:

  • Tut der Code, was die Spezifikation sagt? Hier verdient die Nachvollziehbarkeit ihr Geld. Wenn jeder Use Case auf Code und auf einen Test zeigt, kannst du die Frage beantworten statt raten.
  • Passt der Code zur Architektur? Architekturtests, Abhängigkeitsregeln, Modulgrenzen.
  • Stimmt die Spezifikation selbst? Ein Agent setzt eine falsche Spezifikation perfekt um. Das ist der Fehlerfall, an den sich noch niemand gewöhnt hat.

Der letzte Punkt ist der unangenehme. Früher hat ein Entwickler eine schlechte Anforderung oft beim Umsetzen bemerkt. Dieses informelle Sicherheitsnetz ist weg. Verify muss es absichtlich ersetzen.

Operate

Operate bleibt Operate. Software läuft, und es ist ihr egal, wer sie geschrieben hat.

Monitoring, Logging, Incidents, Kapazität, Kosten. Alles gleich. Wenn überhaupt, wird es wichtiger, denn die Produktion ist jetzt der Ort, an dem du herausfindest, ob deine Spezifikation die echte Welt beschrieben hat oder nur die, die du dir vorgestellt hast.

Eine kleine Ergänzung: Das Feedback aus Operate muss zurück in die Spezifikation, nicht nur in den Code. Wenn du einen Incident behebst, indem du Code änderst, und den Use Case unangetastet lässt, dann bringt der nächste Generierungslauf den Fehler fröhlich wieder zurück. Ich habe das schon gesehen. Es ist eine sehr moderne Art von Regression.

Der Satz, um den es eigentlich geht

Bisher war der Code das Vermögen. Jetzt ist die Spezifikation das Vermögen, und der Code ist ein Ergebnis, das du neu erzeugen kannst.

Das ist die ganze Sache in einem Satz. Alles andere folgt daraus. Warum Specify eine eigene Phase bekommt. Warum Verify ein Budget braucht. Warum die Rückkopplung aus Operate in der Spezifikation landen muss.

Es ändert auch, was du kaufst, wenn du Software kaufst, und was du besitzt, wenn ein Lieferant geht. Wer den Code bekommt, aber nicht die Spezifikation, hat die kleinere Hälfte bekommen.

Der Einwand

Der kommt sowieso, also sage ich ihn selbst: „Ihr habt nur umbenannt und das Testen aus Build herausgezogen.“

Ja. Das ist eine faire Beschreibung.

Und genau das ist der Punkt. Wenn etwas einen eigenen Namen bekommt, bekommt es einen Owner, ein Budget und einen Platz im Plan. Wenn es eine Unteraufgabe bleibt, wird es gestrichen. Das ist kein technisches Argument, sondern ein organisatorisches. Und organisatorische Argumente entscheiden, ob eine Praxis den Kontakt mit einem echten Projekt überlebt.

Bitte baut daraus keine drei neuen Abteilungen

Plan-Build-Run ist in vielen Firmen zu drei Silos mit drei Chefs geworden. Anforderungen wurden über eine Mauer zu Build geworfen, und Build hat ein Release über eine Mauer zu Run geworfen. Wir haben fünfzehn Jahre und eine ganze DevOps-Bewegung gebraucht, um diese Mauern wieder abzureissen.

Baut sie nicht mit neuen Etiketten wieder auf. Specify-Generate-Verify-Operate ist ein Kreislauf in einem Team und kein neues Organigramm. Dieselben Leute sollten die Spezifikation schreiben, die Generierung laufen lassen, das Ergebnis prüfen und den Pager tragen. Eine eigene Verify-Abteilung wäre das schlechteste mögliche Ergebnis dieses Artikels.

Was du am Montag tun kannst

Wenn du das ausprobieren willst, ohne etwas umzubauen:

  1. Nimm ein Feature, das ansteht. Schreib es als System Use Case, bevor jemand Code schreibt. Hauptablauf, Alternativen, Nachbedingungen.
  2. Leg es ins Repository, neben den Code, in die Versionsverwaltung.
  3. Gib es einem Agenten zusammen mit euren Projektregeln und schau, was zurückkommt.
  4. Prüf das Ergebnis gegen den Use Case, nicht gegen deine Erinnerung an das Meeting.
  5. Wenn das Ergebnis falsch ist, frag zuerst, ob die Spezifikation falsch war. Korrigier die Spezifikation, dann generier neu.

Das ist ein Durchlauf. Aus einem ehrlichen Durchlauf lernst du mehr als aus jeder Beschreibung eines Frameworks, auch aus dieser hier.

Keep IT simple

Vier Phasen statt drei. Eine neue Phase, die wir immer gemacht, aber nie benannt haben. Und eine Verschiebung bei dem, was wir für wertvoll halten.

Mehr ist es nicht. Es ist keine Revolution, und ich wäre vorsichtig bei jedem, der es als solche verkauft. Es ist eine kleine Korrektur an einem Modell, das uns gute Dienste geleistet hat und jetzt eine Box mehr braucht.