LLenny's Podcast
← All episodes
Andrew Ambrosino28 June 2026

OpenAI Codex lead on the new shape of product work

6Frameworks
15Insights

Frameworks in this episode

Innovation3 steps

Adversarial Dogfooding Loop

Force all your work through your own product even when it's the wrong tool, so it becomes the right tool

Read →
Innovation3 steps

Build-and-Bake: Ship the Same Feature Until the Model Catches Up

Prototype ambitious features now, let them sit, and re-release the same shape each time models leap

Read →
Strategy3 steps

Detune Precision by Time Horizon

The shorter the horizon, the more detail; keep long-range plans deliberately hazy to avoid false precision

Read →
Productivity3 steps

Label the Process Stage, Not the Polish

A production-looking prototype no longer means it's production-ready — say the stage out loud

Read →
Productivity3 steps

Match the Medium to the Point

When implementation is cheap, the skill is choosing document vs prototype for the point you're making

Read →
Leadership3 steps

Zone Defense for Product Work

Spread taste-makers out to cover the whole field instead of clustering on the same problem

Read →

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Myth Buster· 2

Myth Buster06:30

PRDs Aren't Dead — You Just Have to Pick the Right Medium

Against the popular 'PRDs are dead, prototypes are in' claim, Andrew pushes back. When implementation is abundant, the skill is choosing the right format for the point you're making: a document for product clarity in a vague area, a prototype to stress-test an interaction.

  • Non-engineers are tempted to jump straight to a prototype to show what they mean
  • Engineers are tempted to write lots of documents that aren't worth reading
  • The format should match the point: docs for clarity, prototypes for interaction testing
  • Because building is cheap, choosing the medium is now the important decision

“you've seen many product leaders say PRDS are dead prototypes are in and I actually don't believe this at all.”

Andrew Ambrosino · 07:00

“if implementation is abundant, then it's really important to pick the right format for the point you're trying to make.”

Andrew Ambrosino · 07:30
#product#prd#prototyping#communication
Myth Buster16:30

Is the Design Process Dead? Both True and False

Andrew was never a fan of the formal design process even before AI — the diverge/converge, research-guaranteed-quality academic ritual. He agrees the day-to-day specifics are dead, but says the process as an overlay (knowing what stage you're at) matters more than ever now that speed of implementation has collapsed.

  • The old process assumed you could only afford to build once, so you exhaustively explored first
  • Prototyping got pulled in early via Figma/Origami; now full implementation gets pulled in too
  • Tied to exact tools and day-to-day specifics, the process is dead
  • As an overlay that marks where you are in the process, it's more important than ever

“So to say the design process is dead, I feel like it's both true and false, right?”

Andrew Ambrosino · 20:30

“I genuinely was not a fan of this process before AI”

Andrew Ambrosino · 17:00
#design#process#product#ai

Hot Take· 3

Hot Take03:00

Implementation Is Cheap Now — Taste Is the Real Bottleneck

Andrew argues the traditional product process has inverted: because anyone can now stand up any feature by talking to a model, implementation is no longer the expensive part. What's scarce is taste and curation — sifting the dozens of uncoordinated attempts at the same feature into something coherent.

  • Anyone can build almost any feature from scratch just by talking to the models
  • Old process derisked expensive implementation up front via docs, research and prototypes
  • That assumption is gone; the bottleneck moved from building to judging
  • One needed feature might have ~90 uncoordinated teams implementing it at once
  • The hard work is curation: what's good, what to fold together, how to frame it

“The implementation is actually not the expensive part anymore. It's dare I say taste.”

Andrew Ambrosino · 05:00

“right now I'm sure there are 90 different explorations for there's this feature that we desperately need to do”

Andrew Ambrosino · 04:30
#product#taste#ai#process#openai
Hot Take24:30

Getting Rid of the Product Role Is a Terrible Idea

Andrew warns against the extreme 'everyone's just a builder' bandwagon. Eliminating roles dangerously eliminates the idea that disciplines have knowable best practices — hard-won processes that get abandoned because someone wrote a bit of code. Every discipline has a real skill component.

  • Killing roles can kill the recognition that specialties have knowable best practices
  • Product as a discipline has real, tried-and-failed processes worth keeping
  • The 'this isn't your lane' gatekeeping can go away — but not everyone can do everything, in breadth or depth
  • You can use Excel and still not be able to work on the finance team

“I I've heard a lot of companies be like, we're getting rid of the product role, which I think is, by the way, a terrible…”

Andrew Ambrosino · 25:00

“part of the danger in eliminating the concept of roles is that it can dangerously eliminate the idea that things are specialties with knowable best…”

Andrew Ambrosino · 25:00
#roles#product#hiring#management
Hot Take40:30

A Plea to Research: Make Models Better at Deleting Code

Andrew calls out a core weakness blocking fully autonomous development: models almost always increase complexity. His public ask to research teams anywhere is to make models better at deleting code — because complexity creep becomes a real problem when you try to put development on autopilot.

  • All models currently tend to increase complexity
  • Complexity creep is a blocker for autonomous, unsupervised development
  • Andrew's explicit ask: make models better at deleting code
  • They're not yet at a 'set up a loop that improves the app' stage, but trying

“If research is listening at any company, please make the models better at deleting code.”

Andrew Ambrosino · 41:00

“One thing that I think all models suffer with right now is just they they usually increase complexity.”

Andrew Ambrosino · 40:30
#models#code#autonomy#research

Explainer· 3

Explainer10:00

What 'Good Taste' Actually Means (Beyond Aesthetics)

Andrew unpacks the buzzword 'taste.' People overemphasize the aesthetic part; taste is really systems thinking — how a thing fits the wider context, what theme it belongs to, and, most importantly, deciding what to build in the first place when you could build anything.

  • There's an aesthetic component (e.g. an animation that's too snappy for its meaning)
  • But the bigger part is systems thinking: how this fits the whole and where you're going
  • Much of taste is wider context and how to present information
  • The real taste question is 'if we can build anything, what's the goal and how do we get there?'

“there's also a a systems thinking part of it. Like how does this fit in the system?”

Andrew Ambrosino · 11:00

“how do we how do we get there that I think is like actually the real taste question here.”

Andrew Ambrosino · 12:00
#taste#design#product#judgment
Explainer12:00

Why Frontier Models Are Still Bad at Design

Andrew gives practical and deeper reasons AI lags at design. Design is harder to grade than code (there's no clean compile-or-not loop), labs prioritized coding because it accelerates AI research, and design demands novelty plus a codebase-abstraction layer that pure visual skill doesn't cover.

  • Design is harder to grade than code — the human taste feedback loop is tedious to build
  • Labs invested in coding first because correct code accelerates AI research; design doesn't feed that flywheel
  • Design needs novelty and randomness, whereas engineering wants to reuse known patterns
  • A rebrand isn't updating 263 components — it's the semantic abstractions between them, which models still miss

“I think design's a little bit harder to grade um than than software”

Andrew Ambrosino · 12:30

“if I have a model that outputs linear's website every time that's not the challenge here right”

Andrew Ambrosino · 14:00
#ai#design#models#research
Explainer28:30

'Zone Defense': How Product People Should Coordinate Now

Andrew describes running product like zone defense. If two product people work too closely, that's a bad signal — you want to spread out, find the gaps, and get full company coverage. With top-down year-long planning dead, taste-makers steer chaotic idea generation from inception to shipped product.

  • Two product people working too closely is often a bad signal
  • Do a force-directed exercise to find gaps and create space between people
  • Top-down, year-long planning no longer works amid the chaos of ideas
  • Taste-makers guide products from inception; you want full 'company coverage'

“if two product people are working too closely that's often not a good signal”

Andrew Ambrosino · 28:30
#product#management#coordination#planning

Story· 3

Story33:30

The Same Codex App Would Have Failed in November

Andrew is confident the Codex app they shipped in February would have flat-out failed if released in November — with the exact same shape. The only difference was the models between those months. It's the case for building ambitious features now and letting them 'bake' until a model leap makes them work.

  • Identical product shape, radically different outcome just months apart
  • The only variable that changed was model intelligence
  • Strategy: list features you want, prototype them, ship the ready ones, let others bake
  • Re-try baked features each time there's a leap in the models

“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…”

Andrew Ambrosino · 33:30
#codex#product#timing#models#openai
Story52:30

Codex Was 'Actively Hostile' to Non-Engineers — Who Refused to Leave

Once Codex hit internal PMF with engineers, people from marketing, comms, finance and legal started using it too — even though the app was actively hostile to them, showing code and asking to run terminal commands. OpenAI tried building friendlier surfaces for those personas, but nobody would leave Codex.

  • Codex hit clear internal PMF with engineering and research workflows first
  • Non-technical staff adopted it despite it being 'actively hostile' to them
  • OpenAI tried porting Codex lessons into ChatGPT and Atlas for other personas
  • The revealing result: nobody would leave Codex for the apps built for them

“we have people from marketing from comms from finance from legal from basically every discipline who are using this codeex app even though it is…”

Andrew Ambrosino · 53:00

“nobody would leave the Codex app for the apps that were allegedly for these other personas.”

Andrew Ambrosino · 54:00
#codex#adoption#pmf#openai
Story57:30

Codex Built Itself a Premiere Pro Extension to Edit Videos

Their in-house videographer Brent edited launch videos with Codex — not because it's a video editor, but out of curiosity. Codex understood he used Premiere Pro, edited the backing files, and when it couldn't do everything, built itself an extension it could install into Premiere Pro and talk to.

  • Codex isn't a video editor and has no video UI
  • It started because Brent was simply curious whether Codex could edit videos
  • It edited the files backing Premiere Pro's timeline
  • When that wasn't enough, it wrote and installed its own Premiere Pro extension to control the app

“So naturally, what Codex then did was built itself an extension that could be installed into Premiere Pro that it could then talk to”

Andrew Ambrosino · 58:00

“He started just because he was curious if Codex could edit videos.”

Andrew Ambrosino · 57:30
#codex#video#extensions#ambition

Takeaway· 4

Takeaway08:30

A Prototype That Looks Production-Ready Can Anchor You Wrong

The medium used to carry signal about where you were in the process — something that looked like production meant assumptions had been derisked. That link is now broken. A polished-looking exploration can trick a whole company into thinking it's ready to ship when it isn't.

  • Previously, 'looks like production' implied late-stage, derisked, design-reviewed work
  • Now polish and process-stage are divorced from each other
  • A too-polished exploration makes people say 'can we release this now?'
  • It may look ready for prod but not reflect the research or the business goal

“you do not want to over anchor on this thing that was meant to be an exploration, but now it looks so production ready”

Andrew Ambrosino · 09:30
#design#prototyping#product#process
Takeaway21:30

Your Role Is the Average of What You Spend Time On

In the Codex org, role collapse is real — designers speak engineer, PMs write code. Rather than being defined by the fences between disciplines, people are defined by the average of where their work actually lands. If most of your work is PM work, you're a PM for now.

  • The Codex org saw more role collapse than other teams because it's a technical product
  • Designers speak engineer; PMs write code and use technical language
  • People are defined less by discipline boundaries, more by the average of their work
  • The whole app is shaped by a dogfooding loop — they use the app even when it's not the best tool

“everybody's sort of defined less by the fence and the boundaries of where design stops and engineering starts, but more the average of where they're…”

Andrew Ambrosino · 22:00
#roles#teams#product#openai
Takeaway31:30

Nine-Month Plans Are False Precision

Andrew says planning isn't revolutionary at OpenAI — the shorter-term something is, the more detail it needs. They still plan nine months out, but it has to stay hazy: any precision added to a long-range plan right now is false precision because the models keep changing what's possible.

  • The shorter-term a thing is, the more detail its plan needs
  • Long-range plans must stay hazy on purpose
  • Precision on a nine-month plan is false precision and wastes time
  • On the applied product side, anything planned in November wasn't what actually happened

“any amount of precision that you add to a 9-month plan right now is false precision.”

Andrew Ambrosino · 32:00

“the shorter term something is, the more detail it needs.”

Andrew Ambrosino · 32:00
#planning#roadmap#product#ai
Takeaway1:07:30

Don't Get Married to Your Process — Marry Your Outcomes

Andrew's one piece of advice for succeeding with AI: don't get married to your exact process, get married to the outcomes you're uniquely able to deliver, and change your process freely to try things. Tying your identity to a specific tool or skill (like Figma auto layout) is a trap when AI will out-do that too.

  • Don't get married to your exact process
  • Marry the outcomes you are uniquely able to deliver
  • Change your process to try new things
  • Being 'the best at Figma auto layout' is a losing bet — AI will be better at that

“do not get married to your exact process. Get married to like the outcomes that you are uniquely able to deliver”

Andrew Ambrosino · 1:08:00
#career#ai#process#advice