Teil der Serie Domain-Driven Design Meets AI.
Der vorherige Beitrag, KI als Design-Partner — Entwerfer, Prüfer, Kritiker, hat gezeigt, dass KI innerhalb des Synergetic Blueprint drei Rollen einnimmt — Entwerfer, Prüfer, Kritiker — und dass dies Positionen sind, keine Akteure. Während der Blueprint fortschreitet, bleiben die Rollen unverändert, während wechselt, wer sie ausfüllt: Menschen entwerfen ganz oben, wo das Neue entsteht, KI entwirft im taktischen Design, wo der Kontext reichhaltig genug ist, um verlässlich zu sein, und an der Grenze dazwischen wechselt der Akteur.
Die Rolle zu benennen sagt dir, was du von der Ausgabe einer KI erwarten kannst. Es sagt dir aber noch nicht, wie du diese Ausgabe sicher nutzt — wann du ihr vertraust, wann du sie hinterfragst und wie du die Menschen, die das Domänenwissen besitzen, fest in der Kontrolle hältst. Genau das ist die Aufgabe der fünf Prinzipien in diesem Beitrag. Sie sind die Spielregeln für KI-gestützte Modellierungs- und Coding-Sitzungen: wie wir KI prompten, was wir zurückerwarten und wie wir ihre Ausgabe in unsere Artefakte einfließen lassen.
Warum überhaupt Prinzipien?
Weil KI Dinge überzeugend falsch macht.
Eine KI ist weder ein Verstand noch eine Datenbank. Sie ist ein statistisches Modell ihrer Trainingsdaten — sie erfasst die Muster in einem großen Korpus und erzeugt Text, indem sie vorhersagt, was als Nächstes kommt (Zhao et al., 2023). Sie modelliert die Verteilung dieser Daten, nicht die Wahrheit; wenn die Daten zu einem Thema unzureichend sind, erzeugt das Modell trotzdem eine selbstbewusste Antwort, die die Daten gar nicht stützen. Sie kann Statistiken erfinden, Studien zitieren, die nie veröffentlicht wurden, oder eine echte Quelle falsch wiedergeben. Forschende sind sich nicht einmal einig, ob das behebbar ist: Eine Forschungsrichtung argumentiert, Halluzinationen seien prinzipiell vermeidbar (Kalai et al., 2025), eine andere, sie seien eine innewohnende, mathematisch unvermeidliche Beschränkung (Xu et al., 2024). Vermeidbar oder nicht — es passiert, und jede Praxis, die KI in einen Designprozess einbindet, muss davon ausgehen, dass es passieren wird.
Diese eine Tatsache ist es, gegen die die übrigen Prinzipien absichern. Sie ist auch der Grund, warum KI am richtigen Ort so nützlich ist. Softwaredesign braucht zwei Arten von Arbeit: formalisierte Arbeit, etwa die Implementierung einer gut spezifizierten Schnittstelle in YAML, und kreative Arbeit, etwa den Entwurf einer neuen Anwendung rund um eine neue Geschäftsidee. Übergib der KI die formalisierte Arbeit, und sie ist ein Beschleuniger. Verlange von ihr, die kreative Arbeit hervorzubringen, und du wirst enttäuscht — sie kann nicht über das hinausreichen, was ihr Training erfasst hat. Diese Arbeitsteilung gut hinzubekommen, genau dafür sind die Prinzipien da. Und dieser Bedarf an Orientierung ist nichts KI-Spezifisches; er gilt auch für die Zusammenarbeit zwischen Menschen.
Die fünf Prinzipien auf einen Blick
1. KI macht Dinge überzeugend falsch. Grundlegende Vorsicht. KI-Ausgaben sind ihrer Konstruktion nach plausibel und nur dann korrekt, wenn sie sich zufällig mit der Trainingsverteilung decken. Behandle Eloquenz nicht als Beleg für Wahrheit.
2. Expert:innen zuerst. Die Quelle der Wahrheit für eine Domäne liegt in Menschen, nicht in Prompts. KI kann helfen, Domänenwissen zugänglich zu machen und zu ordnen; sie kann die Expert:innen, die es besitzen, nicht ersetzen. Binde sie vom ersten Gespräch an ein und behalte sie als diejenigen, die validieren, ob ein Design tatsächlich Sinn ergibt.
3. Artefakte sind Prompts. Jedes Artefakt, das der Blueprint hervorbringt — Domain Story, Visual Glossary, EventStorming-Board, API Product Canvas — ist nicht nur ein Ergebnis menschlicher Zusammenarbeit, sondern auch eine Eingabe für die KI. Die Qualität der Ausgabe ist proportional zur Qualität der Eingabe. Genau das formalisiert Spec-Driven Development, und das Commitment-Level eines Artefakts sagt dir, wie weit du dem vertrauen kannst, was die KI daraus erzeugt.
4. Validieren, bevor du weitergibst. Kein Artefakt fließt im Blueprint in das nächste ein, bevor ein Mensch mit Domänenwissen es geprüft hat. Das ist das Human-in-the-Loop-Prinzip, und es muss zwei gegensätzliche Fehlermodi ausbalancieren: die Junior-Person, die KI-Ausgaben überzogen vertraut, und die Senior-Person, die ihnen reflexhaft zu wenig vertraut.
5. Der Advocatus Diaboli im Raum. Zusammenarbeit bedeutet, dass jemand Widerspruch leisten muss. Der Provocateur hinterfragt Annahmen mittendrin, solange Entscheidungen noch formbar sind — und das kann ein Mensch oder eine KI sein, aber niemals als letzte Instanz. Welcher Akteur die Rolle ausfüllt, wechselt entlang des Blueprint: KI provoziert die menschlich geführte Vision im strategischen Design; der Mensch provoziert die Entwürfe der KI im taktischen Design.
Das ist keine Checkliste, die man der Reihe nach abarbeitet. Die Prinzipien greifen ineinander und wiederholen sich in jedem Schritt — „Validieren, bevor du weitergibst” gilt überall dort, wo KI etwas erzeugt; „Der Advocatus Diaboli im Raum” gilt überall dort, wo es einen Vorschlag zu hinterfragen gibt, wer ihn auch immer gemacht hat. Der Rest dieses Beitrags diskutiert die Prinzipien im Einzelnen.
Expert:innen zuerst
Um Software zu entwerfen, musst du die Problemdomäne und die Bedürfnisse der Nutzer:innen verstehen. Dieses Wissen lebt in Menschen, nicht in Prompts. KI kann dir helfen, darauf zuzugreifen und es zu ordnen, aber sie kann die Expert:innen, die es besitzen, nicht ersetzen.
Deshalb kommen die Domänenexpert:innen immer zuerst. Sie sind von Beginn des Designprozesses an beteiligt, und das Design entsteht, indem man ihnen zuhört. Sie sind die Quelle der Wahrheit für die Problemdomäne und diejenigen, die validieren können, ob ein Design tatsächlich Sinn ergibt. Wir haben das im vorherigen Beitrag gesehen, und es wiederholt sich in jedem Schritt des Blueprint.
Hier findet auch die folgenreichste Übergabe des gesamten Prozesses statt. Der Übergang von der strategischen zur taktischen Ebene des Synergetic Blueprint ist der Moment, in dem der Akteur, der den primären Entwerfer spielt, von einem Menschen zu einer KI wechselt. Vor dem Übergang wird Expertise erhoben und geformt — Arbeit, die nur Menschen leisten können. Danach ist Expertise in Artefakten festgehalten, die reichhaltig genug sind, damit die KI verlässlich daraus entwerfen kann. „Expert:innen zuerst” ist es, was diesen Übergang sicher macht: Die KI übernimmt das Entwerfen erst, wenn die Expert:innen bereits genug von sich in die Artefakte eingebracht haben.
Artefakte sind Prompts
Im ersten Beitrag dieser Serie haben wir den Synergetic Blueprint als eine Sammlung von Artefakten eingeführt, die unser Verständnis der Problemdomäne und unsere Designentscheidungen festhalten. Diese Artefakte sind nicht nur Ergebnisse des Designprozesses; sie sind auch Eingaben für unsere KI-Mitarbeitenden.
Die Qualität der Ausgabe, die du von einer KI erhältst, ist proportional zur Qualität der Eingabe, die du ihr gibst (Brown et al., 2020; Wei et al., 2022). Ein Prompt ist nicht bloß eine Frage — er ist ein kognitiver Rahmen. Seine Struktur, seine Genauigkeit und der eingebettete Kontext bestimmen, welche der latenten Fähigkeiten des Modells zum Vorschein kommen und welche unzugänglich bleiben. So betrachtet ist Prompt-Design weniger eine Frage der Bequemlichkeit als ein Akt bewusster Wissensübertragung.
Wir erzeugen diese Artefakte in menschlicher Zusammenarbeit — in Workshop-Formaten wie EventStorming (Brandolini, 2013) oder in Eins-zu-eins-Gesprächen mit Domänenexpert:innen (Evans, 2003). Und die Artefakte, die wir dort erzeugen, sind die Prompts für die KI:
- Eine gut strukturierte Domain Story (Hofer & Schwentner, 2021) ermöglicht es der KI, gute Event-Vorschläge für eine EventStorming-Sitzung zu erzeugen.
- Ein klares Visual Glossary (Zörner, 2021) ermöglicht es ihr, akkurate Code-Snippets für das Domänenmodell zu erzeugen.
- Ein detailliertes API Product Canvas (Junker & Lazzaretti, 2025) ermöglicht es ihr, eine präzise API-Spezifikation zu erzeugen.
Genau diese Beziehung — Artefakte als Prompts — formalisiert Spec-Driven Development.
Spec-Driven Development
Bei Spec-Driven Development (SDD) beginnst du mit einer Spezifikation, statt erst zu coden und später die Doku zu schreiben (Böckeler, 2025). Ein KI-Coding-Agent erhebt Anforderungen und schreibt Spezifikationen, bevor überhaupt Code geschrieben wird. Die Spezifikation ist ein Vertrag darüber, wie sich der Code verhalten soll, und sie wird zur Quelle der Wahrheit: Agenten nutzen sie, um Code zu erzeugen, zu testen und zu validieren (Delimarsky, 2025; Tessl, 2025).
Die Artefakte des Synergetic Blueprint — Domain Stories (Hofer & Schwentner, 2021), EventStorming-Maps (Brandolini, 2013), Visual Glossaries (Zörner, 2021), API Product Canvases (Junker & Lazzaretti, 2025), User Stories (Cohn, 2004) — sind die Prompts für die KI-Rollen. Wenn die KI der Kritiker ist, ist die Domain Story der Prompt, um sie gegen die bereits entlang des Blueprint erzeugten Artefakte zu prüfen. Wenn die KI der Entwerfer ist, ist das API Product Canvas der Prompt, um eine OpenAPI-Spezifikation zu erzeugen. Die meisten Frameworks für KI-gestütztes Design und Entwicklung, SDD darunter, folgen genau diesem Muster.
Spec-Commitment-Level
Nicht jede Spezifikation hat dasselbe Gewicht. SDD unterscheidet drei Commitment-Level (Böckeler, 2025), und das Level, auf dem du dich befindest, bestimmt, wie viel Vertrauen du in die Ausgabe setzt, die die KI daraus erzeugt.
Spec-first — die Spezifikation wird für die erste Implementierung eines Features erstellt und dann verworfen, sobald das Feature ausgeliefert ist. Wenn sich das Feature später weiterentwickelt, wird eine neue Spezifikation geschrieben. Menschen und KI erstellen Spezifikation und Code gemeinsam, aber die Spezifikation wird nicht gepflegt.
Spec-anchored — die Spezifikation wird mit der ersten Implementierung erstellt und entwickelt sich dann mit ihr weiter. Sowohl Spezifikation als auch Code werden gemeinsam erstellt, und beide werden über die Zeit gepflegt.
Spec-as-source — die Spezifikation ist die Quelle der Wahrheit. Code wird aus ihr erzeugt, und die Spezifikation wird auch danach weiter gepflegt.
Entlang des Blueprint begegnen dir alle drei, und welches Level zutrifft, hängt meist davon ab, wie das Team das Artefakt nutzt:
- Spec-first passt zum Entdecken. User Stories (Cohn, 2004) sind oft einmalig. Während der Ideenfindung sind die North Star Metric (Ellis, 2017), der Business Plan (Osterwalder & Pigneur, 2010) und die Wardley Map (Wardley, 2022) spec-first: Man erkundet Optionen und legt sich erst fest, wenn Domänenexpert:innen und Stakeholder sie validiert haben.
- Spec-anchored umfasst die lebenden Artefakte: die Domain Story (Hofer & Schwentner, 2021), das Visual Glossary (Zörner, 2021), die EventStorming- (Brandolini, 2013) und Event-Modeling-Maps (Dilger, 2024) — und, im taktischen Design, die Context Map (Evans, 2003), die Example Map (Smart & Molak, 2023), das Bounded Context Canvas (DDD Crew, 2019), das Domänenmodell (Evans, 2003), das Architecture Communication Canvas (Starke & arc42 Contributors, 2023) und das API Product Canvas (Junker & Lazzaretti, 2025). Sie halten Verständnis und Designentscheidungen fest und entwickeln sich mit dem Code weiter, während beide reifen.
- Spec-as-source ist das Muster, dem man mit Vorsicht begegnen sollte. Wenn eine Spezifikation mehrdeutig, unvollständig oder im Fluss ist, verstärkt ihre Nutzung als Erzeugungs-Prompt jede Lücke — die KI erzeugt selbstbewusste Ausgaben aus einem unsicheren Vertrag. Das Muster ist nur dann tragfähig, wenn die Spezifikation eine Schwelle an Formalität und Stabilität überschreitet, die die meisten Dokumente nie erreichen (Emrich & Ade, 2026; Piskala, 2026).
Eine OpenAPI-Spezifikation (OpenAPI Initiative, 2024), die als veröffentlichte Schnittstelle eines Microservice dient, ist genau jenes seltene Artefakt, das sich spec-as-source verdient: vorschreibend statt beschreibend, maschinenlesbar statt Prosa und an der Grenze bewusst eingefroren. Veränderung breitet sich von ihr nach außen aus, nicht nach innen zu ihr hin.
Ein Punkt, der klar gesagt werden sollte: Selbst dort, wo eine OpenAPI-Spezifikation als spec-as-source qualifiziert, brauchst du selten einen KI-Agenten, um sie in Code zu verwandeln. Standard-Generatoren wie der OpenAPI Generator (OpenAPI Generator Contributors, 2026) erledigen das bereits zuverlässig und ohne Halluzinationsrisiko. Die Spezifikation bleibt der lebende Vertrag für den Bounded Context — keine statische Quelle, aus der ohne menschliche Beteiligung Code herbeigezaubert wird.
Prototypen sind der andere Spec-as-source-Fall: Sie verdichten die vorgelagerten Artefakte zu etwas, das konkret genug ist, um die Entscheidungen dahinter zu validieren (Junker, 2026).
Die Kernaussage gilt über den gesamten Blueprint: Je höher das Commitment-Level, desto höher der Einsatz und desto sorgfältiger muss die Ausgabe geprüft werden, bevor sie in deine Codebasis oder dein Design eingeht. Spec-first-Ausgaben erkundest und verwirfst du; spec-anchored-Ausgaben integrierst und pflegst du; spec-as-source-Ausgaben lieferst du aus. Artefakte als Prompts zu behandeln gibt der KI den Kontext, den sie braucht, um nützlich zu sein — aber auch eine gut geprompte KI erzeugt Ausgaben, die Muster in den Trainingsdaten widerspiegeln, nicht die Wahrheit über deine Domäne. Und genau deshalb muss als Nächstes etwas geschehen.
Validieren, bevor du weitergibst
Der Blueprint erzeugt eine Menge Artefakte — manche von Menschen, manche von KI, viele gemeinsam erstellt. Jedes einzelne sollte validiert werden, bevor es in das nächste nachgelagerte Artefakt einfließt (Boehm & Basili, 2001; Ford et al., 2021).
Wenn die KI ein Artefakt erzeugt, muss es ein Mensch validieren, der das Domänenwissen und die Designexpertise besitzt, um es gegen alles Vorgelagerte zu prüfen. KI modelliert die Verteilung, nicht die Wahrheit (Kalai et al., 2025; Xu et al., 2024) — und selbst eigens dafür gebaute Retrieval-Augmented-Generation-Werkzeuge halluzinieren in Domänen mit hohem Einsatz irgendwo zwischen 17 und 33 Prozent der Fälle (Magesh et al., 2025). Der Mensch mit Domänenwissen ist derjenige mit Zugang zur grundlegenden Wahrheit, die dem Modell strukturell fehlt.
Wenn Menschen ein Artefakt erzeugen, sollte es von anderen Menschen validiert werden (Perry et al., 2023) — und hier kann die KI den Platz des Kritikers einnehmen, Annahmen hinterfragen und Inkonsistenzen, Lücken und Widersprüche zutage fördern. Wenn beide es erzeugt haben, validiere mit anderen Menschen und mit anderen Methoden. Workshop-Artefakte etwa lassen sich durch Prototypen validieren, die aus den Workshop-Ergebnissen erzeugt werden (Junker, 2026).
Das ist das Human-in-the-Loop-Prinzip, und es ist älter als die KI. Es geht zurück auf Wieners Kybernetik, in der ein menschlicher Operator als Komponente innerhalb eines Rückkopplungsregelkreises behandelt wurde (Wiener, 1961); der Begriff „Human-in-the-Loop” ist ein direkter Nachkomme, populär geworden im maschinellen Lernen zur Beschreibung von Systemen, die um menschliches Feedback und Urteilsvermögen gebaut sind (Holzinger, 2016; Monarch, 2021). Das Prinzip verlangt ausgewogenes Vertrauen in KI-Ausgaben (Lazaros et al., 2026).
Was Validierung schwer macht, ist, dass Vertrauen in einem Team nicht gleichmäßig verteilt ist. Eine Junior-Entwickler:in neigt dazu, KI-Ausgaben übermäßig zu vertrauen — sie erfindet Erklärungen für unklare Vorschläge und hält an ihnen fest, selbst wenn sie spürt, dass etwas nicht stimmt (Buçinca et al., 2021). Eine Senior-Entwickler:in neigt dazu, ihnen zu wenig zu vertrauen. Ein guter Validierungsprozess mildert beides ab, mit klaren Kriterien für die Prüfung von Artefakten und einer Kultur des kritischen Denkens — etwa Pair- oder Mob-Programming (Emrich & Ade, 2026).
Validierung verhindert, dass sich Fehler und Missverständnisse den Blueprint hinab fortpflanzen, wo sie sonst zu technischen Schulden und Designfehlern erstarren würden. Sie ist kein einmaliges Tor, sondern eine fortlaufende Tätigkeit, die sich durch den gesamten Prozess zieht, während Artefakte erzeugt und verfeinert werden. Validierung ist nicht bloß Testen und auch nicht Kontrollieren. Sie ist Zusammenarbeit.
Der Advocatus Diaboli im Raum
Zusammenarbeit bedeutet, dass jemand Widerspruch leisten muss. Du brauchst einen Advocatus Diaboli, der die Annahmen und die Logik jedes Vorschlags hinterfragt — und der Wert davon ist kein Mythos: Gruppen, die die Technik einsetzen, treffen messbar bessere Entscheidungen und überdenken ihre eigenen Positionen bereitwilliger (Schweiger et al., 1986).
In einem Workshop kann eine Senior-Entwickler:in oder sogar der Moderator den Part übernehmen. Die Moderation tritt aus der Rolle der neutralen Beobachtung heraus und wird zur aktiven Teilnehmerin, benennt Risiken und drängt die Gruppe auf eine Entscheidung (Kelle et al., 2024). Wenn die KI die Rolle übernimmt, kann sie die Annahmen und die Logik eines Vorschlags genauso wirksam hinterfragen (Chiang et al., 2024) — mit einer harten Grenze: Die KI darf niemals zur Richterin werden. Wenn Menschen sich ihren Einschätzungen als Autorität beugen, statt Entscheidungen selbst zu bewerten, ist der Advocatus Diaboli klammheimlich zum Tyrannen geworden (Jong et al., 2025). Wer die Rolle auch ausfüllt — der Kritiker handelt mittendrin, solange Entscheidungen noch veränderbar sind, nicht erst, nachdem sie in das nächste Artefakt eingeflossen sind.
Hier wird die Rollenverteilung aus dem vorherigen Beitrag konkret, denn welcher Akteur den Kritiker spielt, wechselt entlang des Blueprint:
- Im strategischen Design führen Menschen als Entwerfer, und die primäre Rolle der KI ist die des Kritikers — sie hinterfragt eine Vision, die sie nicht selbst hervorbringen kann. Im Larder-Beispiel kann die KI eine North Star Metric von „Anzahl der geteilten Rezepte” unter die Lupe nehmen, indem sie fragt, wie sie mit den Geschäftszielen zusammenhängt und ob sie den Wert, der den Nutzer:innen geliefert wird, wirklich erfasst. (Die KI kann auch hier mit-entwerfen — etwa beim Erheben von Geschäftsanforderungen —, aber der Mensch bleibt der Urheber der Vision.)
- Im taktischen Design kehrt sich die Zuordnung um. Die KI wird zum Entwerfer; der Mensch nimmt den Platz des Kritikers ein, widerspricht den Entwürfen der KI und verlangt eine Begründung für jede Entscheidung. Ob ShoppingItem eine Entität innerhalb des ShoppingList-Aggregats ist oder ein Wertobjekt, das die Liste lediglich enthält, ist eine Domänenentscheidung, keine strukturelle — der Vorschlag der KI ist plausibel, und plausibel ist nicht dasselbe wie richtig.
Die Rolle bleibt dieselbe. Nur der Akteur wechselt.
Das Kernargument
Bring den Synergetic Blueprint mit diesen fünf Prinzipien und den Spec-Commitment-Leveln zusammen, und du erhältst etwas Nützlicheres als entweder „nutze KI für X” oder „KI ersetzt Y”. Du erhältst eine Disziplin, die sich gegen überzeugend falsche Ausgaben absichert und die echten Stärken der KI nutzt.
- KI macht Dinge überzeugend falsch ist die Vorsicht, der alles andere Rechnung trägt.
- Expert:innen zuerst hält die Quelle der Wahrheit bei den Menschen, die das Domänenwissen besitzen, denn KI kann dieses Wissen ordnen, aber niemals hervorbringen.
- Artefakte sind Prompts deutet jedes Artefakt als die Eingabe um, die die Ausgabe der KI formt — und das Commitment-Level sagt dir, ob du es erkundest, pflegst oder auslieferst.
- Validieren, bevor du weitergibst setzt einen domänenkundigen Menschen in die Schleife, bevor irgendetwas nachgelagert weiterfließt, und balanciert das Übervertrauen der Junior-Person gegen das Untervertrauen der Senior-Person aus.
- Der Advocatus Diaboli im Raum hält das Design ehrlich, indem der Kritiker Annahmen hinterfragt, solange sie noch formbar sind.
Die Prinzipien sind nicht auf einen einzelnen Schritt beschränkt. „Validieren, bevor du weitergibst” gilt überall dort, wo KI ein Artefakt erzeugt, auf jedem Commitment-Level. „Der Advocatus Diaboli im Raum” gilt überall dort, wo es einen Vorschlag zu hinterfragen gibt, gleich wer ihn gemacht hat. Sie greifen ineinander und wiederholen sich, und welcher Akteur welche Rolle ausfüllt, wechselt, während sich die Arbeit von der Ideenfindung zur laufenden Software bewegt.
Von hier an hört die Serie auf, über die Zusammenarbeit mit KI zu reden, und beginnt, sie zu tun — Schritt für Schritt entlang des Blueprint.
Als Nächstes in dieser Serie: North Star und Geschäftsplanung mit KI — dort, wo jedes Produkt beginnt: am entdeckenden Rand, bevor ein einziger Bounded Context gezeichnet wurde, wenn die Frage noch nicht „Wie bauen wir es?” lautet, sondern „Was bauen wir, und warum sollte es jemand wollen?“. Wir beginnen mit der North Star Metric und dem Geschäftsplan — den ersten Artefakten des Blueprint und klar spec-first: erkundet, hinterfragt und überarbeitet, lange bevor irgendetwas festgelegt wird.
Diese Serie ist aus meiner Arbeit am Buch DDD Meets AI entstanden, das demnächst bei Springer Nature erscheint.
References
Böckeler, B. (2025). Understanding spec-driven-development: Kiro, spec-kit, and Tessl. martinfowler.com, “Exploring Gen AI” series. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
Boehm, B., & Basili, V. R. (2001). Software defect reduction top 10 list. Computer, 34(1), 135–137. https://doi.org/10.1109/2.962984
Brandolini, A. (2013). EventStorming. https://www.eventstorming.org. https://www.eventstorming.org
Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D. M., Wu, J., Winter, C., … Amodei, D. (2020). Language models are few-shot learners. Advances in Neural Information Processing Systems, 33, 1877–1901.
Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To trust or to think: Cognitive forcing functions can reduce overreliance on AI in AI-assisted decision-making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1), 1–21. https://doi.org/10.1145/3449287
Chiang, C.-W., Lu, Z., Li, Z., & Yin, M. (2024). Enhancing AI-assisted group decision making through LLM-powered devil’s advocate. Proceedings of the 29th International Conference on Intelligent User Interfaces (IUI ’24), 103–119. https://doi.org/10.1145/3640543.3645199
Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley.
DDD Crew. (2019). Bounded context canvas. GitHub repository, ddd-crew/bounded-context-canvas. https://github.com/ddd-crew/bounded-context-canvas
Delimarsky, D. (2025). Spec-driven development with AI: Get started with a new open source toolkit. The GitHub Blog. https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
Dilger, M. (2024). Understanding Eventsourcing: Planning and implementing scalable systems with Eventmodeling and Eventsourcing (p. 500). Independently Published. https://leanpub.com/eventmodeling-and-eventsourcing
Ellis, S. (2017). What is a North Star Metric? GrowthHackers Blog. https://blog.growthhackers.com/what-is-a-north-star-metric-b31a8512923f
Emrich, M., & Ade, F. (2026). EXACT-Coding: Beyond vibe coding: AI-assisted development mit TDD und software craft. LeanPub. https://leanpub.com/exact-coding
Evans, E. (2003). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley.
Ford, N., Richards, M., Sadalage, P., & Dehghani, Z. (2021). Software architecture: The hard parts: Modern trade-off analyses for distributed architectures. O’Reilly Media.
Hofer, S., & Schwentner, H. (2021). Domain storytelling: A collaborative, visual, and agile way to build domain-driven software (1st ed., p. 288). Addison-Wesley.
Holzinger, A. (2016). Interactive machine learning for health informatics: When do we need the human-in-the-loop? Brain Informatics, 3(2), 119–131. https://doi.org/10.1007/s40708-016-0042-6
Jong, S. de, Moberg, R., & Berkel, N. van. (2025). Confirmation bias as a cognitive resource in LLM-supported deliberation. https://arxiv.org/abs/2509.14824
Junker, A. (2026). From domain story to prototype: Specification-driven prototyping in DDD workshops. codecentric AG knowledge hub, “Domain-Driven Design Meets AI” series. https://www.codecentric.de/en/knowledge-hub/blog/from-domain-story-to-prototype
Junker, A., & Lazzaretti, F. (2025). Crafting great APIs with Domain-Driven Design: Collaborative craftsmanship of asynchronous and synchronous APIs. Apress. https://doi.org/10.1007/979-8-8688-1457-0
Kalai, A. T., Nachum, O., Vempala, S. S., & Zhang, E. (2025). Why language models hallucinate. https://arxiv.org/abs/2509.04664
Kelle, E. van, Verschatse, G., & Baas-Schwegler, K. (2024). Collaborative software design: How to facilitate domain modeling decisions (p. 300). Manning Publications.
Lazaros, K., Vrahatis, A. G., & Kotsiantis, S. (2026). Human-in-the-loop artificial intelligence: A systematic review of concepts, methods, and applications. Entropy, 28(4), 377. https://doi.org/10.3390/e28040377
Magesh, V., Surani, F., Dahl, M., Suzgun, M., Manning, C. D., & Ho, D. E. (2025). Hallucination-free? Assessing the reliability of leading AI legal research tools. Journal of Empirical Legal Studies, 22(2), 216–242. https://doi.org/10.1111/jels.12413
Monarch, R. (Munro). (2021). Human-in-the-loop machine learning: Active learning and annotation for human-centered AI. Manning Publications.
OpenAPI Generator Contributors. (2026). Generators list. OpenAPI Generator documentation. https://openapi-generator.tech/docs/generators
OpenAPI Initiative. (2024). OpenAPI specification, version 3.1.1. Linux Foundation. https://spec.openapis.org/oas/v3.1.1.html
Osterwalder, A., & Pigneur, Y. (2010). Business model generation: A handbook for visionaries, game changers, and challengers (p. 288). John Wiley & Sons.
Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do users write more insecure code with AI assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS ’23). https://doi.org/10.1145/3576915.3623157
Piskala, D. B. (2026). Spec-driven development: From code to contract in the age of AI coding assistants. https://doi.org/10.48550/arXiv.2602.00180
Schweiger, D. M., Sandberg, W. R., & Ragan, J. W. (1986). Group approaches for improving strategic decision making: A comparative analysis of dialectical inquiry, devil’s advocacy, and consensus. Academy of Management Journal, 29(1), 51–71. https://doi.org/10.5465/255859
Smart, J. F., & Molak, J. (2023). BDD in action: Behavior-driven development for the whole software lifecycle (2nd ed., p. 488). Manning Publications.
Starke, G., & arc42 Contributors. (2023). Architecture communication canvas. arc42, canvas.arc42.org. https://canvas.arc42.org/
Tessl. (2025). Spec-driven development with tessl. Tessl documentation. https://docs.tessl.io/use/spec-driven-development-with-tessl
Wardley, S. (2022). Wardley maps: Topographical intelligence in business (M. Craddock, Ed.). LeanPub. https://leanpub.com/wardleymaps
Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., Chi, E., Le, Q., & Zhou, D. (2022). Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35, 24824–24837.
Wiener, N. (1961). Cybernetics: Or control and communication in the animal and the machine (2nd ed.). MIT Press.
Xu, Z., Jain, S., & Kankanhalli, M. (2024). Hallucination is inevitable: An innate limitation of large language models. https://arxiv.org/abs/2401.11817
Zhao, W. X., Zhou, K., Li, J., Tang, T., Wang, X., Hou, Y., Min, Y., Zhang, B., Zhang, J., Dong, Z., Du, Y., Yang, C., Chen, Y., Chen, Z., Jiang, J., Ren, R., Li, Y., Tang, X., Liu, Z., … Wen, J.-R. (2023). A survey of large language models. https://arxiv.org/abs/2303.18223
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.
