← All episodes · Peter Yang

Inside How OpenAI Uses Codex to Do Product Work | Rohan Varma

2026-07-05 · original episode

Overview

Peter Yang sits down with Rohan Varma, a product manager on OpenAI's Codex team, to unpack how Codex (OpenAI's coding and computer-use agent) has completely rewired how product managers, engineers, and designers work inside OpenAI. Rohan explains that Codex isn't just a coding tool anymore, it's become an operating layer for the whole company: synthesizing customer feedback from Slack, Notion, Linear, and email, generating PRDs and slide decks, running automations that trigger off Slack messages, and even controlling a browser to complete tasks no API supports. The conversation moves from high-level philosophy (the product development lifecycle has effectively inverted, from 'plan then build' to 'build everything, then decide what ships') into a live, demo-heavy walkthrough of Rohan's actual daily workflows in the Codex app.

The back half of the episode is a tour of concrete PM workflows: turning Slack feedback threads into Linear tickets on autopilot, setting up conditional automations that fire once and then delete themselves, using ImageGen inside Codex to rapidly prototype UI ideas from a single screenshot, building disposable one-off internal tools and dashboards on the fly, and using Codex as a 'chief of staff' to triage meetings, summarize threads, and track commitments. Rohan and Peter also swap tips on parallel Codex threads, the new 'goal' feature for long-running autonomous tasks, thread-spawning orchestration, and the mindset shift required to get maximum leverage out of an agent that can, in Rohan's words, do '10x more ridiculous' things than most people think to ask for.

Throughout, both hosts frame this as a broader referendum on the PM role: rather than devaluing product management, they argue heavy AI automation frees PMs from busywork (writing docs, chasing status updates, synthesizing feedback) so they can spend more time on customer conversations and high-leverage decisions, while the AI handles synthesis, drafting, and increasingly the automation of automations itself.

Topics

How Codex has inverted the PM workflow at OpenAI

Rohan opens by describing two levers by which Codex has changed his job: the mechanics of the PM role itself, and the fact that everyone around him (engineers, designers, PMs) now works differently too, so the whole team's division of labor has shifted. Historically, PM work was dominated by information synthesis: reading through hundreds of daily bug reports, enterprise escalations, and Twitter complaints, then turning that into ideas and plans. At OpenAI, the Codex team is deliberately thin on product headcount, and Rohan says this is only possible because Codex does the heavy synthesis work, pulling context from Notion, Linear, email, and Google Drive so that even someone dropped onto a brand-new project can be fully up to speed in twenty minutes.

He argues the artifact-generation side of the job (slides, PRDs, prototypes, docs) has also been automated away, freeing PMs to spend far more time on decision-making and direct customer conversations. Peter connects this to a meme about 'plans being written for agents, not humans,' and Rohan agrees that long-range planning has become almost obsolete inside OpenAI: instead of 12-month roadmaps, the team thinks in roughly 4-week windows, deciding current priorities and re-evaluating as they go, because Codex lets them build and evaluate ideas nearly instantly rather than needing to plan far ahead.

Rohan describes this as the product development lifecycle being 'inverted': previously, teams spent enormous upfront effort planning so that engineers only built the most important things; now, the default is to just build things first (often as fast internal prototypes) and then decide afterward what's worth shipping. He cites the in-app browser as a concrete example: an engineer, Adam Fraser, built a working browser prototype in a single morning purely to speed up his own front-end iteration, showed it to Rohan unprompted, and that finished prototype became the seed for what shipped as a real product feature, rather than starting from a spec document.

Fewer human bottlenecks, more engineer autonomy

Rohan explains that with tools like Codex, human-to-human collaboration becomes the real bottleneck rather than raw execution speed. On most Codex product lines there are only one or two engineers per feature area, and previously each project would require product decisions to flow through PM check-ins that happened maybe a couple times a week. Now that engineers can move extremely fast independently, Rohan's role shifts toward defining upfront guardrails, the small set of strategic questions that need explicit decisions, so a feature stays cohesive with the broader product strategy, while engineers and designers are trusted to make the bulk of micro-decisions autonomously.

He jokes that Codex itself is his only way of tracking what all these autonomous engineers are actually building day to day: whenever he hears an unfamiliar term in a meeting or Slack thread, he has Codex go gather context on it, and says a couple of times a day he learns about some impressive feature someone shipped that he had no idea was in progress. This reflects a broader point he returns to throughout the episode: OpenAI operates like a research lab even in how it builds product, constantly experimenting rather than committing to fixed long-term plans, and Codex is treated as core infrastructure so essential that losing access to it would seriously disrupt the company's ability to operate.

The gap between developers and 'normie' ChatGPT users

Peter raises what he calls the key adoption problem: OpenAI has roughly a billion ChatGPT users, but how do you get non-technical or less-ambitious users to actually adopt an agent as powerful as Codex without overwhelming them? Rohan responds that even among developers, only the top 5-10% of the most 'AI-pilled' frontier engineers at large enterprises are maximizing what Codex can do; a long tail is still just pair-programming or doing light delegation. He notes an important asymmetry: developers have watched AI coding capability expand incrementally over roughly three years, so they've built intuition for what's possible, while non-developers have mostly just experienced ChatGPT as a chat interface, so their mental model of what they can ask an agent to do is far narrower and out of step with what Codex can actually now delegate.

Rohan frames closing that ambition gap as one of the biggest open problems for OpenAI: figuring out how to make people, especially non-engineers, feel comfortable asking for far more ambitious things than a chatbot Q&A. Peter shares his own experience of getting progressively more ambitious with requests, citing a skill he built that posts to seven social platforms simultaneously using browser automation, since most of them don't expose APIs, which segues directly into a discussion of Codex's computer/browser-use capability as one of its most magical features.

Browser use, automations, and Codex 'using itself'

Rohan calls out the browser-use/computer-use capability as central to Codex's design philosophy: build simple, general primitives that let Codex operate a computer, then let the model combine them so users never need to understand the mechanics, they simply state a goal. His favorite example: he asked Codex to turn a Notion doc into a hosted 'Site' (OpenAI's new website-hosting product). When he later reviewed the execution trace, he discovered Notion's MCP integration didn't expose the doc's embedded images, so Codex independently opened a browser, inspected the DOM, extracted the actual image files, and used them in the generated site, without being told to do any of that explicitly.

This leads into a detailed walkthrough of Codex's automation system. Rohan describes setting up roughly five or six recurring automations: for example, having Codex synthesize Slack feedback threads into a Linear board every day or week, then Slack him when it's done. Critically, he shows that automations aren't just recurring, they can be conditional and self-terminating: he described telling Codex, 'when Alex responds to this message, draft a reply email based on our last DM, then delete the automation,' and Codex will actually set up a watcher, act once the trigger fires, and remove itself afterward. Peter riffs that this means you could set up an automation where anyone who tags Rohan in a long Slack thread gets an auto-generated reply pretending to be him, and Rohan confirms a coworker (Alex) already does something similar, faking an '@Codex' Slack bot purely via a polling automation.

The conversation touches on a real limitation: automations currently run locally, only while Rohan's laptop is on, so a Friday-morning automation won't fire if his machine is off. Options discussed include running automations on a dedicated Mac Mini, and Rohan reveals Codex already has mobile support and remote/cloud-controlled instances, with native cloud automations explicitly on the roadmap though not yet shipped.

Live demo: ImageGen for rapid design prototyping

Rohan walks through a live demo in a sandboxed 'dummy environment' (since he can't show OpenAI's actual internal tools) of using ImageGen directly inside Codex by tagging the imagegen skill. He took a screenshot of the Codex 'composer' UI where users select a project, and asked Codex/ImageGen to prototype four or five alternative designs for that project-selection experience. It generated several distinct visual mockups almost instantly, staying within the existing design language just from the reference screenshot alone (no separate design-system file needed for this example, though OpenAI has also built internal skills that enforce their design language, and Codex can integrate with Figma plugins to pull actual design tokens).

Rohan calls this an 'AGI moment' for him: he'd previously thought of ImageGen as a novelty (e.g., 'turn my hair blue'), but realized it's a dramatically faster prototyping loop than generating multiple full React dummy websites to compare design directions. After picking a favorite mock, he can ask Codex to turn just that one into an actual working site prototype that can be shared and discussed with the team.

This flows into a discussion of the 'skill creator', a meta-skill that lets you tell Codex to look at a thread and package the pattern into a reusable skill for future consistency. Both hosts admit a shared worry: since they don't always read the diffs when a skill gets updated based on feedback, there's a risk of skills slowly degrading or 'slopifying' as fixes accumulate. Rohan says OpenAI is actively thinking about how to evaluate skill/plugin output when it changes, but for now his own practice is simply to manually test the updated skill and confirm it still looks right before moving on.

Disposable software and Codex as a personal chief of staff

Rohan describes a broader pattern he calls 'disposable software': because Codex makes building small tools essentially free, he frequently generates one-off apps that aren't meant to be reused. A recurring example is asking Codex to review all his unread Slack messages, identify the most important ones to respond to, and render a prioritized list as a simple local website. When a one-off tool proves useful enough to keep using, he'll ask Codex to set up an automation that regenerates it on a schedule (e.g., hourly), effectively turning a throwaway app into a persistent personal dashboard.

He extends this to a 'commitment tracker' variant, asking Codex to scan the last day of messages and surface every commitment he made, which helps offload the mental burden of tracking to-dos. Rohan says this lets him delegate organization and persistence entirely to the tool, and estimates Codex successfully knocks out roughly 80% of the tasks he hands off this way, which frees significant mental space. Peter connects this to his own framing that across nearly every workstream (strategy included), AI can typically do about 80% of the work, leaving a shrinking sliver of human judgment on top.

Rohan adds that a huge amount of PM time historically went into pure context-gathering, e.g., being added to a 50-message Slack thread and having to read all of it. Now he'll copy the thread and ask Codex for a TLDR, letting him respond immediately. He estimates he's now doing three to four times more work per day than he would without Codex. He also mentions using it for interview note summarization and even drafting his own performance review, since Codex has memory of his work and can compile a definitive list of everything he's contributed over a period like three months, something he says he's historically been bad at documenting himself, having spent most of his career as a founder just doing the work rather than tracking it.

Meeting load, calendar triage, and working as a 'delegator'

Peter asks whether Rohan's schedule is still dominated by meetings or whether he gets real build time. Rohan says he spends a large share of his time on OpenAI's enterprise motion, meaning many meetings, though mostly valuable customer conversations rather than internal overhead; his actual hands-on build time tends to start around 5pm. He describes using Codex explicitly as a 'personal chief of staff': at the start of each week it reviews his full calendar, consolidates meetings to create protected focus blocks, and flags which meetings could be replaced by a Slack DM instead.

On managing multiple parallel agent threads, Rohan says he typically runs five or six Codex threads at once, though he name-checks power users like Peter Steinberger who operate at a level beyond that ('maybe don't necessarily immediately start that at home'). Crucially, he frames his approach as full delegation rather than active monitoring: he fires off a task and doesn't check on it until a natural break, then reviews all the completed work at once, comparing it to how you'd manage a human report you trust rather than someone you have to micromanage. A concrete example he gives is having Codex 'nurse' a pull request end-to-end: wait for CI, fix CI failures, respond to human review feedback, and only ping him on Slack once it's fully ready to merge, collapsing what used to be ten separate check-in points into a single final notification.

Advanced tips: goal mode, thread orchestration, and tool integration

Peter asks whether Rohan has gone further into 'systems that manage systems,' referencing the loop-building trend some power users discuss on Twitter. Rohan says he hasn't gone as far as some (again citing Peter Steinberger as the frontier), but describes his personal optimization heuristic as constantly asking 'could Codex have done this?' for everything he does, and separately looking for the category of tasks people don't even attempt today because they'd normally be too tedious to be worth it, calling that an underexplored opportunity space. As a concrete example, he now maintains a live 'project overview' site per Slack project channel, which Codex updates every couple of hours by scanning all the channel's conversation and changes, turning it into a persistent, current source of truth rather than a document that's stale the moment it's written.

On concrete tips, Rohan highlights that Codex recently shipped the ability for a thread to spawn and control other threads, enabling a high-level orchestrator pattern. His top practical advice is to make sure Codex is integrated into every tool you use, even if that requires building custom CLIs or plugins, and that when a native integration doesn't exist, computer/browser use can often fill the gap. His broader mental model: whenever Codex fails at something, the right question isn't to give up and do it yourself, but to ask what context or information a human would have used to get it right, and then find a way to give Codex that missing context so the gap closes permanently going forward.

Peter adds his own tips from building an automated podcast-to-social pipeline: chaining multiple skills together (transcript-to-newsletter, a 'remove AI slop' cleanup skill, and a social-posting skill using browser automation for platforms without APIs), plus a tool called 'hyperframes' for generating video assets from text, and an HTML slide-generation skill. Both agree they manually review outputs rather than fully auto-publishing, in contrast to creators who 'just automate everything' and produce low-quality volume. Rohan notes this same bottleneck-shifting dynamic applies at OpenAI: since Codex lets engineers ship so much software so quickly, new bottlenecks emerge elsewhere in the org, like marketing being unable to produce assets fast enough, which OpenAI's DevEx team addressed by building Codex-based skills to auto-generate demo videos and graphics.

What this means for the PM profession

Closing out, Peter asks whether the PM profession, which he says had drifted toward being 'cross-functional alignment secretaries,' is becoming more fun again thanks to these tools. Rohan agrees enthusiastically, arguing that AI leverage isn't just about doing the same work faster; at the AI-native companies he's worked at (OpenAI and Cursor), it's about doing categorically more things end-to-end per person, not just accelerating a fixed task list. He frames this as personally exciting: being able to own more of the full lifecycle of a product, delight customers more, and operate without feeling constrained by capacity, since 'it's literally not a question of what is possible, it's just what should we do.'

Peter raises the flip side: this doesn't necessarily mean people work less, since the sheer expansion of what's possible tends to fill available time with more ambitious work rather than shrinking anyone's workload. Rohan agrees, noting he's always been someone who works a lot and that reducing hours was never his personal goal, though he expects genuine shifts in work patterns as these tools keep improving. The episode closes with Rohan pointing people to his Twitter and LinkedIn (Rohan Verma) for updates on what the Codex team ships next.

Visuals

1. Manual askDo a task once in a Codex chat, e.g. synthesize Slack feedback into a Linear board
2. Request automationAsk Codex to repeat this on a schedule (daily/weekly) or on a trigger (e.g. 'when Alex replies')
3. Codex configures itselfCodex sets up the recurring job or conditional watcher without further specification
4. Notify on completionCodex Slacks Rohan when the task finishes, e.g. 'PR is ready to merge'
5. Self-terminate if conditionalFor one-time triggers, Codex deletes the automation once the acceptance criteria are met

	Before Codex	With Codex
Planning horizon	12-month roadmaps planned upfront	~4-week priority windows, re-evaluated continuously
Product development order	Plan extensively, then build the most important things	Build broadly and fast, then decide what ships
Context gathering	Manually read 50-message Slack threads, docs, tickets	Codex synthesizes Notion/Linear/Slack/email into a TLDR in minutes
Artifact creation	PMs manually write PRDs, decks, prototypes	Codex generates drafts, mockups (via ImageGen), and prototypes on request
Status tracking	10+ manual check-ins per PR/project	One notification once Codex confirms the task is fully done

Takeaways

• The PM 'plan first, build later' model is inverting at OpenAI: teams now build fast prototypes first and decide afterward what's worth shipping, rather than spending weeks on upfront specs.
• Codex automations can be conditional and self-deleting, e.g., 'when X replies on Slack, draft a response, then delete this automation', not just scheduled recurring jobs.
• ImageGen inside Codex can turn a single UI screenshot into several on-brand design mockups in seconds, often faster than prototyping with throwaway React apps.
• Ask 'could Codex have done this?' after every task, and when Codex fails, diagnose what context a human had that Codex lacked, then feed it that context so the gap closes permanently.
• Treat Codex like a trusted direct report: fire off tasks across 5-6 parallel threads and review results at natural breakpoints instead of babysitting each one.
• Disposable, one-off internal tools (a prioritized Slack-response dashboard, a commitments tracker) are now cheap enough to generate on the fly and can be promoted into scheduled automations once proven useful.

Notable quotes

Aim for something that seems 10x more ridiculous than you ever think it could, and it probably can do like 90% of it.— Rohan Varma

You cannot walk from point A to point B in the OpenAI office without hearing Codex get mentioned.— Rohan Varma

Codex actually knows how to set up its own automation. It just comes back to you. You didn't have to think about what it was doing while it was doing it.— Rohan Varma

It's literally not a question of what is possible. It's just everything is possible. It's just what should we do?— Rohan Varma

It was just a known thing among everybody that any document is effectively immediately out of date the moment you ship it.— Rohan Varma

Over the course of the day, I'm probably doing three or four x more than I would have without Codex.— Rohan Varma