Greg Brockman

First of all, anything in there that maybe we can go back to the beginning of? I think my narrative seeing it from the outside was, on the GPT-5 launch, there was something happening in Claude Code and the way I was using Claude Code that wasn't reflected in the model and product strategy, or at least publicly. So what were you thinking? What was going on internally then?

Yeah. So I'd say in beginning of 2025, we actually did set coding software engineer as a top-level company goal, right? So we were actually very focused on saying, “Hey, coding is a thing that we want to really deliver on.” And the thing I think we missed or were slower to was, you know, we'd always had the best numbers on coding competition benchmarks, things like that. But actually connecting it to real world software engineering, that was the thing that we had under-invested in and under-appreciated relative to its importance. And so I think we had kind of the smartest models, but that doesn't mean that they're the easiest to use. They never had seen a messy code base or how a programmer might interrupt it halfway through. All of that, thinking about the personality, what it is like to talk to the thing. Those were not as keenly in our sights and focus. And I think that that was a real lesson for us, is to realize that how do we actually make this thing useful actually is a lot about those things. It's not just about the raw intelligence. And I think we became really aware of this maybe midway through the year, and then there was a real sprint to close that gap. And Michelle Pokrass led a team there.

Wait, what's her name?

Michelle—

Michelle.

Pokrass. And yeah, so she and her team did a ton of the grind of just talk to customers, see what the gaps are, these little things that people are annoyed about. Let's go fix them. Make sure we add that change into the post-training, that kind of thing. I think it's actually kind of a beautiful lesson in many ways, right? That it's not just this raw intelligence that we're trying to deliver. We're trying to make something that's useful for people, right? And actually people need to be at the center of that, and that was really the way we started to operationalize this. And on the tooling side, that we'd experimented with a few different form factors, and I think that the place we'd started was with a... And we actually had several different efforts. We ended up merging two of them and then merging another two of them. So we ended up with a little bit of exploration and then collapse, but I think that a lot of the energy was about what is the right form factor? And if you project into the future, that the right form factor is an AI in the cloud, right? That has its own laptop, that's able to execute things on its own. And so we actually built that, and that was basically Codex Cloud. But it didn't get PMF, and I think it was too early, right? And I think that my overall realization, too, is if you look at the evolution of AI coding, I mean, we led with basically working together with Microsoft to deliver GitHub Copilot back in, was that '22? Something like that. And you start out with auto-complete, then you move to more of the Cursor style. Like, okay, it's gonna be a sidebar but most of the time you're still doing the work in your editor. Then it's this agentic, you know, sort of Codex app or CLI. I think eventually it's going to end up being that cloud thing. I think that's coming soon.

Yeah.

And it makes you really realize you also need to calibrate on where the technology is now and build for the moment.

So one of the other things I think is really interesting, and it's a big challenge that a lot of AI companies face, even beyond the model companies, which is the models are moving so fast that any product strategy you have has to change every three to six months as the products change. And so there's this really interesting thing with the Codex model line, but also the Codex app, where what you're able to do with the models now is fundamentally different than what you were able to do when ChatGPT was first designed. But you have this gigantic app and gigantic user base, and model tuned for those people that have a certain set of expectations. One of the things I think is super interesting about the journey of Codex is it was this separate model line and separate product that now it seems like you're trying to put back in. But in order to get to where it is, it sort of feels like it had to be separate, and there's a lot of different ways to solve it. So it seems like one thing that you did is split it out, and now you're gonna put it back in. What Anthropic has done, for example, is they have tabs. It's like Code and then Co-work in the same app, and I think that's kind of messy. So tell me about that from a product strategy, research strategy perspective, that kind of move and why you have to do it and what's the best way to do it?

Well, the challenge here is fundamentally an innovator's dilemma. Right? You have a very successful product. Lots of people are using it, relying on it, loving it. Lots of diversity of different use cases, all of those things. But then you have a new leapfrog coming, and that is rapidly taking off, and you just see the value of if you could bring that to all your existing users, think about the value there. And by the way, no one has seen the consumer agentic moment yet. That just hasn't happened. And I think that the way we approach this has been very deliberate, and we're taking a very step-by-step strategy. And so a lot of it actually comes down to technological unification, right? We realize that having a single agentic implementation, the harness, the connectors, all of those things, each of those are pretty general purpose regardless of what your use case is. So you really want to build them once in a unified way. And I think the goal ultimately is zero tabs, right? It's like the actual thing you want.

Thank God.

I know, right?

I saw the tab version today, and I was like, "No, don't do the tab."

I know. But it's not to say you don't take tabs as a stepping stone, right? And you want as few tabs as possible. And I think that is actually a really key thing. But again, back to where are we going? You want an AI that you can talk to. Right? And if you think about a voice interface, it immediately suggests to you, you can't have tabs in a voice interface. It just doesn't even make sense. ChatGPT right now, you have model pickers, and you have different features on the left and things like that. What you want is all that to just blur away, right? You just want an AI, like a agent in the cloud that can solve problems for you, right? That's like constantly out there thinking about how it can help you and what value it can add. And so sometimes that's you proactively putting things in. Sometimes that's it trying to find news articles of interest, or you wake up and your calendar has been managed well and your inbox has been triaged, and it's like, "I need these three things from you." That isn't really a sci-fi vision anymore, right? We have the technology for it. We just need to do a little bit of engineering, a lot of bit of engineering. But we need to do that to scale and deliver it to everyone. And so there will be a step-by-step here of how we deliver tabs, and part of the reason you need that is because there still is so much depth to what chat is, right? That it's able to scale to a billion users, which means that there's a lot of diversity and complexity under the hood that isn't obvious if you're just like, "Hey, it's a text box. How hard could that be?" It's like the simplest products are the ones that have the most depth of implementation and thought behind them. But ultimately, our ambition and where we want to go is to deliver, we call it the personal AGI. We want this to be one unified experience, and you can chat with it. You can get trustworthy answers to questions and advice, but you can also ask it to go and accomplish work tasks for you. And all of that, I think, should be in a single seamless fashion.

But let's talk about the way to get there. It's really interesting about what you said is the first thing you said about the innovator's dilemma, because usually the innovator's dilemma, it's like you have got an incumbent, and then you've got a set of startups that are gonna beat the incumbent because the incumbent can't see the valuable thing that the startups can see 'cause it looks smaller. And normally that's not happening within one company all the time. At least I don't, from disk drives in the '80s, I don't think they were moving that fast in the '80s to see that. And so what does that change about how to run a company if, because the frontier is moving so quickly, you have to expect to disrupt yourself?

That is the fundamental structure behind OpenAI in many ways, right? We've always set a goal, at least at a qualitative level, of every single year doing something that just totally obsoletes what we did before. Right? That just feels like a step function better than anything we've seen. And we basically have done that pretty consistently. And so that means you have to be set up for constant self-disruption. And a lot of that is around where you put pressures, right? One of the things that used to cause me a lot of pain is we'd produce a new model that was no one had ever seen anything like it, and it would sit on a shelf because we're like, "Well, we're busy with the shipping the current things. We're fixing bugs," whatever. And it means, no, you actually really need to have a prioritization engine that says getting a new model out well is a priority, and that actually comes over some of the needs of the day. Now, you can't take that too far, right? Because you also really need to make sure that you're doing a good job of constantly upleveling based on what you're learning from the world. That's part of why we deploy. And so I think that there's a constant management challenge of how to balance these priorities, and there's no one general purpose answer to it. That is fundamentally the job of management is to internalize these trade-offs and make decisions. But I'd say that the way that we structure our teams is towards thinking about, [we] want smaller teams that can move faster, can try out new things. The way that we structure our code bases, all of these things are towards the vision of saying we're not just ossifying on a thing. It's like really about the machine that makes the machine.

How do you then keep people motivated and excited to do quality work if you're like, "I spent so much time making ChatGPT amazing, and now there's this new model out, which means that the Codex team is getting all this love, and there's so much thrash in our roadmap," and all that kind of stuff. How do you do that well?

I think that there's several pieces to it. Number one is I think that really helping people see the value in what they are doing is important, right? It's very easy to just give all the oxygen to the new shiny thing. And that is a mistake, right? And I think this is true across many companies, but you see it especially here, that there's so much core value that's delivered by people doing the behind the scenes unglamorous work, right? So improving reliability and latency, all of these, improving how different regions are handled, things like that. Those actually transfer, right? And I think that understanding what is one-time work that is specific to the current moment and the current system versus what's gonna transfer to the future, I think the more that you can highlight these investments, we're gonna have to make them for the new system versus the old system anyway. And so just actually internalizing what we're learning from reality and making sure we do a good job of meeting the moment. Sometimes the specific implementation won't transfer, but the lessons will. And so I think really helping people understand that, honestly, a lot of it is just calling it out, just saying, "This team that is behind the scenes has been quietly just making things better. That's exactly the kind of thing that we wanna see." 'Cause you kind of don't need to put as much highlight on the people who are doing the thing that's going to get all the attention by itself. So I think a lot of it is what management highlights tends to reflect on what the values are within, that people perceive within the org.