Dieser Bonus-Teil ist die Anleitung, wie du die Requirements-Pipeline mit Claude Code bei dir einrichtest, vom leeren Ordner bis zur ersten geprüften Story. Die eigentlichen Prompts und Skills liegen in einem offenen Repo, das ich pflege; dieser Beitrag ist die menschliche Auffahrt dazu.

Eine Sache vorweg, weil sie mir wichtig ist: Das Kit ist generisch. Es enthält das Gerüst und die Skills, aber keine Firmeninhalte. Deine Wissensbasis (Compliance, Produkte, Entscheidungen) füllst du selbst. Genau diese Trennung ist Teil des Konzepts.

Was im Starter-Kit steckt

Das Repo ist bewusst ein sauberes Gerüst, kein fertiges Produkt. Drin ist:

• Die Skills als Prompt-Dateien: Discovery, Interview, Review (mit den sechs Perspektiven), Finalize, Ticket-Push, Sync und die Projektmanagement-Helfer.
• Die CLAUDE.md – die Schaltzentrale, die Claude Code bei jeder Session erklärt, wie alles zusammenspielt.
• Die HOWTO.md – der menschliche Einstieg mit allen Befehlen und typischen Abläufen.
• Das Story-Template mit der Finalisierungs-Checkliste.
• Leere Wissensschichten (Organisation, Produkte, Portfolio), die du nach und nach befüllst.

Alles Klartext-Markdown, versioniert in Git. Du liest und änderst jede Datei selbst, die KI arbeitet auf denselben Dateien wie du.

Voraussetzungen

Viel brauchst du nicht:

• Claude Code, eingerichtet und lauffähig.
• Git für die Versionierung.
• Obsidian ist optional, aber angenehm, um im selben Verzeichnis menschlich zu lesen und zu schreiben.
• Jira nur, falls du an ein Team übergibst, über einen MCP-Server. Ohne Jira läuft alles im Vault-Modus, Tickets sind dann einfach Markdown-Dateien.

So richtest du die Requirements-Pipeline mit Claude Code ein

Der Ablauf ist bewusst kurz gehalten:

1. Repo klonen und in Claude Code öffnen. Claude liest die CLAUDE.md automatisch und weiß damit, wie das System tickt.
2. /setup aufrufen. Der Setup-Skill interviewt dich: Welches Produkt richten wir ein? Welches Ticket-System (Vault oder Jira)? Welche Perspektiv-Reviews sollen Standard sein? Er legt nur an, was du wirklich brauchst.
3. Schicht 1 befüllen – deine organisationsweiten Guidelines: Compliance, Security-Baseline, Architektur-Prinzipien. Das ist das Fundament aus Teil 2. Rohmaterial einfach in den inbox/-Ordner werfen und /inbox-process laufen lassen.
4. Erste Story: /interview. Jetzt läuft der Ablauf aus Teil 3 bis 6 – Interview, Review, Finalisierung, Übergabe.

Mehr ist es im Kern nicht. Die Tiefe steckt nicht in komplizierter Bedienung, sondern in den Skills und der Wissensbasis dahinter.

Ein Blick in einen Skill

Damit du ein Gefühl bekommst, wie die Prompts aussehen: Jeder Skill ist eine Markdown-Datei mit einem klaren Auftrag und, ganz wichtig, festen Verhaltensregeln. Ein Ausschnitt aus dem Prinzip, das für alle gilt:

Ein Skill hat immer eine Meinung und einen Vorschlag. Aber er führt nichts durch ohne Bestätigung und lässt alle Optionen offen, einschließlich „brauchen wir nicht“. Irreversibles (Commit, Ticket anlegen, Datei verschieben) wird immer vorher gezeigt und bestätigt.

Genau dieser Satz ist der Grund, warum das System unterstützt, statt zu übernehmen. Die vollständigen Skills mit allen Prompts findest du im Repo.

Es bleibt deins – mit und ohne KI

Ein letzter Punkt, der sich durch die ganze Serie zieht: Weil alles Klartext-Markdown ist, gehört dir das System auch ohne KI. Fällt Claude Code weg, hast du immer noch ein sauber strukturiertes, lesbares Wissenssystem und deine Stories. Du verlierst Tempo, nicht die Substanz. Das Kit macht dich stärker, es macht dich nicht abhängig.

Das Repo

Das komplette Starter-Kit liegt hier: github.com/tschiffler/requirements-engineering-pipeline.

Nimm es, fork es, bau es um. Wenn du es einsetzt oder verbesserst, freue ich mich über deine Erfahrungen, die fließen in die nächste Version zurück.

Danke fürs Mitlesen

Damit ist die Serie „Requirements Engineering mit KI-Agenten“ komplett, vom Schmerz über das Fundament, das Interview, das Review und die Sprache des Teams bis zur Übergabe. Und jetzt zum Selbernachbauen.

Der Gedanke dahinter bleibt derselbe wie in Teil 1: Der Mensch besitzt die Absicht, die Agenten besitzen die Prüfung. Das Kit gibt dir die Prüfung an die Hand. Die Absicht bleibt bei dir.

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

Der Beitrag Bau es dir selbst: die Requirements-Pipeline mit Claude Code erschien zuerst auf Das ist die Welt von Thomas.

Dieser Agent ist der Advocatus Diaboli, einer von sechs, die bei mir jede Story prüfen. Zusammen bilden sie ein Multi-Agent-Review: sechs spezialisierte Blickwinkel, die gleichzeitig auf denselben Draft schauen, jeder mit einer anderen Brille, keiner müde, keiner betriebsblind.

Und genau da liegt der Punkt, den ein einzelner Mensch nicht leisten kann.

Der Schmerz: eine Story, eine Perspektive

Wenn ich eine Story alleine schreibe, schreibe ich sie aus meinem Kopf. Mit meinen blinden Flecken. Ich denke an die Funktion, aber übersehe die Authentifizierung. Ich denke an den Nutzen, aber nicht an die personenbezogenen Daten, die dabei anfallen. Ich denke an heute, aber nicht an die Architekturentscheidung von vor zwei Jahren.

Das ist keine Schwäche von mir speziell, das ist einfach so. Kein Mensch trägt gleichzeitig den Security-, den Datenschutz-, den UX- und den Architektur-Hut. Wir tragen einen, vielleicht zwei. Der Rest fällt hinten runter.

Und wo fällt es auf? Im besten Fall im Refinement, wenn das halbe Team schon Zeit investiert. Im schlechtesten Fall mitten in der Umsetzung. Beides teuer, beides vermeidbar.

Multi-Agent-Review: sechs Brillen gleichzeitig

Statt einer Perspektive schicke ich den Draft aus Teil 3 durch sechs. Jeder Agent liest denselben Entwurf und dieselbe Wissensbasis aus Teil 2 – aber mit einem klar umrissenen Auftrag:

• Security – Angriffsflächen, Authentifizierung, Datenzugriffe.
• UX / Nutzer – schlüpft in die Rolle der Persona und sucht fehlende Flows und unklare Formulierungen.
• Architektur – Breaking Changes, Migrationsbedarf, Konflikte mit bestehenden Entscheidungen.
• Compliance – Datenschutz, regulierte Prozesse, personenbezogene Daten.
• Story-Qualität – testbare Akzeptanzkriterien, INVEST, Vorschläge zum Splitten.
• Advocatus Diaboli – die Gegenrede. Warum sollten wir das nicht bauen?

Jeder liefert seine Funde mit einer klaren Gewichtung zurück: Blocker, Wichtig oder Nice-to-have. Und weil sie parallel laufen, kostet mich das nicht sechsmal so viel Zeit, sondern ungefähr so viel wie eine gründliche Review – nur eben aus sechs Richtungen.

Der Advocatus Diaboli, der mich vor mir selbst schützt

Den einen will ich hervorheben, weil er so unbequem wie wertvoll ist.

Der Advocatus Diaboli hat genau einen Job: Gegenargumente finden. Gibt es eine einfachere Lösung? Was, wenn eine bestehende Funktion 80 Prozent des Problems schon löst? Welche Annahme in der Story ist eigentlich ungeprüft?

Das ist das Gegenteil von einer KI, die dir nach dem Mund redet. Und es ist genau das, was ich als überzeugter Erfinder meiner eigenen Ideen am wenigsten selbst mache. Ich bin verliebt in meine Idee, der Advocatus ist es nicht. Diese Distanz ist Gold wert.

Die Synthese: auch Widersprüche werden sichtbar

Aus den sechs Rückmeldungen wird ein Bild: die Blocker, die vor der Finalisierung geklärt sein müssen. Das Wichtige, über das ich entscheiden sollte. Das Nice-to-have.

Das Beste daran sind aber die Widersprüche zwischen den Agenten. Ein Beispiel, das immer wieder vorkommt: Security fordert, alle Zugriffe zu protokollieren. Compliance schränkt genau dieses Protokollieren ein, weil personenbezogene Daten im Spiel sind. Zwei berechtigte Perspektiven, ein echter Zielkonflikt. Ein einzelner Reviewer hätte ihn nie gesehen, die Synthese legt ihn offen und sagt klar: Hier musst du entscheiden.

Und dann entscheide ich

Das ist mir wichtig: Die Review entscheidet nichts. Sie legt mir alles sauber auf den Tisch: Blocker, Wichtiges, Widersprüche, offene Annahmen. Aber die Entscheidung, was davon zählt und wie der Zielkonflikt aufgelöst wird, treffe ich. Die sechs Agenten sind mein Beraterstab, nicht mein Chef.

Genau so bleibt die Story am Ende meine, nur eben eine, die durch sechs Prüfungen gegangen ist, statt durch keine.

Was ich dabei gelernt habe

Die Angst, KI würde die Anforderungsarbeit verflachen, dreht sich hier ins Gegenteil. Ein gutes Multi-Agent-Review macht meine Stories nicht generischer, sondern schärfer, weil sie Fragen beantworten müssen, die ich mir allein nie gestellt hätte.

Und die Idee, in die ich verliebt war? Die habe ich nicht gebaut. Der Advocatus hatte recht, und mir zwei Wochen Arbeit an der falschen Sache erspart.

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

Der Beitrag Multi-Agent-Review: Sechs Perspektiven auf eine Story – und ein Advocatus Diaboli erschien zuerst auf Das ist die Welt von Thomas.

Genau das ist der Kern, wenn du Anforderungen mit KI erheben willst: nicht schneller tippen, sondern besser denken. Die KI schreibt die Story nicht für mich, sie führt mich durch ein Gespräch, an dessen Ende ich selbst klarer bin als vorher.

Das klingt banal. Ist aber das genaue Gegenteil von dem, was die meisten mit KI machen.

Der Fragebogen-Reflex

Der erste Reflex, bei Menschen wie bei KI, ist: alles auf einmal. Ein großes Template, zwanzig Felder, „bitte vollständig ausfüllen“. Oder du kippst der KI in einem Absatz deine halbe Idee hin und sie spuckt eine fertig aussehende Story aus.

Das Problem: So entsteht eine Scheinvollständigkeit. Du füllst Felder, weil sie da sind, nicht weil du die Antwort wirklich durchdacht hast. Und die KI ergänzt den Rest mit plausiblen Annahmen. Am Ende steht ein Dokument, das fertig aussieht, und auf Vermutungen gebaut ist.

Anforderungsarbeit ist aber kein Formular. Sie ist Denkarbeit. Und Denken erzwingt man nicht mit mehr Feldern, sondern mit den richtigen Fragen zur richtigen Zeit.

Anforderungen mit KI erheben heißt: eine Frage nach der anderen

Deshalb läuft es bei mir als echtes Gespräch. Eine Frage. Ich antworte. Die KI hört zu, hakt nach, stellt die nächste. Kein Fragebogen, ein Dialog.

Die Reihenfolge ist bewusst gewählt: Erst was genau, dann warum (der eigentliche Wert), dann für wen, dann, die unbequeme, was explizit nicht, und zum Schluss der Kern der Akzeptanzkriterien.

Der Unterschied zum Fragebogen ist der gleiche wie zwischen einem guten Interviewer und einem Formular: Der Interviewer merkt, wenn eine Antwort schwammig ist, und bohrt nach. Das Formular nimmt jede Antwort, auch die faule. Genau dieses Nachbohren („für wen genau?“, „was passiert, wenn nicht?“) ist die Arbeit, die eine Story trägt oder scheitern lässt. (Über den Interview-Ansatz selbst habe ich hier schon ausführlicher geschrieben.)

Während wir reden, prüft die KI schon

Und jetzt kommt der Teil, der mir das Gespräch erst richtig wertvoll macht: Während ich rede, arbeitet die KI im Hintergrund.

Sie gleicht meine Idee live gegen die bestehenden Tickets ab: Gibt es das schon, unter anderem Titel, in einem anderen Epic? Sie schaut in die Wissensbasis aus Teil 2: Widerspricht die Idee einer Architekturentscheidung? Steht sie im Konflikt mit etwas, das wir bewusst verworfen haben? Gibt es Abhängigkeiten zu anderen Stories?

Das ist der Moment aus Teil 1, nur von innen betrachtet: „Das gibt es schon. Zweimal.“ Ich muss dafür nicht 200 Tickets im Kopf haben, die KI hat sie parat, während ich mich aufs Denken konzentriere. Vor einem Live-Abgleich fragt sie mich übrigens kurz, ob sie loslegen soll. Auch hier bleibe ich der, der entscheidet.

Am Ende steht ein Draft, nicht das Ticket

Wichtig: Was aus dem Interview herausfällt, ist ein Draft. Ein strukturierter Entwurf mit Titel, dem eigentlichen „als wer will ich was und warum“, ersten Akzeptanzkriterien, einer klaren Abgrenzung und den gefundenen Abhängigkeiten. Dazu ein schneller INVEST-Check, und wenn die Sache zu groß ist, ein Vorschlag, sie zu splitten.

Es ist ausdrücklich nicht das fertige Ticket. Es ist mein Rohmaterial, sauber vorbereitet, aber noch nicht entschieden. Und es ist eine simple Markdown-Datei, die ich lesen und ändern kann, ganz gleich, ob die KI gerade mitspielt oder nicht.

Der Draft geht als Nächstes durch die Mangel. Und zwar nicht durch eine Perspektive, sondern durch ein ganzes Gremium.

Was das im Alltag verändert

Die größte Wirkung hat nicht die Zeitersparnis, die gibt es, ist aber nicht der Punkt. Die größte Wirkung ist, dass ich gezwungen werde, meine eigene Idee zu Ende zu denken, bevor sie irgendwer anders sieht. Die unbequemen Fragen kommen jetzt von der KI, an meinem Schreibtisch, und nicht später im Refinement vom halben Team.

Die Exportfunktion von neulich? Die sieht heute anders aus als die Idee, mit der ich reingegangen bin. Besser. Weil mir jemand die eine unbequeme Frage gestellt hat, bevor ich losgelaufen bin.

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

Der Beitrag Anforderungen mit KI erheben: ein Interview statt eines Fragebogens erschien zuerst auf Das ist die Welt von Thomas.

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.

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.

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.

Ein Kollege hat mich letzte Woche zu einem Termin mitgenommen. Eine Gruppe Menschen, die über eine Kooperation mit dem Arbeitsmarkt zu uns gekommen sind. Menschen, die viele Bewerbungen schreiben. Die wenige oder gar keine Antworten bekommen. Die sich schwertun — manche, weil Deutsch nicht ihre erste Sprache ist, manche, weil die Bewerbung einfach nicht rund ist, manche, weil sie schlicht nicht wissen, wie das heute alles funktioniert.

Und dann fiel das Thema KI.

Die Reaktion hat mich ehrlich gesagt überrascht. Nicht, weil ich keine Ahnung hatte, dass da Skepsis herrscht. Aber wie weit weg das alles von meiner eigenen Realität ist — das hat mich dann doch getroffen.

Wir reden aneinander vorbei

In meiner Welt ist KI Alltag. Ich nutze sie täglich: Anforderungserhebung, Code-Reviews, Texte, Planung. Meine Frau Sarah hat auch angefangen damit — ein bisschen zögerlich noch, aber sie nutzt es. Bei uns ist KI längst kein Thema mehr, das man groß erklären muss.

Und dann sitzt du da, mit Menschen, die noch nie ChatGPT aufgemacht haben. Die KI kennen als Schlagzeile, als Bedrohung, als das Ding, das irgendwann kommt und alles verändert.

Das Ding ist aber: es ist schon da.

Was mich wirklich nachdenklich gemacht hat — wir ITler denken über Dinge nach wie: Welches Modell ist besser? Wie prompted man richtig? Welche Aufgaben delegiere ich an KI, welche nicht? Das sind unsere Probleme. Und das ist natürlich meilenweit entfernt von jemandem, der sich fragt: „Werde ich beim nächsten Bewerbungsgespräch überhaupt noch von einem Menschen gelesen?“

Der Akkuschrauber

Ich habe versucht, das runterzubrechen. Mein Standardvergleich für solche Momente: der Akkuschrauber.

Kein Handwerker dreht heute tausend Schrauben von Hand. Jeder greift zum Akkuschrauber. Nicht weil er muss, sondern weil es einfach sinnvoll ist. Und trotzdem hat nicht der Akkuschrauber das Haus gebaut — der Handwerker hat es gebaut. Das Werkzeug hat ihm nur geholfen.

KI ist nichts anderes. Ein Werkzeug. Kein Teufelswerkzeug, kein Jobkiller, kein Alleskönner. Ein Werkzeug, das man einsetzen kann — oder auch nicht. Aber wer es nicht einsetzt, macht es sich unnötig schwer.

Das gilt übrigens nicht nur für ITler.

Die Sache mit dem Bewerbungsscreening

Ein Punkt, der in der Runde aufkam, hat mich nicht losgelassen. Wenn KI schon heute Bewerbungen voraussortiert — und das tut sie in vielen Unternehmen bereits — dann sind Menschen, deren Bewerbung nicht passt, raus. Ohne dass ein Mensch draufgeschaut hat. Ohne zweite Chance.

Das ist hart. Ich will das nicht schönreden.

Aber die Konsequenz daraus ist nicht, KI abzulehnen. Die Konsequenz ist, das Spiel zu verstehen und mitzuspielen. Keine generische Bewerbung an hundert Unternehmen schicken. Sich mit der Stelle beschäftigen. Die eigene Bewerbung prüfen lassen — von KI, von Freunden, von wem auch immer. Und dann nochmal prüfen.

Lass dir deine Bewerbung von ChatGPT durchlesen. Dann von Gemini. Schau, was beide sagen. Und dann entscheide selbst, was davon zu dir passt — denn wenn eine KI plötzlich hochgestochenes Kanzleideutsch aus dir macht, du aber eigentlich bodenständiger Handwerker bist, dann klingt das nicht nach dir. Und das hilft niemandem.

Wie fängt man an?

Das war die praktischste Frage des Abends, und sie verdient eine praktische Antwort:

Schritt 1: Öffne chat.openai.com oder gemini.google.com. Schreib rein, was dich beschäftigt. Stell eine Frage. Schau, was passiert. Kein Tutorial, kein Kurs — einfach machen.

Schritt 2: Nimm ein konkretes Problem, das dir gerade im Kopf rumgeht — deine Bewerbung, ein Anschreiben, eine schwierige E-Mail. Und unterhalte dich mit der KI darüber wie mit einem Freund. Nicht als Suchmaschine, sondern als Gesprächspartner.

Schritt 3: Gib der KI eine Rolle. Sag ihr: „Du bist HR-Mitarbeiter bei Firma X. Hier ist meine Bewerbung. Was würdest du daran bemängeln?“ Du wirst überrascht sein, wie anders die Antwort wird — und wie viel konkreter.

Die Angst vor KI verliert man nicht durch Nachdenken. Man verliert sie durch Benutzen.

Ein Tipp noch — für alle, die gerade bei null anfangen

Der KI-Podcast der ARD hat vor Kurzem eine Folge rausgebracht zum Thema: Wie fange ich 2026 mit KI an? Ist es zu spät? Was mache ich zuerst? Wirklich empfehlenswert — kein Tech-Insider-Geraune, sondern ehrlich für Einsteiger gemacht.

Was ich mitgenommen habe

Ich sehe mich nicht als KI-Missionar. Das ist nicht mein Ding.

Aber dieser Termin hat mir gezeigt, dass wir in der IT sehr schnell vergessen, wie weit wir von der Realität anderer Menschen entfernt sind. Wir diskutieren über Kontextfenster und Modellvergleiche, während andere noch nicht mal wissen, dass man KI kostenlos nutzen kann.

Das ist keine Kritik an irgendjemandem — das ist einfach so. Aber ab und zu aus der eigenen Bubble rausgucken und sich fragen: Was beschäftigt eigentlich die Menschen, die nicht täglich mit diesem Thema arbeiten? Das tut gut. Mir jedenfalls.

Und das Schönste daran: Was heute noch nicht funktioniert, funktioniert in einem halben Jahr. Ich hab das selbst erlebt — spielmit.eu hätte ich vor einem Jahr mit KI nicht so bauen können wie Anfang dieses Jahres. Die Entwicklung geht schneller als jeder Kurs hinterherkommt.

Also: Gebt KI eine Chance. Probiert Dinge nochmal aus, die vor einem Jahr nicht geklappt haben. Und verliert die Angst — nicht durch Reden darüber, sondern durch Machen.

Der Beitrag Angst vor KI überwinden — und der Moment, in dem mir klar wurde, wie weit wir in der Bubble sind erschien zuerst auf Das ist die Welt von Thomas.

Ich bin Softwarearchitekt. Seit vielen Jahren. Und ich habe mich vor einiger Zeit auch mal in Richtung Business Analyse bewegt — bewusst, mit einem klaren Grund. Aus dieser Kombination heraus habe ich eine ziemlich konkrete Meinung zu der Frage. Hier ist sie.

Warum ich überhaupt in Richtung Business Analyse gegangen bin

Projekte scheitern nicht, weil Entwickler schlecht sind. Das ist meine feste Überzeugung. Sie scheitern, weil zwei Welten aneinander vorbeireden: der Fachbereich und die IT. Beide sprechen unterschiedliche Sprachen, beide meinen es gut, und am Ende entsteht Software, die niemanden wirklich glücklich macht.

Ich glaube, ich kann einem Fachbereich komplexe Dinge einfach erklären. Und ich kann durch die richtigen Fragen helfen, die richtige Lösung zu finden — oder zumindest die Basis dafür. Das wollte ich mit der Business Analyse nutzen. Raus aus dem reinen Entwicklerdenken, rein in die fachliche Welt, um genau an dieser Schnittstelle besser zu werden.

Das ist eine Fähigkeit, die — so viel sei vorweggenommen — in einer KI-Welt nicht weniger wichtig wird. Im Gegenteil.

Was sich gerade wirklich verändert

AI leistet heute schon Erstaunliches. Das ist keine Frage mehr. Wer das bezweifelt, hat vermutlich noch keinen echten Entwicklungsalltag mit einem LLM verbracht.

Aber: AI nutzt die Freiheiten, die man ihr gibt. Vollständig. Und das ist genau das Problem.

In meinen eigenen Projekten habe ich erlebt, wie AI plötzlich veraltete Libraries eingesetzt hat, ohne mit der Wimper zu zucken. Ich habe gesehen, wie Security-Themen einfach ignoriert wurden — Software offen wie ein Scheunenohr. Dokumentation? Fehlanzeige, wenn man nicht explizit danach fragt. Und Architekturentscheidungen trifft die AI eben auch selbst, wenn man ihr keinen Rahmen vorgibt.

Das bedeutet nicht, dass AI schlecht ist. Das bedeutet, dass man wissen muss, was man ihr übergibt — und was nicht.

Der Softwareentwickler als Dompteur

Mein Bild für die Zukunft des Entwicklers ist das des Dompteurs. Nicht der, der die Tiere besiegt. Sondern der, der weiß, wie sie ticken, und der die Richtung vorgibt.

Was braucht es dafür konkret?

Fachlichkeit. Der zukünftige Entwickler muss verstehen, was ein Fachbereich wirklich braucht. Nicht um es selbst zu bauen, sondern um es der AI so aufzubereiten, dass die AI es sauber umsetzen kann. Wer nur Code schreibt, aber keine Anforderungen versteht, hat ein Problem.

Architekturkompetenz. Welches Framework? Welche Architektur? Wie wird das System betrieben? Diese Entscheidungen kann die AI nicht alleine treffen — zumindest nicht sinnvoll. Hier braucht es Erfahrung.

Review und Qualitätssicherung. Prüfen, ob das was die AI gebaut hat, auch wirklich zur Fachlichkeit passt. Ob es sicher ist. Ob es wartbar ist. Das ist kein Nice-to-have, das ist Kernaufgabe.

Guidelines setzen. Rahmenbedingungen für AI-Entwicklung definieren: Security-Standards, Coding-Guidelines, Testabdeckung. Wer das nicht einfordert, bekommt einen Jenga-Turm — von außen stabil, innen wackelig.

Macht mir das Angst?

Ehrlich gesagt: Nein.

Ich sehe AI als Werkzeug. Wie den Akkuschrauber. Als der auf den Markt kam, ist kein einziger Handwerker pleite gegangen. Sie wurden schneller, effizienter, konnten mehr liefern. Nur weil man jetzt einen Hammer hat, ist ja nicht alles gleich ein Nagel.

Wir müssen wissen, welches Werkzeug wir wann einsetzen. Wir müssen lernen, wie es funktioniert. Wer heute sagt „KI macht mich arbeitslos, also ignoriere ich sie“ — der hat das falsch verstanden. Wer heute sagt „KI macht alles, ich muss nichts mehr können“ — der auch.

Die Industrie hat das schon einmal erlebt. Neue Maschinen, neue Techniken, neue Produktivität. Die Arbeitswelt hat sich verschoben, nicht aufgehört.

Was heute schon klar ist

Einen Junior-Entwickler zu beraten, was er in Zukunft tun soll? Ehrlich — ich hab da keine perfekte Antwort. Die Welt verändert sich gerade schnell genug, dass langfristige Karriereratschläge mit Vorsicht zu genießen sind.

Was ich sagen kann: Fachlichkeit, Kommunikationsfähigkeit und der Wille, neue Werkzeuge zu verstehen und zu nutzen — das wird nicht weniger gefragt sein. Wer diese Kombination mitbringt, hat auch in einer KI-getriebenen Entwicklungswelt seinen Platz.

Und wer jetzt anfängt, mit AI zu entwickeln, zu experimentieren und zu lernen wo die Grenzen liegen — der ist schlicht besser aufgestellt als jemand, der abwartet.

Wie seht ihr das? Ich bin gespannt auf eure Perspektive — schreibt’s in die Kommentare.

Der Beitrag Softwareentwickler und KI – wer hat morgen noch einen Job? erschien zuerst auf Das ist die Welt von Thomas.

War es nicht.

Was mich dabei mehr beschäftigt als das Produkt selbst: Was KI-getriebene Produktentwicklung wirklich bedeutet – und warum das größte Risiko nicht der Code ist, sondern der Moment, in dem man der AI einfach antwortet.

Das Grundproblem: Die AI will alles. Sofort. Vollständig.

Stell dir vor, du engagierst einen hochmotivierten Architekten für dein neues Haus. Noch bevor du „Hallo“ gesagt hast, fragt er: Wie viele Stockwerke? Welche Heizung? Soll die Küche offen oder geschlossen sein? Kellergarage oder nicht? Welche Fensterfront gen Süden?

Genau so verhält sich eine AI in der Anforderungserhebung.

Claude – mein Entwicklungspartner in diesem Projekt – stellte von Anfang an präzise, durchdachte Fragen. Die zielten auf eine vollständige, ganzheitliche Lösung ab. Architektonisch macht das Sinn. Produktentwicklungstechnisch ist es eine Falle.

Denn: Wer von Anfang an alles entscheidet, entwickelt am Ende perfekt an den echten Bedürfnissen vorbei.

Das klassische Wasserfallproblem – nur mit KI-Turbo.

Wasserfall 2.0: Schneller in die falsche Richtung

Das Wasserfallmodell ist nicht deshalb gescheitert, weil Menschen zu dumm waren, es umzusetzen. Es ist gescheitert, weil sich Anforderungen verändern, sobald man anfängt, sie zu konkretisieren. Weil der erste echte Nutzer immer Dinge sieht, die kein Workshop-Teilnehmer vorhergesehen hat. Weil Lernen durch Tun nicht durch Planen ersetzt werden kann.

KI-getriebene Entwicklung löst dieses Problem nicht automatisch. Im Gegenteil: Sie beschleunigt es. Man kann in wenigen Stunden ein vollständiges Konzept durchdenken, dokumentieren und in Code überführen – und dabei systematisch an den echten Nutzerbedürfnissen vorbeientwickeln.

Bei spielmit.eu hatte ich genau diesen Moment. Früh wurden UI-Entscheidungen getroffen: Welche Buttons gibt es? Welche Aktionen sind auf welchem Screen verfügbar? Das Ergebnis war ein Interface voller Funktionen – technisch korrekt umgesetzt, aber praktisch eine Zumutung. Tausend Buttons, überladene Screens, keine klare Führung. Erst nach echten Tests und vielen Iterationen kam man auf eine schlanke Lösung.

Wäre man iterativer vorgegangen, hätte das nach dem ersten echten Klick auffallen müssen. Nicht nach zwanzig Entwicklungsrunden.

Die Lösung: Aktiv bremsen, iterativ lernen

Das Gegenmittel klingt einfach. Es ist es nicht.

Als die AI begann, Fragen zu stellen, die ich noch gar nicht beantworten konnte – oder sollte –, musste ich aktiv eingreifen. Meine Standardantwort wurde:

„Damit beschäftigen wir uns später. Lass uns iterativ vorgehen und gemeinsam lernen.“

Das klingt banal. In der Praxis erfordert es diszipliniertes Zurückhalten. Die AI bietet immer eine Antwort an, die sich vollständig und plausibel anfühlt. Die Versuchung, einfach mitzumachen, ist groß.

Was konkret geholfen hat:

Interview statt Fragebogen. Statt alle Fragen auf einmal zu beantworten, habe ich Claude gebeten, sie einzeln zu stellen. Eine Frage. Meine Antwort. Nächste Frage. Das reduziert die Gefahr, sich in frühen Annahmen zu verlieren, dramatisch.

Fachlichkeit vor Technik. Bevor auch nur eine Zeile Code geschrieben wurde, haben wir stundenlang nur die fachliche Logik durchdrungen. Was ist das eigentliche Problem? Wer hat es? Was ist der kleinstmögliche Schritt, der echten Wert liefert?

Kleine, dokumentierte MD-Files statt einem Monolith. Alles landet im Projektverzeichnis – aber verteilt auf kleine, fachlich fokussierte Markdown-Dateien. Eine pro Thema, nicht eine für alles. Das hält das Kontextfenster handhabbar und vermeidet, dass die AI wichtige Anforderungen aus dem Blick verliert.

Prioritäten setzen, nicht alles gleichzeitig. Bei spielmit.eu war von Anfang an klar: Datenschutz und Security sind nicht verhandelbar, alles andere ist nachrangig. Dieses Primat musste ich aktiv verteidigen – nicht einmal, sondern immer wieder.

Nicht-Determinismus: Das unterschätzte Risiko

Eine AI ist kein deterministisches System. Das klingt technisch. Die praktischen Konsequenzen sind handfest.

Derselbe Fehler kann in zwei aufeinanderfolgenden Sessions unterschiedlich interpretiert werden. Einmal findet die AI ihn. Beim nächsten Anlauf übersieht sie ihn – weil sie zwischendurch andere Anforderungen priorisiert hat, weil der Kontext gewachsen ist, weil… nun ja, weil sie eben nicht deterministisch ist.

Man dreht sich im Kreis, ohne es zu merken.

Das erfordert eine Qualität, die kein Prompt ersetzen kann: eigene Wachheit. Als PO oder Architekt muss man verstehen, was gerade wirklich passiert. Wer das vollständig abgibt, verliert die Kontrolle – leise, ohne Drama, und oft erst dann sichtbar, wenn es teuer wird.

Was die AI einfach nicht mitdenkt

Irgendwann habe ich in den Code geschaut. Veraltete Vue-Libraries, fast überall outdated minor versions. Der anschließende Update-Marathon kostete unnötig Zeit – und funktioniert hat er nur, weil wir eine hohe Testabdeckung hatten.

Das Ärgerliche: vollständig vermeidbar. Ein einfacher Check zu Projektbeginn hätte das verhindert. Die AI denkt nicht von alleine an Library-Hygiene, Security-Checks oder Dependency-Management.

Das sind keine Kleinigkeiten. Es sind genau die Dinge, die erfahrene Entwickler im Schlaf prüfen – und die beim KI-getriebenen Entwickeln aktiv eingefordert werden müssen. Am Anfang. Nicht nach zwanzig Iterationen.

Dasselbe gilt fürs Refactoring. Bei größeren Umstrukturierungen wurden Anforderungen vergessen, „zentralisierter“ Code tauchte trotzdem noch an alter Stelle auf. Clean Code und Testabdeckung sind keine akademischen Tugenden. Sie sind das Einzige, was einen vor dem Jenga-Turm rettet – dem Produkt, das von außen funktioniert, das man aber nicht mehr anfassen möchte.

Was AI in der Anforderungserhebung wirklich gut kann

Was KI in der Anforderungserhebung wirklich gut kann? Blinde Flecken aufdecken. Sie stellt Fragen die man selbst nicht stellt – einfach weil man zu nah am Problem dran ist. Genauso gut kann sie Perspektivwechsel erzwingen. „Wie würde ein datenschutzbewusstes Elternteil darauf reagieren?“ – solche Fragen lassen sich schnell und konsequent durchspielen. Was sie dabei aber nicht kann: entscheiden. Die Konsequenzen durchdenken ja, die Entscheidung treffen nein. Das bleibt beim Menschen – weil nur der weiß was er noch nicht weiß.

Der Trick ist, die AI aktiv zum Mitdenken anzuregen. Sie tut das nicht von alleine. Man muss fragen: „Welche Annahme, die wir gerade treffen, könnte sich als falsch herausstellen?“ Oder: „Was spricht dagegen?“

Fazit: AI First ist (noch) keine Option

KI-getriebene Entwicklung funktioniert. Mit Spielregeln, mit Disziplin, mit dem Willen, klein anzufangen und lieber öfter zu lernen als schnell zu skalieren.

AI First – also vollständige Entwicklung ohne menschliche Architektur-Entscheidungen, ohne Review, ohne iteratives Korrektiv – ist heute noch nicht möglich. Wer es trotzdem versucht, bekommt entweder ein Produkt, das die fachlichen Anforderungen nicht erfüllt. Oder, schlimmer, eines, bei dem man das glauben könnte – darunter aber ein Fundament aus technischen Schulden, das nur durch Zufall noch steht.

Die gute Nachricht: Die Kombination aus menschlicher Erfahrung und AI-Geschwindigkeit ist mächtig. Alleine hätte ich spielmit.eu nie gebaut – der Aufwand wäre zu groß gewesen für ein kostenloses Freizeitprojekt. Mit AI als Entwicklungspartner war es möglich.

AI First – also vollständig ohne menschliches Korrektiv – funktioniert heute noch nicht. Wer es trotzdem versucht, merkt das früher oder später. Ich bin froh, dass ich es in der Freizeit gelernt habe.

Der Beitrag KI-getriebene Anforderungserhebung: Warum du die AI bremsen musst, bevor du startest erschien zuerst auf Das ist die Welt von Thomas.

Mir ging es genauso. Und irgendwann habe ich beschlossen, das Problem zu lösen.

Wenn Spielverabredungen zum Organisationsmarathon werden

Ob im Kindergarten oder in der Grundschule – die Situation ist immer die gleiche: Man kennt sich vom Sehen, aber der Schritt zur konkreten Verabredung ist oft erstaunlich schwierig. Es scheitert an banalen Dingen: Welcher Nachmittag passt? Hat das andere Kind Zeit? Wie erreiche ich die Eltern überhaupt?

In WhatsApp-Gruppen geht die Frage „Hat jemand heute Nachmittag Zeit zum Spielen?“ zwischen Kuchenbestellungen und Laternen-Bastelanleitungen unter. Aushänge werden übersehen. Und nicht alle Eltern möchten ihre Handynummer in einer Gruppe mit 25 Familien teilen – verständlich.

Dabei ist das gemeinsame Spielen für Kinder unglaublich wichtig. Freundschaften entstehen nicht nur in der Kita oder Schule, sondern vor allem nachmittags – beim Toben im Garten, beim Lego bauen oder beim gemeinsamen Abenteuer auf dem Spielplatz. Als Vater wollte ich meiner Tochter das ermöglichen, ohne jedes Mal eine halbe Stunde Organisationsaufwand zu haben.

Von der Idee zum Projekt: „Dann mach ich’s halt selbst“

Die Idee zu einer Plattform für Spielverabredungen trage ich schon länger mit mir herum. Ich habe sie immer wieder mit anderen Eltern diskutiert – im Kindergarten, auf dem Spielplatz, beim Abholen. Die Reaktion war jedes Mal die gleiche: „Das wäre großartig, so etwas bräuchten wir!“

Also habe ich gesucht. Nach einer App, einer Plattform, irgendetwas, das genau dieses Problem löst. Gefunden habe ich: nichts. Es gibt Familien-Kalender, Eltern-Netzwerke, Messenger-Gruppen – aber keine einfache Lösung, die nur diese eine Frage beantwortet: Wer hat wann Zeit zum Spielen?

Also habe ich spielmit.eu gebaut. Nicht als Startup, nicht als Geschäftsmodell. Sondern weil ich das Problem selbst hatte und es für alle Eltern kostenlos lösen wollte.

Einfach, weil es einfach sein muss

Das Konzept ist bewusst simpel gehalten:

• Spielgruppen erstellen – zum Beispiel „Kindergarten Sonnenblume“ oder „Klasse 2a“. Über einen Einladungslink treten andere Eltern bei.
• Verfügbarkeit eintragen – jede Familie gibt an, an welchen Nachmittagen ihr Kind Zeit hat.
• Spielpartner finden – der Finder zeigt auf einen Blick, welche Kinder aus der Gruppe heute oder morgen verfügbar sind.
• Verabredung vorschlagen – mit Datum, Uhrzeit und Aktivität. Die andere Familie bekommt eine Benachrichtigung und kann zusagen oder absagen.

Kein Social Media, keine Werbung, keine endlosen Chats. Einfach nur: Wer hat wann Zeit zum Spielen?

Datenschutz ist nicht optional – besonders bei Kindern

Als IT-Berater und Vater war mir eines von Anfang an wichtig: Datenschutz. Wir reden hier über Kinder. Da gibt es keine Kompromisse.

Deshalb haben Kinder bei spielmit.eu keine eigenen Accounts. Es gibt keine Fotos – stattdessen wählt jedes Kind ein lustiges Emoji als Avatar. Die Plattform ist DSGVO-konform, alle Daten liegen in der EU (Frankfurt), und Eltern können ihre Daten jederzeit vollständig exportieren oder löschen lassen.

Diese bewusste Entscheidung gegen „je mehr Daten, desto besser“ war mir wichtig. Kinder brauchen Schutz, nicht noch eine Plattform, die ihre Daten sammelt.

Von der Idee zur fertigen App – mit KI als Entwicklungspartner

Hier wird die Geschichte besonders: Ich habe spielmit.eu nicht mit einem klassischen Entwicklerteam gebaut. Ich habe die gesamte Plattform in enger Zusammenarbeit mit Claude entwickelt – dem KI-Assistenten von Anthropic.

Bevor jemand denkt, ich hätte „einfach ein paar Prompts eingegeben und fertig“: So funktioniert das nicht. Was als Experiment begann, wurde zu einem intensiven Entwicklungsprozess über viele Wochen und hunderte Iterationen. Ich habe die Architektur entworfen, Entscheidungen getroffen, Code reviewt und getestet. Claude hat mir dabei geholfen, diese Entscheidungen schnell und in hoher Qualität umzusetzen.

Wer sich für die technische Seite interessiert – wie man KI-gestützte Softwareentwicklung richtig macht, mit Architektur-Dokumentation, Tests und Sicherheit – dem empfehle ich meinen Artikel „Mehr als nur ein Prompt: Warum Architektur-Dokumentation das Geheimnis meines KI-Projekts ist“.

Was spielmit.eu heute kann

Mittlerweile ist die Plattform unter spielmit.eu live und wird von ersten Familien genutzt. Ein paar Highlights:

• Spielpartner-Finder: Zeigt auf einen Blick, welche Kinder aus der Gruppe diese Woche verfügbar sind – inklusive gemeinsamer Interessen.
• Spontan-Anfragen: „Wer hat HEUTE um 15 Uhr Zeit?“ – eine Nachricht an alle verfügbaren Familien der Gruppe.
• Push-Benachrichtigungen: Neue Einladungen und Nachrichten kommen direkt aufs Handy.
• Android App im Play Store: Kann direkt als App installiert werden.
• Nachrichten: Direkter Kontakt zwischen Familien, ohne Telefonnummern tauschen zu müssen.

Und das Beste: spielmit.eu ist komplett kostenlos. Keine Premium-Features, keine versteckten Kosten. Ich habe die Plattform gebaut, weil ich das Problem selbst hatte – nicht um damit Geld zu verdienen.

Für wen ist spielmit.eu gedacht?

Die Plattform ist für alle Eltern, die Spielverabredungen einfacher organisieren wollen:

• Kindergarten-Eltern, die andere Familien besser kennenlernen möchten
• Grundschul-Eltern, deren Kinder nachmittags Spielpartner suchen
• Zugezogene Familien, die in einer neuen Umgebung Anschluss suchen
• Berufstätige Eltern, die wenig Zeit für aufwändige Absprachen haben
• Elternbeiräte, die eine einfache Lösung für ihre Gruppe suchen

Ein Elternteil erstellt eine Gruppe, teilt den Einladungslink – und schon kann es losgehen. Keine Registrierungshürden, keine Kosten.

Mitmachen: Ich suche Unterstützung!

spielmit.eu ist ein Herzensprojekt – und es gibt noch viel zu tun. Aktuell ist die App im Google Play Store für Android verfügbar. Für eine iOS-App im Apple App Store fehlt mir allerdings ein Apple Developer Account. Zwar ist die App auf iOS heute als PWA App nutzbar (also manuell über die Webseite installierbar), eine App im Store wäre jedoch deutlich schöner.

Deshalb mein Aufruf: Wenn du Lust hast, dich an diesem Projekt zu beteiligen – sei es als Tester, mit Feedback oder mit technischer Unterstützung – melde dich gerne bei mir. Besonders freue ich mich über Kontakt zu Personen, die einen Apple Developer Account haben und Erfahrung mit dem Veröffentlichen von Apps im App Store mitbringen. Gemeinsam könnten wir spielmit.eu auch für iPhone-Nutzer als native App verfügbar machen.

Was ich als Vater dabei gelernt habe

Dieses Projekt hat mir zwei Dinge gezeigt:

Erstens: Die Hürde, sein Kind zu verabreden, ist oft höher als man denkt. Es liegt selten am fehlenden Willen der Eltern – es fehlt einfach ein einfacher Weg, sich zu koordinieren. Genau diese Lücke füllt spielmit.eu.

Zweitens: KI verändert, was ein einzelner Mensch umsetzen kann. Alleine hätte ich für ein Projekt dieser Größenordnung Wochen, vermutlich Monate gebraucht. Mit einem Team? Hätte ich es als Non-Profit-Projekt wahrscheinlich nie gemacht – der Abstimmungsaufwand wäre einfach zu groß gewesen für etwas, das kostenlos bleiben soll. Durch Claude als Entwicklungspartner wurde der gesamte Entwicklungsprozess extrem beschleunigt. Aber Vorsicht: Ein Selbstläufer ist KI-gestützte Entwicklung definitiv nicht. Ich habe die Architektur entworfen, jede Entscheidung getroffen, Code reviewt, getestet und immer wieder korrigiert. Claude ist ein hocheffizienter Assistent – aber kein Autopilot.

Ausprobieren?

Wenn du Kinder im Kindergarten- oder Grundschulalter hast und Spielverabredungen einfacher organisieren willst, probier es aus: spielmit.eu

Erstell eine Gruppe für eure Kita oder Klasse, teil den Link mit anderen Eltern, und schau was passiert. Ich freue mich über jede Familie, die mitmacht – und über jedes Kind, das dadurch einen Spielnachmittag mehr bekommt.

Du hast Fragen, Feedback oder möchtest dich beteiligen? Schreib mir gerne – ich freue mich über jede Rückmeldung.

Der Beitrag Spielverabredungen für Kinder organisieren – Wie ich als Vater eine App gebaut habe, die Eltern den Alltag erleichtert erschien zuerst auf Das ist die Welt von Thomas.

Vom „Vibecoding“ zur stabilen Architektur

Für spielmit.eu habe ich mich auf Neuland gewagt: Es waren meine ersten echten Gehversuche mit einer Progressive Web App (PWA) und Firebase Firestore. Die Funktionen der Anwendung sind mittlerweile extrem umfangreich – und ich gebe offen zu: Ohne KI hätte ich diesen Funktionsumfang in dieser Zeit niemals erreicht. Die KI hat mir einen enormen Teil der „Fleißarbeit“ abgenommen, von der Modellierung der Daten bis hin zu komplexen Cloud-Function-Logiken.

Doch wer heute solche Systeme baut, weiß: Wer sich blind auf die KI verlässt, erntet schnell technische Schuld. Um das Projekt nachhaltig und wartbar zu halten, habe ich die KI als hocheffizienten, aber streng geführten Assistenten eingesetzt:

• Test-Pflicht als Dogma: Sicherheit entsteht durch Transparenz. Ich habe die KI konsequent dazu gezwungen, für jede Funktion umfassende Testfälle zu schreiben. Ein Feature war erst dann „fertig“, wenn die Test-Suite – die ich selbst mit-definiert habe – komplett grün war.
• Die ARCHITECTURE.md als Anker: Um zu verhindern, dass die KI bei der Generierung vom Pfad abweicht, habe ich eine zentrale Architektur-Dokumentation erstellt. Sie dient als mein „System-Gedächtnis“. Jede Änderung der KI musste sich an dieser Architektur messen lassen.
• Sicherheit durch Disziplin: Die Firestore-Sicherheitsregeln waren mein größtes Lehrstück. Mal waren sie zu offen, mal zu restriktiv. Hier half kein „Bitten“, sondern konsequentes Testen, bis die Regeln exakt den Sicherheitsanforderungen entsprachen.

Ein enormer Lernweg

Auch wenn die KI viele Prozesse beschleunigt hat, war das Projekt für mich eine intensive Lernreise. Die Arbeit mit Firebase-Regeln, Triggern, Indizes und Laufzeitbeschränkungen hat mir tiefe Einblicke gegeben, die weit über das hinausgehen, was man in einem Tutorial lernt. Ich wollte nicht nur ein Tool „hingezaubert“ bekommen, sondern verstehen, wie man moderne Software nachhaltig aufbaut und wartbar hält.

Fazit

spielmit.eu ist heute ein lebendes System, das ich – dank der Architektur-Dokumentation und der engen Einbindung der KI – souverän weiterentwickeln kann. Mein Lernfazit: KI-gestützte Softwareentwicklung ist eine fantastische Hebelwirkung, sofern man ihr einen extrem strikten Rahmen vorgibt. Der „No-Brainer“-Moment existiert noch nicht – aber mit der richtigen Struktur wird die KI zu einem mächtigen Werkzeug für das eigene technische Verständnis.

Neugierig geworden? Wenn du auch genug vom WhatsApp-Chaos hast: Schau gerne bei spielmit.eu vorbei und probiere es aus. Ich freue mich riesig über jedes Feedback, das mir hilft, die Plattform noch besser und intuitiver zu machen!

Der Beitrag Mehr als nur ein Prompt: Warum Architektur-Dokumentation das Geheimnis meines KI-Projekts ist erschien zuerst auf Das ist die Welt von Thomas.