Bei spielmit.eu, einem meiner privaten Projekte, habe ich der KI am Anfang einfach freien Lauf gelassen. „Bau mir das“ – und sie hat gebaut. Schnell, plausibel, von außen sah alles gut aus. Bis ich genauer hingeschaut habe: Innen wackelte es. Datenschutz-Annahmen, die keiner geprüft hatte. Strukturen, die beim ersten Anfassen nachgaben. Ein Jenga-Turm, der so lange steht, bis jemand den falschen Klotz zieht.

Der Fehler war nicht die KI. Der Fehler war, dass ich keine Wissensbasis für KI aufgebaut hatte, bevor ich sie arbeiten ließ. Kein Rahmen, kein „so arbeiten wir hier“. Sie musste raten. Und raten kann sie beeindruckend gut – nur eben nicht zuverlässig richtig.

Das war der Moment, in dem ich mein Vorgehen umgedreht habe: erst das Fundament, dann die Agenten.

Was passiert, wenn die KI raten muss

Eine KI ohne Kontext ist wie ein neuer Kollege am ersten Tag, den du sofort eine Anforderung schreiben lässt. Er ist klug, motiviert, formuliert schöne Sätze – aber er kennt eure Historie nicht, eure Entscheidungen nicht, eure Grenzen nicht.

Also füllt er die Lücken mit Annahmen. Die klingen plausibel, weil er gut klingt. Und genau das ist die Falle: Das Ergebnis sieht fertig aus, obwohl es auf Vermutungen steht.

Bei Anforderungen ist das teuer. Eine Story, die eine bestehende Architekturentscheidung ignoriert. Ein Feature, das gegen eine Datenschutzvorgabe läuft, die es längst gibt. Ein Vorschlag, den ihr vor einem Jahr aus gutem Grund verworfen habt. Nicht, weil die KI dumm ist – sondern weil ihr niemand gesagt hat, was gilt.

Eine Wissensbasis für KI schlägt jeden cleveren Prompt

Die meisten versuchen, dieses Problem mit besseren Prompts zu lösen. Immer längere Anweisungen, immer mehr „beachte bitte auch…“. Das skaliert nicht. Du kannst nicht vor jeder Frage die halbe Firmenhistorie ins Chatfenster tippen.

Der bessere Hebel ist eine Wissensbasis für KI: strukturiertes, kuratiertes Wissen, auf das jeder Agent bei jeder Aufgabe automatisch zugreift. Nicht im Prompt, sondern als fester Kontext im Hintergrund. Die KI rät dann nicht mehr – sie liest nach.

Der Unterschied ist derselbe wie zwischen einem Berater, der dein Unternehmen zum ersten Mal sieht, und einem, der seit Jahren dabei ist. Gleiche Intelligenz, völlig andere Qualität der Antwort. Nicht weil der eine schlauer ist, sondern weil er den Kontext hat.

Zwei Schichten: was für alle gilt, was nur fürs Produkt

Bei mir liegt diese Wissensbasis in zwei Schichten – und diese Trennung ist der eigentliche Trick.

Schicht 1 – Organisation. Alles, was immer gilt, egal woran ich arbeite: Compliance und Datenschutz, Security-Baselines, Architektur-Guidelines, die grobe Strategie, das Stakeholder-Verzeichnis. Diese Schicht ist bei jeder Analyse aktiv.

Schicht 2 – Produkt. Alles, was nur ein bestimmtes Produkt betrifft: Personas, Architekturentscheidungen (inklusive der wichtigen Frage „Was haben wir bewusst nicht gebaut – und warum“), bestehende Stories, Roadmap, nicht-funktionale Anforderungen.

Warum die Trennung? Weil Compliance für alles gilt – die will ich nicht bei jedem Produkt neu erfinden. Und weil Produktwissen isoliert bleiben muss – eine Entscheidung aus Produkt A darf die Analyse für Produkt B nicht verfälschen. Schicht 1 gilt überall, Schicht 2 wird passend zum aktuellen Produkt dazugeladen. So hat jeder Agent denselben, sauberen Informationsstand.

Das Fundament gehört zuerst mir, dann der KI

Jetzt kommt der Teil, der mir besonders wichtig ist: Diese Wissensbasis ist keine „KI-Konfiguration“. Es sind einfache Markdown-Dateien in Obsidian – Klartext, den ich lese, pflege und verstehe.

Das heißt: Das Fundament nützt zuerst mir. Es ist mein Zweitgehirn, meine dokumentierten Entscheidungen, mein „so arbeiten wir hier“. Dass die KI dieselben Dateien liest, ist ein Nebeneffekt – ein sehr nützlicher, aber eben nur ein Nebeneffekt.

Damit bleibt der Ansatz genau das, was ich in Teil 1 beschrieben habe: KI-basiert, aber nicht KI-abhängig. Fällt die KI aus, habe ich immer noch ein sauber gepflegtes, lesbares Wissenssystem. Ich verliere Tempo, nicht das Fundament. Genau das meine ich mit Guidelines-First – ein Prinzip, über das ich schon im Dompteur-Modell geschrieben habe.

Was ich dabei gelernt habe

Die wichtigste Lektion: Die Qualität der KI-Arbeit hängt weniger am Modell und am cleveren Prompt, als man denkt – und viel mehr an dem, was die KI lesen darf. Wer vorne beim Kontext spart, zahlt hinten bei den Ergebnissen.

spielmit.eu läuft heute anders. Erst das Fundament, dann die Agenten. Der Jenga-Turm steht nicht mehr auf Vermutungen, sondern auf einer Wissensbasis, die ich selbst geschrieben habe.

Das ist Teil 2 der Serie „Requirements Engineering mit KI-Agenten“. Im nächsten Teil wird es konkret: das Interview – wie aus einer rohen Idee ein Story-Draft wird, ganz ohne Fragebogen, und wie die KI dabei nebenbei merkt, dass es eine Idee vielleicht schon gibt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“