OpenAI's Codex Lead: Why Coding as We Know It is Over

You still need software engineers today. You still need designers. I'm a PM. Do you need PMs? You know, you can have some fun jokes about that. I don't think you need them.

For me, the most exciting future with AI is one where everyone just feels like a superhuman, like empowered by AI. And for that, we need tools that everyone feels fluent with.

Actually our job is the distribution of intelligence and this is really unintuitive but like we put all this effort into training these models and then we serve these models to our competitors.

For sure I would agree that coding is one of the first domains where LLMs are really good. But what does it mean for coding to be automated? It's like kind of a heavy statement, right? For example.

So excited to be here. Thank you.

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, and 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, and 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, you know, I basically every now and then I have to reach myself and like flip back into this idea of winning. But really what motivates me even more than that is I think I just love building things and building things for people. And man, 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 think for sure I would agree that coding is one of the first domains where LLMs are really good. You know, what does it mean for coding to be automated? It's like kind of a heavy statement, right? Like for example, now that we no longer write assembly, like 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 actually there was much more demand for code and there were many more software engineers required. But yeah, part of what they used to do is automated in the same way that like, do you know the origin of the word computer?

Um, I might pronounce the location wrong, but I think it was at Bletchley Park. There were all these machines for like decoding German Enigma. And like there were humans who would like punch out punch cards and like put them into the machine and do a bunch of like tabulated math. I'm probably butchering this, but basically there was like an intensely manual part of work. And even like the first spreadsheet software was kind of loosely based off this idea that you would have an office full of desks arranged in a grid and people doing tabulations and then passing their sheets to the next person. And so all these things, like those specific tasks have become automated, but every time that's happened there's been an explosion in demand for the output, and so you need many more people actually to do that kind of work even if the specific task has changed.

Yeah, and I, you know, sometimes we change what terms mean, right? Like the term computer now refers to something else, but now we have the term software engineer, and so I definitely think we'll have many more builders. You know, something interesting that I'm observing now is like there's this compression of the talent stack. Like, you know, you still need software engineers today. You still need designers. I'm a PM. Do you need PMs? You know, you could have some fun jokes about that. I don't think you need them. Um, but maybe, you know, maybe when you say engineer, you might be thinking of someone who's like much more full stack, right, than has been true before. Like even if you go back a few years, you had many more places where there was like the backend engineer and the front-end engineer, right? Whereas like now, at least if I think about the Codex team, like there's very few — that's much less the case, and things are much more full stack, right? And so I think this talent stack will compress, but we'll still have people building.

Yeah, yeah. It's my fun joke. I think, well 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 like actually explicitly undefined, and your goal is just to adapt to whatever the team or business needs. And you know, often if you have a bunch of people like say here like trying to build as quickly as possible, then what a product manager can do is spend time like taking a few steps back and trying to look around corners and figure out what to do. You know, collaborate with the folks in go-to-market and maybe be the team's like greatest cheerleader and quality raiser. But like all of those things I just described, which are maybe my current role, could be done by a really strong eng lead or a designer who thinks a lot about product. And so I think it's like often useful to have product managers, but you probably don't want many of them until the team is really large.

For sure. Okay, that's a fun one. I think there are multiple bottlenecks, but that's maybe the most sort of clickbaity one. So, uh, if you don't mind, we'll do this slightly socratically. Like, how many times would you say you use AI today?

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

Exactly. And like I hear things now from engineers like at OpenAI and also outside who are telling me like, you know, I constantly have Codex running. I never close my laptop, and if it's not running while I'm in a meeting, I'm like wasting my time. I need to make sure Codex always has work for me that it's doing. And that's like super cool and super exciting, but that's a lot of work, right, to like manage these agents and make sure they're always working. Going back to the 30 times per day thing. Yeah. Like when we look at how often, you know, Codex users are using Codex, it's like kind of this like tens of times kind of range. I think AI should be helping us tens of thousands of times per day. You know, compute budget permitting, we'll get there over time. And but the problem is like, at least if I think of myself, like I work on this stuff. I know I should be using AI for everything, but I'm too lazy to like type out that many prompts, and I am too uncreative to figure out all the ways that AI can help me. And so I end up kind of at a similar number as you. Um, and I'm, you know, I still am at the point where when I use AI to do something cool like prep for this conversation with you, I'm like kind of proud of myself. I'm like, 'Oh, cool. I managed to use AI in this new way.' But that's fine for people like you and me who are like really interested in this topic, right? But I don't think most people we should expect to, like, in order to benefit from, you know, AGI, should need to like put so much effort into how to use this tool. It should just be effortless for them. And so I think the world we want to get to is one where to use AI you don't really need to like 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's just like knows you, connected to your context, and chimes in helpfully.

Yeah, totally. So I think that it is our job to make sure that we have the models with amazing capabilities, and then eventually to get to a world where this is like highly productized, and so you just have this like magic text box or audio input or whatever, or you can just add AI to your like group chat and it just starts to help. But I think there's quite an interesting in-between stage, and I think that that is actually where the most value lies right now. So here's what I mean. You could try to productize like 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, what is the right form factor. You know, someone was on your podcast earlier, and they said something that I thought was quite interesting about how you cannot adopt AI at enterprise without FDEs. Yeah, it was Matt Fitzpatrick from Invisible AI.

Yeah, I think that's why I think it's the bottleneck. So basically here are the three 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. And also we'll 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. And we're already seeing people start to do this with like the Codex app, like people like, Codex app is built for 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 like productization that you were talking about where you have highly specific features that just work immediately out of the box for people. And I think we're going to speedrun this entire like one, two, three journey in the next months.

I think you're right. If you're trying to go like all the way from zero to one and you have this like — and I don't mean grand negatively here — but if you have like a grand vision for some like ultimate workflow automation system, then yeah, you're going to have to clear through all of these security hurdles, all these like compliance hurdles that are really real, right? Build connections to all these data systems and like systems of record and action. Um, yeah, so 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 like massively underleveraging the potential of AI in like helping that company. Whereas if you can maybe do that in parallel, right? But if you can just give AI to the people like actually doing the work, um, they can start to like 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 just like an analogy or something. Here is like imagine if, you know, you work in like a customer support role and AI is being brought into your role and starting to automate like meaningful chunks of your work, but you've never heard of ChatGPT nor are you allowed to use it, right? So in this world, in that scenario, you have like no intuition for what this thing is. Whereas in a world where actually you've been using ChatGPT for work at the same time as like parts of your work are getting automated by an LLM, you have much more intuition for how this works. And you know, I would argue you feel much more empowered about this idea that it's being accelerated. You have some degree of control to steer like where these automations are built as opposed to like it's like this complete like Ex Machina kind of thing that is quite disempowering. So bringing this back, like 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, every workflow is for a human who is somewhere, right? An employee somewhere, and that employee is accessing that tooling via their browser or via their file system, like at the end of the day, right? And so at the end of the day, everything comes to an interface that an agent running locally on your computer can work with. And you know, I think it's quite unusual. Like in OpenAI, we're building a browser, Atlas, right? And you might wonder why. And there are many reasons why, but I think one of the key reasons is that by building a browser, we can build sort of — and by controlling it like tightly end to end — we can build like safe agentic browsing for enterprise that is a way to access things agentically that are otherwise not yet built out by FDEs.

It's — I mean, the simple answer is it's super important. Um, we...

This is just my opinion, but I don't think we're going to end up in like this kind of monopolistic world. I think there's so much competitive pressure that there'll be like multiple answers to this. But I will say that we have like 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. But even so, like you know, with GPT-5.2 Codex, that model is like significantly more efficient than prior models. And so in the feedback we've heard is that people actually feel like now this is like a very competitively fast model than before. So there's 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. So we recently rolled out a change where in the API like those models are served like 40% faster, and in Codex they're served like 25% faster. So I think like speed matters a lot, and we're kind of approaching it from all angles, like both the hardware, how you do inference, and the model level.

Um, I don't know. I think I struggle with that. I think like, you know, fundamentally in this new world where anyone can build and it is increasingly easy to build things, like what is hard, right? I think having a good relationship with the customer, knowing what they need, is as hard as ever, maybe even harder as it's just like there's just more stuff in the market to choose from. You know, the other things that are hard are like building the right thing, having a really high-quality thing. But going back to the sales and marketing thing, like I don't think that goes away because I think that's just gotten harder as any given market gets more competitive with more software out there.

So like I'll speak for myself and then for the team. I would say like most people that I know are basically not opening editors anymore. Um, and this was a step-function change that happened. It's been happening gradually, but I'd say that the external market touchpoint for this was like GPT-5.2 Codex, where all of a sudden the model was like way better at running for longer, handling tasks end to end, you know, managing its context and following instructions. And so we kind of saw this inflection point, and that's actually part of why we built the app. Um, so you know, broadly I think before GPT-5.2 Codex, the kinds of AI features we were using to write code were like tab completion or maybe you were pair programming with the model. And in my mind, you know, you still needed to be at your laptop with your hands on the keyboard-ish, and like it might go off and do a little bit of work, but you know, you kind of still need to be there and like drive it. It's just like handling these small things for you. And then at the time of GPT-5.2 Codex in December, we kind of switched to like, actually I'm just going to fully delegate this task. It's like, you know, I'm going to do a plan with it, make sure we like the spec that it's going to do, and then I'm just going to go let it cook. And this is quite a different way of working. So it's changing like literally as we speak. And so part of why we built this Codex app that we released last week is because we wanted to build like a form factor or user experience where it felt like very ergonomic to be delegating instead of pairing with an agent, and so like delegating to multiple agents at once. And so even at OpenAI this is changing massively. Um, I don't have a percentage stat for you, but I would say like the vast majority of code is written by AI. And I would say that now probably like most people are not even like opening IDEs. Maybe if they are opening IDEs, it's like maybe you want to own the interface, right? So you'll like help flesh out like the interface between like two modules and then like AI fills it out. Or maybe you want to like collaborate on a plan but then have AI fill it out. The code itself is not being written by humans anymore.

Okay, so the formal definition, right, integrated development environment? I mean that phrase is so squishy that like literally anything could be an IDE, right? So 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. Like for me, I think of an IDE as like 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. So you know, it has a lot of affordances for managing multiple agents, for delegating, for reviewing changes. It has really prominent skills, which are an open standard that are really useful for doing non-coding work, stuff like you know, triaging tasks, or monitoring deploys or something, but it doesn't have text editing.

So there are a few things here. Um, first off, the spec for what you want to do or the plan becomes more important than ever, right? So like think like architecturally, like how should this code work. Um, so you know, we recently shipped like a very prominent plan mode that works a little differently than others, where you have the agent go off and like propose how it's going to do something. It's like quite a long plan, and then it asks you questions about if you agree on how it wants to do it or if you want to have input. And this is very similar to like if you had a new hire who was new to your codebase and, you know, they had to present a sort of a request for comments to the rest of the team before they started doing the work. So even though that's not formally code review, I would say review of the plan is actually something that's becoming more important because we're entering more of this like delegation phase of working with agents. So that's an underrated thing. Um, then okay, 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 like a lot of AI slop. Like people will just be submitting PRs to these open-source repos and they're trash, and like maybe the person submitting the PR hasn't even tested them or definitely hasn't reviewed the code. I think this is a problem. And so a common practice with Codex is to have Codex like review its own PR or its own change. And Codex is actually incredibly good at this. We've explicitly trained the model to be good at code review. Um, and you know, that included things like making sure it's like really good at creating like high-signal feedback, so it'll like basically have few false positives of criticism, which means you can really trust when it has feedback. And so not only do we encourage people like on the team and elsewhere like to just ask Codex to review, you can then also set it up to just like automatically review. So like nearly all code at OpenAI is reviewed by Codex automatically whenever you push it to a repo. Actually, like one fun thing for people who haven't tried Codex yet or didn't try it recently is sometimes the way that people like see how good our models are is by asking Codex to review a different model's code, and basically they're like, 'Oh shoot, I should probably just be using Codex to write my code in general.'

We've taken this like kind of counterintuitive approach with Codex to just build it super openly. So like the Codex core harness is open source, and we're always trying to make it easier for people to switch. So for instance, when we first launched Codex last year, we created like — I mean, 'created' is even a heavy word, it was just we just established a convention which is 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 can use, and pretty much every agent except Claude uses AGENTS.md, which is awesome. And then just last week actually, we helped push for putting skills, which are a standard for like giving the agent instructions and scripts, we pushed for those to be stored in sort of a neutral-named folder called agents instead of in like Codex or something. And again, everyone has jumped on it except the usual suspect. So I think it's really great for the developers to have a lot of choice, and we're trying to make it even easier for people to try different things. Now that said, I think these coding tasks, right, where you're asking an agent to write some code, they're quite hermetic. And what I mean by this — because you can — it's like, or maybe an analogy in TV would be like episodic, right? Like you can come in and you've got this like open-ended like agents file that like any agent can read from. You've got these skills that any agent can use. Um, and you can ask the agent to write some code and it produces a patch, and that patch goes into Git. So kind of like both ends of this are pretty neutral, vendor-neutral. So very easy to move between for now. As agents start to do work that is not writing code but more general work, again for software engineers or beyond for any builder, they're going to need to start interfacing with other systems, right? So as they start, maybe your agent is talking to Sentry, right, or it's talking to your Google Docs or something, then I think these agents become much stickier because actually deciding to connect an agent to that system is a sticky decision. And if you're an enterprise really trusting that the agent is going to have access to these tools, but there are really good secure guardrails and sandbox and like controls over how the agent works with these systems, I think is critically important. And that's not something that you're going to want to do multiple times. And so, you know, we've been kind of building Codex knowing that this is coming. Um, and so we have like the most conservative sandboxing approach. Sandboxing is kind of like a set of controls, OS-level controls over what the agent can do. Um...

Yeah. I mean it's interesting because I think on the one hand like we think about this obviously we're running a business, but you know our mission here is to like ensure that like we safely deliver the benefits of AGI to all humanity. And so something that's like unintuitive to people about like the Codex team...

Our job is the distribution of intelligence, right? Um, and so we're obviously building out Codex, and this is really unintuitive to a lot of listeners, but like we put all this effort into training these models and then we serve these models to our competitors, right? And from our perspective...

Yeah, I'm totally aware of this. Like where OpenAI is like a really interesting and unusual place to work. But basically, because we're playing such a long game, for us, like if the competition gets better, we learn. It's actually helpful for us. And so we're pushing really hard at growing Codex and finally growing...

Yeah.

I don't think so. Like for example, there are a bunch of recent launches. Like even today, I literally just like quote-tweeted a thing this morning about a launch from Warp. No particular affiliation, right? And there are a bunch of cool ideas in there about how they like framed up the way that their agent can work in the cloud at the same time as working locally. For me that's like inspiring, and I think I see all these things from various companies. And like one of the coolest things about the space is it's like we're all kind of inevitably reaching the same conclusions together and then building things out. And so you know, on the Codex team, I think we have some massive advantages, right? We have the massive distribution advantage with ChatGPT, we have the massive like 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 like no one else has early access to those. And so 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 you know, again, we serve our models to everyone, where we push for open standards so that everyone can use like all the things that we're pushing for as well.

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? And in order to achieve that, we then need to build businesses to generate revenue. And also that's something we've — that's really interesting we noticed with having the Codex team, which is a sort of combined team of research and product, is also by building these successful products we create a lot of pressure to improve the model in sort of 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. And like I was saying earlier, I think we really want to build products for individuals and then allow the like people to become fluent in those products and then like pull in automation. And I think that may be counterintuitive but will result in way more impact than anyone purely approaching it from like the enterprise workflow perspective. Um, so you know, I think that's mostly a question of product execution, and then that works for say like prosumer. When it comes to enterprise, the go-to-market side is really important. Like something that I've learned the hard way is if we go to an enterprise and we're just like, 'Hey, we're here, like feel free to use this stuff,' that doesn't work. There's actually quite a lot of education that needs to be done, and there's a lot of like configuration that we need to support and sort of like education of the broader team. So like 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 like propagate that mechanism of operating to the rest of the team.

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

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

I think daily active will be better soon. Yeah, we just happen to use weekly active. It's like a standard here. And I think as we were getting started, it made sense. But I actually agree with the criticism there. It's like we should probably just be daily. Like 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, you know how like with Google search it's just like, okay, anything I need to do I just like go into this text box and I can navigate to the right location. Then you have ChatGPT, it's like for any information I need I can go into this text box, type it out, and get information that helps me. And I think the next phase that we'll see this year is like for any task I need to do, as opposed to just get 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.

The simple answer is yes, but actually I think there's two components here. Like if we just imagine the future, like just let's think of some sci-fi movie, right? Like what does AI look like? I believe that sci-fi is a really good predictor of what the future should look like. And usually it's pretty simple because it's a story. And I think simple is usually right. It's going to be some just like 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 like my coding AI and then I have this like different place for my like sales AI and I have to like be like, 'Hey, I'm now talking to sales thing' and like do that. It's just like 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 conversational interface will be sort of the pillar of everything that you can talk to about anything, um, and that you can add into any group chat or whatever so it can like discover how to help you. But then if you're like 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 can only work by talking to them. That's like super annoying, right? So at some point, you want to get to the show notes and like look at them yourself and like edit them yourself, right? You want to edit the thing yourself. So I think we'll pair chat with like functional like graphical interfaces that are bespoke to like what someone needs. So like in my case, I will probably chat to like do my, you know, podcast prep. But when it comes to like actually looking at product and code, I probably want like the Codex app that I can go into and get deep in.

Whereas maybe if we're talking to a marketer, maybe that marketer will like 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 like a super custom GPT for like ad analytics or something that they go into.

My quickest answer to this is that like 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. So like when people ask like, oh, how can I make my codebase more efficient for the agent to work with? The answer is often like, well, have you looked at it yourself and is it easy for a human to work with? So like a very specific example would be like running tests in a codebase. Naively, if you just set up most test runners, they just emit all the outputs of all the tests. And so like 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. Turns out that's terrible for AI as well. But if you filter it down to just only emit the failed test, better for humans, also better for agents. So probably the agent-to-agent interaction points will be very similar to like if there was a human in the loop and that's nice because it means you can kind of atomically replace individual systems.

I definitely don't think they have a significant advantage in terms of data on coding. I think that from what we've seen, and I would defer to my research team on this, but I feel like we have plenty enough data to build really good coding models. I actually think the place that's more interesting for getting data now is like as we get into like knowledge work tasks. That's kind of data that's not really available most places on the internet. And so you start to have like really interesting brainstorms for like 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 they're Slack or something. Yeah, I think that kind of knowledge work task distribution is much harder than coding.

Yeah. I mean, I think the way that we think about these things is just like how do we move as quickly as possible? And so, you know, becoming able to set these things up in-house is very expensive in time and we're a small team. So, 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.