PM werden im KI-Zeitalter 05 | Bleib vage, und die KI füllt die Lücken für dich

Du sagst der KI „bau ein Login”.

Sie baut es dir. Aber zwischen diesem einen Satz und dem fertigen Code trifft sie eine ganze Reihe von Entscheidungen, die du nie erwähnt hast: E-Mail oder Telefonnummer, mit oder ohne Bestätigungscode, nach wie vielen falschen Passwörtern das Konto gesperrt wird, wie lange, ob in der Fehlermeldung „Passwort falsch” oder „Konto oder Passwort falsch” steht, ob es ein „Angemeldet bleiben” gibt, wie lange die Sitzung gültig ist. Keine dieser zwölf Entscheidungen hast du getroffen — sie hat sie alle für dich geraten.

Das Problem ist nicht, ob sie richtig rät, sondern dass sie überhaupt nicht fragt. Hätte ein Mensch den Job übernommen, hätte er zurückgefragt: „Ist unser Login per Telefonnummer oder per E-Mail?” Die KI tut das nicht. Sie ist eine yes-machine: sie macht, was du sagst, nicht, was du meinst. An den Stellen, die in der Anforderung nicht vorkommen, setzt sie den Default ein, den sie im Training am häufigsten gesehen hat — Validierungsregeln, Ablauflogik, Fehlerbehandlung, für alles füllt sie etwas nach, und meist ist es nicht das, was du wolltest.

Sean Grove von OpenAI hat einmal gesagt: Der Code, den du schreibst, macht nur 10 bis 20 % deines Werts aus, die übrigen 80 bis 90 % sind, das Zu-Bauende klar zu formulieren. Wenn die KI den Schritt „rausschreiben” komplett übernimmt, bleibt für dich genau jene vorgelagerten 80 % — die Anforderung so weit zu treiben, dass sie keine Mehrdeutigkeit mehr enthält. Hier sind vier Handgriffe zum Nachmachen.

1. Adjektive durch Zahlen ersetzen

„Etwas schneller”, „etwas einfacher”, „auffälliger”, „gute Erfahrung” — solche Wörter kann die KI nicht überprüfen, sie kann sie nur selbst definieren. Jemand schrieb der KI „das System soll schnell auf Überstrom reagieren”, und die KI markierte diesen Punkt direkt als „nicht überprüfbar”: Es gibt keinen messbaren Schwellenwert, wie schnell ist „schnell”?

Ersetze die Adjektive durch Zahlen, und die Mehrdeutigkeit verschwindet. Aus „das Laden soll schnell sein” wird „der erste Bildschirm erscheint innerhalb von 1,5 Sekunden”; aus „die Liste soll nicht zu lang sein” wird „maximal 8 Einträge pro Bildschirm, ab dann blättern”; aus „der Button soll auffällig sein” wird „Button in der Primärfarbe, Kontrast zum Hintergrund hoch genug zum klaren Erkennen”. Was sich als Zahl oder Regel schreiben lässt, soll kein Adjektiv bleiben.

2. Alle Zustände ausschreiben

doaipm betont durchgehend die vier realen Zustände: Laden, Leer, Fehler, Erfolg. Sagst du nur „bau eine Bestellliste”, baut die KI dir standardmäßig den Erfolgszustand — Daten vorhanden, Netz gut, alles in Ordnung.

Bestellliste: Beim Laden ein Skeleton-Screen anzeigen; wenn keine einzige Bestellung existiert, „Noch keine Bestellungen” anzeigen plus einen Einstieg zum Bestellen; schlägt die Anfrage fehl, „Laden fehlgeschlagen, zum Wiederholen tippen” anzeigen; im Normalfall pro Eintrag Bestellnummer, Betrag und Status anzeigen.

Wie eine leere Liste aussieht, was der Nutzer während des Ladens sieht, wie ein Fehler gemeldet wird — diese drei schreibst du nicht hin, dann macht die KI sie entweder gar nicht oder füllt irgendetwas nach. In echten Produkten ist die Wahrscheinlichkeit, dass Nutzer auf Leer und Fehler stoßen, weit höher, als du denkst.

3. Die Grenzfälle auflisten

Am leichtesten weggelassen — und am leichtesten schiefgegangen — sind die Ausnahmepfade. Untersuchungen dazu, welche Annahmen die KI bei unscharfen Anforderungen nachfüllt, zeigen: Genau hier füllt sie am meisten nach — was passiert, wenn Daten abgelaufen sind, wenn jemand ohne Berechtigung zugreift, wenn zwei Personen denselben Eintrag gleichzeitig bearbeiten, wenn etwas in einen Timeout läuft.

Baust du einen Gutschein, musst du das klar formulieren: Was erscheint, wenn der Nutzer bei abgelaufenem Gutschein auf „Einlösen” tippt; wem derselbe Gutschein zugerechnet wird, wenn zwei Geräte gleichzeitig bestellen; ob der Gutschein zurückkommt, wenn der Nutzer ihn halb eingelöst und dann eine Erstattung erhalten hat. Listest du das nicht auf, denkt sich die KI für jeden Fall eine Annahme aus, und erst wenn es in Produktion knallt, merkst du, wie sie damals geraten hat.

4. Nach dem Schreiben mit einem Null-Kontext-Test selbst prüfen

Ob eine Anforderung klar genug ist, dafür gibt es ein fertiges Maß: Gib sie jemandem, der von diesem Projekt überhaupt nichts versteht — kann er danach genau das bauen, was du im Kopf hattest? Verstehen zwei Leute nach dem Lesen es auf zwei verschiedene Weisen, ist es noch nicht klar genug; zerleg weiter, bis keine Mehrdeutigkeit mehr übrig ist.

Wenn dir das zu mühsam ist, gibt es einen noch bequemeren Weg: Lass die KI erst nicht loslegen, sondern die Annahmen, die sie für dich nachfüllen will, einzeln auflisten. Was sie da auflistet — „ich nehme standardmäßig an, der Gutschein gilt sortimentweit”, „ich gehe von 7 Tagen Gültigkeit aus” — das sind genau die Stellen, die du eben nicht klar gesagt hast. Stopf sie, bevor sie loslegt.

Eine Sache, die du heute tun kannst: Such dir eine Anforderung aus, die du gerade der KI zuwerfen willst, schick sie noch nicht ab, sondern geh sie einmal nach „Adjektive durch Zahlen, alle Zustände ausschreiben, Grenzfälle auflisten” durch und schick sie dann erst. Vergleich danach, wie weit dieses Ergebnis von dem abweicht, das du achtlos abgeschickt hättest.

Weiterführende Links

• Sean Grove (OpenAI) „The New Code”: Die Spezifikation ist 80–90 % deines Werts — https://www.youtube.com/watch?v=8rABwKRsec4
• Improve & Repeat „Why Requirements Matter So Much for AI Coding Agents” (die Liste der Annahmen, die KI bei unscharfen Anforderungen nachfüllt): https://improveandrepeat.com/2026/04/why-requirements-matter-so-much-for-ai-coding-agents/
• Teil 03 dieser Serie „Behandle KI als Kollegen, nicht als Werkzeug”: /de/blog/ai-as-colleague/
• Teil 04 dieser Serie „Das Urteil „sollten wir es bauen” kostet jetzt mehr als „können wir es bauen"": /de/blog/judgment-over-feasibility/