Lenny's Podcast · Jun 28, 2026
Andrew Ambrosino, product and engineering lead for OpenAI's Codex app, argues that AI has inverted the traditional product process: implementation is now cheap and abundant, making taste, curation, and judgment the new scarce resource. The episode covers how product roles are evolving, why design lags behind code in AI capability, and how autonomous agent workflows are reshaping day-to-day product work.
Because anyone can now stand up a feature by talking to a model, the constraint in product work has shifted from building to deciding what is worth building and keeping.
If your product process is still organized around de-risking implementation, it is misaligned with the actual cost structure of your team. Your planning, approval, and resource allocation rituals were designed for a world that no longer exists.
It is like moving from a world where printing a book costs thousands of dollars to one where printing is free — the job is no longer typesetting, it is editing.
Taste is the ability to make high-quality decisions across aesthetics, systems thinking, and strategic direction when there is no shortage of things to choose from.
This is the argument that traditional PM process skills (writing PRDs, running sprints) are necessary but no longer sufficient. The PMs who thrive are those who can stand in a room full of polished prototypes and make a confident, well-reasoned call on what is right.
Taste is the editorial function in a newsroom flooded with contributed articles — the value is not in writing more pieces, it is in knowing which one to run.
Whatever medium you use to express an idea first shapes every decision that follows, so the choice of starting format is itself a high-stakes product decision.
Stakeholders — including executives — will over-anchor on whatever they see first. If you show a prototype before the problem is defined, you have effectively made a product decision by accident.
It is like showing someone a rough sketch versus a finished rendering of a house — the rendering makes them react to details that may not even belong in the design yet.
Because you can build anything quickly, you must now explicitly decide which format best serves the specific point you are trying to make — that decision is no longer implicit.
If your team defaults to prototypes because they are easy, you are making a format choice that signals false maturity to every stakeholder who sees it. Explicit stage-setting becomes a communication responsibility that did not exist before.
It is like choosing between a voice memo, a text message, and a formal email — the content might be the same but the format changes what the recipient does with it.
Your real role is the weighted average of your daily activities, not the label on your org chart — and that average is now expected to shift continuously.
For a PM, this is both an opportunity and a threat: you can contribute more broadly, but you are also competing with engineers and designers who are expanding into your traditional territory. Your defensible value is judgment and depth, not role monopoly.
It is like a basketball player whose position is described by where they spend most of their time on the court, not by a fixed label — a 'power forward' who mostly plays guard is effectively a guard.
Zone defense PM means each product person takes responsibility for a patch of the product landscape rather than for a specific team or process, filling gaps as they appear.
This reframes what a PM's day looks like in an AI-forward org: less roadmap ownership, more pattern recognition across many parallel efforts. If you are used to owning a track end-to-end, zone defense requires a mental shift toward influence without direct ownership.
It is like a basketball zone defense where each defender owns a region of the court, not a specific opponent — you go where the ball is, not where your man is.
When companies abolish the product role, they do not just lose headcount — they lose the institutional knowledge of what has been tried, failed, and why.
This is a direct risk for PMs in orgs moving fast on AI adoption. The counter-argument is not 'PMs are special' — it is 'product discipline encodes knowledge that is expensive to rediscover.' Make that knowledge visible and explicit.
Getting rid of PMs because engineers can now write code faster is like getting rid of editors because journalists can now publish instantly — the constraint was never the printing press.
In AI products, timing a feature release to model capability maturity is as important a product decision as the feature's design.
Traditional product logic says a failed feature is a signal to kill it or pivot. In AI products, failure may be a timing signal, not a product-market fit signal. Your backlog of 'failed' AI features deserves a second look every model generation.
It is like launching a streaming video service in 1998 — the product idea was right but the infrastructure was not ready; the same launch in 2010 is Netflix.
A 'baby product' is a stripped-down replica of your production app that approximates all key interactions, purpose-built for fast, low-risk design exploration.
This is a concrete process primitive that replaces Figma-based prototyping for teams with AI coding capability. If your design process still routes through static prototypes for interaction exploration, this is a more testable and representative alternative.
It is like a wind tunnel model of a car — physically accurate enough to test aerodynamics, but never intended to drive on a road.
Design capability lags in AI models because creating a feedback loop that teaches a model what good design is requires human taste as part of the grading mechanism, which is harder to automate than checking if code compiles.
AI-generated design will remain unreliable for brand differentiation and novel UX patterns for the foreseeable future. Design taste and originality are defensible human contributions — do not automate this prematurely.
Training a model on design is like training a judge by giving them a rulebook with no cases — the judgment required is relational and contextual, not rule-following.
Deliberately using your own product for real work, even when it slows you down, generates the most honest and actionable product feedback possible.
Structured research and analytics surface what users report; dogfooding surfaces what users experience but do not articulate. In fast-moving AI product development, the latency of traditional research cycles is too high — dogfooding compresses discovery to near-zero.
It is like a chef who only eats at their own restaurant — they will find every bad dish faster than any critic.
Any precision added to a roadmap beyond a short time horizon in an AI-driven product context is fabricated — it signals confidence that does not exist and costs real planning time.
This challenges the enterprise product planning ritual of quarterly and annual roadmaps. For AI product work in particular, a detailed 9-month plan is not a commitment — it is a liability that anchors teams to assumptions that will be wrong.
Adding detail to a 9-month AI product plan is like drawing a precise weather map for next autumn — the framework is useful but the specifics are fiction.
The sustainable career move in an AI-accelerated environment is to hold your process loosely and your outcomes tightly — tools and steps are replaceable, the value you deliver is not.
For any PM with 10+ years of practice, the process you have refined is also the process most likely to be partially automated. The question is whether your identity is in the process or in the judgment that underlies it.
It is the difference between a navigator who knows how to read stars and one who knows how to use GPS — when satellites go down, one of them is still useful.
Your product process is built for a cost structure that no longer exists.
Every gate, approval step, and de-risking ritual in traditional product development was designed because implementation was expensive. AI has made implementation abundant. If your process has not changed, your team is paying a tax for a constraint that is gone.
The PM role is not dying — but the defensible part of it is shifting fast.
The parts of PM work that were gatekept by access to implementation (writing specs, coordinating design/dev handoffs) are dissolving. What remains — and what cannot easily be automated — is judgment: what to build, when, in what form, for whom. That is where PM value concentrates now.
AI product failures may be timing failures, not product failures.
If you have features in your graveyard that failed because the AI was not good enough, those are worth revisiting with every model generation. The product shape may have been right; the model readiness was not. This is a different backlog management mental model than traditional PM practice.
it's been kind of research ideation maybe there was some prototyping but it was you know even when we got past waterfall it was still kind of flavored of like the implementation is expensive and so you what you want to do is you want to derisk all implementation up front through documents through research through prototypes because prototypes and designs are cheaper was kind of the the assumption there uh and that's changed that's like totally changed
Concise historical framing of why the old product process was structured the way it was — and the explicit claim that this assumption has now been invalidated. Directly relevant for any PM questioning whether their current process still makes sense.
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 and that that the only difference was the models between November and February, right?
The clearest single data point in the episode on model-readiness as a product variable. Directly actionable: it reframes how to interpret AI feature failures in your own backlog.
there's sort of a an abstraction layer that is an interplay between the software design and the code it's being written. Like this thing over here in this corner should share x y and z in the codebase with this thing down here. Right? And that's a little bit different than saying the model needs to be a better designer
Explains why AI design weakness is not just about visual aesthetics but about deep semantic relationships in codebases — relevant for anyone thinking about where AI-generated UI will and will not be reliable.
I generally look for like obviously command over the discipline but then the taste to say like hey you're going to have unlimited tokens and I don't like we can't just be doing slop like you need to be able to determine what's signal, what's noise, like in a world of just infinite content.
Operationalizes what 'taste' means in hiring terms at an AI-native product team — useful signal for what to screen for when building or joining such a team.
the lesson in all of this was just that like the whole developer tool versus general knowledge work tool like there's a lot of nuance here that isn't just one or the other. And I think we really we believe really strongly in this and that there are certainly in the same way that we talk about the average of your role is like what your role is now. This is true on the product side too.
Connects the role-fluidity concept to product positioning — the same 'average' framing that applies to people applies to products. Relevant for product strategy and positioning decisions.