Vibe Coding ist schon überholt — und das ist eine gute Nachricht für Product Manager
2026 stand Andrej Karpathy — derjenige, der den Begriff „vibe coding” populär gemacht hat — auf der Bühne und erklärte ihn für überholt. Was er an seiner Stelle vorschlug, nannte er agentic engineering, und er beschrieb es als eine Liste von Tätigkeiten: Design-Specs schreiben, Pläne überwachen, Diffs prüfen, Tests schreiben, Evaluation-Loops bauen, Berechtigungen verwalten, Qualität sichern.
Lies diese Liste noch einmal — ohne die ingenieurspezifischen Begriffe. Entscheiden, was gebaut werden soll. Prüfen, ob das Ergebnis der Absicht entspricht. Definieren, was „gut genug” bedeutet, und sich weigern, darunter zu liefern. Das ist keine neue Disziplin. Wie Jeff Gothelf es formulierte: Die Urteilsvariante ist der Job — sie war es immer. Die KI hat nur die Verstecke weggeräumt, hinter denen wir das früher verbargen.
Das ist die wichtigste Verschiebung für alle, die heute Produkte bauen — und sie weist in eine Richtung, die die meisten zunächst für kontraintuitiv halten.
Die Fähigkeit, die bleibt, ist nicht Coden
Ein Jahrzehnt lang war „Lern programmieren” der universelle Rat für alle mit einer Produktidee. 2026 hat sich dieser Rat still umgekehrt. Wenn KI-Agenten ein klar formuliertes Problem in lauffähige Software verwandeln können, ist Dokumentation schreiben nicht mehr der Job — Intention, Klarheit und Urteilsvermögen sind der Job. Die Branche hat einen Namen für die Menschen, die jetzt zählen — und es ist nicht „Prompt Engineer”. Product Schools Einschätzung war direkt: KI-Produktmanager sind die PMs, die 2026 den Unterschied machen.
Die Mechanik bestätigt das. Branchenweit hat sich ein Konsens darüber herausgebildet, was ein KI-nativer PM tatsächlich tut — und er lässt sich auf drei Verben verdichten:
- Beschreiben: Was du willst, klar genug formulieren, dass ein fähiger Agent darauf handeln kann.
- Zerlegen: Das Problem in Stücke aufteilen, die klein genug sind, um sie einzeln zu prüfen.
- Urteilen: Ob der Output der Absicht entspricht — und was mit den 15 % passiert, wo er es nicht tut.
Keines dieser drei Dinge ist Programmieren. Alle drei sind Produktmanagement.
Warum kein Code schreiben können ein Vorteil sein kann
Hier kommt der Teil, der falsch klingt — und es nicht ist. Wer programmieren kann, hat im Hinterkopf ständig eine laufende Schätzung: Wie aufwändig ist das zu bauen? Diese Schätzung ist nützlich, wenn du derjenige bist, der baut — und ein Hemmnis, wenn du entscheidest, was überhaupt existieren sollte. Die Idee wird beschnitten, bevor sie ausgesprochen ist: nicht nach Nutzerwert, sondern nach Implementierungsaufwand.
Wer nicht programmieren kann, hat diesen Reflex nicht. Was bleibt, sind die einzigen Fragen, die am Anfang wirklich zählen: Was braucht der Nutzer eigentlich? Stimmt diese Erfahrung? Dann ist die Aufgabe, es klar zu formulieren. Und „die Idee klar formulieren” ist die älteste Kernkompetenz eines Product Managers überhaupt.
Das ist kein Argument dafür, unwissend zu bleiben. Es ist ein Argument dafür, dass der Engpass sich verschoben hat. Die knappe Ressource ist nicht mehr die Tippgeschwindigkeit im Editor — sondern die Klarheit dessen, was man verlangt.
„Sag es, die KI baut es” ist eine Methode, kein Gefühl
Der Haken: Vibe Coding hat sein Nachruf aus gutem Grund verdient. Wer die Prompts locker hält, dem driftet jeder Lauf davon: Designer haben bemerkt, dass KI-Prototypen den Platz einnehmen, den früher Wireframes hatten — aber derselbe Prompt produziert bei jedem Durchlauf subtil andere Ergebnisse. Semantische Drift, die sich schnell aufschaukelt. Vage Intention rein, inkonsistentes Produkt raus.
Die Antwort ist also nicht, härter zu prompten. Es geht darum, mit Disziplin zu arbeiten. Diese Disziplin nennen wir DO AI PM — und sie läuft auf einige Grundsätze hinaus:
- High Fidelity zuerst. Den Wireframe überspringen. Direkt das echte, lauffähige Ding bauen — echter Content, echte Zustände (Laden, leer, Fehler, Erfolg), echte Interaktionen — und durch tatsächliches Ausführen verifizieren. Ein funktionierender Prototyp schlägt einen beschriebenen jedes Mal, auch im Entscheidungsraum.
- Fünf Phasen, kleine Schritte. Discover → Define → Design → Develop → Validate. In Define: Lass die KI zuerst Fragen stellen, bevor sie das Spec schreibt. In Develop: Immer nur eine Sache auf einmal ändern.
- Ein Sicherheitsnetz. Keine echten Secrets oder Produktionsdaten im Prototyp. Die unumkehrbaren Knöpfe — Veröffentlichen, Löschen, Bezahlen — drückt der Mensch. Produktion nicht anfassen. Im Zweifel fragen.
Diese letzte Liste ist der Unterschied zwischen „Ich hatte Glück mit einem Prompt” und „Ich kann das nächsten Montag wieder.”
Der Beweis ist das Werk
Eine Methode, die sich nur selbst erklärt, ist nichts wert. Deshalb steht hinter allem hier echte Arbeit — alles auf diese Weise mit Claude Code gebaut: SoloMD (ein Markdown-Editor), Unterm (ein Terminal, das KI-Agenten steuern können), unfetch (ein Download-Manager für Menschen und KI), StoryAlter (ein KI-Schreibbegleiter), und Unflick (ein Mediaplayer für Menschen und KI). Diese Website selbst — acht Sprachen, dieser Blog, die Folien — wurde auf dieselbe Weise herausgesagt. Keine einzige Zeile davon wurde von Hand geschrieben.
Die Methode erklärt die Arbeit; die Arbeit beweist die Methode.
Karpathy hatte recht: Vibe Coding ist vorbei. Was es ersetzt, ist keine härtere Art von Engineering — es ist die Disziplin, gut zu entscheiden und klar zu beschreiben. Das hat einen Namen, und es ist ein guter Zeitpunkt, diesen Job zu haben.
Wer spüren möchte, wie sich „Sag es, die KI baut es” anfühlt — 言出法随 (das Gesprochene wird sofort Wirklichkeit) —, fängt im Methodenzentrum an.
Weiterführende Links
Diskussion