PM werden im KI-Zeitalter 02 | Keine Technik zu verstehen — warum das sogar ein Vorteil ist

Schauen wir zuerst auf etwas, das jemand gebaut hat, der nicht programmieren kann.

Marcus Rush betreibt eine Immobilienvermittlung für Wohnimmobilien und ist selbst kein Programmierer. Mit Claude und Zapier hat er sich einen KI-Agent namens Russ zusammengebaut: Jeden Morgen bewertet der aus über 11.000 Kontakten die Leads, schreibt für jeden seiner Makler einen fertigen Follow-up-Plan für den Tag und verwaltet nebenbei seinen Kalender. Ein Vermittlungschef hat sich ein internes System gebaut, das das Tagesgeschäft erledigt — ohne eine einzige Zeile von Hand geschriebenen Code.

Das ist kein Einzelfall. Eine Statistik aus 2026 zeigt: Unter den aktiven Nutzern von Vibe Coding sind 63 % keine Entwickler. Ein Designer ohne Programmierhintergrund hat mit Replit und KI selbst ein Produkt live gebracht und kommt damit auf 20.000 $/Monat — mehr als das Doppelte seines früheren Gehalts.

Legt man das nebeneinander, erkennt man etwas Kontraintuitives: Auf dem Weg „von der Idee zu etwas, das wirklich läuft” kommen Menschen ohne Technikwissen manchmal leichter voran als Ingenieure.

Der Ingenieur muss erst etwas ablegen

Jemand hat beobachtet, wie erfahrene Ingenieure mit KI arbeiten. Sie sind es gewohnt, um jedes Umsetzungsdetail zu ringen, fragen zurück „Warum nicht X?”, „Hast du Y bedacht?” — und die Standardreaktion des Modells ist „Klar, dann bauen wir das ein”. Den über zwanzig Jahre antrainierten Instinkt, für jede einzelne Zeile Code geradezustehen, müssen sie im Zusammenspiel mit der KI erst einmal ablegen.

Genau das fällt ihnen schwer. Loslassen müssen sie das bisschen Beharren darauf, dass „jede Zeile von mir selbst geschrieben und mit eigenen Augen geprüft sein muss”. In jenem METR-Experiment arbeiteten 16 erfahrene Programmierer mit KI an Projekten, die sie seit Jahren selbst pflegten — und waren tatsächlich 19 % langsamer, glaubten aber, sie seien 20 % schneller gewesen. Je vertrauter jemand mit der Materie ist, desto eher gerät er mit dem Werkzeug aneinander.

Menschen ohne Technikwissen haben diesen Ballast nicht. Sie haben nichts abzulegen.

„Das ist doch viel zu schwer” — jemand ohne Technikwissen sagt das nicht

Ein Teil des Urteils von Product Managern kam früher daher, „wie schwer dieses Feature umzusetzen ist”. Dieses Wissen hat eine Nebenwirkung: Je genauer du weißt, wie viel hinter einer Idee umgebaut werden muss und wie viele Fallgruben dabei lauern, desto eher würgst du sie ab, noch bevor du sie überhaupt ausgesprochen hast. Wer es kann, zensiert sich am härtesten selbst.

Menschen ohne Technikwissen bauen sich diese Hürde nicht. Sie wissen nicht, dass es schwer ist, also sagen sie zuerst klar, was sie wollen, und überlassen der KI den Teil mit der Umsetzungsschwierigkeit. Genau das meint doaipm mit 言出法随: Sag es klar, und die KI baut es dir. Marcus wusste nicht, „wie schwer” es ist, eine Bewertungslogik über 11.000 Kontakte zu schreiben — er wusste nur, was er wollte, und hat es ausgesprochen.

Knapp ist, die Idee klar zu formulieren — nicht, den Code zu schreiben

Dass der Agent Russ läuft, liegt nicht daran, dass Marcus Python kann, sondern daran, dass er sein Geschäft kennt: wonach Leads bewertet werden, welche Punkte in den Follow-up-Plan gehören, welche Kontakte vorne stehen. Das sind Urteile, keine Technik.

Die KI schließt nicht aus Auslassungen. Sagst du es nicht klar, baut sie dir nach Voreinstellung eine Version — meist nicht die, die du wolltest. Wer Regeln, Grenzen und Zustände klar benennen kann, liefert eine Qualität, die um eine Größenordnung über der anderer liegt. Diese Fähigkeit hat nichts damit zu tun, ob man programmieren kann. Unter den Ratschlägen von a16z an Product Manager steht einer: Reine Prozessmanager werden aussortiert, Hebelwirkung haben die mit „Builder-Mentalität”. Builder-Mentalität heißt, bereit zu sein, eine Idee selbst in die Hand zu nehmen, sie umzusetzen und zur Validierung zu bringen — ob man programmieren kann, gehört nicht dazu.

Den Vorteil gibt es nicht umsonst

Keine Technik zu verstehen heißt nicht, gar nichts verstehen zu müssen. Hinter dem Zapier, das Marcus nutzt, und dem Replit, das der Designer nutzt, steckt jeweils ein Handwerk, das man sich aneignen muss: wie man eine Anforderung in kleine Schritte zerlegt, die die KI in einem Zug aufnehmen kann; wie man beurteilt, ob das, was sie liefert, stimmt; wo man innehalten und einen echten Menschen übernehmen lassen sollte.

Was Menschen ohne Technikwissen am ehesten übersehen, ist das Sicherheitsnetz. Pack in den Prototyp keine echten Kundendaten; Knöpfe wie Veröffentlichen, Löschen, Bezahlen — alles, was sich nicht mehr rückgängig machen lässt, sobald es gedrückt ist — überlässt man dem Menschen. Marcus’ Russ „schreibt” den Maklern Follow-up-Pläne, lässt sie aber nicht für jemanden „abschicken” — auf diesen Knopf drückt am Ende ein Mensch.

Eine Sache, die du heute tun kannst: Such dir eine kleine Idee, bei der du immer dachtest „dafür brauche ich einen Ingenieur”, frag nicht erst, ob sie schwer ist, schreib Punkt für Punkt klar auf, was du willst, und wirf es der KI hin, damit sie eine erste Version baut. Schau erst, wie weit sie kommt, und urteile dann.

Weiterführende Links

• Zapier „Vibe coding examples: Real projects from non-developers” (Fallbeispiel Marcus Rush / Rush Home): https://zapier.com/blog/vibe-coding-examples/
• a16z „5 Principles for PMs in the AI Era” (Builder-Mentalität vs. Prozessmanager): https://a16z.com/stay-relevant-in-ai/
• Teil 01 dieser Serie „Welche Aufgaben dem Product Manager von der KI abgenommen werden — und welche dadurch erst recht wertvoll werden”: /de/blog/ai-pm-what-changed/