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“

Der Beitrag Guidelines-First: Warum eine KI ohne Wissensbasis am Jenga-Turm baut erschien zuerst auf Das ist die Welt von Thomas.

Ich saß da und wusste kurz nicht, ob ich mich ärgern oder freuen soll. Geärgert, weil ich gerade dabei war, Arbeit zu doppeln, die längst getan war. Gefreut, weil mir das jemand jetzt sagt. Und genau an diesem Punkt hängt das Thema, über das gerade alle streiten: KI-generierte User Stories.

Die will nämlich kaum jemand lesen. Und ehrlich gesagt: ich auch nicht.

Dass es mir jetzt auffällt – an meinem Schreibtisch und nicht erst im Refinement, wo so eine Diskussion die Zeit des ganzen Teams frisst und die Velocity drückt – ist kein Zufall. Genau das ist mein Job: solche Dinge früh erkennen und im Zweifel vorab mit mir selbst und meinen Agenten klären.

Erst der ehrliche Teil: der Schmerz

Die Story von neulich war der harmlose Fall. Da hat es jemand – die KI – rechtzeitig gemerkt. Meistens merkt es keiner. Und dann passiert genau das, was Anforderungsarbeit seit Jahren zäh macht:

Du legst eine Story an, die es längst gibt – nur unter anderem Titel, im falschen Epic, von jemand anderem geschrieben. Du findest sie nicht, weil du gar nicht weißt, dass du suchen müsstest. Zwei Teams bauen dieselbe Sache.

Oder jemand bringt eine Idee auf, die vor zwei Jahren schon einmal auf dem Tisch lag und bewusst verworfen wurde. Die Story liegt irgendwo in Jira – mit Glück archiviert, im schlimmsten Fall längst gelöscht. Mit genug Recherche fände man sie wieder. Aber genau das ist der Punkt: Als PO will ich das Backlog nach vorne bringen, nicht vor jeder Idee zum Detektiv werden und ständig hinterfragen, ob es das nicht schon gab. Diese Sucharbeit brauche ich – und genau die kann mir eine KI abnehmen.

Oder die Story ist sauber formuliert, klingt rund – und im Sprint fällt auf, dass sie am Datenschutz vorbeigeht, ein Sicherheitsloch aufreißt oder einer Architekturentscheidung widerspricht. Jetzt ist es teuer.

Und selbst wenn alles gut läuft: Kaum hast du das Ticket ans Team übergeben, entwickelt es sich in Jira weiter – neu geschnitten, ergänzt, umpriorisiert. Deine Planung steht derweil auf altem Stand. Du merkst es nicht. Bis es kracht.

Das ist der Schmerz. Nichts davon ist spektakulär. Aber es summiert sich – zu doppelter Arbeit, vergessenen Entscheidungen und Stories, die im luftleeren Raum entstehen.

„Keine KI-generierten User Stories“ – und sie haben recht

Wenn ich davon erzähle, kommt oft der Reflex: „Dann lass doch die KI die Stories schreiben.“ Und genauso oft kommt von guten Entwicklern der Gegenreflex: „Bitte nicht. KI-generierte User Stories merke ich sofort – und dann lese ich sie nicht gern.“

Der Frust dahinter ist berechtigt. Nichts ist ermüdender als glatter Text, der so tut, als hätte jemand nachgedacht, aber niemand hat. Gleichzeitig erwarten dieselben Leute, dass ein Product Owner 2026 KI nutzt. Kein Werkzeug in der Hand zu haben, das alle anderen längst haben, wirkt eben auch nicht souverän.

Das klingt nach Widerspruch. Ist es aber nicht. Beide Seiten reden nur über zwei verschiedene Dinge. Das Problem ist nicht, dass KI im Spiel ist. Das Problem ist, was sie tut.

Warum Prüfen das Schreiben schlägt

Eine Story zu schreiben heißt: eine Absicht zu formulieren. Warum bauen wir das? Für wen? Was lassen wir bewusst weg? Das hängt an Kontext, an Historie, an Verantwortung – an Dingen, die in meinem Kopf und in den Köpfen meiner Kollegen stecken, nicht im Trainingsdatensatz eines Modells. Wenn ich das an eine KI abgebe, kommt genau der Text heraus, den keiner lesen will: plausibel und hohl.

Eine Story zu prüfen ist das genaue Gegenteil.

Prüfen heißt: alles gegen alles abgleichen. Gibt es das schon? Widerspricht es einer Entscheidung von damals? Was sagt der Datenschutz, was der Sicherheitsblick, was der Nutzer? Das ist stumpfe, vollständige, ausdauernde Arbeit – und genau da bin ich als Mensch schwach. Ich vergesse Tickets. Ich habe nicht alle Architekturentscheidungen im Kopf. Ich kann nicht gleichzeitig die Security-, die Datenschutz- und die Nutzerbrille tragen.

Eine Maschine kann das. Unermüdlich, bei jedem einzelnen Ticket.

Deshalb schreibt bei mir die KI nicht – sie prüft. Ich behalte den Teil, den nur ich kann: entscheiden, was wir bauen und warum. Sie übernimmt den Teil, den ich alleine nie so gründlich hinbekäme. Das ist keine Bequemlichkeit. Das ist Arbeitsteilung nach Stärken.

Die These, auf der alles aufbaut

Der Mensch besitzt die Absicht. Die Agenten besitzen die Prüfung.

Was am Ende im Ticket steht, wurde nicht geschrieben. Es wurde geprüft – und von mir entschieden. Deshalb sind meine Stories besser durchdacht, seit KI im Spiel ist, nicht schlechter.

Zwei Bausteine davon habe ich hier schon beschrieben: den Interview-Ansatz statt Fragebogen und das Dompteur-Modell mit Guidelines-First. In dieser Serie setze ich sie zu einem kompletten Vorgehen zusammen.

KI ist eine Ergänzung – kein Allheilmittel

Damit das nicht falsch ankommt: Die KI ist bei mir nicht der Chef. Wir Product Owner sind die Profis, die entscheiden – die KI unterstützt. Und Unterstützung heißt für mich ausdrücklich, dass ich auch dann arbeiten kann, wenn sie mal nicht da ist.

Deshalb liegt meine gesamte Wissensbasis – alle Guidelines, alle Stories, alle Entscheidungen – als einfache Markdown-Dateien in Obsidian. Klartext, den jeder Mensch lesen und selbst bearbeiten kann, ohne Spezialwerkzeug, versioniert in Git. Die KI liest genau dieselben Dateien wie ich, kein verstecktes Format dazwischen.

Der Workflow ist KI-basiert, aber nicht KI-abhängig. Ist das Modell mal nicht erreichbar, bin ich offline oder fällt der Dienst aus, verliere ich Tempo – nicht meine Daten und nicht die Kontrolle. Dann mache ich eben von Hand weiter. Genau das ist der Unterschied zwischen einem Werkzeug, das dich stärker macht, und einem, von dem du abhängig wirst.

Was ich dabei gelernt habe

Der wichtigste Perspektivwechsel war, die KI nicht als schnelleren Texter zu sehen, sondern als etwas, das ich alleine nie leisten könnte: Hunderte Tickets vor jeder neuen Idee durchsehen, jede alte Entscheidung parat haben, gleichzeitig aus fünf Blickwinkeln auf dieselbe Anforderung schauen.

Das nimmt mir die Fleißarbeit ab – und lässt mir den Kopf frei für das, was wirklich meine Aufgabe ist.

KI-generierte User Stories im eigentlichen Sinn entstehen bei mir also nicht. Was am Ende rausgeht, ist geprüft – und von mir verantwortet.

Und die Story von neulich? Die habe ich nicht angelegt. Die gab es ja schon.

Das ist der erste Teil einer Serie über mein Vorgehen im Requirements Engineering mit KI-Agenten. Im nächsten Teil geht es ums Fundament: warum eine KI ohne Wissensbasis am Jenga-Turm baut – und was sich ändert, sobald sie kuratierten Kontext bekommt.

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

Der Beitrag Warum ich keine KI-generierten User Stories schreibe – und KI trotzdem überall einsetze erschien zuerst auf Das ist die Welt von Thomas.