Warum sich Domänenwissen nicht extrahieren lässt

This blog post is also available in English

TL;DR

• KI-Ansätze wie BMAD gehen davon aus, dass Domänenwissen vollständig vorhanden ist und sich direkt extrahieren lässt.
• Die Kognitionswissenschaft zeigt jedoch, dass ein Großteil dieses Wissens implizit, sozial eingebettet und zeitabhängig entsteht.
• Strukturierte Interviews können diese Formen von Wissen nicht erfassen und verdrängen wichtige Erkenntnisprozesse.
• Bewährte Methoden setzen deshalb auf Iteration, gemeinsame Praxis und kontinuierliches Lernen statt auf einmalige Erhebung.
• Die zentrale Verschiebung besteht darin, dass sich der Mensch an die Maschine anpasst, nicht umgekehrt.

Dies ist der vierte Beitrag der Reihe „Developing with AI Through the Cognitive Lens“. Sie untersucht, wie KI-Werkzeuge beeinflussen, wie Entwickler:innen und Teams lernen, arbeiten und Expertise aufbauen. Auf Basis kognitionspsychologischer Forschung geht es darum, was passiert, wenn wir geistige Arbeit an KI delegieren. In diesem Beitrag weitet sich der Blick über das Programmieren hinaus auf das Requirements Engineering. Ziel der Reihe ist kein vorgefasstes Urteil über KI, sondern den kognitionswissenschaftlichen Befunden zu folgen, wohin sie führen. In diesem Fall führt das zu grundsätzlicher Skepsis gegenüber einer ganzen Klasse von Werkzeugen.

In den bisherigen Beiträgen ging es darum, was die Kognitionspsychologie über hilfreiche und problematische Einsatzweisen von KI beim Programmieren sagt. Programmieren ist jedoch nur ein Teil der Softwareentwicklung. Zunehmend werden KI-Agenten auch für die Erhebung von Anforderungen eingesetzt. Marketingversprechen für Tools wie BMAD sprechen davon, dass statt Wochen nur noch Stunden für Requirements Engineering nötig sind. Können BMAD und andere Werkzeuge für spezifikationsgetriebene Entwicklung etablierte Methoden zur Anforderungserhebung tatsächlich ersetzen? Die Kognitionspsychologie hat dazu einiges zu sagen.

Wie BMAD und andere SDD-Tools funktionieren

Tools wie BMAD versprechen, den Prozess des Requirements Engineering drastisch zu beschleunigen. Statt Wochen mit Workshops, Interviews und iterativer Verfeinerung führt ein KI-Agent Stakeholder durch einen strukturierten Erhebungsprozess und erstellt innerhalb weniger Stunden ein umfassendes Spezifikationsdokument. Buildmode.dev, einer der prominentesten Vertreter dieses Ansatzes, behauptet, die Anforderungserhebung zu reduzieren von „2–3 Wochen auf 6 Stunden“.

Der Ablauf beginnt meist mit einer Produktidee oder einer groben Vision. Ein KI-Agent, der die Rolle eines Business Analysts übernimmt (bei BMAD heißt er Mary), interviewt dann den Stakeholder oder die Domänenexpertin und stellt Fragen zu Nutzer:innen, Zielen, Randbedingungen und technischen Anforderungen. Aus den Antworten erzeugt er ein Spezifikationsdokument, das als Blaupause für die Implementierung dient. In ambitionierteren Setups wie BMAD zerlegen zusätzliche Agenten diese Spezifikation in Epics, Stories und Tasks, die wiederum eine weitere Schicht von Agenten umsetzt. Der Mensch wechselt vom Ausführen der Arbeit hin zum Liefern von Domänenwissen und zum Reviewen der Ergebnisse.

Das wirkt auf den ersten Blick attraktiv, insbesondere für alle, die schon in langwierigen Requirements-Workshops gesessen haben, deren Ergebnis vor allem aus Annahmen bestand, die als Entscheidungen formuliert wurden. Wenn ein Agent denselben Job schneller und strukturierter erledigt, warum sollte man ihn nicht einsetzen?

Das Extraktionsparadigma

Allen diesen Tools liegt eine implizite Annahme über die Natur von Domänenwissen zugrunde: Es befindet sich in den Köpfen von Stakeholdern und Expert und muss nur abgerufen werden. Die richtigen Fragen, in der richtigen Reihenfolge gestellt, bringen es ans Licht. Der Agent in der Rolle des Business Analysts agiert dabei wie ein besonders systematischer, geduldiger und konsequenter Interviewer. In dieser Logik folgt alles dem Paradigma der Extraktion: Wissen ist eine Ressource, die gefördert wird, der Mensch ist das Vorkommen.

Diese Annahme ist so tief im Workflow verankert, dass sie selten explizit gemacht wird. Gelegentlich passiert es doch. Der oben erwähnte Beitrag von Buildmode.dev beschreibt den eigenen Ansatz als Ersatz für „iterative discovery“. Dieser Begriff impliziert, dass Anforderungen sich über Zeit entwickeln, durch Feedback, Umsetzung und Lernen. Wer das ersetzen will, geht davon aus, dass das Wissen bereits vollständig vorhanden ist und nur effizient abgerufen werden muss.

Die meisten Tools bleiben an dieser Stelle stehen und behandeln den Menschen als unvollkommene, aber akzeptable Quelle. Einige gehen weiter. Ouroboros, ein Agent-Framework, dessen altes README unverblümt feststellte, dass „HUMANS ARE NOT RATIONAL“, zieht die nächste Konsequenz: Wenn Menschen nicht zuverlässig ausdrücken können, was sie wissen, liegt das Problem nicht an der Methode der Extraktion, sondern am Menschen.

Was die Kognitionswissenschaft dazu sagt

Michael Polanyis Feststellung, dass „wir mehr wissen, als wir sagen können“, bringt das Problem prägnant auf den Punkt. In „The Tacit Dimension“ (1966) argumentiert er, dass ein großer Teil dessen, was Expert wissen, nicht bewusst zugänglich ist und daher nicht artikuliert werden kann. Dieses implizite oder stille Wissen steht im Gegensatz zu explizitem Wissen.

Wenn eine erfahrene Domänenexpertin ihren Arbeitsprozess beschreibt, lässt sie zwangsläufig Dinge aus, weil sie sich ihres Wissens nicht bewusst ist. Dazu gehören etwa Schritte, die sie bei bestimmten Sonderfällen immer ausführt, oder implizite Prüfungen, die sie vornimmt, bevor sie ein Problem eskaliert. Solche Aspekte tauchen in strukturierten Interviews oft nicht auf, weil sie längst unterhalb der Schwelle bewusster Reflexion verankert sind.

Das SECI-Modell von Nonaka fügt eine weitere Dimension hinzu. Implizites Wissen ist nicht nur schwer zu formulieren, sondern grundsätzlich sozial. Wissen entsteht in Organisationen durch Zyklen aus Sozialisation, Externalisierung, Kombination und Internalisierung. Diese Prozesse benötigen gemeinsamen Kontext, Vertrauen und Zeit.

Entscheidend ist: Die Methoden, mit denen implizites Wissen tatsächlich sichtbar wird, basieren nicht primär auf Interviews. Sie setzen auf gemeinsame Praxis und direkte Beobachtung. Wenn jemand über die Schulter schaut und fragt: „Warum hast du das gerade so gemacht?“, werden implizite Annahmen deutlich, die in keinem Fragebogen auftauchen würden. Ein KI-Agent, der ein textbasiertes Interview führt, ist per Definition nicht Teil dieses sozialen Gefüges.

Eine dritte Dimension, die im Requirements Engineering selten berücksichtigt wird, ist Zeit. Graham Wallas beschreibt in seinem Modell kreativen Denkens die Inkubationsphase als zentral. Das bedeutet, dass das Gehirn auch außerhalb bewusster Aufmerksamkeit an Problemen weiterarbeitet. Studien zeigen, dass etwa REM-Schlaf die Fähigkeit verbessert, Informationen zu verknüpfen und nicht offensichtliche Zusammenhänge zu erkennen.

Für die Anforderungserhebung heißt das: Einige der wertvollsten Einsichten lassen sich nicht planen. Sie entstehen unter der Dusche oder mitten in der Nacht. Ein sechsstündiges Interview mit einem KI-Agenten bietet keinen Raum für solche Prozesse. Es verkürzt diese Phase nicht, es streicht sie vollständig.

Diese drei Perspektiven führen zu derselben Schlussfolgerung: Das Extraktionsparadigma missversteht die Natur dessen, was es zu gewinnen versucht. Domänenwissen ist keine statische Ressource. Es ist implizit, sozial eingebettet und über die Zeit verteilt. Methoden, die diese Eigenschaften ignorieren, verfehlen genau das Wissen, auf das es ankommt.

Wie implizites Wissen explizit wird

Das Problem ist nicht neu, und in der Softwareentwicklung gibt es etablierte Ansätze, die damit umgehen. Domain Storytelling etwa nutzt gemeinsame Erzählformate, in denen Domänenexpert ihre Arbeit schildern, während eine Moderation die Inhalte visuell festhält. So werden Sprache, Rollen und Abläufe sichtbar, die tatsächlich relevant sind. Der Ansatz funktioniert, weil er eine gemeinsame Situation schafft: Alle Beteiligten arbeiten gleichzeitig am selben Verständnis, Missverständnisse werden sofort sichtbar.

Ähnlich funktioniert Event Storming. Hier kommen Entwickler und Domänenexpert rund um eine gemeinsame Zeitleiste von Domänenereignissen zusammen. Unterschiedliche Perspektiven treffen aufeinander, Reibung entsteht, und genau daraus ergeben sich Erkenntnisse, die keine einzelne Person allein hätte formulieren können.

Beiden Ansätzen liegt eine Annahme zugrunde, die dem Extraktionsparadigma widerspricht: Domänenwissen existiert, wird aber erst im Austausch, durch Iteration und gemeinsame Arbeit explizit.

Domain-Driven Design wird gelegentlich so interpretiert, als plädiere es für eine umfassende Modellierung der Domäne im Vorfeld. Martin Fowler widerspricht dem in seinem Vorwort zu Eric Evans’ Buch ausdrücklich. Starke Domänenmodelle entstehen über Zeit, und selbst erfahrene Modellierer entwickeln ihre besten Ideen oft erst nach den ersten Releases. Domain-Driven Design war nie als Rechtfertigung für Big Design Up Front gedacht, sondern als Ansatz für eine kontinuierliche, iterative Auseinandersetzung mit der Domäne über den gesamten Lebenszyklus eines Systems hinweg. Ein großer Teil des relevanten Wissens entsteht spät und wird durch die Erfahrung im Bau und Betrieb des Systems erarbeitet.

Genau das lässt sich in einer sechsstündigen Erhebung nicht abbilden.

Fazit

Die Logik des Extraktionsparadigmas, zu Ende gedacht, bleibt nicht bei besseren Interviews stehen. Ouroboros, das Agent-Framework, das ich oben erwähnt habe, macht den nächsten Schritt explizit. Das Problem ist nicht die Methode, sondern der Mensch. Die vorgeschlagene Lösung besteht darin, den Menschen zu „reparieren“, damit er klarer, konsistenter und vollständiger kommuniziert, kurz: leichter von Maschinen verarbeitet werden kann.

Hier zeigt sich der sogenannte Reverse Centaur in der Praxis. Während beim klassischen Centaur der Mensch die Maschine steuert, hat sich das Verhältnis umgekehrt. Die Maschine setzt den Rahmen, definiert Kategorien und stellt die Fragen. Die Aufgabe des Menschen besteht darin, sich in diese Struktur einzufügen. BMAD erreicht das nicht durch Zwang, sondern durch den Eindruck von Unterstützung: ein geführter Prozess, strukturierte Fragen, ein klares Ergebnis. Gefordert wird keine andere Denkweise, sondern die Anpassung an einen Ablauf, der maschinenlesbare Antworten belohnt und keinen Raum für Unschärfe, Vorläufigkeit oder implizites Wissen lässt.

Diese Verschiebung ist kein Zufall, sondern die konsequente Folge eines Paradigmas, das Wissen als extrahierbare Ressource betrachtet, statt als Fähigkeit, die sich entwickelt. Dieses Paradigma beginnt nicht bei BMAD oder Ouroboros. Große Sprachmodelle sind selbst Ausdruck davon: trainiert auf dem akkumulierten, verschriftlichten Wissen der Menschheit, verdichtet in einem statistischen Modell, ohne Zustimmung oder Vergütung derjenigen, die dieses Wissen hervorgebracht haben. BMAD und Ouroboros führen diese Logik lediglich weiter, von der Extraktion menschlichen Wissens in Modelle hin zur Extraktion von Domänenwissen in Spezifikationen und schließlich zur schrittweisen Anpassung des Menschen an die Anforderungen der Maschine.

Die zentrale Frage ist daher keine technische, sondern eine der Richtung. Technologie hat schon immer verändert, wie Menschen arbeiten und denken. Neu ist das nicht. Entscheidend ist, ob diese Anpassung einseitig verläuft: wenn vom Menschen erwartet wird, für die Maschine lesbarer zu werden, während die Maschine nicht in gleichem Maß lernt, sich am Menschen auszurichten.