Die Lücke hat sich umgekehrt

Delphi. Menschen reisten wochenlang um herauszufinden, was sie tun sollten. Entscheiden war schon immer der langsame Teil.

Warum Spezifikationen heute wichtiger sind denn je

Teil der Serie Domain-Driven Design Meets AI.

Der erste Beitrag dieser Serie hat den Synergetic Blueprint als den roten Faden vorgestellt, der die Methoden des DDD zu einem durchgängigen Prozess verbindet, und argumentiert, dass KI diesen Prozess nicht ersetzt, sondern seinen Anspruch in der Praxis erst einlösbar macht. Five Principles for AI-Assisted DDD hat anschließend die Spielregeln festgelegt, darunter jene, auf der dieser Beitrag aufbaut: Artefakte sind Prompts.

Dieser Beitrag tritt einen Schritt hinter die einzelnen Techniken zurück und stellt eine unbequemere Frage. Warum ist das alles heute wichtiger als noch vor fünf Jahren?

Das haben wir in den 1950er-Jahren geklärt

Wenn jemand ankündigen würde, ein Softwaresystem ganz ohne Spezifikation zu bauen, würde man das für einen Scherz halten. Wir wissen seit den 1950er-Jahren, dass man spezifizieren muss, was ein System tun soll, bevor man etwas Brauchbares bauen kann. Benington hat es 1956 beschrieben (Benington, 1956). Royce hat es 1970 noch einmal verstärkt (Royce, 1970). Es ist eine der wenigen Fragen, die unsere Disziplin früh geklärt hat.

Dann kam Vibe Coding (Karpathy, 2025), und für einen Moment sah es so aus, als hätten wir das alles vergessen.

Ich glaube nicht, dass wir es vergessen haben. Darunter hat sich etwas verschoben, und die alten Gewohnheiten passten nicht mehr zur neuen Form.

Früher war die Lücke groß

Zwischen Discovery, also der Arbeit herauszufinden, was gebaut werden soll, und Delivery, also der Arbeit, es vor die Nutzer zu bringen, lag immer eine Lücke.

Jahrzehntelang wurde sie in Monaten gemessen. Wir haben ein System spezifiziert und es dann ein Jahr lang gebaut. Selbst 2019 brauchten die langsamsten Organisationen in den DORA-Daten noch ein bis sechs Monate, um eine einzige Änderung in Produktion zu bringen (DORA and Google Cloud, 2019). Was wir in der Discovery gelernt hatten, war veraltet, bevor es jemand nutzen konnte.

Agile hat sie verkleinert (Beck et al., 2001). Lauffähige Software alle paar Wochen. Dann Continuous Delivery, in Tagen (Humble & Farley, 2010). Dann die besten Teams, die auf Abruf deployen, mit einer Lead Time unter einem Tag (DORA and Google Cloud, 2019; Forsgren et al., 2018). Für eine kurze, angenehme Zeit liefen Discovery und Delivery ungefähr gleich schnell. Man konnte am Dienstag etwas lernen und es am Donnerstag ausliefern.

Mit KI-gestützter Programmierung wurde die Lücke nicht weiter kleiner. Sie hat sich umgekehrt.

Zwei Kurven mit unterschiedlichen Untergrenzen

Hier dreht sich das Argument, deshalb lohnt es sich, den Mechanismus genau zu benennen, statt auf einen Benchmark zu zeigen.

Die Delivery-Zeit ist durch Maschinendurchsatz begrenzt. Kompilieren, testen, deployen und jetzt generieren. Jeder dieser Kostenblöcke wird kleiner seit dreißig Jahren, und der letzte am schnellsten (CircleCI, 2026). Von Quartalsreleases zu Deployment auf Abruf ist keine moderate Verbesserung. Es sind vier oder fünf Größenordnungen, und die Untergrenze darunter liegt nahe null.

Die Discovery-Zeit ist durch etwas ganz anderes begrenzt: wie viele Menschen sich einig werden müssen, wie lange sie brauchen, um ein gemeinsames Verständnis aufzubauen, und wann sie alle Zeit haben. Diese Kosten bestimmen menschliche Kognition und Kalender.

Discovery ist schneller geworden. Collaborative Modeling hat sie schneller gemacht, und genau dafür wurde es erfunden. Aus einer dreiwöchigen Spezifikationsphase wurde ein zweitägiger Workshop. Nennen wir es fünf- oder zehnmal besser. Das ist ein echter Gewinn.

Aber es ist eine lineare Verbesserung gegen eine exponentielle, und die beiden Kurven haben unterschiedliche Untergrenzen.

Die Untergrenze von Delivery geht gegen null. Die Untergrenze von Discovery ist die Zeit, die eine Gruppe von Menschen braucht, um sich über etwas Kompliziertes wirklich einig zu werden, und diese Zahl hat sich kaum bewegt und wird sich auch nicht bewegen. Diese Kurven schneiden sich. In welchem Jahr sie sich geschnitten haben, darüber kann man streiten. Dass sie sich geschnitten haben, nicht.

Brooks hat uns 1987 gesagt, dass die Entscheidung, was gebaut werden soll, der schwere Teil ist (Brooks, 1987). Daran hat sich nichts geändert. Geändert hat sich, dass es jetzt auch der langsame Teil ist.

„Aber KI beschleunigt doch auch die Discovery“

Das ist der stärkste Einwand gegen dieses Argument, und er hat zum Teil recht. Ein Modell kann Interviewnotizen verdichten, eine mögliche Struktur vorschlagen, den Optionsraum aufspannen, das Diagramm entwerfen und in Sekunden ein erstes Glossar liefern. Der erste Beitrag dieser Serie hat genau das argumentiert: KI verkürzt den Kaltstart, und auf einen Entwurf zu reagieren fällt leichter, als auf ein leeres Board zu starren.

Man muss allerdings hinsehen, was da beschleunigt wird. Das Aufschreiben war nie der Engpass. Kein Projekt der Geschichte war zu spät, weil das Abtippen des Modells zu lange gedauert hat.

Der Engpass ist die Einigung. Es geht darum, sechs Menschen dazu zu bringen, unter „ausgeliefert“ dasselbe zu verstehen. Ein Modell liefert in Sekunden einen Entwurf, aber es kann nicht dafür sorgen, dass die Leiterin Betrieb und der Leiter Buchhaltung voreinander merken, dass sie dieses Wort seit zwei Jahren unterschiedlich verwenden. Das passiert in einem Raum, im menschlichen Tempo, und es ist der Teil, der darüber entscheidet, ob die Software richtig ist.

KI macht die billige Hälfte der Discovery billiger. Die teure Hälfte bleibt unberührt.

Wenn Delivery nicht mehr der Engpass ist, entscheidet Discovery

Das ist ein unbequemer Schluss für eine Disziplin, die vierzig Jahre lang das andere Ende der Kette optimiert hat. Wenn Code billig ist, hängt die Qualität unserer Software fast vollständig von der Qualität unseres Verständnisses ab. Wer das Falsche schnell baut, ist nur früher am falschen Ort angekommen.

Deshalb ist Collaborative Modeling heute wichtiger als zu der Zeit, in der es erfunden wurde, und ich meine die ganze Familie. Domain Storytelling (Hofer & Schwentner, 2021), EventStorming (Brandolini, 2013), Event Modeling (Dilger, 2024; Dymitruk, 2019), Example Mapping (Adzic, 2011; Wynne, 2015), das Visual Glossary (Zörner, 2021) und die übrigen Artefakte, die der Blueprint zusammenhält. Sie unterscheiden sich in der Notation, in der Granularität und darin, was sie in den Mittelpunkt stellen, und man wählt nach dem Problem aus, das gerade vor einem liegt. Gemeinsam ist ihnen das, worauf es hier ankommt: Sie bringen eine Gruppe von Menschen dazu, gemeinsam eine explizite und präzise Beschreibung davon zu erzeugen, wie ein Geschäft tatsächlich funktioniert.

Dieses Ergebnis ist kein Bild, das man einmal malt und dann auf einem Miro-Board liegen lässt. Es ist eine Spezifikation. Sie sagt, was passiert, in welcher Reihenfolge, wer es auslöst und was das System danach anzeigt. Präzise genug, dass Menschen sich darauf einigen können, und präzise genug, dass eine Maschine daraus bauen kann.

Diese zweite Eigenschaft war früher ein netter Nebeneffekt. Jetzt ist sie der eigentliche Punkt. Genau das meint auch das dritte Prinzip, wenn es sagt: Artefakte sind Prompts. Die Qualität dessen, was die KI liefert, ist durch die Qualität dessen begrenzt, was man ihr gibt, und die Artefakte des Collaborative Modeling sind genau diese Eingabe.

Was LLMs wirklich fehlt

LLMs scheitern an fachlicher Arbeit nicht, weil sie nicht „intelligent“ wären. Sie scheitern, weil sie keinen Zugang zur Domäne haben.

Die Regeln, die darüber entscheiden, ob eine Software richtig ist, stehen selten im Code und fast nie im Internet. Sie stecken in den Köpfen der Menschen, die das Geschäft seit Jahren Probleme bearbeiten und wissen, wie man damit umgeht (meistens sogar an der Software vorbei, die sie dafür benutzen). Sie stecken im Dauerstreit zwischen Betrieb und Buchhaltung. Sie stecken in der Ausnahme, die nur im Dezember vorkommt. Ein Modell, dem man das nicht gesagt hat, produziert plausiblen Code, der auf eine Weise falsch ist, die niemand bemerkt, bis er in Produktion läuft. From Stories to Code hat durchgespielt, wie das in der Praxis aussieht und was sich ändert, sobald die fachlichen Artefakte im Prompt stehen.

Die Lösung ist kein längerer Prompt. Es ist ein gemeinsames, explizites Modell der Domäne, das Team und Maschine lesen können. Collaborative Modeling war immer sinnvoll, weil es Menschen zu einer Einigung bringt. Jetzt hat es eine zweite Aufgabe: Es ist der Kanal, über den die Domäne die Werkzeuge erreicht, die den Code schreiben. Welche Technik man auch wählt, das Ergebnis muss explizit genug sein, dass es jemand versteht, der nicht im Raum war. Und eine Maschine war nie im Raum.

Wir waren nie verrückt, auf Spezifikation zu bestehen. Wir waren nur langsam darin, und Delivery war langsam genug, dass die Kosten verborgen blieben. Diese Ausrede gibt es nicht mehr.

Als Nächstes in dieser Serie: Die verborgene Grenze zwischen strategischem und taktischem Design — der Punkt im Blueprint, an dem das Erheben aufhört und das Bauen beginnt, an dem der primäre Drafter vom Menschen zur Maschine wechselt und an dem eine misslungene Übergabe am teuersten zu korrigieren ist.

Diese Serie ist aus meiner Arbeit am Buch DDD Meets AI entstanden, das im Februar 2027 bei Springer Nature erscheint.

---

Referenzen

References

Adzic, G. (2011). Specification by example: How successful teams deliver the right software. Manning Publications.

Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development. https://agilemanifesto.org/.

Benington, H. D. (1956). Production of large computer programs. Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, 15–27.

Brandolini, A. (2013). EventStorming. https://www.eventstorming.org. https://www.eventstorming.org

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

CircleCI. (2026). The 2026 state of software delivery. CircleCI. https://circleci.com/landing-pages/assets/2026-state-of-software-delivery-report.pdf

Dilger, M. (2024). Understanding Eventsourcing: Planning and implementing scalable systems with Eventmodeling and Eventsourcing (p. 500). Independently Published. https://leanpub.com/eventmodeling-and-eventsourcing

DORA and Google Cloud. (2019). Accelerate: State of DevOps 2019. DORA / Google Cloud. https://dora.dev/research/2019/dora-report/2019-dora-accelerate-state-of-devops-report.pdf

Dymitruk, A. (2019). Event modeling: What is it? eventmodeling.org. https://eventmodeling.org/posts/what-is-event-modeling/

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. Building and scaling high performing technology organizations. IT Revolution Press.

Hofer, S., & Schwentner, H. (2021). Domain storytelling: A collaborative, visual, and agile way to build domain-driven software (1st ed., p. 288). Addison-Wesley.

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley.

Karpathy, A. (2025). There’s a new kind of coding I call “vibe coding”. Post on X (formerly Twitter), @karpathy. https://x.com/karpathy/status/1886192184808149383

Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON, 26, 1–9.

Wynne, M. (2015). Introducing example mapping. Cucumber blog.

Zörner, S. (2021). Software-architekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten (3rd ed., p. 309). Carl Hanser Verlag.