Der Code kompiliert, läuft sauber durch – und trifft trotzdem die falsche fachliche Annahme.

Du gibst dem Coding Agent eine präzise Aufgabe. Er liefert in Minuten: lesbar, idiomatisch, mit Tests. Beim Review fällt es dann auf. Die Rabattlogik rechnet auf den Bruttopreis statt auf den Nettopreis. Der Status-Übergang erlaubt einen Sprung, den es in deiner Domäne nie geben dürfte. Nichts davon ist ein Syntaxfehler. Es ist schlechtes Verständnis – in gutem Code verpackt.

Das Modell kennt deine Sprache nicht – nur Wahrscheinlichkeiten

Ein LLM sagt das nächste Token voraus. Es hat Millionen Codebasen gesehen und weiß, wie eine plausible Lösung aussieht. Was es nicht weiß: was in deiner Domäne wahr ist. Wo eine Bestellung verbindlich wird. Welche Invariante niemals verletzt werden darf. Warum ein „Kunde“ in eurem Vertrieb etwas anderes ist als ein „Kunde“ in eurer Buchhaltung.

Genau hier entsteht der Fehler. Das Modell füllt die Lücke mit dem statistisch Naheliegenden – nicht mit dem fachlich Richtigen. Das Ergebnis wirkt kompetent, weil die Oberfläche stimmt. Plausibilität und Korrektheit fallen bei generiertem Code auseinander, und plausibler Code ist schwerer zu entlarven als offensichtlich kaputter.

Die übliche Reaktion: längere Prompts, mehr Kontext, präzisere Anweisungen. Das verschiebt das Problem, löst es aber nicht. Denn die Frage ist nicht, wie du die Domäne besser beschreibst. Die Frage ist, ob du sie überhaupt verstanden und festgehalten hast – in einer Form, die maschinenlesbar ist.

Modellierung ist kein Vorbau – sie ist der Input

Lange galt Modellierung als die Phase vor dem Coden: Diagramme zeichnen, Stories schreiben, dann anfangen. In der Welt der Coding Agents kehrt sich das Verhältnis um. Das Modell ist nicht mehr die Vorbereitung auf den Code – es ist das Material, aus dem der Code entsteht.

Ein LLM scheitert nicht an mangelnder Intelligenz. Es scheitert daran, dass deine Domäne nirgends in einer Form steht, die es verarbeiten kann.

Damit wird Modellierung zur eigentlichen Hebelstelle. Eine unscharfe Domäne erzeugt unscharfen Kontext, und unscharfer Kontext erzeugt fachlich falschen Code – nur eben schnell und in großen Mengen. Wer den Output verbessern will, muss am Input arbeiten. Und der Input ist das Modell.

Vier Ebenen, auf denen Modellierung den KI-Output bestimmt

Die Domäne sichtbar machen, bevor du sie beschreibst

Bevor ein Modell präzise sein kann, muss das Team überhaupt dasselbe meinen. In den meisten Architekturdiskussionen passiert das nicht: Es entstehen Diagramme und Dokumente, aber kein geteiltes Verständnis von Verantwortlichkeiten, Grenzen und Randbedingungen. Annahmen bleiben implizit – bis sie später als Designkonflikt oder teure Nacharbeit auftauchen.

Architectural Roleplay dreht den Ansatz um: Statt ein System von außen zu beschreiben, übernehmen die Teilnehmenden Rollen in einem konkreten Szenario und spielen den Ablauf durch. Wer handelt, wer entscheidet, welche Information wird gebraucht, wo wird übergeben? Durch das Nachspielen werden widersprüchliche Zuständigkeiten und fehlende Entscheidungen früh sichtbar – an einer Stelle, an der sie sich noch billig korrigieren lassen.

Du nimmst eine Moderationstechnik mit, die verborgene Annahmen aufdeckt, bevor sie sich in Code verfestigen.

→ Architektur erleben statt nur beschreiben mit Stefan Priebsch

Die Modellierungs-Diskussion auf der richtigen Flughöhe halten

Collaborative-Modelling-Workshops sollen gemeinsames Verständnis schaffen. Oft passiert das Gegenteil: Business spricht über Ziele, Architektur über Strukturen, Entwicklung über Details – alle erleben dieselbe Diskussion, aber niemand versteht dasselbe. Angelehnt an Gregor Hohpes Architect Elevator geht es darum, Abstraktionsebenen bewusst wahrzunehmen und gezielt zu wechseln: hochziehen, runterbrechen, übersetzen, stoppen.

Das ist heute relevanter als je zuvor. Workshop-Ergebnisse landen nicht mehr nur in Tickets und Dokumentation, sondern werden zum Kontext für Coding Agents. Was im Raum unklar bleibt, verschwindet nicht – es wird weiterverarbeitet und verstärkt. Unschärfe in der Diskussion wird zu Unschärfe im Code.

Du lernst, Kommunikationsbrüche im Moment zu erkennen und Gespräche bewusst zwischen den Ebenen zu bewegen – damit das, was am Ende als Kontext bei der KI ankommt, tatsächlich trägt.

→  Riding the Elevator in Collaborative Modelling Workshops mit Beija Nigl

Modellierungs-Artefakte in LLM-Input verwandeln

Die meisten Teams haben LLM-Code bereits ausprobiert – mit dem bekannten Ergebnis: syntaktisch plausibel, fachlich falsch, schwer zu debuggen. Die These dieses Workshops: Die Antwort liegt in Methoden, die Architekt:innen längst kennen. Domain Storytelling und EventStorming erzeugen nicht nur gemeinsames Verständnis, sondern präzise Artefakte – und genau die erweisen sich als außerordentlich wirksamer LLM-Input.

Hands-on durchläufst du die volle Pipeline: Domain Story und Visual Glossary, Prototyp, EventStorming, OpenAPI- und AsyncAPI-Spezifikation. Jeder Modellierungsschritt schärft die fachliche Sprache, und eine schärfere Sprache erzeugt besseren Output. Der Effekt kehrt sich sogar um: Das LLM macht Workshop-Ergebnisse sofort testbar – die Distanz zwischen Modell und Feedback schrumpft von Wochen auf Minuten.

Du nimmst eine Methode mit, die deine Modellierung direkt in maschinenlesbaren Kontext übersetzt – ohne dass du den Prompt von Hand schreiben musst.

→ DDD trifft LLM mit Dr. Annegret Junker und Ferdinand Ade

Das Modell zur ausführbaren Spezifikation machen

Viele Projekte scheitern, lange bevor jemand Code schreibt: Anforderungen sind unklar, Architektur entsteht zu spät, das Team iteriert sich zu dem hin, was vorab hätte stehen müssen. Event Modeling setzt früher an und zerlegt ein System in kleine, in sich geschlossene „Slices“ – modulare Bausteine, die zugleich Architektur-Blueprint und Spezifikation sind.

Diese Slices sind die Grundlage für Spec-Driven Development: Das Modell wird zur einen Quelle der Wahrheit, geteilt zwischen Fachbereich und Engineering. Und es bleibt nicht beim Diagramm. Die Spezifikationen lassen sich direkt an KI-Tools übergeben, die daraus lauffähige Implementierungen erzeugen. Statt die KI mit vager Absicht zu prompten, gibst du ihr ein präzises, mit den Stakeholdern erarbeitetes Modell.

Du nimmst eine wiederholbare Methode mit, die den Weg von der Idee über das Modell bis zur KI-gestützten Implementierung durchgängig macht.

→  From Idea to Architecture: Spec-Driven Development mit Martin Dilger

Was du heute tun kannst

• Nimm dir einen LLM-Fehler aus der letzten Woche und frage nicht „Wie hätte der Prompt besser sein müssen?“, sondern „Welche Domänenregel stand nirgends explizit?“ – das deckt die echte Lücke auf.
• Schreib für einen kleinen Bounded Context die Kern-Invarianten in klare Sätze: was immer gelten muss, was nie passieren darf. Genau dieser Text ist besserer KI-Kontext als jede Prompt-Optimierung.
• Bevor das nächste Feature an einen Agenten geht: zeichne den fachlichen Ablauf einmal als Ereigniskette (wer löst was aus, was ist das Ergebnis). Übergib diese Kette als Kontext – und vergleiche den Output mit dem ohne.

Fazit

Bessere KI-Ergebnisse kommen nicht von besseren Prompts, sondern von besseren Modellen. Die Disziplinen, die Architekt:innen ohnehin beherrschen – gemeinsame Modellierung, saubere Domänensprache, präzise Spezifikation – sind in der Welt der Coding Agents von der Vorarbeit zum eigentlichen Produktionsfaktor geworden.

Wer die Domäne nicht modelliert, überlässt sie dem Modell. Und das rät – schnell, selbstbewusst und falsch.

Wer diese vier Ebenen – Domäne sichtbar machen, sauber kommunizieren, in LLM-Input übersetzen, zur ausführbaren Spec verdichten – hands-on vertiefen will: Die Workshops von Stefan Priebsch, Beija Nigl, Annegret Junker mit Ferdinand Ade und Martin Dilger beim Software Architecture Summit in Berlin arbeiten genau daran.

Key Takeaways

• LLMs erzeugen plausiblen, aber fachlich falschen Code, weil ihnen die Domäne fehlt – nicht die Intelligenz.
• Längere Prompts verschieben das Problem; den Hebel hast du beim Modell, nicht beim Prompt.
• Modellierung ist nicht mehr Vorarbeit, sondern der Input, aus dem KI-Code entsteht.
• Domain Storytelling, EventStorming und Event Modeling produzieren genau die präzisen Artefakte, die ein LLM verarbeiten kann.
• Unschärfe im Workshop wird zu Unschärfe im Code – Klarheit in der Kommunikation ist eine technische Größe geworden.