OpenAI Codex lead on the new shape of product work | Andrew Ambrosino
In a Nutshell
The core shift in product work is that implementation has become cheap, so taste, curation, and steering now determine outcomes—teams generate dozens of uncoordinated builds, and the bottleneck is identifying which attempts are worth folding in. AI accelerates coding far more than design because design feedback loops require human taste and novelty that current models lack, leaving an abstraction layer between visual output and coherent system design out of reach. The highest-value people combine high agency with strong taste to shepherd ideas from concept to production, and the winning organizations design processes that support both bottom-up exploration and ongoing optimization rather than trying to do both at once.
These notes were generated by AI and may contain inaccuracies.
90% of people at OpenAI use Codex. Not 90% of engineers. That's 90% of the entire company. The goal for Codex is to create the best desktop app that has ever existed. The quality bar had to be so high that there was never hesitation opening the app to do the next thing, making it the natural choice, similar to how people open a browser tab.
Since January, Codex usage has grown 6x with over 5 million weekly active users. Internally at OpenAI, nearly 100% of employees use Codex weekly, and that includes non-engineers.
Design is harder to grade because the human aspect of taste is part of the feedback mechanism needed, which remains out of reach with current technology.
Everybody at OpenAI is very agentic, has great ideas, and everybody's building everything. The implementation is actually not the expensive part anymore. It's taste.
The product process has inverted. Previously, research, ideation, and prototyping came before implementation because implementation was expensive, so teams tried to derisk everything upfront through documents, research, and prototypes. Now that has changed completely.
There are 90 different uncoordinated teams implementing and trying different approaches to the same feature. The curation process has become critical: of those 90 attempts, what is good about them, what should be folded into other aspects, how should they be framed, should they be part of another feature, how many segments should be in the toggle.
Taste includes an aesthetic component but also systems thinking: how does this fit in the system, where are we going, what theme is this part of, how to present this. Taste also involves determining what should be built when anything can be built, what the goal is, and how to get there.
Many product leaders say PRDs are dead and prototypes are in, but this is not entirely true. Because implementation has gotten so cheap across every medium, it is tempting to jump straight to a prototype, especially for non-engineers. However, for engineers it is tempting to write many documents that are not worth reading.
The key is picking the right format for the point being made. If the point is product clarity around a vague area, it might be a document. If the goal is getting something in people's hands to try out and stress test an interaction pattern, it is a prototype.
The primal mark refers to the first mark a designer or artist makes on a painting or piece of art, which everything else responds to. Sometimes the prototype is the wrong first thing to do because then the team is just responding to that prototype versus a different idea or bigger idea.
Previously, the medium implied baked-in signal about where something was in the process. Seeing something that felt like the app in production meant it was late in the process, assumptions had been derisked, design had looked at it, and it aligned with business goals. Now those things are divorced because it is no longer hard to get resources to build until properly derisked.
The risk is over-anchoring on something meant as an exploration that now looks so production-ready that it appears visually ready for production, but it is not actually the right model of where the research is going or what users are asking for or what is right for the business.
The head of product at Linear tweeted that people overemphasize the aesthetic part of what taste means, using Paul Graham as an example of someone with great taste who wears cargo shorts. Taste includes aesthetic judgment but also systems thinking and wider context.
There are practical reasons why AI has lagged in design and harder problems to crack. Design is harder to grade than software because creating a loop to train models on what is good design versus bad design is more tedious and onerous than checking if code compiles or does what it is supposed to. The human aspect of taste is part of the feedback mechanism needed.
Labs historically invest in making models good at things that accelerate AI research. In the early era of coding models, a model writing correct code would accelerate research in a way that cannot be made for design, though this is not directly in the flywheel.
There is an aspect of culture to what is considered good design. Last year every new website was a copy of Linear's website. If a model outputs Linear's website every time, that is not the challenge. There is an amount of novelty that is more important in design than in software engineering. Software engineering almost wants to overindex on known patterns, whereas design has an element of randomness and novelty.
Even as models get good at design, there is an abstraction layer that is an interplay between software design and the code being written. Things in different parts of the codebase should share certain properties. This is different from the model being a better designer. It is not just visual design but significantly deeper, about abstractions in the codebase.
If a company does a rebrand, the shallow version is updating 263 components one by one. The deep version is the semantics between things that look different but are both in lists with the same style conveying the same interaction pattern to the user. This abstraction layer still feels out of reach with current technology.
The Codex app is not a terminal and not an IDE. It is a chat thing that codes and shows code. It would be hard for AI to create a whole new paradigm for how to code. Human brains continue to be valuable for creativity and coming up with something new versus patterns of things done before.
The previous design process involved user research, divergence, and convergence. It was predicated on the assumption that implementation is expensive and teams can only afford to build once, so they needed to exhaustively go through the problem space and solution space before implementing.
Tools like Figma and Origami allowed pulling interactive prototypes earlier into the process. Now all of the implementation can be pulled into that process. There is a mismatch because a fully polished prototype that looks ready to ship leads people to ask if it can be released now, but the team is actually in the early design process stage.
Many companies have a baby version of the product, like baby Cursor or baby Codex, a dramatically simplified codebase that approximates all interactions of the production app and is quicker to vibe code over. This is a huge tool that is part of the design process.
If tied to the exact day-to-day specifics of the old process, then the design process is dead. But the overlay of the process, knowing where the team is in the process, is still more important than ever.
There has been more role collapse in the Codex org than in other parts of the company and the economy. This is a technical product for engineers, so designers speak engineer, product managers speak technical language and write code. Alexander has a master's degree in computer science.
There is significantly more overlap in roles than there used to be. Roles are defined less by the boundaries of where design stops and engineering starts, and more by the average of where people are working. If the average of someone's work on the design team is code writing, they are doing engineering work on average.
The entirety of the Codex app has been informed by the dogfooding loop. There is a desire among the team to try to do as much as possible in the app even when it is not the best tool so that it can become the best tool. A lot of design work happens by using the app and identifying what is broken about it.
The team often does not improve their process so they can make the product better to do it, which is an uncomfortable place to be, but the process changes week to week.
A person's role is the average of what they spend their time on. If most work is PM work, they are a PM for now. If it is engineering, they are an engineer for now.
Andrew warns against extreme approaches to eliminating roles, noting some companies declare they are getting rid of the product role entirely, which he calls a terrible idea. The danger is that it can eliminate the idea that things are specialties with knowable best practices. When this happens, the whole discipline of product that has been built up with real best practices, real things that have been tried and failed, and real processes gets abandoned because people say "Oh, I wrote some code."
Andrew welcomes the boundary of "this isn't your lane" going away, but emphasizes there is a balance. Not everyone can work on everything both in terms of breadth and depth. This is why managers are not going to go away. Every discipline has a skill component to it. Andrew notes that engineers are often guilty of not recognizing that engineering is a skill involving writing code, while assuming other roles are just people vibing. He gives the example that you can use Excel but you cannot work on the finance team.
It is now easier to switch roles and easier to learn best practices. It is easier to not tie your effectiveness in a role with the ability to use the exact tool. The focus shifts to whether you can get yourself into the right mindset, learn which things work and which do not. Andrew shares his personal experience of feeling he should not be a software engineer because he did not care about assembly language or memorizing TypeScript syntax. He identifies this as gatekeeping that equates being good at a role with being good at a specific tool, and believes this is starting to erode.
When asked how many people are on the Codex team, Andrew gives the answer that it is somewhere between 10 and a few thousand. He explains this as a real answer because the team sees the product as the culmination of everything everybody works on at OpenAI, including model research, models being good at tool and browser use, model personality, front-end infrastructure, and all product work. However, they are not accepting PRs daily from thousands of people on whatever they want.
The actual Codex team has double digits of engineers, probably half that on the design side, and a few product people. Product work is more of Alexander's own defense play. A common trait among everybody on the Codex side or desktop side is agency and taste. There are a lot of former founders or people who were at larger companies doing founder-shaped things, and a lot of people with immense taste.
Andrew notes that at OpenAI they let teams get very large. There is management, but the teams are quite large and mostly composed of ICs, which he thinks is good.
Andrew explains the "zone defense" analogy he has discussed with Alexander. If two product people are working too closely, that is often not a good signal. As a product person, you want to do forced directed activity where you identify the gaps. In this new world, curation, steering, and alignment are a lot of what product work involves because there is a ton of chaos with people throwing ideas all over the place. The whole top-down year-long planning thing is not going to work.
Product people need to act as taste makers who guide things from inception to what the product should be. This means wanting company coverage, so product people spread out and create space between themselves so there is full coverage. Then they fill in the gaps. The goal is to hire engineers who are product-minded so that not every piece of code needs full team review for product coherence. Everyone should have these skills, but what people go deep on has to change.
The most valuable people are those who can take an idea from idea to done with the taste to know this is great, shepherding it throughout with an obsession with making it awesome. This is how Andrew thinks about hiring and who will do well in this new world.
Andrew sees IC versus management as not that management is going away or that everyone is an IC, but that everyone is kind of both now. If you are an IC, you are not typing code out character by character. You are managing something, managing agents, managing work that is happening that comes together to do a certain thing. If you are a manager of teams, you are doing the same thing just at a different granularity.
Andrew looks for command over the discipline but then the taste to say that with unlimited tokens you cannot just be doing slop. You need to be able to determine what is signal and what is noise in a world of infinite content.
People are very frustrated with Andrew because things are constantly shipping and changing, making planning roadmaps very hard. Andrew says they do not do anything revolutionary on planning. The basic gist is that the shorter term something is, the more detail it needs. They do plan for 9 months out, but that has to stay very hazy because any amount of precision added to a 9-month plan is false precision and wastes time.
On the applied side when doing product work, anything planned in November may have been true for December but is not what happened. Research is different, but on the product side planning is really hard. They need to know what they think models are able to do on what timeline.
At Andrew's last company, they saw a shift where they were starting to use models to drive features and the product process fell down. The approach became to list out all the things they were interested in doing for the next year or two, prototype all of them, decide which things are ready now, and let the others sit and bake. Then every time there is a new leap in models, they try that thing again with it swapped out. The premise of whether features were good or not was based on whether the models were smart enough, not the shape of the features.
Andrew is very confident that the Codex app released in February would have absolutely failed in the market if it had been ready in November. The only difference was the models between November and February. The product with the exact same shape had totally different outcomes depending on just a few months of timing.
The approach includes building a bunch of things that may not work yet, keeping them around, and waiting for a model to catch up. The challenge is being very clear about what stage of the design process something is in. People still have the muscle memory that if they wrote the code for a thing, they should put it out there. Andrew clarifies that having an artifact means you can test it against future models.
Andrew traces a thread through Operator in ChatGPT, agent working inside Atlas, and the in-app browser in the Codex app. These are fundamentally the same feature, but re-releasing it with different intelligence totally changes the outcome. He pushes people not to be stubborn and say this is not working so it is a bad feature. It might not be ready yet.
With the original Codex release, it said it was Codex web and was not good for interacting with. You would give the model a task and it would go off, do the task, and come back to you with it finished. The problem was that it did not do the task that well. That form factor was too early. Then cloud code came out totally local, not hooked up to the cloud, does not pretend to be as agentic, is going to ask you questions, is going to sit there, and you cannot just delegate your life to it. That worked way better because that was the point the models were at. They were too AGI-pilled for the moment.
The lesson is that you might need to release a thing six different times before it works, and the shape might not change at all.
Once a product or feature exists, it is really easy for people to find paper cuts and optimize, and they should. People on Twitter like to remind them of this. But this is why OpenAI also has a culture of bottoms-up exploration. Sometimes the same way the Codex app came and disrupted ChatGPT in some way, things will get disrupted by a future effort. You cannot always as one team be good at both the disruptive piece and the maintaining a product and its quality piece. You have to design a process that allows for both.
Andrew notes that loops are so last week. The question of how much of the product is AI-written is hard to answer because if you are using the goalposts from last year, 100% of their product right now is AI-written code. The question is more whether the code is written supervised versus unsupervised. He welcomes the moving of goalposts because that means they are making product progress.
There have been explorations around autonomously developed software, harness engineering stuff, and different explorations like what if you came in overnight and did garbage collection of the codebase to clean it up. All models suffer with increasing complexity right now. Andrew wishes research would make models better at deleting code.
When trying to put development completely on autopilot, problems arise on both the human side and the codebase side. Feature requests involve teaching a model which features to build, which ones to ignore, which ones to group together and reframe. It involves teaching a model how to build the right abstractions. All of this is getting better, but they are not at a place where they can just set up a loop that improves the app by listening to Twitter, Slack, and email.
Andrew has the best job in the world right now. When developing the original Codex app, the goal for him personally was to make it the thing that he wrote the code with. He needed to make it so good at development that he could build the Codex app with it. The Codex app at that time was a development tool. They did a super quick dogfooding loop because you cannot do a thing, you fix that so you can do the thing, now you can do the thing, now you can do more things.
After release, the next challenge was that people were starting to do different shaped things with it. Andrew needed to grow it and hire a few people and help. His role changed at the same time that the role of the app needed to change. He needed to do more product discovery, figure out the right loops for seeing what everybody was working on, and steer things that were off track. That is what he started using the Codex app for.
Andrew has tried to align his own usage of the Codex app with the problem they are trying to solve. Now he needs to build a spreadsheet that models things out and do internal deep research on all the efforts that have gone into areas of research for the next version. There was a release or series of releases in May that introduced the in-app browser, computer use, and artifact creation to the Codex app. That was Codex's for almost everyone release.
Andrew had a Notion doc with everything that needed to happen and was automating going out to gather updates from pull requests from Slack channels and updating the status tracker. This is now pretty commonplace, but at the time he felt like he was at the bleeding edge of how to manage a product release.
Andrew gets up in the morning and sees the daily brief from everything from the 3,000 Slack channels he is in, showing which things need his attention. He can message back and say give him five questions and he will answer them.
To set up an automation, Andrew creates a scheduled task that goes through his Slack channels and identifies the things he cares about and thinks are most important. He is still defining categories of things to watch out for and providing context. The first few times it runs, it might need some steering. With the app, he does not have to find out how to edit the instructions. He can just say next time this runs, can you please worry about this instead, or deemphasize this workstream, or this thing happened and it did not come up in a brief, can you make sure that stuff in the shape. He can coach it along the way and it will update the way that it notifies him.
Andrew notes that this has been a core problem with the chatbot shape. He knows how to set this up and has time to set it up because for him it is product discovery to set it up. But if you are not working at OpenAI and not developing this, you do not want to have to figure out all this stuff. They need to figure out that shape of things.
Andrew built a little app that filters spammy email for Box. Every email that comes in, it looks at it and decides if this is unsolicited cold email stuff that he does not want to look at, labels it, and puts it somewhere else. To set that up, one of the steps was going into the Google Cloud console and setting up all the Pub/Sub API things and triggers, which is an annoying and slow interface. He asked the app to do it for him.
The computer use feature allows the system to take over the computer and start clicking through interfaces. It figures out how to work without connectors by directly interacting with the screen. Designing the decision boundary between different connectors is interesting—deciding when to use the in-app browser versus the Chrome extension versus computer use is done through feeling it out. A Twitter thread described the three approaches and what each is best used for.
Personal workflows are interesting because some patterns really click for people. Everybody is making personal systems and everyone's approach is different, but certain themes arise. When a pattern works for many people, it should become a first-class experience in the app rather than requiring users to set it up themselves.
Memory is an example of this. Many people set up an Obsidian base or Notion area and configure how to build their mind palace. This is generic enough that it should be a built-in memory feature rather than something users have to configure themselves.
Other processes are job-specific. Some things should remain user-configured because they represent how someone does their job, while other patterns should become primitives in the product. This requires taste and judgment to determine what enters the product versus what stays as a personal workflow.
Dan Shipper predicted that people would start using Codex to run their SaaS apps from within the app. Instead of going into Chrome separately, the vision is working within the Codex app using Notion, Linear, and Salesforce with an agent helping along the way.
There have been multiple attempts at browser-shaped activity: Operator, tragic de agent mode, Atlas, and now the in-app browser inside the desktop app. There is also the ability to install a Chrome extension where the app connects to Chrome.
Originally the app was an Electron app and the in-app browser was for development and testing front ends. It was positioned as a developer tool, not for general use. The team switched to the OWL stack that powered the Atlas browser, which enabled multi-tab support and enterprise security for logging into websites.
The core challenge has been determining the shape of the browser. One option is that the browser is only for the agent—when the desktop app needs to control something, it opens a browser it can control quickly without the latency of Playwright. The alternative is positioning the app as everything, where users use it as their primary browser. These approaches have significant trade-offs.
The app creates tedious problems like keyboard shortcuts. The question is whether to do key mapping to VS Code, Chrome, Linear, or the app's own system. The goal is muscle memory that carries over, but different products have different shapes and sub-shapes.
The app must work for users who have never built anything, from basic users to power users like Peter trying to code with it. Peter is described as potentially the last terminal holdout.
Codex started as a CLI, then the team decided to build the app. There was uncertainty about the app but conviction that it could be a right-sized surface for developers—a chatbot-like experience where users could see code but not edit it directly.
In January and February before the Codex app release, the team was dogfooding it internally. They found clear internal product-market fit on engineering and research workflows. The team was convinced it would be successful but needed to raise the quality bar before releasing it.
At the company, other workflows were spun up. People from marketing, comms, finance, legal, and every discipline started using the Codex app even though it was actively hostile to non-developers—it showed them code and asked for approval to run commands. This revealed that the product surface was not right for these users.
The initial plan was to add Codex capabilities to other surfaces like the ChatGPT desktop app and the Atlas browser to create a more general knowledge work tool. However, nobody would leave the Codex app for the apps allegedly designed for their personas.
The lesson was that the distinction between developer tool and general knowledge work tool has nuance and is not a binary choice. People doing Excel work do not want to see git repository information. However, the system can infer a lot about what kind of work someone does from their actions and can start simple then grow complexity as needed.
Modes may be useful for organizing the experience and making entry points legible. The belief is that the shape built can take on deep vertically focused work. The team works with finance, science, and legal teams internally. If the right extensibility primitives and general model are built, anything can be done with it.
The direction is to combine Codex and ChatGPT rather than creating confusion between two apps. The goal is not to call it a super app, but the concept is one place people go to do their work.
The app is a home base for keeping track of all tasks across different surfaces. Some work happens entirely in the app. For other work, the app opens other applications. The app can connect to Excel so that when financial modeling requires the full desktop Excel experience, it talks directly to the add-in in Microsoft Excel. When done, the user can close Excel.
The philosophy is not about drawing a rectangle on the screen where everything must happen inside it. The app should be a home where users start work, end work, and automate work, using whatever tools are needed.
Videos were shot for the original Codex app launch. The in-house DX videographer Brent was tasked with editing them. He edited all the videos with Codex, which was an early example of unexpected usage.
Brent started using Codex because he was curious if it could edit videos. Codex is not a video editor and has no video editing UI, but it understood he used Premiere Pro. It could do some edits by modifying the backing files in Premiere Pro, but it could not do everything.
Codex then built itself an extension that could be installed into Premiere Pro so it could communicate with the app and change markers inside Premiere Pro. This demonstrated a model where Codex and ChatGPT can seamlessly interact with specialty tools users already have rather than needing to build replacements for those tools.
There are two models being pursued simultaneously. One is interacting with existing specialty tools through connectors, computer use, or extensions. The other is opening web apps inside Codex so the agent can do additional work with them.
Andrew described his career before OpenAI as feeling like constant failure. He was a startup founder for a long time and eventually sold the company for parts. It was years of work in heavily regulated spaces that felt like a slog.
He went to another startup trying to build AI tools in a locked-down regulated industry, and again experienced repeated attempts that did not work.
At OpenAI, there have been many micro failures on the product. The team would propose a shape, share it in Slack, and receive a 2,000-message thread explaining why it was wrong. The culture of direct feedback internally is why the external product has been strong.
Andrew stated he failed for somewhere between 10 and 15 years before reaching the current point and is still surprised every day that things are going well.
Books recommended:
- The Gruffalo (a children's book that became part of the bedtime routine with a chart: pajamas, brush teeth, books, Gruffalo, blankie)
- The Big Orange Splot (or similar title), a very old children's book about Mr. Plumbean who lives on a street where all houses are identical. A bird drops orange paint on his house. He decides to go all in, painting his house with hammocks and alligators. Neighbors initially object citing property values, but one by one they talk to him over lemonade and begin redoing their own houses, including one building a boat. The book is recommended especially for newbies and for people who dislike HOAs. The core message is about agency—you can just do things.
Favorite recent media:
The Magic School Bus is back on Netflix with a new animated version. Kate McKinnon plays the main Miss Frizzle (now Professor Frizzle is the original). Andrew watches hour-long Netflix episodes back to back rather than movies.
Favorite product:
Linear was mentioned as a favorite software product, though Andrew noted that in theory the team uses it for planning.
On roles and convergence:
Andrew has been a PM, designer, and engineer. He finds all three roles very different. The things that make a role tough for one person make it easy for others. There is convergence and fluidity being introduced that is refreshing, especially for people with agency who want to do what needs to get done. Some things should not go away, but people should find the work worth doing and figure out how to do it.
The Premiere Pro story illustrates being ambitious with AI. People should have curiosity about the project, an intentional outcome, and use Codex as the platform to see what happens. There is no risk beyond a few tokens.
When asked about skills, the advice given is not to get married to any exact process. Instead, get married to the outcomes you are uniquely able to deliver, then change your process to try things. AI will be better at many specific skills, so the focus should be on outcomes.
Success with AI requires a high level of self-awareness. Most of the population will not be early adopters. Relearning things constantly is difficult, and repetition is unpleasant. Being a founder requires repeating yourself, which is challenging for people who dislike repetition. The goal is to do the job in a different way every day.
Keep Lenny's Podcast in your library
Save the videos and channels worth coming back to, and find them again in one place.
