OpenAI Codex and the new shape of product work

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.

TL;DR

• Codex is not only an engineering tool inside OpenAI: Ambrosino says nearly all OpenAI employees use it weekly, including non-engineers.
• The product process is inverted: instead of spending most effort de-risking before implementation, teams can create many concrete prototypes quickly.
• Cheap implementation creates a new problem: too many production-looking artifacts with too little shared clarity about what they prove.
• "Taste" becomes more valuable because someone has to choose what to build, which artifact to trust, how to present an idea, and when something is ready.
• Roles are becoming more overlapping, but eliminating disciplines entirely is a mistake. Product, design, engineering, finance, and other functions still have real best practices.
• Product planning in AI products has to account for model capability timing. The same product shape can fail in November and work in February because the model changed.
• The long-term Codex vision sounds less like an IDE and more like a work home base: a place to start, track, automate, and coordinate work across other tools.

Implementation is no longer the expensive part

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?

Documents are not dead; prototypes are not always right

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 is not just aesthetics

"Taste" can sound vague, but this episode makes it more concrete.

Taste includes:

• knowing what is worth working on;
• choosing the right medium for an idea;
• understanding how a feature fits into the system;
• knowing when an artifact is signal versus noise;
• judging whether a design expresses the right meaning;
• preserving product coherence when everyone can build;
• deciding what should become a product primitive versus remain a personal workflow.

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.

Why AI is still awkward at design

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.

Role collapse is real, but role deletion is stupid

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.

Product work becomes zone defense

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.

Planning has false precision now

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:

• list the possible product shapes;
• prototype more of them than you would have before;
• keep artifacts around as capability tests;
• rerun them when models improve;
• do not confuse "we wrote the code" with "this should ship."

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.

Loops are the frontier, but not magic

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.

Codex as work home base

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:

• start work there;
• end work there;
• automate recurring work there;
• connect to tools like Slack, Excel, Chrome, or Premiere Pro;
• let the agent use other apps when the native surface is not enough.

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."

The practical takeaways

For product teams:

• Stop treating implementation as the main scarce resource.
• Start treating curation, taste, and verification as bottlenecks.
• Do not replace every document with a prototype; choose the medium that matches the uncertainty.
• Clearly label artifacts by stage: sketch, test, prototype, model-capability probe, or ship candidate.
• Keep roles porous, but do not erase disciplines.
• Plan around model capability changes, not only calendar quarters.

For individuals:

• Do not marry your current process. Marry the outcomes you are uniquely good at delivering.
• Learn enough of adjacent disciplines to cross boundaries without disrespecting them.
• Use AI to create artifacts earlier, but keep your judgment active.
• Build personal loops, then notice which ones deserve to become durable workflows.
• Get better at deciding what not to build.

For AI product builders:

• Assume users will use your product for jobs you did not design for.
• Watch dogfooding loops carefully; weird internal workflows may reveal the next primitive.
• Design for delegation across tools, not only activity inside your rectangle.
• Make setup conversational where possible, but do not pretend that chat alone solves product shape.

The dry residue

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.