Produktmanager von OpenAI Codex: KI soll dich nicht dazu bringen, Dinge schneller zu tun, sondern Dinge, die du früher nicht gewagt hast, zu tun.

Wenn Sie in den Büroräumen von OpenAI von Punkt A zu Punkt B gehen, ist es unmöglich, nicht das Wort „Codex“ zu hören. Das ist keine Übertreibung – Rohan Varma sagt, dass der Betrieb von OpenAI in ernsthafte Schwierigkeiten geraten würde, wenn Codex ausfällt. Und er ist einer der Menschen, die dieses Werkzeug unverzichtbar gemacht haben.

Rohan Varmas Weg ist ziemlich interessant. Er ist Mitbegründer von Cursor und hat das KI-Programmierwerkzeug geschaffen, das Entwickler auf der ganzen Welt süchtig macht. Im Februar 2026 wurde er von OpenAI abgeworben, und seine Identität wechselte von „Gründer“ zu „Produktmanager“. Aber er sagt, dass dieser Übergang völlig nahtlos war – denn die interne Funktionsweise von OpenAI Codex ist fast identisch mit der von Cursor: Das Team ist extrem klein, die Geschwindigkeit ist extrem hoch, und jeder baut dieses Produkt mit demselben Werkzeug.

Peter Yangs Podcast „Behind the Craft“ lud Rohan zu einem praxisintensiven Interview ein. Während des Interviews führte Rohan mehrere Live-Demonstrationen durch – von automatisierten Workflows, die über Slack ausgelöst werden, über die schnelle Generierung von Designvarianten mit Image Gen bis hin zur Umwandlung beliebiger Gesprächsthreads in wiederverwendbare Fähigkeiten. Dies ist kein theoretischer Kurs zum Thema „Wie sollte ein Produktmanager im KI-Zeitalter vorgehen?“, sondern ein Produktmanager eines echten KI-nativen Teams öffnet seine tägliche Arbeitsweise für Sie.

Dieser Artikel ist eine bearbeitete Fassung von Folge 138 von Peter Yangs Podcast „Behind the Craft“ mit dem Titel „OpenAI PM Reveals How He Uses Codex to Do Product Work | Rohan Varma“, die am 5. Juli 2026 auf YouTube veröffentlicht wurde. Im Folgenden finden Sie die vollständige übersetzte Fassung.

1

Zwei Hebel: Die Arbeitsweise und die Rolle des Produktmanagers haben sich verändert

Rohan unterteilt die Auswirkungen von Codex auf die Arbeit von Produktmanagern in zwei Ebenen. Die erste Ebene ist leicht verständlich – die konkrete Vorgehensweise, das „Wie“, hat sich geändert. Informationssynthese, Kontexterfassung, Dokumentationserstellung und die Koordination über verschiedene Tools hinweg – all diese Aufgaben, die früher einen großen Teil der Zeit eines Produktmanagers in Anspruch nahmen, können jetzt in großem Umfang an Codex delegiert werden.

„Wir erhalten täglich Hunderte von Datenpunkten und Problemen von Unternehmenskunden, über Feedback auf Twitter und aus verschiedenen anderen Kanälen“, gibt er ein Beispiel. „Ich kann mich in nur 20 Minuten vollständig in ein neues Projekt einarbeiten. Codex durchsucht automatisch alle unsere Tools – Notion, Linear, Gmail, Google Drive – und fasst alles zusammen, was passiert ist, bevor ich dazu gestoßen bin.“

Aber die zweite Ebene ist entscheidender: Die Rolle selbst wird neu definiert. Wenn alle Ingenieure, Designer und Produktmanager in einem Team Codex verwenden, ändert sich auch die Topologie der Zusammenarbeit. Das typische Setup des OpenAI Codex-Teams sieht so aus – eine Produktlinie hat nur ein oder zwei Ingenieure, und die Rolle des Produktmanagers wandelt sich von einem „Vermittler“ zu einem „Kalibrator an beiden Enden“: Er legt die strategischen Leitplanken auf der einen Seite fest und sorgt für den letzten Schliff bei der Markteinführung auf der anderen Seite, während die Ausführungsebene vollständig den Ingenieuren und Codex überlassen werden kann.

„Früher hat man bei der Produktentwicklung viel Zeit in die Vorplanung gesteckt, um sicherzustellen, dass die Ingenieure nur die wichtigsten Dinge tun“, sagt er. „Jetzt ist es genau umgekehrt – zuerst macht man alles, und dann entscheidet man, was es wert ist, tatsächlich veröffentlicht zu werden.“

2

Kein PRD, nur „zuerst machen, dann darüber sprechen“

Diese „Umkehrung“ hat bei OpenAI längst den Alltag durchdrungen. Rohan nennt ein sehr konkretes Beispiel: Codex erhielt vor kurzem ein Produktupdate, bei dem ein integrierter Browser in die Anwendung aufgenommen wurde. Wie kam es zu dieser Funktion? Eines Morgens kam der Ingenieur Adam zur Arbeit, sagte zu Rohan „Schau dir das an“ und zeigte ihm das Ergebnis – weil es lästig war, beim iterativen Arbeiten im Frontend ständig zwischen Fenstern zu wechseln, hatte er es selbst mit Codex erstellt.

„Er hat keine Anforderungsdokumentation geschrieben, keine Ausrichtungssitzungen abgehalten – er fand es einfach lästig und hat es gebaut. Als ich es sah, sagte ich: ‚Das ist großartig, wir müssen einen Weg finden, es zu veröffentlichen.‘“ Eine Funktion, die in den Hauptzweig des Produkts integriert werden kann, hat nicht einmal eine Zeile PRD in ihrer „Geburtsurkunde“.

Rohan erwähnt auch ein Meme, das derzeit in Silicon Valley kursiert – „Pläne sind für Agenten, nicht für Menschen“. Wenn man die „Ziel“-Funktion von Codex nutzt, iteriert es selbstständig, erfüllt die Ziele und nimmt Feinabstimmungen vor. Die Zeit, die Menschen mit dem Lesen von Plänen verbringen, sollte sie lieber nutzen, um sich die tatsächlich ausgeführten Ergebnisse anzusehen.

Dahinter steckt eine tiefere organisatorische Logik: Die Zusammenarbeit zwischen Menschen wird zum Flaschenhals. Im traditionellen Modell, wenn ein Projekt fünf oder sechs Ingenieure umfasst, beginnen die Koordinationskosten die Geschwindigkeit zu beeinträchtigen. Wenn aber jeder – insbesondere Ingenieure – seine individuelle Arbeitsfähigkeit durch Codex erheblich steigert, wird die Produktentscheidung zu einer Ansammlung zahlreicher Mikroentscheidungen. „Der ideale Zustand ist, dass Ingenieure diese Mikroentscheidungen selbst treffen können, ohne auf mich warten zu müssen.“

Daher hat sich auch der Fokus von Rohans täglicher Arbeit verschoben. Er verbringt mehr Zeit mit Unternehmenskunden und dem Team und weniger Zeit mit „Informationssynthese“ und „Dokumentationspflege“. „Codex erledigt die manuellen Teile, sodass der Produktmanager mehr Zeit mit den Nutzern verbringen kann – das ist eigentlich das, was ein Produktmanager tun sollte.“

3

Mache es einmal, und lass es sich dann selbst automatisieren

Der eindrucksvollste Teil des gesamten Interviews sind die Workflows, die Rohan live demonstriert. Das Kernmuster lässt sich in einem Satz zusammenfassen: Erledige die Aufgabe zuerst manuell einmal, und lass Codex dann diesen Prozess selbst automatisieren.

Er zeigte, wie er mit Nutzerfeedback umgeht. Bei OpenAI wird Slack intensiv genutzt, und eine Menge Feedback verteilt sich auf verschiedene Kanäle. Rohans Vorgehensweise ist – er öffnet zuerst einen Thread in Codex und durchläuft manuell den Prozess „Feedback aus Slack sammeln → klassifizieren → in das Linear-Board eintragen“. Sobald dieser Ablauf funktioniert, sagt er nur: „Jetzt richte eine Automatisierung ein, die dies einmal pro Woche ausführt.“

Codex kann nicht nur Automatisierungen einrichten, sondern auch die von ihm erstellten Automatisierungen selbst modifizieren. „Ich könnte hinzufügen – schick mir nach Abschluss eine Slack-Nachricht. Dann wird Codex die Konfiguration dieser Automatisierung aktualisieren.“ Rohan sagt, dass er etwa fünf oder sechs solcher Automatisierungen laufen hat, die verschiedene wiederkehrende Aufgaben abdecken, von der Informationssammlung über die Feedback-Klassifizierung bis hin zu Statusaktualisierungen.

Aber noch beeindruckender sind „einmalige, ausgelöste Automatisierungen“. Er demonstrierte ein Szenario – er schickte seinem Kollegen Alex eine Nachricht und stellte dann in Codex ein: „Wenn Alex auf meine letzte private Nachricht antwortet, entwerfe eine Antwort-E-Mail an den Kunden.“ Codex überwacht diese Slack-Privatnachricht im Hintergrund, und sobald die Bedingung erfüllt ist, erstellt es automatisch die E-Mail und löscht dann diese Automatisierung selbst.

„Codex weiß, wie es sich selbst bedienen soll“, sagt Rohan. „Du musst die Anforderungen nicht bis ins kleinste Detail aufschlüsseln. Du sagst ‚wenn Alex antwortet, schicke eine E-Mail‘, und es nutzt seine zugrundeliegenden Fähigkeiten – es prüft alle paar Minuten Slack, erstellt die passende Auslösebedingung und löscht sich selbst nach Abschluss. Du musst dir keine Gedanken darüber machen, wie es funktioniert.“

Peter Yang scherzt halb ernst: „Also kannst du eine Automatisierung einrichten, die Codex vorgibt, du zu sein und auf lange Slack-Beiträge zu antworten?“ Rohan lächelt: „Ja, einige in unserem Team nutzen das @Codex-Tag, um Automatisierungen auszulösen, die als sie selbst antworten.“

4

Image Gen ist nicht dazu gedacht, dir die Haare blau zu färben

„Image Gen gibt mir ein Gefühl, das fast einem AGI-Moment gleicht.“ Rohan sagt das ohne zu scherzen.

Sein Argument lautet: Die meisten Menschen verstehen Bildgenerierung als Verbraucheranwendung, wie „färbe meine Haare blau“ oder „erzeuge mir ein Bild einer Katze“. Aber bei der Produktarbeit liegt ihre wahre Stärke in der schnellen Prototyperkundung.

Er demonstrierte live – er machte einen Screenshot der „Projekt auswählen“-Oberfläche von Codex und sagte dann zu Image Gen: „Basierend auf diesem UI, erzeuge vier oder fünf verschiedene Designvarianten.“ In wenigen Sekunden lieferte Codex fünf völlig unterschiedliche Interaktionskonzepte. Keine Textbeschreibungen, sondern direkt visualisierbare Mockups, über die man sofort diskutieren kann.

„Das ist viel schneller, als fünf gefälschte React-Seiten zu erstellen, um verschiedene Konzepte zu testen“, sagt er. „Ich bin zunehmend der Meinung, dass die erste Iteration von Produktideen nicht mit Code, sondern direkt mit Image Gen erstellt werden sollte.“

Normalerweise führt er zuerst eine visuelle Erkundung mit Image Gen durch, wählt ein oder zwei Richtungen aus und gibt dann die Anweisung: „Mache das erste Konzept zu einem echten Prototyp und lade es auf Codex Sites hoch, damit ich es mit dem Team teilen kann.“

In diesem Workflow gibt es noch ein „magisches“ Werkzeug, das ständig verwendet wird: der Fähigkeitsersteller. In Codex kannst du am Ende jedes Gesprächsthreads den Fähigkeitsersteller aufrufen und ihm sagen: „Mache aus dem gesamten vorherigen Interaktionsprozess eine wiederverwendbare Fähigkeit, damit du bei ähnlichen Anforderungen in Zukunft meine Präferenzen kennst.“ Rohan nutzt dies, um seine Designsprache zu festigen: „Du interagierst 20 Minuten lang mit Codex, um ein zufriedenstellendes Design zu erstellen, und sagst dann ‚wandle diesen Thread in eine Fähigkeit um, damit zukünftige Designs konsistent bleiben‘ – und es merkt sich wirklich deine ästhetischen Präferenzen.“

Peter Yang äußert eine Sorge – wenn man KI unbegrenzt Fähigkeiten immer wieder aktualisieren lässt, werden die Fähigkeitsdateien nicht zu unscharfem „Slop“? Rohan räumt ein, dass dies ein Problem ist, das gelöst werden muss. Derzeit ist die Vorgehensweise noch sehr primitiv – „führe es aus, sieh dir das Ergebnis an, und wenn es passt, nutze es weiter“. Aber er verrät, dass das Team untersucht, wie die Qualität der Ergebnisse von Fähigkeiten über verschiedene Iterationen hinweg automatisch bewertet werden kann.

5

„Einmalige Software“ und sich selbst aktualisierende Dokumente

Rohan stellt ein Konzept vor – Disposable Software. Wenn die Grenzkosten für die Erstellung einer Software mit Codex nahezu null sind, fängst du an, Dinge zu bauen, die früher „nicht wert waren, um sie zu erstellen“.

„Ich lasse Codex oft direkt eine kleine Einmal-App bauen“, sagt er. Ein typisches Beispiel: Wenn sich zu viele Nachrichten in Slack ansammeln, lässt er Codex „alle ungelesenen Slack-Nachrichten durchsuchen, die wichtigsten hervorheben, auf die ich antworten muss, und dann eine lokale Webseite generieren, die sie nach Priorität sortiert anzeigt“ – der gesamte Vorgang dauert kaum eine Minute, und man wirft die App danach weg.

Wenn ein solches Einmal-Werkzeug wiederholt verwendet wird, fügt er eine weitere Automatisierung hinzu – „aktualisiere diese Seite alle zwei Stunden“. So wird das temporär erstellte kleine Werkzeug zu einem dynamischen Dashboard mit null Wartungskosten.

Diese Idee wird auf Teamebene zu etwas noch Interessanterem erweitert. Jedes Projekt im OpenAI-Team hat einen zugehörigen Slack-Kanal. Rohan beginnt, für jeden Kanal eine Codex Site zu erstellen – eine Projektübersichtsseite, die automatisch Kontext aus Slack-Gesprächen extrahiert und sich kontinuierlich selbst aktualisiert.

„Früher wusste jeder eine unumstößliche Regel – jedes Dokument ist veraltet, sobald du es verschickst“, sagt er. „Aber jetzt können wir Dokumente erstellen, die wirklich in Echtzeit auf dem neuesten Stand bleiben. Wenn ein neuer Mitarbeiter kommt, öffnet er diese Site und sieht den vollständigen aktuellen Status des Projekts. Auch ich nutze es, um mich schnell auf den neuesten Stand zu bringen.“

Dokumente werden nicht mehr von Menschen geschrieben, sondern von der KI aus den echten Arbeitsabläufen „destilliert“.

6

Thread-Orchestrator: Lass Codex Codex verwalten

Während des gesamten Interviews fragt Peter Yang Rohan wiederholt nach einer Grenzfrage: Wie viele Codex-Threads kannst du gleichzeitig ausführen? Gibt es eine Ebene, wie bei Peter Steinberger (Gründer von OpenClaw), wo Codex wirklich zu einem „System wird, das Systeme verwaltet“?

Rohan gibt zu, dass er dieses Niveau noch nicht erreicht hat. Aber er enthüllt eine kürzliche wichtige Funktionsaktualisierung: Codex kann jetzt andere Codex-Threads steuern. „Du kannst einen übergeordneten ‚Orchestrator-Thread‘ haben, der andere Unterthreads aufruft, verwaltet und auf ihre Ergebnisse wartet.“ Das ist ein neues Programmierparadigma – nicht Menschen schreiben Code, um mehrere Agenten zu koordinieren, sondern die Agenten organisieren sich selbst.

Normalerweise führt er fünf oder sechs Codex-Threads gleichzeitig aus, aber seine Einstellung ist die des „Delegierens“. „Ich sitze nicht herum und warte auf die Ergebnisse von Codex. Vor einer Sitzung schicke ich ihm eine Aufgabe – zum Beispiel die Erstellung einer Folienpräsentation für das morgige Meeting mit einem bestimmten Team – und dann gehe ich zur Sitzung. Wenn ich zurückkomme, öffne ich Codex, und das Ergebnis liegt bereits vor.“

Er nutzt die „PR-Betreuungs“