Die konsumierbare Domäne: Knowledge Engineering für KI-gestützte Entwicklung

Das alte Versprechen

Ende der 70er prägte der Stanford-Informatiker Edward Feigenbaum den Begriff "Knowledge Engineering". Er beschrieb damit den Prozess, Expertenwissen zu extrahieren, zu strukturieren und in einem Software-System nutzbar zu machen. Zentral war eine neue Rolle: der "Knowledge Engineer" als Mittler zwischen Fachexperte und System. Das Versprechen: Wenn man Expertenwissen in Regeln übersetzen könnte, ließe sich Expertise beliebig vervielfältigen.

In den 1980ern investierten Unternehmen weltweit Milliarden in regelbasierte Expertensysteme. Innerhalb eines Jahrzehnts scheiterte der Ansatz an drei Problemen:

• Knowledge Acquisition Bottleneck: Fachexperten konnten ihr Wissen oft nicht vollständig artikulieren. Vieles war implizit und nicht in Wenn-Dann-Regeln zu fassen.
• Skalierungsproblem: Wissensbasen wurden von Hand kodiert, Regel für Regel. Die Komplexität stieg dabei exponentiell: Jede neue Regel konnte mit jeder bestehenden interagieren. Für jede neue Domäne musste man von vorne anfangen.
• Brittleness: Die Systeme funktionierten innerhalb ihres engen Regelwerks, versagten aber bei unvorhergesehenen Fällen.

Knowledge Engineering verschwand aus dem Diskurs.

40 Jahre später standen wir in einem konkreten Migrationsprojekt vor einem ähnlichen Problem. Fachwissen musste aus den Köpfen von Experten extrahiert, strukturiert und so aufbereitet werden, dass Entwicklerteam und KI-Agents damit arbeiten können.

Der Unterschied zu damals: Wir übersetzen Fachwissen nicht mehr in formale Regeln. Die regelbasierten Systeme der 80er operierten auf explizit kodiertem Wissen. Das war prinzipiell präzise, aber die Komplexität der Regelwerke war von Menschen nicht mehr beherrschbar. LLMs arbeiten anders. Sie abstrahieren aus natürlicher Sprache, ohne das Wissen im formalen Sinne zu "haben". Das macht sie weniger präzise, aber radikal besser im Umgang mit Umfang und Komplexität. Genau deshalb funktioniert unser Ansatz: Die KI hilft uns, Fachwissen zu strukturieren und zugänglich zu machen. Die fachliche Richtigkeit prüfen weiterhin Menschen.

Was dabei entstand, nennen wir die "konsumierbare Domäne".

Die Ausgangslage

Bei einer Versicherung läuft seit fast 20 Jahren ein Tool auf Excel, Visual Basic und MS Access. Es zieht Daten aus dem ERP-System, rechnet Prämienverteilungen und Schadenabrechnung über mehrere Rückversicherer und schiebt Buchungssätze zurück ins ERP-System. Millionenbeträge, jedes Jahr.

Nur sehr wenige Mitarbeiter verstehen dieses System fachlich. Die Domäne ist so komplex, dass Änderungen am System nur mit hohem Risiko möglich waren.

Keine Dokumentation, keine automatisierten Tests. Alles steckt in den Köpfen. Gleichzeitig sollte die Anwendung erweitert werden, und Excel, Visual Basic und MS Access ist kein Stack, auf dem man kritische Finanzprozesse dauerhaft betreiben will.

Unser Auftrag: Das Tool auf einen modernen Stack migrieren. Und dabei die Fachlichkeit nicht verlieren.

Wie eine konsumierbare Domäne entsteht

Phase 1: Den Code befragen

Bevor wir mit Menschen sprachen, sprachen wir mit dem Code. Wir ließen eine KI den kompletten VBA-Quellcode analysieren, mit der Aufgabe: die Fachlichkeit des Systems erklären und dort, wo der Code allein nicht ausreicht, offene Fragen formulieren.

Aus mehreren Analyse-Sessions entstand neben einem ersten fachlichen Verständnis des Systems ein konsolidierter Fragenkatalog. Jede Session betrachtete den Code aus einer anderen Perspektive und produzierte unterschiedliche Ergebnisse. In der Synthese wurden Redundanzen bereinigt und die Fragen nach fachlichen Bereichen strukturiert.

Phase 2: Interviews mit Fachexperten

Mit dem Fragenkatalog gingen wir in die Interviews. Über acht Stunden, verteilt auf mehrere Sitzungen. Wir ließen die Gespräche aufzeichnen und moderierten sie mit dem Ziel, die Transkripte anschließend mit der KI weiterzuverarbeiten. Das ergab über 60.000 Wörter Rohmaterial.

Dieses Ziel bestimmte, wie wir die Interviews führten. Wir nennen das "AI-gerechtes Interviewen".

Kapitelmarken setzen. Wir sprachen explizit aus, wenn wir das Thema wechselten: "Wir reden jetzt über Prozess 2, die Vertragsverwaltung." So konnte die KI das Gespräch sauber segmentieren und Aussagen den richtigen fachlichen Bereichen zuordnen.

Für die KI mitsprechen. Wenn der Fachexperte etwas Wichtiges sagte, wiederholten wir es in eigenen Worten. Wir fassten Zwischenergebnisse zusammen und formulierten Aussagen nochmal strukturiert. Die Redundanz machte die spätere Synthese robuster.

Den Fragenkatalog flexibel einsetzen. Wir baten die Fachexperten zunächst, frei zu erzählen. Während sie erzählten, erkannten wir, welche Fragen aus dem Katalog passten, und warfen sie ein. So blieb das Interview ein natürliches Gespräch. Aber eines, das systematisch die offenen Fragen füllte.

Phase 3: Synthese zur konsumierbaren Domäne

Aus Code-Analyse und Interviews synthetisierte die KI fachliche Beschreibungen, technische Spezifikationen und Prozessdiagramme, ergänzt um ein Glossar.

Anders als beim Knowledge Engineering der 1980er werden die Wissensbasen nicht mehr von Hand kodiert. Stattdessen synthetisiert die KI strukturiertes Fachwissen aus natürlichsprachlichen Quellen. Das Ergebnis ist keine klassische Dokumentation, die nach Projektende veraltet. Es ist eine Wissensschicht, die sowohl vom Team als auch von KI-Agents konsumiert werden kann. Das ist es, was wir "konsumierbare Domäne" nennen: Fachwissen in einer Form, die für Menschen lesbar und für Maschinen verarbeitbar ist.

Der Domänenwissen-Agent

Auf der konsumierbaren Domäne sitzt ein Agent. 80 Zeilen Markdown. Er hat Zugriff auf die gesamte Prozessdokumentation, den Legacy-Code und die Interviewtranskripte. Seine Werkzeuge sind ausschließlich lesend: Er kann suchen und lesen, aber nichts verändern. Das ist eine bewusste Einschränkung. Der Agent ist ein Auskunftssystem, kein Akteur.

Die zentrale Designentscheidung: eine Frage, eine Antwort. Kein Scope-Creep, keine Spekulationen. Je fokussierter die Aufgabe, desto zuverlässiger die Antwort.

Er durchsucht die Quellen priorisiert: zuerst die validierte Prozessdokumentation, dann den Legacy-Code, dann die Rohtranskripte. Wenn er sich unsicher ist, sagt er das explizit. Wenn Quellen sich widersprechen, benennt er den Widerspruch.

Wir setzen den Agent im gesamten Entwicklungsprozess ein: bei der Spezifikation, der Story-Erstellung, der Testplanung und der Implementierung. Bei komplexen Fragen wird er mehrfach befragt, zu unterschiedlichen Teilaspekten. Die Antworten werden zusammengeführt.

Was wir gelernt haben

Die KI findet, was Menschen übersehen

Bei der Code-Analyse entdeckte die KI einen Fehler in der Feldzuordnung, der seit Jahren im System steckte. Dem Fachexperten war er nicht bekannt. Der Bug hatte keine Auswirkung auf die Abrechnungsbeträge, verfälschte aber gespeicherte Nachvollziehbarkeitsdaten.

Widersprüche als Feature

Wir haben die KI bei der Synthese explizit angewiesen, nach Widersprüchen zwischen Interview-Aussagen und Code zu suchen. An mehreren Stellen beschrieb der Fachexperte eine andere Logik als die, die im Code implementiert war. Ab und zu widersprachen sich auch Aussagen aus verschiedenen Interviews zum selben Thema. Diese Widersprüche haben wir dokumentiert und in den Folge-Interviews geklärt. Manche waren echte Fehler. Andere waren bewusste Abweichungen, die historische Gründe hatten. In jedem Fall wurde das Wissen präziser.

In dieser Genauigkeit hätten Menschen die Menge an Rohmaterial nie aufnehmen und systematisch auf Widersprüche prüfen können.

Die KI liegt auch falsch

Bei einer zentralen Berechnungslogik lag die KI daneben. Der Fachexperte erkannte es, gab Feedback, und wir arbeiteten es ein. Insgesamt schätzen wir, dass etwa 80 Prozent der fachlichen Zusammenhänge auf Anhieb richtig erfasst wurden. Die restlichen 20 Prozent mussten in Validierungsschleifen korrigiert werden. Die KI liefert einen Entwurf, der Experte gibt Rückmeldung, die Dokumentation wird präziser.

Review-Kapazität einplanen

KI produziert sehr viel Content sehr schnell. 56 Prozessdiagramme, 38 Dateien, Hunderte Seiten Spezifikation. Menschliche Reviewer haben eine begrenzte Aufnahmekapazität. Man muss bewusst einplanen, dass Fachexperten nicht alles auf einmal prüfen können, und Reviews in handhabbare Portionen aufteilen.

Das ist kein KI-spezifisches Problem. Auch von Menschen erstellte Artefakte werden überflogen statt geprüft. Entscheidend ist das Format: Rechenbeispiele zwingen zum genauen Hinschauen, Prozessdiagramme lassen sich leicht abnicken.

Rechenbeispiele als Validierungswerkzeug

Eine Sache hätten wir früher machen sollen: Rechenbeispiele erstellen und vom Fachexperten prüfen lassen. An unklaren Stellen haben wir Rechenbeispiele erstellt und mit dem Fachexperten abgeglichen.

Das war ein Durchbruch. Ein Rechenbeispiel mit konkreten Zahlen macht Missverständnisse sofort sichtbar: Stimmt dieser Betrag? Fehlt hier ein Schritt? Warum ist das Ergebnis negativ?

In Zukunft würden wir von Anfang an mit Beispielen arbeiten, möglicherweise mit Example Mapping als strukturierter Methode. Nicht nur als Ergänzung zur Dokumentation, sondern auch als Basis für eine testgetriebene Entwicklung.

Wie es sich im Projekt anfühlt

Entwickler als Knowledge Engineers. In unserem Migrationsprojekt gab es keine Product Owner und keine Business Analysten. Die Entwickler übernahmen die Rolle des Wissensextraktors, unterstützt durch die KI. Sie strukturiert das Wissen, findet Widersprüche, bereitet Zusammenhänge auf. Was beim Menschen bleibt: Ergebnisse einordnen, Fragen priorisieren, Entscheidungen treffen. In einem anderen Kontext, etwa bei einer Neuentwicklung mit mehreren Stakeholdern, würde die KI eine BA- oder PO-Rolle ergänzen, nicht ersetzen.

Onboarding: Die Schwelle sinkt. Ein Kollege war nur einen Tag pro Woche im Projekt. Normalerweise wäre das bei dieser Fachlichkeit schwierig. Mit dem Domänenwissen-Agent konnte er jederzeit fachliche Fragen stellen und sich in der Domäne orientieren. Er blieb arbeitsfähig, ohne einen Kollegen synchron aus der Arbeit reißen zu müssen.

Ein Kollege bei der Versicherung mit mehrjähriger Branchenerfahrung bewertete unser fachliches Verständnis als ungewöhnlich tief für die kurze Projektlaufzeit. Das liegt daran, dass das Wissen in einer Form vorliegt, die systematisches Durcharbeiten ermöglicht. Die Einstiegshürde in die Domäne wird niedriger. Sie verschwindet aber nicht.

Der Fachexperte fühlt sich nicht bedroht. Er war beeindruckt, nicht besorgt. Sein Wissen wird erstmals dokumentiert und zugänglich gemacht. Er ist nicht mehr das alleinige Bottleneck. Das ist auch für ihn eine Entlastung. Bei der Zwischenpräsentation scherzten wir, den Agent nach ihm zu benennen.

Ausblick: Was wir noch nicht wissen

Wir beschreiben hier einen Ansatz, der in einem konkreten Projekt funktioniert hat. Es ist wichtig, die Bedingungen zu benennen, die diesen Erfolg begünstigt haben. Und die offenen Fragen, die sich daraus ergeben.

Warum dieses Projekt ein günstiger Fall war. Wenige Fachexperten mit konsistentem Wissen. Ein klar abgegrenztes Legacy-System. Keine widerstreitenden Stakeholder-Interessen. Wenn mehrere Fachexperten widersprüchliche Vorstellungen haben oder Prozesse erst definiert statt migriert werden müssen, muss man dafür Lösungen finden.

Die nächste Stufe: Der Fachexperte ohne Mittler. Aktuell sind wir als Entwickler die Schnittstelle zwischen Fachexperte und KI. Das funktioniert, skaliert aber nur begrenzt. Eine denkbare nächste Stufe wäre ein Interface, in dem der Fachexperte selbständig mit der KI interagiert und die Dokumentation iterativ wächst. Ob das ohne technische Begleitung funktioniert, ist eine offene Frage.

Skalierung auf größere Systeme. Das abzulösende System war überschaubar. Der Domänenwissen-Agent funktioniert, weil das Modell sich gezielt durch die Inhalte arbeiten kann. Bei größeren Codebasen oder mehreren Fachdomänen stellt sich die Frage, ob ein einzelner Agent noch ausreicht oder ob man spezialisierte Agents pro Fachbereich braucht. Auch die Wissensbasis selbst wächst mit jedem Interview und jeder Korrekturschleife. Ab welchem Punkt wird der Kontext zu groß, um präzise zu bleiben?

Vier Empfehlungen

Wer einen ähnlichen Weg gehen will, dem sind vier Dinge aus unserem Projekt mitgegeben:

1. Bindet die echten Experten ein, keine Proxies. Sprecht vor allem viel und regelmäßig mit denen, die das System täglich nutzen. Das implizite Wissen steckt in den Köpfen der Anwender, nicht in der vorhandenen Dokumentation. Und plant genug Zeit für Interviews ein.
2. Baut die konsumierbare Domäne von Tag 1. Strukturiert nach Prozessen, mit Glossar und Rechenbeispielen. Das ist kein Dokumentations-Overhead, sondern das zentrale Artefakt eures Projekts. Die Grundlage, auf der Mensch und KI gemeinsam arbeiten. Beginnt mit den Rechenbeispielen, nicht mit den Diagrammen.
3. Senkt die Schwelle zum Domänenwissen. Die konsumierbare Domäne macht Fachwissen für alle Projektbeteiligten zugänglich. Die Geschwindigkeit entsteht, wenn fachliche Rückfragen nicht mehr den Fachexperten als Engpass haben, sondern über den Domänenwissen-Agent laufen. Das ersetzt keine Rollen, aber es entlastet die Menschen dahinter.
4. Lasst die Verantwortung beim Menschen. Die KI senkt die Schwelle zum Domänenwissen. Sie ersetzt weder den Fachexperten noch den kritischen Blick des Teams. Nutzt sie als Entwurfsmaschine und Auskunftssystem. Aber prüft, korrigiert und entscheidet selbst.