Notes from Lenny's Podcast episode OpenAI Codex lead on the new shape of product work | Andrew Ambrosino.
The useful frame is not simply "Codex writes code." The useful frame is that product work changes when implementation becomes cheap enough that many people can build plausible artifacts before the organization has decided what should exist.
That flips the bottleneck. The scarce thing is no longer typing the code. It is taste, curation, coordination, verification, and knowing which medium to use for which kind of uncertainty.
The core shift is simple: if anyone can ask a model to stand up a feature, the old sequence of product work stops being natural.
Previously, implementation was expensive. That pushed teams toward documents, research, wireframes, and prototypes before writing production code. The whole process assumed that building once was costly, so the organization should de-risk as much as possible before committing engineering time.
Codex changes that assumption. At OpenAI, Ambrosino describes a world where many people can independently build explorations of the same idea. The company may have dozens of uncoordinated attempts at a feature before there is a single official plan.
This is powerful, but it is also messy. If implementation gets cheap while attention and judgment remain scarce, the organization gets flooded with artifacts.
The new question becomes: out of the ninety things people built, which one actually points in the right direction?
A tempting conclusion is that PRDs are dead and prototypes are the new source of truth. Ambrosino pushes against that.
The better rule is: choose the medium based on the uncertainty.
Use a document when the question is product clarity around a vague area. Use a prototype when the question is interaction, feel, or putting something in people's hands. Use production code when the question is whether the system can actually work with real constraints.
The danger is that a prototype now looks too real. In the old process, a polished interface implied that assumptions had been de-risked and that the idea was late in the process. With AI, that signal breaks. A thing can look production-ready while still being an early thought experiment.
That creates a new product-management job: label the artifact correctly. Is this a sketch? A bet? A future model-capability test? A thing we are actually shipping?
"Taste" can sound vague, but this episode makes it more concrete.
Taste includes:
The aesthetic part matters, but Ambrosino's stronger point is about direction. If we can build almost anything, what should this be?
That is why taste becomes more important rather than less. AI expands the option space. It does not automatically rank it.
The episode has a useful explanation for why frontier models are better at code than design.
Code is easier to grade. It compiles or it does not. Tests pass or they fail. A loop can produce feedback automatically. Design quality is harder because the grading signal often includes human taste, culture, novelty, semantic fit, and context.
Software engineering often benefits from known patterns. Design often punishes pure pattern repetition. If every generated website looks like Linear, the model may be imitating good taste without producing new taste.
This does not mean models will stay bad at design. It means design improvement needs a harder feedback loop.
One of the more grounded parts of the conversation is the distinction between overlapping roles and pretending disciplines no longer exist.
On the Codex team, designers write code, PMs are technical, and engineers are expected to have product sense. The boundary between functions is blurrier. Ambrosino describes someone's role as the average of what they spend time doing rather than a fence around permitted activities.
That seems right. AI lowers the tool barrier. A PM can build more. A designer can test more. An engineer can explore product ideas more directly.
But he is also worried about companies overreacting: "we are getting rid of product; everyone is just a builder." That throws away accumulated discipline. Product is not just vibes. Design is not just pixels. Finance is not just using Excel. Engineering is not just writing syntax.
A healthier version is wider overlap plus deeper respect for specialties.
Ambrosino uses a "zone defense" metaphor for product work at OpenAI.
When many people are throwing ideas, prototypes, code, and workflows into the system, product leadership cannot be only top-down roadmap control. The job becomes coverage: where are the gaps, where is the chaos, where does someone need to steer toward coherence?
The product person becomes less like a ticket writer and more like a tastemaker/curator embedded in a fast-moving field of work.
That also changes hiring. The valuable person is not merely someone who can perform one function. It is someone with agency and taste who can take an idea from vague possibility to done, while knowing what quality means along the way.
AI product roadmaps have an unusual dependency: model capability.
Ambrosino says short-term plans need detail, but nine-month plans have to remain hazy because precision becomes fake. A feature can be the right shape but the wrong time. Codex itself might have failed if released months earlier with weaker models.
That suggests a different kind of roadmap:
This is a strong product pattern for AI-native teams: build things that are not ready yet, but be explicit that they are test artifacts, not launch candidates.
Ambrosino jokes that loops are "so last week," but the underlying point is serious. The question is no longer "what percentage of code is AI-written?" The more useful question is whether work is supervised or unsupervised.
Teams are exploring autonomous development loops: agents that clean code, triage feedback, read Slack, group feature requests, and improve systems. The current limitation is that models often increase complexity and are still weak at deletion, reframing, and choosing what not to do.
That maps cleanly to the larger theme: autonomy without taste creates slop at scale.
The frontier is not just more code generation. It is teaching the system which work matters, what good abstractions look like, what to ignore, and when to stop.
The long-term product vision in the conversation is bigger than an IDE.
Codex started as a CLI and then became a desktop app. The surprising internal signal was that people outside engineering kept using the Codex app even though the interface was often hostile to them: it showed code, asked to run developer tools, and behaved like a builder environment.
The lesson seems to be that people were not only looking for a coding tool. They were looking for a place where work could be delegated, tracked, resumed, and coordinated.
Ambrosino resists the phrase "super app," but the shape is close to a home base:
The best example is the videographer who used Codex to edit videos in Premiere Pro. Codex was not a video editor, so it figured out Premiere's files and then built itself a Premiere extension to control what it needed.
That is a very different product category from "chatbot."
For product teams:
For individuals:
For AI product builders:
The strongest lesson from the episode is this:
> When implementation becomes abundant, product work does not disappear. It moves up a level: deciding what matters, choosing the right artifact, preserving coherence, and building feedback loops that can tell signal from slop.
Codex is interesting not because it writes code. Lots of tools write code now. Codex is interesting because it shows what happens when software creation becomes a medium that many roles can use directly. The organization then needs less permission to build, but much more judgment about what built things mean.