Ich habe Anfang Februar in meiner Freizeit eine App gebaut. Mit AI, ohne klassisches Entwicklerteam. Das Ergebnis ist spielmit.eu – eine Plattform, die Eltern hilft, Spielverabredungen für ihre Kinder unkompliziert zu organisieren. Klingt nach einem netten Wochenendprojekt.

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 am Anfang jede Kreuzung entscheidet, hat am Ende ein Produkt, das perfekt auf die falschen Annahmen zugeschnitten ist.

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 erfahrene Devs wissen müssen – und AI nicht von alleine denkt

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

Das klingt bisher wie eine Warnung. Es soll auch eine sein – aber keine Absage.

KI in der Anforderungserhebung kann enorm wertvoll sein. Besonders in drei Bereichen:

Blinde Flecken aufdecken. Eine AI stellt Fragen, die man selbst nicht gestellt hätte. Sie denkt Szenarien durch, die im eigenen Kopf nicht vorkommen, weil man zu nah am Problem ist.

Andere Blickwinkel erzwingen. „Wie würde ein datenschutzbewusstes Elternteil darauf reagieren?“ – solche Perspektivwechsel lassen sich schnell und konsequent durchspielen.

Dinge durchdenken, nicht durchentscheiden. Der Unterschied ist wichtig. AI hilft dabei, Konsequenzen zu durchdenken. Die Entscheidung muss beim Menschen bleiben – weil nur der Mensch 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.

Ich bin froh, dass ich die Grenzen dieses Ansatzes in meiner Freizeit gelernt habe. Und nicht beim nächsten Kundenprojekt.

Wer Kinder im Kita- oder Grundschulalter hat: spielmit.eu – kostenlos, DSGVO-konform, keine Werbung.

Den Artikel über die technische Seite des Projekts gibt es hier: Mehr als nur ein Prompt: Warum Architektur-Dokumentation das Geheimnis meines KI-Projekts ist