OpenAI Codex Product Lead Reveals: Without standards and a roadmap, how do we develop products?

“Interest and autonomy are the most core and most important qualities for humans in the AGI era.”

Compiled & edited by: DeepWave TechFlow

Guests: Alex, Product Lead at Codex; Romain, Developer Experience at Codex

Host: Peter Yang

Podcast source: Peter Yang

Original title: How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain

Air date: April 5, 2026

Key takeaways

Alex is the product lead for Codex, and Romain is responsible for developer experience. They gave me a rare, deep look into how the Codex team operates—including how they use Codex to build products, and how they release products without traditional product specs and roadmaps. Alex also shared some unique perspectives on the future of product managers (PMs), as well as what truly matters in hiring.

Highlights summary

Real-time building and Codex Spark’s “thinking speed”

• “When you want to build something… you can switch into fast mode, even Codex Spark, and then you get that crazy thinking speed to build anything. On the left is GPT-5.4, on the right is Codex Spark—on average, you can have about 1,200 data points (tokens) per second. That speed is absolutely insane.” ——Romain

On specs docs and decision-making processes

• “I think we write very, very few spec documents on the Codex team. Honestly, I think a lot of the work is about getting the people closest to reality to make as many decisions as possible. So we only write specs when the problem ultimately becomes something that’s too hard to fit into one person’s head.” ——Alex

Blurred career boundaries and the evolution of designers

• “Our designers now write more code than the engineers did six months ago. And our focus is no longer about ‘can we generate code.’ What’s truly important is: what we decide to build and how we ensure the product’s high quality. That’s also why, for very complex features, I’m more inclined to find a strong, steady lead to manage them rather than having the product manager (PM) own the delivery and maintenance of these systems.” ——Alex

Product design philosophy: Make the model “invisible”

• “We’re very careful in how we design core functionality, making sure it doesn’t become a barrier between the user and the model—so the model becomes smarter and can automatically complete more tasks.” ——Alex
• “Then on top of that, we think about how to package the product for power users in a way that’s as configurable as possible, so they can explore and use it themselves. For example, there are already users who have implemented sub-agents.”——Romain

Planning philosophy: Rejecting the “awkward middle”

• “At OpenAI, we either plan for short-term goals or long-term goals, but we never do mid-term planning, because mid-term planning is too complex. Short-term planning usually means goals for up to eight weeks from now. Eight weeks is the longest time range we can set; we’ll also define a long-term vision. For example, we might look forward to the future a year from now and imagine that the models will become more intelligent by then. But mid-term planning ends up feeling a bit awkward—it typically shows up as a detailed product roadmap, but we basically don’t do that. We focus more on concrete tasks that will help us achieve our goals, combined with the long-term vision.” ——Alex

Interface changes brought by “agentic delegation”

• “Coding will happen in a way of ‘agentic delegation.’ It feels really strange—like opening multiple tabs in the terminal and letting them run for a few hours. We need a whole new interface, and the timing is actually perfect.” ——Romain

The disappearance of career ladders and “talent stack collapse”

• “It almost makes every traditional career promotion ladder start to become blurry. Each of us is basically a ‘builder,’ and everyone collaborates to get the building done. If a startup has a PM but fewer than about 20 engineers, that might be a dangerous signal. Interest and autonomy are the most core and most important qualities for humans in the AGI era.” ——Romain / Alex

Hiring standards: Work beats a resume

• “When someone messages me privately to say they’re interested in joining our team, my first reaction is to check whether there are links to their work. If there are links, I always click and see whether they’re truly building something. I’d rather look at their thinking and what they’ve actually built. I have no idea what universities these people went to.” ——Alex

On-site demo: Build a game in seconds using Codex Spark

Host Peter: I’m really excited to host Alex and Romain today—they’re from OpenAI’s Codex team. They’re going to demo how to build Codex’s new capabilities, what Codex can do, and how the Codex team keeps shipping products nonstop. Do you want to quickly show what you can actually build with a one-shot prompt?

Romain：

Sure—let me share my screen. There’s actually a lot I can show, but maybe a quick look—like, here’s an iOS app I’ve been building for a while. If I want to add a new feature to this app, I can simply say out loud: “Hey, can you add a new screen to NASA’s moon return mission?” Then I send that prompt with GPT-5.4, and the model creates a new screen for that specific APP.

But we also have a Codex Spark model, which can help you come up with and iterate on basically anything in just a few seconds. Let me show you the difference in how quickly the Spark model responds. On the left is GPT-5.4, on the right is Codex Spark. Then on average you can have about 1,200 tokens per second—that speed is absolutely crazy. So when you want to build something—for example, a game—right before we started this conversation, I actually went to the Codex app and created this little 2D game that’s kind of like Animal Crossing using a quick prompt.

When my thoughts are clear, I really like another feature I use in Codex: I open Codex and keep the conversation floating at the top of the screen. That way, if I’m really working on this game, I can keep iterating and generating more ideas. What do you think, Peter—what would you change about this game you want to build?

Peter：Maybe add some more decorations, houses, trees, that kind of thing, to make it more lively?

Romain：

So I’ll send this task, and basically in a few seconds Codex Spark can do the editing. We’ll see the changes in real time—and that’s it. We’ve already seen new trees appear.

That’s why I’m so excited about Codex. You can genuinely have access to cutting-edge models like GPT-5.4 that can handle very complex tasks—like analysis or migrating millions of lines of code. But when inspiration hits and your thoughts are clear, you can switch into fast mode—even Codex Spark—and then you get that crazy thinking speed to build anything.

For product specs, we only write about 10 bullet points, that’s it

Host Peter：I’m really curious—how do you actually use Codex to build products inside your team? Alex, do you still write specs? Or do you have GPT write a spec? What model do you use to make these things work?

Alex：

I think we write very, very few spec documents in the Codex team. Actually, I think a lot of the work is getting the people closest to reality to make as many decisions as possible, so we only write specs when the problem ultimately becomes something that’s too hard to fit into one person’s brain. By the way, now one person can fit a lot into their brain, because they can delegate a lot of work—they delegate most of the coding work, so one person can do a lot. But if it ends up being something that requires coordinating across multiple people, or maybe a really tricky decision we have to make, then we might write a spec. In those cases, though, the documents we write are often very, very short. We’re talking like 10 bullet points, and then it’s done.

Host Peter：Okay. Can you show me how it works? Like, you give Codex a few bullet points, and maybe it first writes out the actual requirements?

Romain：

Of course! But I want to start by showing you a simpler example. Suppose we’re developing an iOS app, and it’s already completed some tasks. Now you have some ideas for new features for this project, but you’re not sure exactly what direction to take. This is where Codex’s strength really shows—it can help us plan the next steps. For example, I just press Shift+Tab to enter “Plan Mode,” and then I type “what we’re going to build.” Codex will automatically generate an initial plan for me. It analyzes the existing codebase, understands the current state of the project, and proposes some potential ideas. Meanwhile, I can also add my own thoughts to steer the model toward a more complete plan.

In this process, you’ll see Codex provides suggestions based on the current code and files. For example, it might ask: “Should we keep improving the feature we mentioned before? Or should we optimize the reliability dashboard?” If we decide to optimize the reliability dashboard, it will further guide us to think: who are the target users for the optimization? The whole process is like collaborating with a brainstorming partner.

I often use this to drive idea generation. For some simple changes, I just type a prompt and let Codex generate code.

Alex：

And for changes of medium complexity, I might ask it to generate a specific plan or help me reason through the implementation. When I have a vague idea, I usually just open Codex and ask it to help me think through how to solve the problem. Even if I don’t have a clear set of feature requirements in my head, Codex can help me clarify my thinking through questions and exploration.

But to be honest, sometimes I don’t directly use the solutions Codex generates—especially when the change is fairly complex. I’ll explore with Codex’s “Plan Mode” to form a clear line of thinking, and then I share those ideas with the engineering team. Ultimately, that thinking process is more important than the plan it generates.

By the way, our designers now write more code than the engineers did six months ago, which used to be unthinkable. That’s largely due to tool improvements that allow designers to participate more deeply in development. But I also get teased by the team because I submitted too few PRs last year. Even though many changes were just small tweaks, I do think I should do more.

Now, our main focus is no longer on “can we generate code,” because agents (agents) can already complete most coding tasks. What’s truly important is: what we decide to build, and how we ensure the product’s high quality. That’s also why for very complex features, I’m more inclined to find a dependable lead to manage them rather than have the product manager (PM) own delivery and maintenance of these systems.

Designers write more code than engineers did 6 months ago

**Host Peter：**Codex’s applications are very intuitive and easy to use. Compared to some other professional products out there, I think Codex has a much lower learning curve. Other professional products may be powerful, but they take a lot of time to learn. I even feel like if I weren’t following the relevant information on Twitter, I might not even know how to use them.

But one thing that impressed me about Codex is that it’s not only simple and easy to use—it also provides a lot of advanced features, like skills and automations. Do you use these features frequently within your team?

Romain：

Yes, we use them a lot. In fact, I think skills is one of the most interesting features in the Codex app. For example, if you’re using Figma together with a designer, you just open the Figma skill, and it can extract all the details like React components and variables from the Figma file—then Codex automatically generates the corresponding code. Or, say you’re developing an application and want to share or deploy it to Vercel, Cloudflare, or Render. With skills, you can give simple instructions, and Codex automatically handles those tasks.

I recently chatted with a friend. He told me he had a lot of ideas for improving products, so he told Codex, “Write all these tasks into Linear so I can track them.” He used Linear’s skill. Then he told Codex, “I’m going to sleep—you continue and complete all the tasks we just discussed, and mark them as done.” The next day, when he woke up, he found that all the tasks really were completed.

Alex：

On the simplicity of the application you just mentioned, I think we can share how we think about its design. In this space, developers are typically enthusiastic about building automation tools for themselves to simplify daily work. We believe a key feature of the product must be highly configurable. For Codex, it’s like an open-source toolbox—users can dive into it and tailor it to their needs.

Whenever we ship a new feature, there are always users on Twitter complaining that the feature has problems—even before it’s officially launched. The reason is usually that they edited the code themselves or forked it. But to me, that actually proves our product’s success, because these advanced users are exploring the future together with us and pushing the product forward.

However, we also realized that it’s not enough to build a product only for these advanced users, otherwise the product will eventually become complex and hard to understand. We have to find a balance—both satisfy power users and make the product simple and intuitive for regular users. That’s why we’re very cautious in designing the core functionality, making sure it doesn’t become a barrier between users and the model, but instead makes the model smarter and automatically completes more tasks.

Romain：

On top of that, we think about how to package the product for power users in the most configurable way possible, so they can explore and use it themselves. For example, there are already users who have implemented sub-agents. These capabilities weren’t something we designed proactively—they were discovered and experimented with by users themselves. By observing how users use these features, we learn a lot.

Then we ask: How do we make these features super simple for other users too? The Codex app is a great example. Around the time GPT-5.2 Codex was released last December, the model’s capabilities started to steadily stabilize, but it also crossed a threshold. Users could start delegating longer-duration and more complex tasks to the model, and the model could complete them all at once.

We started noticing that some users were already using tmuxing—splitting windows in the terminal to run multiple parallel tasks. We saw some really interesting examples on social media. For example, there’s a photo of Peter Steinberger—his screen has 18 terminal windows across three monitors, and it looks like a sort of “creative open claw.” We got really excited seeing users use Codex in such advanced ways.

At the same time, we continued optimizing task delegation in the core product, like the CLI, to ensure it works well. But we also realized that maybe only the top 1% of engineers would work this way. So we asked: how do we make these capabilities feel more intuitive? That’s why we built the Codex app.

When you open the Codex app for the first time, it looks like a simple chat window. You can start using it right away, and it works normally. But as time goes on, you gradually notice more features—like a sidebar, the ability to run multiple tasks, and easy switching between tasks. You start to feel extremely productive. Then you might notice the “skills” tab and click into explore more. We want users to have an experience that feels almost like playing a game while using the Codex app—constantly discovering new possibilities.

Romain：

Totally agree. And that’s also the vision we’ve had from the very beginning: coding will happen through “agentic delegation.” Even when we started building Codex almost a year ago, we kept thinking about this future. We believe engineers will be able to handle multiple tasks at the same time, while the model takes care of the complex details.

But honestly, at that time, the model’s capabilities weren’t at that level yet. We had to wait for the GPT-5.2 Codex release and then that threshold afterward, when we saw the model reliably work for hours, even days, in a very thorough way. At that point, we suddenly realized that the traditional terminal interface was no longer suitable for this way of working. It feels really weird to open multiple tabs in the terminal and let them run for a few hours. So we need a completely new interface, and the timing was just perfect.

Alex：

Looking back at Codex’s evolution, we went through two important “vibe shifts” (trend inflection points). The first was last August. We launched the Codex Cloud product. It was a fantastic idea—users were really excited—but maybe it was a little early. So in August, we shipped GPT-5, an excellent interactive coding model, and decided to focus on solving the problems the model could handle at the time. That’s when we launched Codex CLI and IDE plugins. In just a few months, the user base grew by 20 to 30 times—that was amazing.

The second inflection point was between last December and this January. That’s when we finally achieved the original vision—delegating tasks to the model. The model’s capabilities reached a new height, allowing it to complete more complex tasks on its own. That marked a whole new phase for us.

Our planning is split into short-term and long-term—we never do mid-term planning

Host Peter：I’m curious how the Codex app was developed. Did you set some kind of annual roadmap a year ago, like “we plan to ship the Codex app at some point”? Or did you mainly observe market demand and rapidly prototype some ideas?

Alex：

Actually, neither. I heard a great suggestion from our researcher Andre: At OpenAI, we either plan for short-term goals or long-term goals, but we don’t do mid-term planning, because mid-term planning is too complex.

Short-term planning usually means goals for up to eight weeks from now, and eight weeks is the longest time range we can set. Within that time frame, we set a specific goal and mobilize the team to go all in and achieve it. That’s a strength of OpenAI—we’re very good at organizing the team around a clearly defined goal.

On the other hand, we also set a long-term vision. For example, we might imagine the future a year from now—thinking that by then, the models will become more intelligent. We might envision that future models can work independently without needing to borrow our computer resources, and no longer be limited to completing one task at a time. We want to have infinite numbers of models that can work independently, complete tasks, self-validate code, and even self-deploy and monitor, without us needing to manually prompt them.

However, mid-term planning feels awkward. It usually looks like a detailed product roadmap, but we basically don’t do that. We focus more on concrete tasks that can help us achieve our goals, combined with the long-term vision.

Taking the Codex app as an example: at the time, one of our strategic goals was to free users from a specific workspace. Traditional development tools (like VS Code) are usually tied to a particular workspace—like a particular checkout point in a code repository or a folder. Even with git worktree, you can only open one working directory at a time, and the CLI has similar limitations.

But our vision was: users can collaborate with intelligent agents in the cloud, and these agents can work independently. We wanted users to be able to interact with multiple agents at the same time, and even have one agent coordinate multiple agents on the user’s behalf—this experience should feel natural and intuitive.

We also realized that if we relied fully on the cloud from the beginning, developers might find it less convenient, because they would need to configure environments. And when the model is executing tasks, if manual intervention or adjustments are needed, it would become more complicated. So we decided to build a localized experience that can collaborate seamlessly with local folders while staying connected to cloud intelligent agents.

When we started developing the application, we had a bunch of “vision thoughts” like this—more abstract ideas. Meanwhile, our engineers also did various prototypes. They would say, “I hope we can have an application.” And that’s how we started trying to build different versions. In fact, we even held a “hack week,” where multiple engineers independently built different versions of the application. You might have been involved—I can’t remember.

When the project truly got going, the only thing we needed to make explicit was why we thought developing an application was a good idea. We didn’t have specific product specs for it. We gradually figured out the product direction through the actual development work.

However, at the time, the project was still somewhat controversial—do we really need to build an application? Our IDE plugin was already very popular—should we focus on improving the plugin’s quality instead? The CLI also had a lot of potential. So if we were going to build an application, what would its purpose be? Which direction should we put our efforts into? Those were some of the questions we faced when the project began.

Romain：

Yes, and luckily, at the time we already had a very mature IDE plugin solution, and we optimized it deeply. Users could use these plugins in VS Code, Cursor, Windsurf, and other IDEs. We accumulated lots of experience from the IDE plugin codebase, which gave us a very solid starting point for developing the Codex app.

Alex：

That’s right. In fact, the Codex app and the IDE plugin share a lot of code at the underlying level. They both connect to the same core Codex harness—a Rust-written open-source framework that the CLI also uses. We intentionally adopted a layered design, so we could share code and extend functionality across different tools.

Host Peter：As for the process of deciding to develop the Codex app… looking back now, it seems like an obvious decision, because using the Codex app is much more intuitive than opening a bunch of terminal windows. But the main reason at the time was that the Codex app is more beginner-friendly, and it’s also the best interface for managing collaboration among multiple intelligent agents.

Alex：

I think our team’s way of thinking is influenced a lot by the AGI vision. We’ve always been thinking: what will the future way of working look like?

In practice, we know we need an interface—so users can naturally delegate tasks to multiple intelligent agents. We know future models will have this capability—in fact, we’ve already seen users trying to delegate tasks across intelligent agents. We need an interface that makes this kind of collaboration feel natural, while seamlessly scaling to the cloud.

We wanted this interface to fit ergonomic design so users feel that collaborating with multiple intelligent agents is an intuitive, natural experience—not something that requires complex operations or tricks.

Romain：

Yes—and the audience for this application isn’t just beginners. In fact, even the most senior and experienced engineers—including top engineers inside OpenAI, like Peter, OpenClaw, and Greg Brockman—are now starting to use the Codex app as their primary development tool. This shows that our vision for agentic delegation is gradually becoming real.

Alex：

Yes. We mentioned Peter because he just joined OpenAI, and we were really excited about it. Last October, while walking with him around Fort Mason in San Francisco, I mentioned the idea of developing a new interface. I told him we wanted an interface that made delegation feel more natural, and he told me he would never use something like that.

But last weekend, he posted a tweet saying, “Turns out the app is pretty useful—I actually like it now.”

What Alex’s day-to-day work as a Codex PM looks like

Host Peter：Alex, you were the only product manager (PM) on the Codex team for a while, right? How many people are on the Codex team now—are you around 50 to 100?

Alex：

Roughly, yes—in that range. Back in May, we were around just 8 people, and I don’t remember the exact number. But since then, our team has grown very fast. Now it’s probably in the range of 50 to 100.

Host Peter：So how do you split your time day to day? What does your daily work look like? Or do you not really have a typical workday?

Alex：

I’ve been thinking about this recently because I find it hard to answer. I realized that my working style is phased, and that’s just my personal way—it might not fit everyone.

For example, when we shipped the Codex app, I was completely in an execution mode. At that time, all my effort went into product quality—making sure we didn’t miss any details, and getting every small thing right. In that mode, I spent a lot of time using Codex tools.

We use Codex to get feedback—like understanding discussions on Slack and user feedback. I have Codex summarize that information, then record it in Linear. On top of that, I use Codex to analyze code quality and make small code changes directly with it. Because sometimes handling small issues directly with Codex is faster than coordinating with other people and getting them to prioritize tasks—especially when our goal is to ship the app within two weeks.

Of course, in that process, there’s also a lot of human stuff—like cheering the team on, motivating people, and also staying critical about the product we’re building. I’ve found that whether I’m in execution mode can be inferred from how often I use Twitter. I don’t know why, but whenever I need to talk to people, I tend to use Twitter more.

Then there’s another mode. For instance, now my mind is very clear: we’ve reached a new phase. We have very strong models now—for example GPT-5.4 is performing extremely well. Our application experience is also beyond expectations and already covers all platforms, including Windows. So now I feel it’s time to truly go back to the cloud and put more effort into that.

When we enter this kind of phase, I spend more time thinking about what to do next and understanding the current state—that’s more of a coordination mode. In this mode, I spend less time on Codex. I use Codex more for communication rather than writing code. So I at least have these two working modes—of course, there might be more.

Host Peter：How much cross-functional alignment do you need to do?

Alex：

We don’t really need to do a lot of cross-functional alignment within the team. We intentionally treat ourselves like a “pirate ship” kind of team. Even within the Codex team right now, it’s only me and the two new product managers who just joined recently. We have some leads, and although until recently everyone basically reported directly to me, we still move the project forward together in a loosely coordinated way—so there isn’t much alignment work inside the team.

But now it’s increasingly clear that a big part of building Codex is developing this coding agent. And people are also getting clearer that coding agents aren’t just useful for writing code—they’re very useful for other tasks too.

For example, we’ve found that users don’t just use the Codex app to write code. They use it for many tasks across the entire software development lifecycle. And now most of OpenAI’s employees use the Codex app—even non-technical people; I often see them using the application.

That realization makes us think we need to ensure Codex isn’t only useful for developers. That requires more cross-functional alignment, because as OpenAI we also have ChatGPT, and a lot of users use it—so we need to be very careful about how we combine these products better.

Romain：

From my perspective, our developer experience team is a bit like an extension of the Codex team. Most of our focus goes into Codex, mainly for a few reasons.

First, it’s a very exciting product, and developers love using Codex—we want to make it even better. As Alex said, our working style is also phased. We’ll work with the Codex team to prepare for product launches—for example, preparing the materials needed for the release and teaching developers how to get the most out of Codex. After the release, we also guide developers to explore how Codex applies in different scenarios.

Another thing that’s really interesting to us is that if you look at the OpenAI platform as a whole, today there are millions of developers using our API to build modal applications ranging from images to speech.

Now the best way to develop has become making Codex the entry point. If you go back a year, or even to when we just launched GPT-5 last summer, we still needed to write a lot of guides teaching people how to write prompts for GPT-5. GPT-5 is a model with very strong reasoning capabilities, and it’s quite different from GPT-4. And now we’re trying to help developers complete tasks in these use cases using Codex and skills.

For example, if you need to update an integration system, we would suggest using Codex and its skills. As a result, Codex can almost completely help you get the job done. So our team also puts a strong emphasis on cross-functional collaboration, and we treat Codex as the foundation of OpenAI’s developer platform.

Alex：

I think there’s something really interesting about how our Codex team works—at least for me, the best part is our engagement with the community. Whether online or at in-person events, we really care about staying connected to the community.

During product launches, our work is very launch-oriented—clearly knowing when to ship what content. At the same time, it’s also very feedback-oriented—whenever the community provides feedback, we act quickly, fix issues, and communicate with them. That’s why our team stays very online, and I think that’s extremely important.

For example, when we launched the Codex app, we worked very closely with Dom and his team. They helped us organize a large-scale alpha testing program, inviting a lot of users to participate and jointly develop the product. Through their feedback, we didn’t just improve the application—we also refined related resources like skills and documentation.

I think that’s the unique advantage of our Codex team: because we’re open source, we keep everything highly transparent about what we do, and the community also supports and gives huge feedback and returns.

Host Peter：Let’s talk about Peter (the founder of OpenClaw). I’m an early user of OpenClaw. How did you integrate Peter into the team? Is his personal agent vision related to what he’s doing right now? How are you planning it?

Alex：

There are two angles. First, Peter is a very heavy user of Codex. In fact, OpenClaw is largely built using Codex. Through his usage experience, he’s provided tons of feedback to the team. Those feedbacks have helped us improve Codex a lot, and although it’s only his “side project,” he’s truly all-in, and we’re especially excited about that.

Second, I can’t disclose too many details right now, but he’s helping us build the next generation of personal agents and integrate them directly into ChatGPT.

Romain：

What fascinates me most about Peter’s work is this: when everyone is using OpenClaw, they might already vaguely see the possibility of the future—but what shocked me is that Peter saw this vision very early on.

If you look back at all of 2025, last year he developed more than 40 open-source projects, and all of them were built around a single core vision: to access his personal tools like his calendar, tweets, and Gmail via a command-line interface. Through these projects, he turned the skills and command-line tools vision into reality. And the coding agent we use today is built on that vision.

In the future, this agent won’t just be a programming tool—it will become any kind of personal agent. So Peter provides incredibly valuable feedback in this process, because he’s already developed many tools that have become core parts of the open-source ecosystem.

Host Peter：

People like Peter who can build such an excellent open-source community are truly admirable. His tools are so good that I don’t even want to open any other apps anymore. I just want to chat with my little robot.

Alex：

What system did you connect it to? Did you connect it to everything?

Host Peter：

Yes, I connected it to a lot of services. For example, it can access my banking information, my YouTube account, my voice assistant, my calendar, and Google services. When I’m lying in bed, my wife asks, “Who are you talking to?” and I say, “I’m chatting with my OpenClaw robot.”

But now there are a lot of “opportunists” charging up to $5,000 to help people set up OpenClaw. So if you can make it more mainstream and easier to get started with, that would be a huge breakthrough—you’re definitely moving in the right direction.

Traditional career promotion ladders are no longer applicable

Host Peter：I remember you guys said something like, “Most teams don’t need so many PMs anymore.” Right?

Romain：

I think the most astonishing part about these tools isn’t just the question of whether you need PMs, or whether the PM role is needed. It almost makes every traditional career promotion ladder start to become blurry. Previously we had clear division of labor: designers did design, engineers did development, PMs did management—maybe with a certain ratio, like some kind of “golden ratio.”

But now, if you’re an engineer, your productivity increases significantly. If you’re a designer, you can gain superpowers through these tools and become more technical. If you’re a PM, before you could only write strategy documents, but now you can prototype directly. This doesn’t mean you need to be responsible for a feature for billions of users, but you can use these tools to genuinely build things and show your vision to the team.

So what fascinates me most is that the boundaries between all these career ladders are blurring. We’re all basically “builders,” and everyone collaborates to get the building done.

Alex：

I remember saying online somewhere that if a startup has a PM and fewer than about 20 engineers, that might be a dangerous signal—maybe I did say something like that.

I think, like you said, all these roles are gradually merging. Designers can do more engineering work, engineers can get into design, and PMs can also participate in building. But engineers usually need to focus on writing code, so previously they wouldn’t handle task triage or other PM-style project management parts.

But now, all of that becomes much easier. You can delegate things to an agent—for example, Codex—to analyze feedback and priorities—so engineers can free up more time to focus on their own work. I think everyone can do other people’s jobs now.

Scott Belsky proposed an idea, “collapse the talent stack.” I like this perspective, and I think it really is happening. The fewer people needed in a room, the smoother things progress, and every decision becomes clearer.

So the question becomes: what can PMs still do? I think many PMs should be considering a career transition. For example, if you’re a PM and you’ve always wanted to become an engineer, but you’re better at managing people and your engineering ability isn’t that strong, then maybe now you could become an engineering manager. With intelligent agents, that might be a clearer role for you. Similarly, some PMs might be more inclined to become designers and be closer to hands-on building work.

In the end, it comes down to individual interests. For me, interest and autonomy are the most core and most important qualities for humans in the AGI era. So if you’re more interested in writing code—and you were in this role before simply because you needed someone to do the PM work—then you can totally pivot to become an engineer and keep doing the same kind of things from an engineering perspective. It’s the same in design too.

But if you’re truly interested in interacting with users, even if that moves you away from hands-on building—for example, trying to understand user needs and identify market trends—then in a team that’s large enough, PM still has room to contribute.

Romain：

Let me add one more thing: I still believe every problem needs a human owner responsible for that problem domain, but I don’t think that person necessarily has to be a PM. It largely depends on the nature of the product.

We’re lucky here because we work on Codex, a tool built for developers. We are the best users ourselves. And because it’s open source, we can directly interact with the community and do co-development.

But if you go back ten years—for example, when I worked at Stripe—at the time the company had 250 people but no PM, and even no AI tools. Why? Because Stripe was an API product, and everyone on the team was an engineer who had a very intuitive understanding of what a great API should be. What we were building was exactly the API we dreamed of: an elegant solution that could be achieved with just a few lines of code.

But if you’re in a different domain—for example, where engineers don’t have that much intuition about user needs—then you might need more PMs to communicate with customers and understand what they need. Especially when the industry or domain you serve doesn’t align well with engineers’ intuition, the PM role becomes more important. But we’re very lucky on the Codex team, because the tool we’re building is exactly the tool we ourselves want to use.

Alex：

In that kind of environment, the PM role might just be a label—it refers to the person who’s most interested in users and cares most about user needs. That person could very well be an engineer who’s extremely close to users. So I think these career labels are gradually losing their traditional meaning. It might be a bit chaotic, but it’s not a bad thing.

Host Peter：

I found something similar in my own team. I think the best engineers don’t ask me “what should we build next.” They go talk to users themselves, figure out what needs building, and then discuss it with me—so everyone’s goals stay aligned.

Romain：

That’s essentially how our Codex team works. Many of the features you use today in the Codex app are actually brilliant ideas proposed by engineers from the bottom up, because they themselves need those features.

Alex：

But I want to say: there’s a type of engineer I really enjoy working with. They like talking to users and thinking about what features should be built. These people are usually also very strong at building systems—fast, capable, with clear thinking. But there are also engineers who have no interest in interacting with users at all; they just want to focus on building systems. I think those people also have a lot of room to grow.

This is my view of the AI era again—we can all “be ourselves” more. AI and the team will help you handle the things you don’t want to do, so you can focus on your own interests and strengths.

Host Peter：

I really do think the “builder” label is very important. I know a lot of PMs want to become leaders, but in the traditional career promotion ladder, once you become VP or something like that, you don’t have time to build things anymore. Every day you’re in product reviews, just giving feedback, but not actually developing. I think many PMs don’t want that. I want to stay close to users and truly ship products.

Alex：

I completely agree. I actually don’t think PM is a leadership role. I’d rather see it as a “gap-filling role.” Sometimes that role might need to take on some leadership responsibilities—but even then, leadership is more about helping the team reach alignment, rather than relying on one person to come up with a genius solution.

One thing I’m confident about: at OpenAI, the best PMs go deep into the details. And I think joining OpenAI in a senior leadership position is very challenging, because the culture here still emphasizes attention to details. So the best way is to go deep into details from the start.

What does the Codex team value in hiring? (And the answer is not your resume)

Host Peter：When you hire for the Codex team, besides requiring candidates to be heavy users of Codex, what qualities do you value even more?

Alex：

I mentioned earlier that I really value candidates’ “agency.” We’re looking for people who will take initiative and do things—that’s one of the most important qualities.

At OpenAI, especially on the Codex team, our culture isn’t the kind of place where, “When you join, we’ll give you 12 increasingly difficult tasks.” Our style is more like: “Welcome aboard! Now, start exploring.”

So we’re more likely to look for self-driven people—people with initiative, their own ideas, who know what they want to do, and who aren’t afraid to challenge existing ideas. Because, to be honest, some existing ideas might be wrong themselves—they might just have been a lucky accident decision we made back then.

The teammate I idealize is someone who’s willing to take on extra responsibilities—maybe even owning some unknown domains. Those are the qualities we care about a lot. As for specific skills, we usually prioritize candidates who are strong technically and related to engineering.

Romain：

I totally agree. In my developer experience (DevX) team, I’m usually looking for people with high agency. They need to be very strong technically, especially when using tools like Codex. But beyond that, I also especially value people who are passionate about working with developers and builders, and sharing knowledge.

For example, we just announced that Thomas will be joining my team this week. He’s the one who developed the open-source Codex monitor. He’s not only very creative—he’s also a heavy user of Codex, and he’s passionate about sharing his experience with how he uses Codex to build tools.

We need people like that because we’re working to lead millions of developers toward the bright future that Codex represents. I believe agentic coding is completely changing how we think about software development, applications, and product building. Our goal is to show the whole world what’s possible and help developers learn how to use these tools to realize their own creativity. That’s the quality I’m looking for.

Alex：

I’ll add that, in my view, the ideal candidate for the DevX team can be described simply as “an excellent engineer who’s also good at using social media and engaging with the community.”

Romain：

You’re right on part of it. But I want to add one more thing: we want candidates to have a strong sense of responsibility to the community, and we also need to consider how social media usage differs across regions worldwide. For example, in some places, developers may be more inclined to use LinkedIn or other platforms rather than Twitter. So we need to expand the definition: candidates need to perform well on social media globally. We especially value people who enjoy engaging with the community, and are passionate about teaching and sharing knowledge.

Host Peter：

Actually, someone’s agency can be seen even before the interview. For example, have they posted work online? Do they have their own side projects?

Alex：

When someone DMs me saying they’re interested in joining our team, my first reaction is: “Do they have links?” If there are links, I almost always click and take a look. I want to inspect their work and see whether they’re truly building something.

Of course, some people include a cover letter explaining why they’re interested in the role, and even attach their resume. But I’d rather see their way of thinking and what they’ve actually built. I also realized something interesting the other day—I have no idea what universities these people went to.

Host Peter：Who cares? Who would care? I’m genuinely glad we live in an era where those dumb degrees don’t matter as much anymore—as long as I can see what you actually built, that’s enough.