Tetris, Vibe Coding und die Output-Falle

Warum Produktmanagement im AI-Zeitalter neu denken muss

Kennst du das Gefühl, wenn eine Tetris-Reihe verschwindet? Dieser kurze, befriedigende Moment. Klick. Weg. Nächste Steine fallen.

Tetris ist ein Lehrstück über Motivation. Klare Ziele. Sofortiges Feedback. Sichtbarer Fortschritt. Die Flow-Forschung beschreibt genau das als die Zutaten für tiefe Konzentration: Du weißt, was du tun musst. Du siehst sofort, ob es geklappt hat. Und du willst mehr davon.

Das Scoreboard von Tetris misst eine einzige Sache: Linien gelöscht. Nicht ob du Spaß hattest. Nicht ob das Spiel dich weitergebracht hat. Linien löschen ist das Ziel, das Ziel ist das Spiel, das Spiel ist sein eigenes Scoreboard.

Und dann gibt es den Tetris-Effekt. In einer viel zitierten Studie berichteten Menschen, die intensiv Tetris gespielt hatten, davon, beim Einschlafen die Spielbilder zu sehen. Fallende Steine. Sich schließende Reihen. Das Bemerkenswerte: Selbst Personen mit schwerer Amnesie, die sich nicht erinnern konnten, überhaupt gespielt zu haben, hatten diese Bilder. Das Gehirn hatte das Muster gespeichert, ohne dass das bewusste Gedächtnis davon wusste.

Ich finde das faszinierend, weil es so präzise beschreibt, was mit uns passiert, wenn wir zu lange das falsche Scoreboard optimieren. Wir fangen an, die Welt in Bausteinen zu sehen, die sich schnell stapeln lassen. Tickets. Releases. Demos. Story Points. Nicht weil wir es wollen, sondern weil unser Gehirn es gelernt hat.

Und jetzt bekommt dieses Muster einen Turbo.

Das eigentliche Problem: Output wird billiger

AI macht Bauen schneller. Viel schneller. Was früher einen Sprint kostete, kostet heute einen Nachmittag. Was früher einen Nachmittag kostete, kostet heute eine Stunde. Die Strecke zwischen "Idee im Kopf" und "sichtbares Ergebnis" wird kürzer und kürzer.

Das klingt erstmal großartig, weil wir jahrelang gelernt haben, dass schnelleres Bauen gut ist. Mehr Velocity. Mehr Releases. Mehr Features. Das war das Versprechen von Agile, von CI/CD, von Low-Code. Jetzt setzt AI noch einen obendrauf.

Aber hier ist das eigentliche Problem: Wenn Bauen nichts mehr kostet, bauen wir mehr. Nicht unbedingt das Richtige. Einfach mehr.

Und das fühlt sich gut an. Der Reward kommt schneller, häufiger, sichtbarer. Grüne Tests. Ein Merge. Ein Screenshot für den Stakeholder. Eine Demo, die "läuft". Das sind Small Wins, und die Organisationspsychologie zeigt, dass genau diese kleinen Fortschritte zu den stärksten Motivatoren für engagierte Wissensarbeit gehören.

Das Gehirn liebt das. Dopaminerge Systeme reagieren stark auf "besser als erwartet", und das Signal verschiebt sich mit der Zeit: nicht mehr der Abschluss belohnt uns, sondern schon der Hinweis, dass er kommt. Der grüne Build-Check ist schon der Kick, nicht erst das Live-Deployment.

Und wenn die Belohnungen unregelmäßig kommen, also manchmal sofort, manchmal nach einem Blocker, manchmal nach einem unerwarteten Win, dann wird das Verhalten noch robuster. Variable Verstärkung erzeugt die hartnäckigsten Gewohnheiten. Deshalb sind Slot Machines so effektiv. Deshalb ist Produktentwicklung motivational so intensiv. Und deshalb ist das, was AI gerade verändert, psychologisch so relevant.

Hier kommt Vibe Coding ins Spiel

Andrej Karpathy hat Anfang 2025 einen Begriff geprägt, der seitdem durch die Tech-Welt geistert: Vibe Coding. Die Idee: Du sagst einer KI in normaler Sprache, was du willst. Du klickst "Accept All". Du schaust, ob es aussieht wie das, was du im Kopf hattest. Und du machst weiter, auch wenn du nicht genau weißt, warum der Code funktioniert.

Merriam-Webster hat den Begriff inzwischen aufgenommen. Was ein kultureller Marker ist: Wenn ein Wörterbuch Slang übernimmt, ist er Mainstream. Die Definition klingt fast nüchtern: Programmieren, ohne zwingend zu verstehen, wie oder warum der Code funktioniert, mit der Erwartung, dass Bugs dazugehören.

Wichtig: Nicht jede AI-Nutzung ist Vibe Coding. Wenn du verstehst, was generiert wird, es testest und bewusst entscheidest, ob du es nimmst, dann ist das AI-Assistenz. Der Unterschied liegt nicht im Tool, sondern in der Kontrolle, die du behältst.

Aber Vibe Coding im Karpathy-Sinne ist die konsequente Weiterentwicklung des oben beschriebenen Musters: maximale Geschwindigkeit, minimale Reibung, sofortiger sichtbarer Output. Rund ein Viertel der Startups im aktuellen Y-Combinator-Jahrgang soll mit fast vollständig KI-generiertem Code arbeiten. Auch unser Projekt, modelAIZ, wurde zu großen Teilen mit AI entwickelt. Das ist kein Randphänomen.

Warum das die Output-Falle verstärkt

Vibe Coding ist in vielerlei Hinsicht nützlich. Prototypen werden billiger. Exploration schneller. Wer früher nicht coden konnte, kann heute Ideen in Minuten sichtbar machen. Kontrollierte Experimente zeigen, dass AI-Assistenz die Aufgabenerledigung bei klar definierten, isolierten Tasks deutlich beschleunigt.

Aber genau darin liegt die Falle: Die Feedback-Schleifen werden kürzer, die Small Wins häufiger, und gleichzeitig kommt ein gut dokumentierter Effekt aus der Human-Factors-Forschung dazu: Automation Bias. Wir neigen dazu, Empfehlungen von Assistenzsystemen zu vertrauen, auch wenn sie falsch oder unvollständig sind. Wer Diffs weniger liest und Fehlermeldungen paste-and-acceptet bis es läuft, ist nicht dumm. Der hat ein Workflow-Design für Tempo gewählt. Aber Tempo plus Automation Bias bedeutet: mehr Output-Rausch bei gleichzeitig weniger Sichtbarkeit für das, was dabei unsichtbar bleibt.

Sicherheitsanalysen zu KI-generierten Code-Vorschlägen zeigen, dass bestimmte Konstellationen zu unsicheren Snippets führen können. Wartbarkeit, Edge Cases, Security werden nicht automatisch schlechter durch AI, aber sie werden schwerer zu sehen, wenn Geschwindigkeit alles schlägt.

Und dann ist da noch ein Effekt, den ich für besonders relevant halte: Wenn eine leitende Person eine Idee hat und daraus binnen Stunden eine Demo entsteht, die "funktioniert", entsteht ein Eindruck von Richtigkeit, lange bevor es Evidenz zur Wirkung gibt. Avinash Kaushik nennt das HiPPO: die Highest Paid Person's Opinion als dominante Entscheidungskraft ohne Daten. Vibe Coding macht HiPPO gefährlicher. "Schau, es läuft doch!" ist kein Beweis. Aber es fühlt sich wie einer an.

Output ist nicht Outcome. Das wissen alle. Und trotzdem.

Teresa Torres bringt es auf den Punkt: Output ist das, was du baust. Outcome ist die Wirkung davon. Ein Feature ist Output. Dass Nutzer dadurch etwas tun, was sie vorher nicht taten, ist Outcome.

Marty Cagan macht daraus eine Organisationsfrage: Teams, die auf Outcomes gemessen werden, arbeiten anders als Teams, die Roadmaps abarbeiten. Melissa Perri hat dafür einen Begriff geprägt, der sich in meinem Kopf festgebissen hat: die Build Trap. Wenn Organisationen Erfolg primär als Output messen, verwechseln sie Feature-Produktion mit Wertschaffung.

Das ist nicht neu. Aber es bekommt jetzt eine neue Schärfe. Denn wenn Output billiger wird, konsumieren wir typischerweise mehr davon, bis eine neue Knappheit entsteht. Im Fall von Software-Output heißt diese neue Knappheit: Aufmerksamkeit, Qualität, Verantwortlichkeit, Vertrauen, Governance.

Wenn Bauen nicht mehr der Engpass ist, verschiebt sich die eigentlich kritische Frage: Was sollen wir überhaupt bauen? Welches Problem lösen wir? Welche Wirkung erwarten wir?

Genau das ist das Handwerk, das Output-Maschinen immer schon unterschätzt haben. Und genau das wird jetzt, mit AI, nicht obsolet, sondern wichtiger.

Was tatsächlich hilft: ein Outcome-Betriebssystem

Die Antwort ist nicht "weniger AI". Es geht darum, die psychologisch naheliegende Fehloptimierung mit ein paar bewussten Gegengewichten auszubalancieren.

Features als Hypothesen behandeln

Nicht "wir liefern Feature X", sondern "wir wetten, dass Feature X Verhaltensänderung Y erzeugt, messbar über Signal Z, innerhalb von N Wochen". Outcome wird konkret, zeitlich greifbar und verhandelbar. Das ist das Gegengift zu einem Gehirn, das das Jetzt immer stärker gewichtet als das Später.

Lerngeschwindigkeit über Liefergeschwindigkeit

Small Wins sind mächtig, das zeigt die Forschung. Also: Nutze sie, aber verschiebe den Win. Feiere nicht "Feature live", sondern "Hypothese widerlegt", "Experiment sauber durchgeführt", "Entscheidungsunsicherheit reduziert". Du entscheidest, welcher Fortschritt zählt.

Das Product Trio ernstnehmen

PM, Design, Engineering gemeinsam in Discovery. Nicht als Meeting-Format, sondern als kleinste Einheit gemeinsamer Entscheidungen darüber, was gebaut wird. Teresa Torres beschreibt das Trio als Gegenmittel zu einseitigem Lösungsdenken, gerade dann, wenn die Kosten des Bauens sinken und der Lösungsraum explodiert.

Automation Bias aktiv entgegenwirken

Wer weiß, dass er dazu neigt, Assistenzsystemen zu vertrauen, kann ritualisierten Gegenzug einbauen: Reviews bei riskanten Änderungen, Threat Modeling bei neuen Flows, explizite "Was müsste falsch sein?"-Checks. Das ist kein Misstrauen gegenüber AI, sondern saubere Praxis.

Prototyping-Tempo von Produktions-Anspruch trennen

Vibe Coding ist großartig für Exploration. Schnell etwas sichtbar machen, eine Idee prüfen, wegwerfen wenn sie nicht trägt. Als Standardpfad in Production ist es etwas anderes, besonders wenn Codebasis, Team und Verantwortung wachsen.

HiPPO testbar machen, nicht mächtiger

Jede starke Meinung wird zur testbaren Hypothese. Jede Forderung bekommt ein Outcome-Kriterium. "Wir brauchen Feature X" wird zu: "Welchen messbaren Effekt erwarten wir, bis wann?" Das ist selten Konfrontation, aber fast immer klärend.

Zurück zu Tetris

Tetris macht süchtig, weil das Scoreboard perfekt auf unser Belohnungssystem abgestimmt ist. Linien löschen, sofortiges Feedback, immer mehr.

Produktentwicklung mit AI läuft gerade Gefahr, genauso zu funktionieren. Features bauen, Feedback sofort, immer mehr. Und je billiger und schneller das geht, desto stärker zieht das Muster.

Der Tetris-Effekt ist real: Wenn du lange genug das falsche Scoreboard optimierst, fängst du irgendwann an, die Welt nur noch in Bausteinen zu sehen. Nicht weil du es willst. Weil dein Gehirn es gelernt hat.

Die Frage ist nicht: Wie bauen wir schneller? Die Frage ist: Wie entscheiden wir, was es wert ist zu bauen?

Das ist die eigentlich kritische Kompetenz im AI-Zeitalter. Und die liegt nicht im Tool.

Quellen & Lesestoff

1. Andrej Karpathy: Original Tweet zu Vibe Coding https://x.com/karpathy/status/1886192184808149383 Der Ursprung des Begriffs. Karpathy beschreibt darin das Vibe Coding als Ansatz, bei dem man der KI sagt was man will, immer "Accept All" klickt, keine Diffs mehr liest und Fehlermeldungen einfach reinkopiert bis es läuft.
2. Simon Willison: "Not all AI-assisted programming is vibe coding" https://simonwillison.net/2025/Mar/19/vibe-coding/ Willison zieht die wichtige Grenze: Wenn du den generierten Code verstehst, testest und erklären könntest, ist es keine Vibe Coding. Vibe Coding beschreibt nur den Teilbereich, wo man "forget that the code even exists".
3. TechCrunch: YC-Kohorte und KI-generierter Code https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/ Die Quelle für die 25%-Zahl. Zeigt, dass das kein Randphänomen ist, sondern bereits Startup-Realität.
4. Stickgold et al.: Der Tetris-Effekt https://www.science.org/doi/10.1126/science.290.5490.350 Die Originalstudie in Science (2000): Tetris-Spieler berichteten von stereotypen visuellen Einschlafbildern des Spiels. Drei Amnesie-Patienten mit schwerem Gedächtnisverlust zeigten dieselben Bilder, obwohl sie sich nicht erinnern konnten, gespielt zu haben.
5. Parasuraman & Manzey: Automation Bias https://journals.sagepub.com/doi/10.1177/0018720810376055 Das Review in Human Factors (2010) belegt Automation Bias als robustes, domänenübergreifendes Phänomen: Die Tendenz, Empfehlungen von Assistenzsystemen zu übernehmen, auch wenn sie falsch sind. Automation Complacency tritt sowohl bei unerfahrenen als auch bei erfahrenen Nutzern auf. Sage Journals Die wissenschaftliche Basis für den "Accept All"-Mechanismus.
6. Peng et al.: The Impact of AI on Developer Productivity https://arxiv.org/abs/2302.06590 Das kontrollierte Experiment mit GitHub Copilot: Entwickler mit KI-Zugang erledigten die Aufgabe 55,8% schneller als die Kontrollgruppe. arXiv Wichtig: nur für klar abgegrenzte Tasks. Beides, Potenzial und Einschränkung, steckt in dieser einen Zahl.
7. Teresa Torres: Outcomes vs. Outputs https://www.producttalk.org/outcomes-vs-outputs/ Die Begründerin des Product-Trio-Modells erklärt den Unterschied klar und praxisnah.
8. Marty Cagan: Product vs. Feature Teams https://www.svpg.com/product-vs-feature-teams/ Die organisatorische Dimension: Warum Teams, die auf Output gemessen werden, strukturell anders entscheiden als solche, die Outcome-Verantwortung tragen.
9. Melissa Perri: Escaping the Build Trap https://www.oreilly.com/library/view/escaping-the-build/9781491973783/ Das Buch, das den Begriff "Build Trap" geprägt hat.
10. Amabile & Kramer: The Power of Small Wins https://hbr.org/2011/05/the-power-of-small-wins Der HBR-Klassiker, der erklärt warum kleine sichtbare Fortschritte so stark motivieren.