← All episodes · Lenny's Podcast
OpenAI Codex lead on the new shape of product work | Andrew Ambrosino
Overview
Lenny Rachitsky interviews Andrew Ambrosino, product and engineering lead for the Codex desktop app at OpenAI — a designer-turned-engineer-turned-PM and former founder whose stated ambition is to make Codex 'the best desktop app that has ever existed, full stop.' The numbers frame the stakes: Codex usage has grown 6x since January to over 5 million weekly active users, and nearly 100% of OpenAI employees — not just engineers — use it weekly.
The core thesis is that AI has inverted the product development process. The old process front-loaded documents, research, and prototypes because implementation was expensive; now implementation is the cheap part, and the scarce skill is taste — curating among the '90 uncoordinated explorations' of any given feature, choosing the right medium for a point, and knowing what to build at all. From there the conversation covers what taste concretely means, why frontier models are still bad at design, role collapse (and why eliminating the product role is 'a terrible idea'), the 'zone defense' model for PMs, why the Codex app would have failed if launched in November instead of February, how Andrew runs his own job through Codex automations, and the vision of Codex/ChatGPT converging into a 'home base' that orchestrates the tools you already use — including the videographer whose Codex built itself a Premiere Pro extension to edit launch videos.
Topics
The process inversion: implementation is no longer the expensive part
The entire traditional product process — research, ideation, docs, prototypes, then implementation — was shaped by one assumption: building is expensive, so de-risk it up front with cheaper artifacts. That assumption is dead. At OpenAI, where everyone is 'very agentic' with unlimited tokens, any needed feature probably has 90 different uncoordinated implementations floating around. Roles haven't fundamentally changed; the process has flipped backwards. The expensive part is now curation: of those 90 attempts, what's good, what folds into what, how should it be framed?
Andrew pushes back on the 'PRDs are dead, prototypes are in' meme. When implementation is abundant, the critical skill is picking the right medium for the point you're making: product clarity around a vague area still wants a document; stress-testing an interaction wants a prototype. He also flags a subtle loss: mediums used to encode process signal — something that looked production-ready WAS late-stage and de-risked. Now a polished-looking prototype may be a day-one exploration, and teams over-anchor on it (Lenny connects this to the 'primal mark' — the first artifact shapes everything downstream). Teams have to explicitly restore that signal: 'this is polished, but we're still in the design stage.'
What taste actually is (not aesthetics)
Riffing on a Linear product lead's tweet — Paul Graham clearly has great taste and wears cargo shorts — Andrew unpacks taste into layers: yes, an aesthetic component (an animation too snappy for its semantic meaning), but more importantly systems thinking (how does this fit the whole?), direction (what theme is this part of?), presentation, and above all: if we can build anything, what should the goal be and how do we get there? That last question is 'the real taste question.'
This is also his hiring filter. The Codex team is double-digit engineers, about half that in design, few product people — heavy on former founders and 'founder-shaped' people with immense taste and agency. His bar: 'you're going to have unlimited tokens and we can't just be doing slop — you need to determine what's signal and what's noise in a world of infinite content.' The most valuable person now is one who can take an idea from conception to done with the taste to know it's great.
Why frontier models are still bad at design
Andrew gives practical and structural reasons. Practical: design is harder to grade than code — the human element of taste is part of the feedback loop, so there's no clean reward signal like 'does it compile' — and labs historically invest in capabilities that accelerate AI research itself, which coding does and design doesn't. Those will fade.
The harder problems: (1) Novelty matters in design in a way it doesn't in engineering — last year every new website copied Linear's, and a model that outputs Linear's website every time has learned culture, not taste; software wants known patterns, design wants an element of randomness. (2) There's an abstraction layer between visual design and code that models don't yet grasp: knowing that two different-looking components should share semantics and code, so a rebrand is a change to shared abstractions rather than 263 one-by-one component edits. That interplay 'still feels out of reach.' On whether design process is dead (referencing Jenny Wen's episode): the ritual — the 'case study factory' that valued process over outcomes — deserves to die, but the overlay of knowing where you are in a process matters more than ever. New tools like 'baby codex' (a simplified clone of the production codebase you can vibe-code interaction experiments over) are the new design process.
Role collapse, zone defense, and why killing the PM role is a mistake
The Codex org has seen more role collapse than most — designers who speak engineer, PMs who write code — but Andrew rejects the 'everyone is just a builder' extreme. Eliminating roles dangerously eliminates the idea that disciplines are specialties with knowable best practices: 'you can use Excel, but you cannot work on the finance team.' His reframe: your role is the average of where your work lands, not the fences around it. What's genuinely eroding is tool-gatekeeping — being good at a role no longer means being good at its tool (he long felt he shouldn't be an engineer because he didn't care about memorizing TypeScript syntax).
For product managers he describes 'zone defense': if two product people are working too closely, that's a bad signal. In a world of bottom-up chaos, tastemakers spread out for full company coverage, guiding ideas from inception and filling gaps, while product-minded engineers reduce the need for coherence review. Management doesn't go away — everyone becomes both IC and manager: an IC managing agents and workstreams is doing the same job as a manager of teams, just at different granularity.
Timing beats shape: the November-vs-February lesson
Planning at model speed: the shorter-term something is, the more detail it needs; a 9-month plan must stay hazy because any precision is false precision. His operating pattern from his last company: list everything worth doing over a year or two, prototype all of it, ship what's ready, and let the rest 'sit and bake' — re-testing each time models leap, because whether a feature works depends on model intelligence, not its shape.
The canonical example: he's 'very confident' the Codex app released in February would have absolutely failed in November — identical product, different models. Same thread runs through Operator → Atlas agent mode → Codex: fundamentally the same feature re-released with different intelligence and totally different outcomes. The original Codex web release was 'too AGI-pilled' — full delegation before models could deliver — while a competing local, more modest tool matched the moment better. The lesson: don't be stubborn about 'this isn't working so it's a bad feature'; it may just not be ready. Writing the code isn't a reason to ship — it's an artifact to test against future models. And one request to research everywhere: models reliably increase complexity — 'please make the models better at deleting code.'
Running your job through Codex: automations, briefs, computer use
Andrew aligns his own Codex usage with whatever his job currently is — the personal dogfooding loop that shaped the app ('make it so good I can build the Codex app with it'). Today that means a morning daily brief distilled from his ~3,000 Slack channels, set up as a scheduled automation he coaches conversationally ('next time this runs, deemphasize this workstream') instead of editing instructions. For the May-era coordinated release (in-app browser, computer use, artifacts — 'Codex for almost everyone'), he automated gathering status from PRs and Slack into a tracker.
Lenny's example: a spam-filtering email app he built in Codex required the miserable Google Cloud pub/sub console setup — so he asked Codex to do it, and computer use simply took over his machine and clicked through ('I don't care if you don't have a connector, man. I'll just start clicking'). The product strategy behind these stories: everyone builds personal systems; when themes recur (memory/'mind palace' setups in Obsidian or Notion), that's the signal to promote a workflow into a first-class product primitive — versus leaving what's genuinely just 'your job process' as configuration. Deciding which is which is, again, taste.
The vision: a home base, not a super app
In January–February, before launch, OpenAI dogfooding revealed clear internal PMF with engineers — but also marketing, comms, finance, and legal staff using Codex despite it being 'actively hostile' to them (showing code, asking to approve shell commands). The company tried adding Codex to ChatGPT desktop and Atlas for those personas, and 'the most annoying problem happened': nobody would leave the Codex app. The developer-tool-vs-knowledge-work-tool binary is false; the answer is one surface that starts simple and grows complex based on what it learns about your work.
Andrew resists the 'super app' framing in favor of 'home base': where you start work, end work, and automate work — and it uses whatever tools the job needs. It talks to the real Excel add-in rather than trapping financial modeling in an in-app spreadsheet. The emblematic story: videographer Brent, curious whether Codex could edit videos, found it understood Premiere Pro, edited the backing files, and — where it hit limits — built itself a Premiere Pro extension it could then command to move markers. Two inverse integration models run in parallel: Codex reaching into your existing tools (connectors, computer use, self-built extensions), and web apps running inside Codex with the agent alongside (Dan Shipper's prediction). Browser shape remains genuinely unresolved: agent-only browser vs. your actual browser, plus 'boring but tedious' problems like whose keyboard shortcuts to inherit.
Fail corner and career advice
Andrew says this is the first time in his career he hasn't felt like he was failing: a startup sold 'for parts' after years of slog in regulated industries, then another regulated-industry AI tools job of repeated failures — '10 to 15 years' of it before skill set, passion, and market lined up. Even now, the Codex/ChatGPT convergence work generates constant micro-failures, surfaced by OpenAI's culture of brutal internal candor ('a 2,000-message thread about how stupid we are') — which he credits for the external product's quality.
His closing advice, from the post-credits conversation: don't get married to your exact process — get married to the outcomes you're uniquely able to deliver, because 'I'm the best at understanding Figma auto layout' is a dead end when AI gets better at that too. Success with AI demands unusual self-awareness and tolerance for constantly relearning; he's candid that this self-selecting early-adopter temperament won't describe most of the population. Lightning round: The Gruffalo and The Big Orange Splot (an anti-conformity parable he reads as an agency story — 'you can just do things'), the Magic School Bus reboot, and Linear as the software product he most admires.
Visuals
- Old world: de-risk before buildingResearch → docs → prototypes → expensive implementation last
- New world: everyone builds first~90 uncoordinated implementations of any needed feature appear
- Curation becomes the bottleneckWhat's good? What folds together? How should it be framed?
- Pick the medium deliberatelyDoc for product clarity, prototype for interaction stress-tests
- Re-state the process stagePolish no longer signals maturity — say 'this is still exploration'
Takeaways
- The product process has inverted: implementation is cheap and abundant, so the scarce skills are curation and taste — choosing what to build and what's signal among infinite output.
- PRDs aren't dead: pick the medium for the point. Vague product questions still want documents; interaction stress-tests want prototypes. And re-state process stage explicitly, because polish no longer signals maturity.
- Judge features by model timing, not shape: prototype broadly, let unready ideas 'sit and bake,' and re-test them at every model leap. The same product can fail in November and win in February.
- Keep roles as specialties while welcoming fluidity: your role is the average of your work, not its fences — but 'you can use Excel' doesn't qualify you for the finance team.
- Product managers should play zone defense: spread tastemakers for coverage across bottom-up chaos rather than clustering on the same feature.
- Marry outcomes, not process: any advantage defined by mastery of a specific tool ('best at Figma auto layout') is a depreciating asset.
Notable quotes
It's backwards. The implementation is actually not the expensive part anymore. It's, dare I say, taste.— Andrew Ambrosino
I am very confident that the Codex app that we released in February, if that had been ready in November, it would have absolutely failed in the market... the only difference was the models.— Andrew Ambrosino
You're going to have unlimited tokens and we can't just be doing slop — you need to be able to determine what's signal, what's noise, in a world of just infinite content.— Andrew Ambrosino
Yes, you can use Excel, but you cannot work on the finance team.— Andrew Ambrosino
If research is listening at any company: please make the models better at deleting code.— Andrew Ambrosino
Do not get married to your exact process. Get married to the outcomes that you are uniquely able to deliver.— Andrew Ambrosino