OpenAI Codex 负责人：我们所知的编码时代已经结束

Ready to go. Alex, I’m so excited for this, dude. I told you I’ve been at a PE conference, and all I could think was, “Thank God I’ve got Alex next, because this is going to be a great one.” So, thank you so much for joining me, man.

Alexander Embiricos

So excited to be here. Thank you.

Now, this is a weird first start, but roll with it. You’ll understand my British intricacies. I’m fascinated by people’s motivations. Are you motivated more by the fear of losing or the thrill and excitement of winning?

Alexander Embiricos

I’m a maximalist. I’m definitely much more motivated by the idea of winning than the fear of losing. But I’ll admit to you something: when I was running a startup before joining OpenAI, one of my darkest moments—and there were many dark moments while I was running the startup—was recognizing that I had spent the past few months trying to avoid losing.

All of a sudden, I was like, “Oh my God, that is why I’m so unhappy, and that’s probably why the startup isn’t going well.” And so, when we flipped, I basically every now and then have to re-teach myself and flip back into this idea of winning.

1. Will AI automate coding?

But really, what motivates me even more than that is I think I just love building things and building things for people. I am so excited for this year because many amazing things that don’t exist yet are going to be built and given to a lot of people.

I’m diving right in. Elon said that coding is one of the first professions to be largely automated. Do you agree, given your position and what you see day to day?

Alexander Embiricos

I think for sure I would agree that coding is one of the first domains where LLMs are really good. What does it mean for coding to be automated? It’s kind of a heavy statement, right?

For example, now that we no longer write assembly, when that change happened and we moved to higher-level languages, did we say coding is automated? Not really, right? We were just able to write much more code, and then, as a result, there was actually much more demand for code and many more software engineers were required.

But, yeah, part of what they used to do is automated, in the same way that—do you know the origin of the word “computer”?

No. I might pronounce the location wrong, but I think it was at Bletchley Park. There were all these machines for decoding German Enigma, and there were humans who would punch out punch cards and put them into the machine and do a bunch of tabulated math. I’m probably butchering this, but basically there was an intensely manual part of the work.

Even the first spreadsheet software was loosely based on this idea that you would have an office full of desks arranged in a grid, with people doing tabulations and then passing their sheets to the next person. All these specific tasks have become automated, but every time that’s happened, there’s been an explosion in demand for the output.

2. The "Compression of the Talent Stack": The future of engineers, designers & PMs

So, you need many more people actually to do that kind of work, even if the specific task has changed.

So you think we will have more engineers in 5 years, not fewer?

Alexander Embiricos

Yeah. Sometimes we change what terms mean, right? The term “computer” now refers to something else. We have the term “software engineer,” and so I definitely think we’ll have many more builders.

Something interesting that I’m observing now is this compression of the talent stack. You still need software engineers today. You still need designers. I’m a PM. Do you need PMs? You could have some fun jokes about that. I don’t think you need them.

But maybe when you say “engineer,” you might be thinking of someone who’s much more full-stack than has been true before. Even if you go back a few years, there were many more places where there was the back-end engineer and the front-end engineer, whereas now, at least if I think about the Codex team, there are very few cases where that’s true. Things are much more full-stack.

I think this talent stack will compress, but we’ll still have people building.

Why do you think we don’t need PMs in this world? You dangled the carrot.

Alexander Embiricos

Yeah, it’s my fun joke. First of all, I think it’s incredibly hard to define what a PM is, what a product manager is. I kind of think of the role as explicitly undefined, and your goal is just to adapt to whatever the team or business needs.

Often, if you have a bunch of people trying to build as quickly as possible, what a product manager can do is spend time taking a few steps back, trying to look around corners, and figuring out what to do. You collaborate with the folks in go-to-market and maybe be the team’s greatest cheerleader and quality raiser.

But all of those things I just described, which are maybe my current role, could be done by a really strong engineering lead or a designer who thinks a lot about product. So I think it’s often useful to have product managers, but you probably don’t want many of them until the team is really large.

3. The bottleneck of AGI

I was stalking the hell out of you for the last few days, which was a very fun expedition into your writing, your tweets, and your prior interviews. You said that human typing speed and validation work is the key bottleneck to AGI, not model compute or architecture, and it kind of left it there. I was like, “Help me understand why human typing speed and validation work is the key bottleneck, and what you really meant by that.”

Alexander Embiricos

For sure. Okay, that’s a fun one. I think there are multiple bottlenecks, but that’s maybe the most clickbaity one. If you don’t mind, we’ll do this slightly Socratically. How many times would you say you use AI today?

30-plus times a day.

Alexander Embiricos

Okay, cool. How many times do you think, assuming it was zero energy expenditure from you, AI could help you per day?

In everything, I think we’ll have inference running 24 hours a day across every single thing.

Alexander Embiricos

Exactly. I hear things now from engineers at OpenAI and also outside who tell me, “I constantly have Codex running. I never close my laptop, and if it’s not running while I’m in a meeting, I’m wasting my time. I need to make sure Codex always has work for me that it’s doing.”

That’s super cool and super exciting, but that’s a lot of work—to manage these agents and make sure they’re always working. Going back to the 30-times-per-day thing, when we look at how often Codex users are using Codex, it’s in this tens-of-times kind of range.

I think AI should be helping us tens of thousands of times per day. Compute budget permitting, we’ll get there over time. But the problem is, at least if I think of myself—I work on this stuff. I know I should be using AI for everything, but I’m too lazy to type out that many prompts, and I’m too uncreative to figure out all the ways that AI can help me.

So I end up at a similar number as you. I’m still at the point where, when I use AI to do something cool, like prepare for this conversation with you, I’m kind of proud of myself. I’m like, “Oh, cool. I managed to use AI in this new way.”

That’s fine for people like you and me who are really interested in this topic, but I don’t think most people should need to put so much effort into figuring out how to use this tool in order to benefit from AGI. It should just be effortless for them.

I think the world we want to get to is one where, to use AI, you don’t really need to figure out the right way to prompt. It’s just super easy for you, and you don’t even need to recognize that AI could help you. It just knows you, is connected to your context, and chimes in helpfully.

That’s where I think Claude has done well in terms of the packaging they’ve done—Claude for Legal, Claude for Excel, where you can implement it and have a DCF model. I’m not into models, but it’s better than one could do before.

Do you think it is your job, then, to productize the prompts and the human actions to remove that bottleneck?

Alexander Embiricos

Yeah, totally. I think it is our job to make sure that we have models with amazing capabilities and then eventually get to a world where this is highly productized.

You just have this magic text box, or audio input, or whatever. You can just add AI to your group chat, and it starts to help.

But I think there's quite an interesting in-between stage, and I think that is actually where the most value lies right now. So here's what I mean. You could try to productize a specific feature of AI for a specific market, and I know that many companies are doing this, but I think it's a little bit hard to know what exactly will work and what the right form factor is.

Someone was on your podcast earlier, and they said something that I thought was quite interesting about how you cannot adopt AI in an enterprise without FDEs.

Yeah. It was Matt Fitzpatrick from Invisible AI.

Alexander Embiricos

So, even though I am literally hiring FDEs—and if you're an FDE, please apply for a job with me—I actually disagree with that entirely. What I think we need to do is build tools for people. You can use FDEs, as Matt said on the podcast, to automate workflows, right? But then you're limited by what you, from your top-down perspective, can do and what you, from your FDE staffing, can staff to be built, right?

4. Building for individuals vs top-down enterprise automation

For me, the most exciting future with AI is one where everyone just feels like a superhuman, empowered by AI. For that, we need tools that are for people, for individual users, and that everyone feels fluent with. I think the phase that's most interesting—the phase we're at now—is building for the kind of people who are interested in figuring out how to use AI.

What we need to ship—and I think this was the genius of when Claude Code first shipped, what they really got right—was a tool that was super easy to use in whatever context you want, just in your terminal. People started experimenting with where to use it. As we think about AI being used outside of coding work, one of the most important things we can do is not overbuild it: not say, “Okay, this is AI capabilities, but only specifically for finance, only specifically for this workflow.” Instead, we should build a much more open-ended tool that someone can use for any given task creatively.

5. The three phases of agent development

Yeah. But does that not put the onus, or the effort, back on the user, back to the point of your bottleneck of human action and lack of activity on them? If you don't define the task, you put the responsibility on them for defining the task, which humans lack the ability or inclination to do.

Alexander Embiricos

Yeah, I think that's why I think it's the bottleneck. Basically, here are the 3 phases in my mind. First, let's have agents work really well for software engineering and coding, because LLMs happen to be good at that. Next, let's realize that, for an agent to be useful more generally, using a computer is super valuable. We'll also realize that all agents are actually coding agents, because coding is just the best way for an agent to use a computer.

So let's take that same super-flexible idea, but make it available to anyone who's excited to explore and tinker. We're already seeing people start to do this with the Codex app. The Codex app is built for software builders, but we're seeing builders use it for all sorts of non-coding tasks.

Then, finally, once we see what's working, let's build that productization that you were talking about, where you have highly specific features that just work immediately out of the box for people. I think we're going to speedrun this entire 1-2-3 journey in the next months.

My challenge with what you said about FDEs and implementation within enterprise is that data security, sensitivity, permissioning, and access provisions are really freaking hard, and people are much less intelligent and confident than we give them credit for. I think, especially in large enterprises, you actually need an FDE to go in and custom-fit a lot of the different horizontal solutions to make it work. Am I wrong?

Boris Power

I think you're right. If you're trying to go all the way from zero to one, and you have this—and I say I don't mean “grand” negatively here—but if you have a grand vision for some ultimate workflow-automation system, then yeah, you're going to have to clear through all of these security hurdles and all these compliance hurdles that are really real, right? Build connections to all these data systems and systems of record and action. So, yeah, you're going to need an FDE to do that.

What I've seen is that when we do these things top-down, we end up massively underleveraging the potential of AI in helping that company. You can maybe do that in parallel, right? But if you can just give AI to the people actually doing the work, they can start to get a mental model for how AI can help, and then they can start pulling AI into their workflows at the same time.

Here's an analogy. Imagine you work in a customer-support role, and AI is being brought into your role and starting to automate meaningful chunks of your work, but you've never heard of ChatGPT, nor are you allowed to use it. In that scenario, you have no intuition for what this thing is. Whereas, in a world where you've been using ChatGPT for work at the same time as parts of your work are getting automated by an LLM, you have much more intuition for how this works.

I would argue you feel much more empowered about the idea that your work is being accelerated. You have some degree of control to steer where these automations are built, as opposed to it being this complete deus ex machina kind of thing. That is quite disempowering.

Bringing this back, I think there is a way to do this, because the data-control issues you mentioned are real, right? But at the end of the day, every tool, every feature, and every workflow is for a human who is somewhere—an employee somewhere. That employee is accessing that tooling via their browser or via their file system. At the end of the day, everything comes to an interface that an agent running locally on your computer can work with.

I think it's quite unusual. In OpenAI, we're building a browser, Atlas, and you might wonder why. There are many reasons why, but I think one of the key reasons is that, by building a browser and controlling it tightly end to end, we can build safe agentic browsing for enterprise—a way to access things agentically that are otherwise not yet built out by FDEs.

6. The importance of inference speed & OpenAI’s partnership strategies

There are so many questions that I have to ask you. I want to go back before I lose the thread. You mentioned engineers not closing their laptops because they don't actually want to lose productivity and time while building with Codex. You partnered with Cerebras, and Cerebras is obviously the fastest provider of inference out there. Amazing win, I think, for both, bluntly. How important is speed for developers when using Codex and in the future of AI coding?

Alexander Embiricos

The simple answer is: it's super important.

And so, is it like an inference monopoly, where you have it now and competitors don't?

Alexander Embiricos

This is just my opinion, but I don't think we're going to end up in this kind of monopolistic world. I think there's so much competitive pressure that there'll be multiple answers to this. But I will say that we have news coming out about that partnership soon, and I'm very excited for these kinds of things to ship. It's going to be awesome.

Even so, with GPT-5.3-Codex, that model is significantly more efficient than prior models. The feedback we've heard is that people actually feel like this is now a very competitively fast model compared to before. There are a lot of things you can do just in terms of the model. There are also things you can do, like improving how you do inference.

We recently rolled out a change where, in the API, those models are served 40% faster, and in Codex they're served 25% faster. I think speed matters a lot, and we're approaching it from all angles: the hardware, how you do inference, and the model level.

You mentioned earlier about putting it in the hands of users, and we talked about inference there. One of my dear friends is Jason Lemkin from SaaStr, and he says that inference is actually the new sales and marketing. Instead of sales and marketing teams, you're paying for inference so users can onboard quickly and easily and see value, and you'll actually see the removal of sales and marketing teams. It's kind of the next generation of PLG.

I don't know. I struggle with that. Fundamentally, in this new world where anyone can build and it is increasingly easy to build things, what is hard, right? I think having a good relationship with a customer and knowing what they need is as hard as ever, maybe even harder, as there's just more stuff in the market to choose from. The other things that are hard are building the right thing and having a really high-quality thing.

7. The transition from "Pair Programming" to "Delegation" with GPT-5.2 Codex

But going back to the sales and marketing thing, I don't think that goes away. As I said, I think that's just gotten harder as any given market gets more competitive, with more software out there. Can I ask how much of your internal code today is produced by Codex? I remember Claude Code—Boris said it was like 100% or nearly 100%. How much is Codex used internally?

Alexander Embiricos

I'll speak for myself and then for the team. I would say most people that I know are basically not opening editors anymore. This was a step-function change. It's been happening gradually, but I'd say that the external market touchpoint for this was GPT-5.2-Codex, where all of a sudden the model was way better at running for longer, handling tasks end to end, managing its context, and following instructions. We saw this inflection point, and that's actually part of why we built the app.

Broadly, I think before GPT-5.2-Codex, the kinds of AI features we were using to write code were tab completion, or maybe you were pair-programming with the model. In my mind, you still needed to be at your laptop with your hands on the keyboard, and it might go off and do a little bit of work, but you still needed to be there and drive. It was just handling these small things for you.

Then, at the time of GPT-5.2-Codex in December, we switched to: “Actually, I’m just going to fully delegate this task. I’m going to have it do a plan, make sure we like the spec, and then I’m just going to let it cook.” This is quite a different way of working, so it’s changing literally as we speak.

Part of why we built the Codex app that we released last week is because we wanted to build a form factor or user experience where it felt very ergonomic to be delegating instead of pairing with an agent—delegating to multiple agents at once. Even at OpenAI, this is changing massively. I don’t have a percentage stat for you, but I would say the vast majority of code is written by AI.

I would say that now probably most people are not even opening IDEs. Maybe if they are opening IDEs, it’s because they want to own the interface, so they’ll help flesh out the interface between 2 modules and then AI fills it out, or maybe they want to collaborate on a plan but then have AI fill it out. The code itself is not being written by humans anymore.

8. Why the Codex app isn't a traditional IDE

Will we have IDEs as a part of the stack in 24 months’ time?

Alexander Embiricos

Okay, so the formal definition is “integrated development environment.” That phrase is so squishy that literally anything could be an IDE, right? I don’t think that’s very useful. If that’s the answer, then yes—you could even argue the Codex app is an IDE. I don’t think it is.

For me, I think of an IDE as a really powerful editor. We explicitly didn’t build editing into the Codex app because we wanted it to be really clear how you’re meant to use it. It has a lot of affordances for managing multiple agents, delegating, and reviewing changes.

It has really prominent skills, which are an open standard that are useful for doing non-coding work, stuff like triaging tasks or monitoring deploys, but it doesn’t have text editing.

9. The importance of plan reviews and automated code reviews

If we assume a large percentage of the code produced is done by Codex, how do you do code reviews, and is AI responsible for internal code reviews?

Alexander Embiricos

There are a few things here. First off, the spec for what you want to do, or the plan, becomes more important than ever. Think architecturally: How should this code work?

We recently shipped a very prominent plan mode that works a little differently than others. You have the agent go off and propose how it’s going to do something. It’s quite a long plan, and then it asks you questions about whether you agree with how it wants to do it or whether you want to have input.

This is very similar to if you had a new hire who was new to your codebase, and they had to present a request for comments to the rest of the team before they started doing the work. Even though that’s not formally code review, I would say review of the plan is actually becoming more important because we’re entering more of this delegation phase of working with agents. That’s an underrated thing.

Then there’s actual code review. I think a problem that I hear a lot of people talking about, especially in the open-source world, is a lot of AI slop. People will just be submitting PRs to these open-source repos, and they’re trash. Maybe the person submitting the PR hasn’t even tested it, or definitely hasn’t reviewed the code. I think this is a problem.

A common practice with Codex is to have Codex review its own PR or its own change. Codex is incredibly good at this. We’ve explicitly trained the model to be good at code review, and that included things like making sure it’s really good at creating high-signal feedback. It will basically have few false positives of criticism, which means you can really trust it when it has feedback.

We encourage people on the team and elsewhere to ask Codex to review, and you can then also set it up to automatically review. Nearly all code at OpenAI is reviewed by Codex automatically whenever you push it to a Git repo.

One fun thing for people who haven’t tried Codex yet or didn’t try it recently is that sometimes the way people see how good our models are is by asking Codex to review a different model’s code. They’re basically like, “Oh, shoot. I should probably just be using Codex to write my code in general.”

10. Building open standards and the "agents.md" convention

You said something really interesting there: for those who maybe haven’t tried it yet, or who are coming back to it, how do you think about retention with this category?

I remember Tom Blomfield, a YC partner, tweeted months and months ago, but it stuck with me—an odd thing in my brain—about the ease of transition between different providers, whether it was Cursor, Claude Code, or Codex. I can’t remember which one it was, to be honest, but how sticky are users, and how do you think about retention?

Alexander Embiricos

We’ve taken this counterintuitive approach with Codex to just build it super openly. The Codex core harness is open source, and we’re always trying to make it easier for people to switch.

For instance, when we first launched Codex last year, we established a convention called AGENTS.md. This is basically a file that you can put instructions for the agent in. We didn’t call it CODEX.md; we just wanted it to be something that all agents could use. Pretty much every agent except Claude Code uses AGENTS.md, which is awesome.

Just last week, we helped push for putting skills, which are a standard for giving the agent instructions and scripts, in a neutral-named folder called `.agents` instead of in `.codex` or something. Again, everyone has jumped on it except the usual suspect.

I think it’s really great for developers to have a lot of choice, and we’re trying to make it even easier for people to try different things.

That said, these coding tasks, where you’re asking an agent to write some code, are quite hermetic. What I mean by this is that you can come in with an open-ended AGENTS.md file that any agent can read from, and you’ve got these skills that any agent can use. You can ask the agent to write some code, and it produces a patch, and that patch goes into Git. Both ends of this are pretty neutral, vendor-neutral, so it’s very easy to move between them for now.

As agents start to do work that is not writing code but more general work, for software engineers or beyond, for any builder, they’re going to need to start interfacing with other systems. Maybe your agent is talking to Sentry, or it’s talking to your Google Docs or something.

I think these agents become much stickier because deciding to connect an agent to that system is a sticky decision. If you’re an enterprise, really trusting that the agent is going to have access to these tools, but that there are secure guardrails, sandboxes, and controls over how the agent works with these systems, is critically important.

That’s not something that you’re going to want to do multiple times. We’ve been building Codex knowing that this is coming, so we have the most conservative sandboxing approach. Sandboxing is a set of operating-system-level controls over what the agent can do.

I’m a fan of 7 Powers: The Foundations of Business Strategy, this brilliant book, which talks about 7 ways that businesses accrue value and sustainability, and your stickiness, or your retention, is one. If we’re on the same team with Codex, how do we create retentive patterns, behaviors, and programs to ensure that people stay with Codex and don’t flip to Cursor when there’s a better model, or Claude Code when there’s a better model?

Alexander Embiricos

It’s interesting because, on the one hand, we think about this. Obviously, we’re running a business, but our mission here is to ensure that we safely deliver the benefits of AGI to all humanity. Something that’s unintuitive to people about the Codex team—

Alex, actually, I know, but your job is the success of Codex, I guess.

Alexander Embiricos

Our job is the distribution of intelligence, right? We’re obviously building out Codex, and this is really unintuitive to a lot of listeners, but we put all this effort into training these models and then serve these models to our competitors, right? From our perspective—

This is so difficult for me as a venture capitalist to understand. You are aware of this.

Alexander Embiricos

Yeah, I’m totally aware of this. OpenAI is a really interesting and unusual place to work. Basically, because we’re playing such a long game, if the competition gets better, we learn. It’s actually helpful for us. We’re pushing really hard at growing Codex.

If they’re closed?

Alexander Embiricos

Yeah.

And they improve, you don't learn.

Alexander Embiricos

I don't think so. For example, there have been a bunch of recent launches. Even today, I literally quote-tweeted a thing this morning about a launch from Warp. No particular affiliation, right? There are a bunch of cool ideas in there about how they framed up the way that their agent can work in the cloud at the same time as working locally. For me, that's inspiring, and I think I see all these things from various companies. One of the coolest things about the space is that we're all kind of inevitably reaching the same conclusions together and then building things out.

On the Codex team, I think we have some massive advantages, right? We have the massive distribution advantage with ChatGPT. We have the massive capability advantage of training our own models to be good in our harness and building our harness to be good at the new models, and no one else has early access to those. I think we're playing to win, and we have a really big advantage, or a number of advantages. But we're also playing this long game where, again, we serve our models to everyone, where we push for open standards so that everyone can use all the things that we're pushing for as well.

11. Winning strategies: Compute advantage, best models, and product execution

Can I ask you what will be the defining factor of winning? I know I'm using venture language, and you're brilliant in a much more free and open way. But what is the defining factor of winning? Again, if I push you, is it GTM—meaning that the biggest enterprises in the world do want to work with OpenAI? I have many friends on your sales team. The inbound that you get from the largest brands is incredible.

So, is it GTM because of the incredible brand, product execution, and Codex being a freaking awesome product, or compute, inference speed, actual compute advantage? Which one is the defining winner?

Alexander Embiricos

Okay, so I think if we're going to talk about it more from an OpenAI perspective, obviously this is way above my pay grade, but I would say it's compute advantage and having the best models, right? In order to achieve that, we then need to build businesses to generate revenue.

Something that's really interesting that we noticed with having the Codex team, which is a sort of combined team of research and product, is that by building these successful products, we create a lot of pressure to improve the model in a faster way. So that's maybe the company perspective, right?

If we come to the product perspective, I think the single most important thing we can do is build a really good product that people want to use. Like I was saying earlier, I think we really want to build products for individuals and then allow people to become fluent in those products and then pull in automation. I think that may be counterintuitive but will result in way more impact than anyone purely approaching it from the enterprise workflow perspective. I think that's mostly a question of product execution, and then that works for, say, prosumer.

When it comes to enterprise, the go-to-market side is really important. Something that I've learned the hard way is, if we go to an enterprise and we're just like, “Hey, we're here. Feel free to use the stuff,” that doesn't work. There's actually quite a lot of education that needs to be done, and there's a lot of configuration that we need to support and education of the broader team.

So that motion looks much more like coming in, pitching, meeting the head of developer experience or whatever, understanding how they want their team to operate, and then giving them tools to propagate that mechanism of operating to the rest of the team.

12. Measuring success: Moving from Weekly Active Users to Daily Active Users

You said the word revenue there, which is one metric to measure a business against. When you think about your metric of success, which you sit down with Sam or Brad or whoever it is and say, “Hey, this is what we're optimizing for,” what is the metric that you use as the defining North Star for your progression?

Alexander Embiricos

It's actually not revenue as the primary. The primary is active users.

How do you measure active users? Daily active users?

Alexander Embiricos

Yeah, we measure weekly active users, and it's just, did this person actually do a turn in our product? Did they send a prompt?

Is weekly active a frequent enough metric, do you think? Sounds nice, but if this is actually replacing the IDE, is daily active not better?

Alexander Embiricos

I think daily active will be better soon. We just happen to use weekly active. It's a standard here, and I think as we were getting started, it made sense. But I actually agree with the criticism there. We should probably just be daily.

I think we need to be getting to a world where, for any given task that you have, your first instinct is to ask an agent to help, right? It's kind of like how with Google Search, anything I need to do, I just go into this text box and I can navigate to the right location. Then you have ChatGPT: for any information I need, I can go into this text box, type it out, and get information that helps me.

I think the next phase that we'll see this year is, for any task I need to do—as opposed to just getting information—I go to this text box or this input, and something happens that helps me, even if it's not the full task, even if it's only a small part of it.

13. Chat vs GUIs: The enduring UI of AI interaction

You said about ChatGPT and the interface there. I'm really fascinated by this because it is a seemingly incredibly efficient input function for busy humans. But I spoke to Anish Acharya, who's a GP at Andreessen, and he came on the other day, and he's like, “No, no, no, no. This was created by Sam and Elon, and it works for very efficient people, but most of the planet wants browser-based discovery, interactions, and UIs.”

Do you think that chat will be the enduring UI in the next wave of AI interaction with humanity?

Alexander Embiricos

The simple answer is yes, but actually I think there are 2 components here. If we just imagine the future, let's think of some sci-fi movie. What does AI look like? I believe that sci-fi is a really good predictor of what the future should look like. Usually it's pretty simple because it's a story, and I think simple is usually right.

It's going to be some entity that I can talk to however I want about whatever I want, right? I shouldn't have to navigate to a place where I work with my coding AI and then have a different place for my sales AI, and have to be like, “Hey, I'm now talking to the sales thing,” and do that. I'm just going to talk to a thing, and it's just going to help.

So I think what we're going to have is that we'll have chat or voice. Basically, a conversational interface will be the pillar of everything that you can talk to about anything, and that you can add into any group chat or whatever so it can discover how to help you.

But then if you're a power user and you're very good at a specific thing, you probably don't want to be disintermediated by having to talk to another person. It'd be like if you had an executive assistant, but you could only work by talking to them. That's super annoying, right? At some point, you want to get to the show notes and look at them yourself and edit them yourself, right? You want to edit the thing yourself.

I think we'll pair chat with functional, graphical interfaces that are bespoke to what someone needs.

So, in my case, I will probably chat to it to do my podcast prep. But when it comes to actually looking at product and code, I probably want the Codex app that I can go into and get deep into. Whereas maybe if we're talking to a marketer, maybe that marketer will chat to ask questions about the product. They're not going to download the Codex app just to ask questions about the product, but maybe they'll have a super-custom GUI for ad analytics or something that they go into.

14. Designing interfaces for agent-to-agent interaction

Totally get that. It kind of wrongly assumes, on my behalf, a consumer interaction at some point in that journey. And I want to ask you, how do you think about agent-to-agent experiences and designing experiences for agents?

Alexander Embiricos

My quickest answer to this is that we've noticed, as we build Codex, that the best interfaces for Codex to do work also tend to be the best interfaces for humans. When people ask, “How can I make my codebase more efficient for the agent to work with?” the answer is often, “Well, have you looked at it yourself, and is it easy for a human to work with?”

One very specific example would be running tests in a codebase. Naively, if you just set up most test runners, they just emit all the outputs of all the tests. As a human, it's really annoying because you have to go in and find the one that failed, and you've got to read hundreds of thousands of lines. It turns out that's terrible for AI as well.

But if you filter it down to emit only the failed test, it's better for humans and also better for agents. So probably the agent-to-agent interaction points will be very similar to if there was a human in the loop, and that's nice because it means you can kind of atomically replace individual systems.

15. The data moat: Coding data vs knowledge work task data

I mentioned our show on LinkedIn, and a wonderful investor from a different company.

It's like Harry Potter: Voldemort. It's like he who shall not be named. I don't want Sam to kill me, but an investor from another company was like, “You've got to ask him: How do you think about a coding data moat, and does Anthropic have all the data now?”

Alexander Embiricos

I think that, from what we've seen—and I would defer to my research team on this—I feel like we have plenty of data to build really good coding models. I actually think the place that's more interesting for getting data now is as we get into knowledge-work tasks. That's the kind of data that's not really available in most places on the internet.

You start to have really interesting brainstorms for how to help a model be good at it. Maybe you have to pay people to simulate doing tasks so that you can learn these trajectories for the model. Maybe you should acquire startups that are no longer in business but have a lot of data, like, say, their Slack or something. I think that kind of knowledge-work task distribution is much harder than coding.

That's so interesting, what you said there about the kind of data that doesn't exist, so to speak. How do you think about your interactions with the data providers—your Mercors, your Turings, your Invisibles, your DataAnnotations of the world? Will you spend 10x there, or will you go, “We're spending too much on data; we should do it ourselves and do data acquisition”?

Alexander Embiricos

I think the way that we think about these things is just: How do we move as quickly as possible? Becoming able to set these things up in-house is very expensive in time, and we're a small team. What I have observed so far is that if we need to run a data campaign at scale, we're usually going to enlist help from one of these companies.

On the consumer side, for Codex, we've spoken about enterprises and going into them. How do you engage in terms of developer experience and developer relations? Do you compete with Lovable and Replit on a low-end consumer basis in a year or 2's time? Is that a business where you're like, “You know what? Codex is not for every person to create an about-me, or for a small business to create their own site”? How do you think about consumer in that way?

Alexander Embiricos

I would say that right now it doesn't feel like we're competing super directly. But I don't know if you saw our Super Bowl ad, the tagline of which is just, “You can just build things.”

With the app, we noticed that many, many people who are less technical are starting to build things, and so the kinds of things they're building are much more hello-world-y. I think that we will see some overlap in use cases, where you have people just pulling up Codex because they have it as part of their ChatGPT.

Actually, a big announcement last week was that we're now offering Codex to people even on free ChatGPT plans or on ChatGPT Go plans, so this is massive in terms of bringing availability to everyone. I think we're definitely going to see people with a free ChatGPT plan coming in and just building simple things where they otherwise might have gone to a specialized tool.

What would you most like to do differently, but for whatever reason you can't?

Alexander Embiricos

This is an interesting one. I feel like it's been a very good few weeks for us. I'm pretty jazzed by everything that's happening.

Yeah, that's really interesting. You said it's been a very good few weeks for us, and I feel that. Does the team feel changing winds of momentum, both in positive and negative cycles?

Boris Power

Absolutely. We are very attuned to it. If you look at the history of Codex, the first thing we launched last year was this amazing idea that people were super excited about: “Hey, we're going to give the agent its own computer in the cloud. You can have as many of them as you want working for you in parallel on tasks.” Super great idea.

Alexander Embiricos

To be honest, it didn't work as well as what we shipped later. It was not the best. Since August, with GPT-5, we started pushing really hard on interactive coding, which is where most of the competition in the market is. We went on an absolute tear. I feel like the public metric we had was that since August, we grew by 20x. Even late in the year, we doubled from December to now. I forget the exact number there, but we were competing neck and neck.

The shift that we felt last week is that we felt like we had the most intelligent model, and that was cemented with GPT-5.3-Codex. We had feedback around our model being slower, maybe less fun to work with, and less good at communicating with you while it was working. We addressed that feedback. That's true even compared to the other competitor model that launched 20 minutes before us and was like, “Maybe this is spicy.” It was SOTA for 20 minutes. SOTA means state of the art.

We'd always been getting a lot of feedback on the quality of the user experience in Codex. Our most popular surface was the IDE extension, and our CLI, which is a command-line interface, was less polished. But with the app, the feedback has been resounding from the market that this is a really high-quality experience. It's simple—unintuitively simple—and people are just loving using it. Even our biggest critics are converted.

Then we had the Super Bowl ad, and then we went free. Going back to your question of what I most want to do differently, the first is that I actually want to get back to cloud. When we pivoted our strategy from building the cloud—focusing on the cloud agent last year—to working interactively, the thinking was very simple. It's kind of what I was telling you about FTEs, actually: If you go too far ahead to workflow automation before your end user is fluent with the tooling and can get it to work simply, then there's this disconnect, and you just have this pipe-dream idea that's not effective except for the most power users.

But once you have this base where people are using your tool every day, like you said, and they're configuring it, and every time they use it, it gets better, then the step up to letting it run independently in the cloud is a much smaller step. I think it's time for us to get back to building out the cloud product and making it super tightly integrated with the local product. It already is somewhat integrated.

The other thing I want to do differently is start thinking more about the bottlenecks. Codegen—writing code—has become basically trivial now, but the hard part is what you were talking about with code review: How do we know the code quality is good? How do we know we're doing the right things?

Those bottlenecks, I think, are underappreciated still and underinvested in. I think we want to get to a world where you can have an agent that is unbottlenecked, that you trust to own an entire microservice or internal tool or whatever, and can do the full iterative loop, including feedback from users, without having to go through human review. That is a really hard problem to solve, both from an intelligence perspective but also from a safety perspective and a controls perspective.

How much weight should we place on benchmarks and evals?

Alexander Embiricos

I think this is probably an annoying answer for you. It's like, some, right? They do tell you—they give you a good measure of intelligence, in my mind. You can put weight on those for intelligence. Especially before evals are saturated, when you see meaningful progress in those benchmarks, it's very helpful.

You have to pair that, though, with what it feels like to use the model. That's a vibes thing. Whenever I talk to anyone, even internally, or even to customers of our models, I'm always surprised by how vibes-based the evaluation of how it feels to work with a model is.

How vibes-based life is. People want to work with people they like. That's the lesson that I give to kids.

In terms of market composition, as an investor, I have to think through the eventual state of this given market, kind of a terminal state. How do you think about that? Is it like Uber and Lyft, and the majority of the market will be on Codex or Claude Code, or is it like AWS, Azure, Google Cloud, and a 33/33/33 split?

Boris Power

I think this might end up with fewer providers that are capturing a lot of value in the long run. Here's why. Maybe this is a bit spicy, but I think that we're kind of in this temporary phase where we have agents that are really good at coding.

If you look back last year, maybe more people thought we would have agents that are good at other domains too, but that didn't happen last year. So we only have PMF for coding agents in the industry overall, I would say, and then there are some very narrow other use cases, like customer support, et cetera.

I think that's probably temporary, and then over time I think we're going to end up with agents that can do anything for you. This is kind of what I was saying earlier: There's just a super-assistant you talk to about anything, and then there is a specific UI that you can go look at if you happen to be deep in a specific function.

In that world, I don't think you want 12 agents at the company, and you have to have your employees go figure out the right one to talk to, because then they won't achieve fluency. If they don't achieve fluency, then they also won't pull automation into their roles.

Alexander Embiricos

But if you have this one thing that you can talk to about anything, right? So your onboarding is just, “Go talk to this thing about anything you need.” Then people will develop muscle memory to go to it. It'll become the center of gravity of work, and people will pull in automation.

So I think that future makes much more sense, and I think as the people building ChatGPT, we're really well set up to deliver that. This is kind of a stretch, but an analogy here is I used to work at Dropbox. For a while—this was before Slack was big—we wondered if people should go comment on documents in Dropbox, or if they should go talk about the documents in Slack. It was obvious that it was more optimal for people to put comments on the right timestamp in the video in Dropbox, or comment on the document in Dropbox, right? So it was more optimal.

However, what we saw is that Slack is such a center of gravity for people talking to each other. Nobody wants to comment on the document; I just want to Slack you, right? So we saw that there was this really big pull toward things happening in Slack, even if it was less efficient. I think we're going to see something similar at work, where if there is a single agent you can use for nearly anything, there will just be this giant pull, and everyone will talk about how they use that one agent for things. Teams will share best practices with each other. There'll be hackathons around how to use that thing. And you'll end up with just a handful of these.

You said that agents aren't really proliferating in terms of usage other than coding, and that this may actually be the time for that. Customer support is one of the examples. My question to you is: I'm an investor today. I'm looking for companies that will accrue value over time and provide incredible products to customers.

There is a belief that the durability of revenue of large SaaS companies today is zero, and that SaaS is dead because the model providers—you, Anthropic, and others—are going to come for our lunch, so to speak. What would you advise me?

Alexander Embiricos

Things are built for humans. Otherwise, what's the point, right? Even SaaS tools are built for humans. For me, my question is: Does this SaaS company own a relationship with a human on the other end of things? If it does, then I suspect it's not going away. Or does the SaaS company own some really important system of record? It's probably not going away.

Maybe both of those two things—the interaction with the human and the system of record—are more important than ever, actually. On the other hand, is the SaaS company a kind of glue layer, but it doesn't own either of those two things? I'm not the expert here, but I'm more nervous about that kind of company.

So if we take that stance, Salesforce and ServiceNow are down 20%, 30%, 40%. I think it's massively exaggerated. I think there are some companies that legitimately should be. Respectfully, I think Dropbox is in a very difficult position.

I think your Monday.coms of the world, though, for the majority of SMBs and consumers who use it—which is a large majority of their market—could they vibe-code a to-do list? Yes. Would it be cost-efficient to do so? Not really, by the time you customize it and perfect it.

To be honest, a to-do list is generally pretty bland in terms of what you need to do: add a task, complete a task, show historical tasks, assign to new members. It's not very difficult, so I think you just keep it. I think it's massively overblown, and I think that's the classic knee-jerk reaction from markets.

But I do think—sorry, I do think you're going to come for customer support, and I wouldn't want to be in that category. I think this maybe changes what kind of founder you invest in, right? There was this perhaps temporary phase that I liked personally as a product builder, where you would invest in the person who could just build good product. You could ignore whether they had a good thesis around a customer, go-to-market, distribution, or anything like that because it was so hard to build good product, right?

I think that was an anomaly. If we look at where we are now, maybe that kind of founder is not the founder you should invest in because it's relatively easier to build good product. You need to go back to investing in the founder who's thought through distribution and who has good domain expertise about what to build for a specific customer.

So again, if you were on my team as an investor, how would you think about interesting areas for us to invest in—companies that will accrue value and not be threatened by model providers? Because, again, you're going into health, you go into code—obviously, Codex is very clear—you go into customer support. Where are you not going, and where's Claude Code not going?

Alexander Embiricos

I'm tempted to just say, “I don't know.” I think it's a hard time to be an investor. The market is so dynamic. It's hard to say.

It's a really tough time to be investing today.

Alexander Embiricos

My answer is kind of twofold, actually. Number 1, I look for things with physical infrastructure. I don't think you're going into energy supply. Number 2 is fintech and banking integrations—gnarly financial products. I don't think OpenAI is going to go into building 500 relationships with banks in Southeast Asia.

Yeah, I tend to agree. It again comes back to whether you're going into a gnarly, complicated market where customer relationships and knowledge of the market are everything. That still seems great.

How bad is the war for talent from the UK? We look at San Francisco, and I say to companies, “It's better to build in Europe because it's impossible to acquire talent and it's impossible to retain it.” Am I wrong?

Alexander Embiricos

I think that the war for talent is incredibly fierce right now. Obviously, at OpenAI, we have an incredibly strong brand, and so we're able to attract a lot of talent. But even so, we put a ton of effort into closing candidates that we're really excited about. Even we feel it. It's not like you just get whoever you want for free.

Can I ask: at the entry price that you get stock at, is it still attractive for the best talent?

Alexander Embiricos

I haven't had anyone tell me anything to the contrary.

To what extent do you think about finding the perfect fit versus finding someone who's good enough?

Alexander Embiricos

Earlier I made my joke about PMs kind of being optional.

Yeah.

Peter Deng

I think that's not actually true. You still need product people, but I do think that they have to be the perfect fit. If you have someone who's not the perfect fit, they might just do more harm than good. So it means that we're way more selective than I might have been in other roles.

I'm a CS student, okay? I'm at Stanford. I'm at Imperial. I'm at Cambridge. I'm wherever—ETH, great institution. What would you advise me, knowing all that you know now, that would help me navigate the next 5 years of my career? I want to be valuable to the AI ecosystem as an engineer entering the workforce in the next year.

Alexander Embiricos

Basically, there's actually never been a better time to be an engineer because you have incredible tooling available to you to get an incredible amount done. Your ability to ramp into a complex codebase that you might be hired into has never been faster because you can ask AI a ton of questions about the codebase, and you can ask it to plan out changes that would otherwise take you days to research.

So I think, first off, I would say you should be very optimistic. But then, of course, once you're at the job, the question is: How do you get the job? I think that because it's never been easier to build things, the thing that becomes scarcer is agency, taste, and quality. I would urge you to just build things, demonstrate your agency and your taste around what you build, build things that are of high quality, and then share those things.

We get a lot of inbound from folks, both applying for jobs through the careers page and also on social. This is just me, but when someone writes to me with some interesting thoughts and a link to an interesting project, that gets my attention much more than a normal résumé does.

Final questions before we do a quick-fire. You mentioned Dropbox earlier. The alumni from Dropbox is incredible. I mean, really, it's amazing to see the talent that's come out of Dropbox. What's your single biggest lesson from Dropbox that has shaped some of your thinking now with OpenAI?

Alexander Embiricos

I don't need to think about that one. That's the thing I was telling you about earlier, right? I think when you're building tooling for people—for end users—you have to think about that tooling as a system of engagement, right? If people don't want to use your tool, if it doesn't naturally feel like the easiest way to get something done, then people just won't use it, right?

Again, I learned that from watching how Slack just absolutely took off. I think about that a lot now when we're building these agents. If we build our agent purely as workflow automation, then it's always going to be like pulling teeth to get that thing started, right? You're going to need to hire Accenture or someone to come in.

They're going to need to deploy FTEs. It's going to be tough. But if you can build a system that people just love using, even if they only use it for partial tasks over time, they'll get better and better at using it. Then you'll get connected to the tools you want over time, and you can start layering in automation. Obviously, these aren't mutually exclusive.

How on earth do you reinvigorate growth at Dropbox today?

16. Advice for the Next Gen of Engineers

Alexander Embiricos

At least from when I was at Dropbox, the thing we were uniquely good at was desktop software. And desktop software—it's funny, it was never not back, but anyway, it's so back. Basically, if you're solving for productivity and knowledge work, yes, there are systems of record everywhere that you need to connect with, but everything at the end of the day happens on the user's computer, either in their browser or locally in apps on their computer.

I do think that the fastest way we're going to see productivity gains from agents at work is going to be, at first, meeting users on their computer and working with the stuff that they have available to them, without having deployed FTEs to set anything up. Then, over time, you'll connect in these various systems. If I was Dropbox, I'd be thinking about how we leverage our unique domain expertise in building really good desktop software and this sort of collaborative layer on top of your computer. How do we leverage that to enable productivity agents? It's a bit broad, but I think that's the angle you go for.

No, I love it, and I really appreciate the response. Final one before we do a quick fire, I promise. I've been brought up in a world where margin matters. Software margins are wonderful, and it's what makes software a brilliant category to invest in. We're seeing margin profiles that are very different in inference-heavy players in particular. To what extent should I put that out of mind and appreciate that costs will come down, the cost of tokens will come down, and actually it's about usage and customer love? Margins will come, or no, margins are actually freaking important. Keep that focus.

17. Lessons from competitors (Claude Code)

Alexander Embiricos

I think both costs are going to come down significantly. I also think that if this is the year of agents being deployed broadly at work and connected, then this is also the year where they're going to have to be connected to all these various systems. I think that's going to be very sticky, and so I view this year as a race. You want to win that race, and you should be okay taking some hit to margin in the meantime.

Dude, quick-fire round. I say a short statement, you give me your immediate thoughts. Does that sound okay?

Alexander Embiricos

Yeah.

What have you changed your mind on most in the last 12 months?

Alexander Embiricos

When I joined OpenAI—I thought this was a little longer than 12 months ago—but when I joined OpenAI, I thought that we would all just be hanging out with our computer screen-sharing, but within 1 year from there, we'd have this agent that we're just talking to. That was completely wrong. I think the rate of progress in multimodal models was slower than I expected. Multimodal means models that work with video and audio.

Instead, what happened was that we saw that agents that work with your computer through code are the way. For me, that's been a complete rethink in terms of how we bring the benefits of AI to people generally. It's not primarily through video and audio.

Which lesser-known competitor do you respect most, and why?

Alexander Embiricos

The first one that came to mind was Amp.

Yeah, Amp.

18. Lessons from Dropbox and Slack

Alexander Embiricos

It's out of the folks at Sourcegraph. Their product has a great reputation for just punching way above its weight. The other thing that I really respect is that they helped initiate this whole standardization around AGENTS.md and agent skills, which is what I was saying earlier about making it easier for users to manage all these different agents that they're trying.

We obviously put out AGENTS.md, but they put out AGENTS.md, and basically Quinn Slack started this all by putting out a tweet that said, “Hey, if you guys buy the domain AGENTS.md, we'll standardize to your spelling.” As small as that was, it initiated this whole standardization that I think has been awesome in the community.

Do you think the response to Anthropic's ads was the right response?

Alexander Embiricos

There were so many different responses. The one that I heard, obviously, I think was right. It was, “Well, 1 company is being pretty negative about the future, and the other company—us, OpenAI—is being really positive and just telling people they can build things and to dream.” I thought that response was brilliant.

What's the hardest product decision you've had to make since being at Codex?

Alexander Embiricos

I can tell you the most painful product decision we had to make.

Great.

Alexander Embiricos

For a while, Codex Cloud was effectively unlimited—not free, like you needed to pay for ChatGPT, but then you had unlimited usage. Every day that we left it that way, we knew it would be harder to wind back its being unlimited. We were just so focused on competing on our other things that had more product-market fit that we punted that decision out.

When we wound back that unlimited usage to some more reasonable limit, there was a lot of blowback from users. It was a very small minority of users who thought everything should be pseudo-free forever, but that blowback affected us everywhere because social chatter doesn't really distinguish between these things. I think the lesson I learned the hard way there is you can't make things unlimited for too long.

Dude, it's like pricing grandfathering. Pricing is just such a hard thing. What do we do today in engineering or product that in 5 years' time you'll look back on and go, “Oh my God, can you believe that we did that?”

Alexander Embiricos

1 is just editing code by hand. Another one might even be actually managing the deployment and monitoring of systems by hand. I basically think that big companies will take a long time to deploy this, but many startups might actually start building on a completely new stack that's fully AI-managed.

To be clear, the stack doesn't exist yet, but a fully managed AI stack could be built to give you really strong, deterministic guardrails over what the agent can do, and control over rolling back deployments and everything like that. We'll get to a world where the way you start a company is you start by getting an agent and just asking it to build things. Then you get more agents in that, and maybe eventually you add your co-founders to this service that you use to work with agents.

You might end up with your main communication tool actually being your agent communication tool. Maybe you're not actually hand-holding this very painful CI and deployment process, but you're just having agents do things.

19. Quick-Fire Round

Weird question, but I'm intrigued. Are you the one providing agent guardrails? What I mean by that is, your agents can go anywhere within an enterprise. Are you responsible for providing those guardrails, or is there a third-party provider saying, “Hey, Alex, you can't go into that—that's human resources,” or, “Oh, you can't go into that—that's marketing”? How do you think about guardrail provisioning, and is that the role of the agent provider or a third-party provider?

Alexander Embiricos

I think we'll probably see both. We are putting a lot of effort into agent guardrails. As I said, I think we're basically the only company that cares about OS-level sandboxing for coding agents. For instance, there's nothing like that that exists on Windows. We're the ones building that, and we're doing it in open source, so hopefully other people can use it.

We think about that a lot. ChatGPT supports connectors, so you can talk to your Google Docs or something. We put a lot of effort into guardrails around what the agent can do with your Google Docs. Those are just 2 examples, but we think a lot about this.

I think, probably, though, the way that we'll do it will not be sufficient. There'll be third parties who provide very bespoke things for very bespoke company needs, and there'll probably be a mix of both.

Final one for you, my friend. What are you most excited about when you look forward 10 years?

Alexander Embiricos

This is probably going to happen in much less than 10 years, but my mission personally when I joined the company was that I just felt like, even with the models we had 1.5 years ago, there was so much capability overhang—the ability for these things to be useful—but we hadn't built the right products around that. People like me were getting more benefit than people like my grandma.

What I'm most excited for is getting to a form factor for AI that means they're just helping everyone, regardless of whether they're in tech, and especially if they're not in tech or if they're older. The concrete vision I have is that at some point we'll add an agent to our family WhatsApp or something, and it'll just start being useful to the family without anyone having to think harder about it than that. There are many other ways that could happen, but I think, concretely, that's the most obvious thing we could do with my grandma.

Dude, I so appreciate you. I so appreciate you putting up with my wandering questions and my very episodic mind. You’ve been fantastic, man.

Alexander Embiricos

Thanks so much. I appreciate you putting up with my wandering answers. So, all good [laughter] here.