Vibe Coding ist Produktdenken: warum Teresa Torres' Feedback-Loops kein Coding-Tipp sind, sondern PM-Handwerk

Teresa Torres hat seit März 2025 mehr Software geschrieben als in ihrem gesamten bisherigen Leben, ohne klassische Programmierkenntnisse. Ihr Weg vom gescheiterten Replit-Prototyp über Lovable bis zu produktiver Software mit Claude Code ist lehrreich, aber nicht wegen der Tools. In ihrem Artikel “Vibe Coding Best Practices” destilliert sie zwei Feedback-Loops, die sie aus dem sogenannten Doom Loop befreit haben: Plan-Review-Fix und Implement-Review-Fix. Was auf den ersten Blick wie ein Coding-Tipp wirkt, ist eine Übersetzung von Produktdisziplin in eine neue Domäne. Und damit für Product People relevanter als jede Tool-Empfehlung.

Was Torres beschreibt, und was sie eigentlich meint

Vibe Coding, ein Begriff von Andrej Karpathy aus dem Februar 2025, meint: Software bauen, indem man beschreibt, was man will. In natürlicher Sprache statt in Code-Syntax. Tools wie Claude Code, Cursor oder Replit übernehmen die Implementierung. Klingt nach Demokratisierung. Ist es auch, mit einer entscheidenden Einschränkung.

Torres' Weg illustriert das: Ihr erster Interview Coach mit Replit war ein Erfolg, bis sie ihn erweitern wollte und an die Grenzen des Prototyps stieß. Sie musste ihn von Grund auf neu bauen. Bei einem Gesundheitstracker für ihren Hund verschwendete sie ein ganzes Wochenende im Doom Loop mit Lovable, nur um das Projekt zu killen und beim zweiten Versuch in unter einer Stunde zum Ziel zu kommen.¹ Seitdem hat sie mit Claude Code einen Business Fundamentals Coach, einen Outcome Coach, Challenge-Software, einen TeresaBot und KI-generierte Opportunity Solution Trees für Vistaly gebaut. Der Unterschied liegt nicht im Tool-Wechsel, sondern in zwei Prinzipien: Je klarer du weißt, was du willst, desto besser der Output. Und: Agenten machen Fehler. Es ist dein Job, diese Fehler zu managen.

Dahinter steht eine Erkenntnis, die für PMs nicht neu sein sollte: Wer seine Anforderungen während der Session ändert, erzeugt widersprüchlichen Code, weil der Agent die Datenschicht, die Logikschicht und die Darstellungsschicht nicht immer synchron hält. Torres erklärt diese drei Software-Schichten explizit, weil genau hier die meisten Doom-Loop-Bugs entstehen: Der Agent vergisst, eine Änderung durch alle drei Ebenen zu propagieren.

Zwei Loops, ein Prinzip aus Discovery

Torres' zwei Feedback-Loops sind nicht zufällig gewählt. Der Plan-Review-Fix-Loop entspricht dem, was Product Teams als Discovery kennen: Bevor gebaut wird, entsteht Klarheit. Torres beschreibt, wie sie jede Coding-Session mit einem Plan beginnt, manchmal als vage Idee, manchmal als konkrete Spezifikation. Entscheidend: Sie iteriert in Markdown, nicht in Code. Das heißt: Anforderungen klären, bevor eine Zeile geschrieben wird. Wenn der Plan steht, prüft ein separater Plan-Reviewer (ein eigener KI-Skill) auf Konsistenz, Over-Engineering und logische Lücken. Torres betont, dass sie dabei nicht in Wasserfall-Manier plant, sondern in kleinen, iterativen Batches.

Der Implement-Review-Fix-Loop folgt nach der Implementierung. Torres hat dafür einen zweiten KI-Skill gebaut: einen Code-Reviewer, der den Output systematisch auf Bugs, doppelten Code und drei Fokus-Bereiche prüft: Error Handling, Test Coverage und Security.² Beide Loops folgen dem gleichen Prinzip: Nicht fertig, bis drei Parteien zufrieden sind. Torres selbst, der arbeitende Agent und der jeweilige Reviewer. Torres berichtet, dass sie den Doom Loop seit Monaten nicht mehr erlebt hat.

Warum das für Product Manager relevant ist

Diese Diskrepanz aus meinem letzten Artikel über die KI-Produktivfalle taucht bei Torres in anderem Gewand auf. Das Gefühl, produktiv zu sein, weil der Agent sofort Code liefert, ist der gleiche Mechanismus wie das Gefühl, produktiv zu sein, weil die KI sofort einen Report generiert. In beiden Fällen fehlt der Prüfschritt: Ist das, was entstanden ist, tatsächlich das, was gebraucht wird?

Torres löst das Problem nicht durch weniger KI-Einsatz, sondern durch mehr Struktur um den KI-Einsatz herum. Sie empfiehlt, Conversations häufig neu zu starten, weil die Outputqualität mit der Kontextlänge abnimmt (ein Phänomen, das sie Context Rot nennt). Und wenn etwas schiefgeht, trennt sie konsequent Diagnose von Reparatur: Erst mehrere Agenten parallel dasselbe Problem analysieren lassen, dann, und nur dann, fixen. Nicht das Tool ist das Problem und nicht das Tool ist die Lösung. Die Arbeitsweise drum herum entscheidet. Ein Muster, das Robert Solow bereits 1987 für Computer beschrieben hat⁴ und das sich bei jeder produktivitätssteigernden Technologie wiederholt.

Was ich verändert habe

Ich nutze Claude Code seit Monaten für mein persönliches Wissenssystem, für CV-Pflege, für Recherche und für die Automatisierung von Workflows. Torres' Artikel hat mir drei Dinge bewusst gemacht, die ich teilweise implizit tat, aber nie so klar benannt hatte:

Erstens: Meine produktivsten Sessions beginnen mit einer klaren Aufgabenstellung in meiner CLAUDE.md, nicht mit einem offenen Prompt. Das ist Torres' Planning-Loop in anderem Format. Meine Rules und Skills sind im Grunde Plan-Reviewer für Wissensarbeit: Sie definieren, was der Agent tun soll und prüfen die Einhaltung. Wenn ich ihn ohne diese Struktur „frei laufen lasse“, entsteht Workslop.

Zweitens: Review-Schritte als feste Checkpoints, nicht als optionaler Nachgedanke. Freitags-Review, Tages-Check-out, Deduplizierungs-Regel: all das sind Implement-Review-Fix-Loops, angewendet auf Wissensarbeit statt auf Code. Torres' Drei-Parteien-Modell (ich, Agent, Reviewer) hat mir gezeigt, dass ich dieses Prinzip konsequenter auf jeden Output anwenden sollte.

Drittens: Diagnose vor Reparatur. Wenn etwas in meinem Vault nicht stimmt (doppelte Informationen, inkonsistente Struktur), war mein Reflex bisher: sofort aufräumen. Torres' Debugging-Prinzip hat mich daran erinnert, erst zu verstehen, warum etwas kaputt ist, bevor ich es anfasse.

Kritische Einordnung

Torres macht vieles richtig: Sie erklärt die drei Software-Schichten (Daten, Logik, Darstellung) explizit, damit auch Nicht-Entwickler ein mentales Modell bekommen. Trotzdem bleibt die Frage, wie viel Architekturverständnis realistisch in einem Artikel vermittelt werden kann. Wer als PM das Drei-Schichten-Modell zum ersten Mal liest, wird damit noch keine Bugs diagnostizieren können. Die Methode braucht Übung, nicht nur Wissen.

Was im Artikel fehlt, ist die Grenze: Ab welcher Komplexität reicht Vibe Coding nicht mehr? Torres baut reale Produkte mit Datenbanken, Integrationen und User-Facing Interfaces. Aber welche Architekturentscheidungen trifft sie bewusst und welche überlässt sie dem Agenten? Was passiert, wenn der Code-Reviewer selbst etwas übersieht? Das wäre die nächste Ebene gewesen, vielleicht der nächste Artikel.