Alexander Embiricos

So, well, I think the place that I'm interested to start, just looking at the trajectory, the big memory I have in my head is being there, the night before the GPT-5 launch.

Mm.

And I feel like I was trying to politely say to you guys, it's cool, but it feels like it's built for pair programming, and—

This is Codex or GPT-5?

Both. It's like the Codex version of GPT-5 and the way that people were using Codex. And the way that it was being even marketed. It was very pair programmer-y, and I was like, there's this thing called Claude Code and compound engineering and blah, blah, blah. I'm curious, what your memory of that conversation was, how you were feeling then, and yeah, just starting there.

Yeah. So I would say for me, GPT-5 was actually a really big deal and a really positive moment because I would say that before GPT-5, we were incredibly far behind on coding models.

Mm-hmm.

A little bit of the history of models here is, when I was working on coding... Well, you heard a little bit of my backstory sometime in the past. I was working on, how do we make the models useful?

Yeah.

So let's build a desktop assistant, let's build a browser. And basically my bet was that multimodal progress would be faster than I anticipated. And maybe model progress generally, but especially for multimodal inputs. And that wasn't the case, and even as they got better, there was latency issues that maybe we could have predicted, but we just hadn't.

And why is that relevant to the making models useful coding stuff?

Okay. Because for me, a lot of what we need to do to make a model useful is we need to let it work with your con... This is so obvious today, right?

Yeah.

But at the time it was like it needs to work in your context.

Yeah, yeah.

It needs to do stuff for you.

Yeah.

Which means it needs to use your applications.

Yeah.

So this is more just my personal journey.

I get it.

And so then we get to, we kinda realize, hey, the rate of progress for coding is really dramatic. Let's lean on that. And so I start working on coding products, and—

And this is pre-GPT-5.

At this point—

This is way before... where are you at OpenAI?

Yeah.

Yeah, yeah, yeah. Okay.

So I worked on ChatGPT Desktop, and then I helped start Atlas as projects, like, two years ago.

Okay. Got it.

And then I think this is late 2024.

Mm-hmm.

We have our reasoning models coming out. There's a ton of progress. Super exciting. My first—

Like an O series?

Yeah. The first feel the AGI moment for me, real massive feel the AGI moment was I saw someone running a reasoning model that was connected to a terminal. I know, again, not exciting now, but it was like— I mean it, yeah... it was fucking cool.

Yeah.

Right?

Yeah.

So then we were starting to work on products to ship.

Yeah. Yeah.

But I think the really salient part that's interesting, even this, we'd have to frame carefully, but basically, we didn't, in my opinion, have really excellent coding models compared to the competition at the time. And so we really predicated our product—

This is pre-GPT-5?

Yes.

Yeah. Yeah.

Around long-running models.

Yeah.

And so we shipped Codex Cloud.

[Codex Cloud] was really just like a product built around a model, and a model research direction of asynchronicity. So we've kind of been oriented around this idea that like you need to start with like a slightly more interactive experience, but didn't really have the models to build it with, so we went with this asynchronous product. Thus, that was Codex Cloud. And Codex Cloud was actually, it was this very cool spike when we launched. Everyone thought it was a great idea. I still think it's a great idea, although I would build it... We're gonna get back to that, and it's gonna look completely different.

It seems like it was like a too early thing rather than—

Yeah.

Well, it's too early and incorrectly done.

Yeah. Oh, interesting.

So the TLDR is that. It was too early because the models weren't smart enough. I would say the models today are smart enough to build Codex Cloud.

You said they are?

Yeah, yeah, yeah. But it's—

To build Codex Cloud?

Yeah, yeah.

Or to make it useful in the—

To make it useful enough. Yeah. It's super clearly there already. Then there's actually two product points that need to be considered. The first is that Codex Cloud was rigidly asynchronous, and it was very annoying to get the work down from the cloud. What we are working on now is making it so that there is no rigid distinction between cloud and local tasks.

Mm.

All chats are just like chats. There's no like... There's not a cloud or a local Linear issue, right? There's just issues.

Yeah, yeah.

So all chats are just gonna be chats. The reasoning loop will actually be running in the cloud. This is already partially true today. It's already partially true today.

This is so fun. I'm like, I love my life.

Yeah, me too. I have those moments like weekly. So you already have the engine. Right? And then you have like some server component, right? And then maybe you have some connectors with like, say Slack as an example. Right? And then you have your computer, and your computer has like Bash or whatever, right? So like today, when you use the product, you're already kind of having... Like you spawn this thing, and then at some point we decide to hit the engine. Right? It comes back to us. We're like, “Oh, should I run... What tool should I run next?” And then it might decide, okay, let's tell the computer to run a Bash command, which might actually call Slack.

Yeah. Yeah, yeah.

So and then again, we get this back, and then da, da, da, da. Right? And so we actually run the... This is running every time. Now obviously if we wanna run a Bash command, then okay, we need to get all the way down here. But actually, it would make a lot of sense to skip hitting the computer for a lot of these loops, but the loop is here right now. And it actually—

And it seems like the problem though is that it's much easier... All my stuff's on my computer already. So I don't have to go like install Slack.

Yeah. Well, so today this is where things run, right? And for simplicity, the loop is running on your computer. Which means that at minimum, even just for thinking, we're coming all the way down to here and up. Right? And then when we have to run a tool, we're happy we made it all the way here, 'cause this is like zero latency, right? But another way that you could do this that would make a lot of sense is you could say, let's actually run the loop here. And so when you're just thinking, you're just doing this, right? That's it. When you want to hit a tool that is not on your computer, such as a connector, why should that live on your computer?

Yeah, yeah, yeah.

You could actually give... So we're—

This is gonna be really good for my CPU usage.

Yeah. So we're gonna have a node REPL running here, and that's just so that we can compose things. You're not doing all the work. It's not mental math. It's like you actually can write code. We'll just go here, right? And increasingly, a lot of stuff will be hosted to the cloud, and if we need to run a Bash command, then we can go hit your computer and do this, right? So the latency doesn't get any worse if you're doing work on your computer. The latency gets better whenever we're not running a Bash command.

Mm.

And now we have this computer, which is your laptop. You can close your laptop. The thing can keep going. It won't be able to run commands, but models are smart. It'll figure it out.

Yeah, yeah, yeah.

So you could do a coding task and then later you have a question about it, and you could like, “Hey, why did you do this?” It doesn't need to run a Bash command to ask that.

Yeah, yeah, yeah.

Or it could spawn... this is computer as a service. We could spawn a container for whatever we want. And which brings us to the second thing. So the first product problem was the rigidity of cloud [versus] local. So actually with this green diagram I just drew for you here, there's no longer a distinction between a cloud task and a local task. Like all tasks are just running the loop. There's also a database now that lives in the cloud.

And either have access to your computer or they don't.

It has access to the computer or not. That's all.

Yeah, yeah, yeah. That's very—

It's like if you run Linear on desktop, maybe the desktop have some features that are not.

Yeah, yeah.

So it's obviously in this case, you're gonna run the app most of the time. But you can also close it and it doesn't matter.

Yeah, yeah, yeah.

And this is gonna be great for automations, right? Like, oh, check my email, whatever. You check the email. You can continue the same conversation with your computer open. And then this means that we can support bring your own box. So if you're a big enterprise and you can only access dev dependencies on VPC or whatever, then we can also hit this thing. And so these things here are called executors now. So a lot of this work is actually happening on open source.

Yeah, yeah.

But this is where we're going, and a lot of it's actually in open source, and it's gonna be a really cool blog post.

That's sick.

And we're hoisting the whole system. So that was—

You're hoisting the whole system?

Yeah, so we call this... we view this as like today the loop is here and we're hoisting the system to the cloud.

That's a good word. I haven't heard people talking about that. Is that like a thing now?

I don't know.

Or you just coined it just now?

No, at OpenAI, we've been using this term. I don't know who coined it. Hoisting? Hoisting.

Hoisting.

I haven't heard that.

Hoisting is just pulling something up, right?

Yeah.

So if you go and look at open source today, you'll already notice that the loop is being separated from the executor. We call this the orchestrator, actually. The orchestrator is being separated from the executor in open source today, but they still both run locally on your computer.

Yeah, yeah.

And we'll still always support that 'cause you might not want stuff in our cloud, right? But then we'll put that up. This is a very hard infrastructure project. It's taking us a lot of time.

I bet.

But I think in this space, it's really hard to decide when to go do something like this. Because we wanna run automations in the cloud today, right? How do we do that? We could either do this, which would really unlock things and I think be a giant leapfrog. Because this takes months to execute. Or we could just go build a new standalone product, with its own page.

Yeah, yeah, yeah.

That is a really interesting question...

And if you wanna look at our growth chart, this was Codex Cloud launch. You know, obviously at the time, the scale looked like this on the chart, right? But so it was like this, maybe, yeah, kinda started out with zero. So we had some real usage, but not by OpenAI standards. And then GPT-5 happened, and it just started doing this [points up and to the right], you know? And at the time it looked like that.

That's usage of Codex Cloud specifically?

This is cloud. This is the cloud era. This is the GPT-5 era.

Yeah. GPT-5, but when you say usage of what in particular?

Oh, sorry. Of the CLI.

Okay. Got it.

That's the product we ship. It just looked like that, right? And then we shipped the IDE extension, which looked like that. Like, again, the chain. And then we had 5.3 Codex, was like this very significant model leap for us.

Yeah, big moment.

5.3 Codex, and then an app. And so then now all these lines look very low now, and it's kind of up here. But that's kind of the journey for me. So yeah, we can unpack it later.

That's really interesting. Well, I wanna get into... Okay, at least from my perspective being outside of the company, what I felt was, let's say the GPT-5 launch, or around then, it felt like there was this split between: professional engineering happens in Codex, and then if you're vibe coding stuff, you should do it in ChatGPT, and you should use the canvas and the artifact stuff. And part of the problem with that is, the bet that Anthropic made with Claude Code was like, if it just has access to your whole computer and you can just delegate tasks to it, that creates all this power and flexibility that compounds because it's on your machine. You're not spinning up a new VM every time, like whatever.

Right, right.

And I was like, that the GPT-5 as a model felt like I was able to use it less well because it wasn't on my computer in that way. So I'm curious how you were thinking about that, and how you were sort of seeing the Claude Code stuff and your strategy relative to that. And then I wanna trace it from there, 'cause 5.3 was the point at which I was like, “Oh, I think OpenAI gets it.” I think you guys, you've figured it out. And it sounds like part of it was the model felt like it wasn't quite right, but I also felt like the harness and the harness strategy was not quite right.

So yeah. So there's a few layers to this. I would say that we took a hard pivot after this.

Mm-hmm. After Codex Cloud?

Yeah, after Codex Cloud. And I would say that this idea of, hey, we need to build a very flexible primitive that runs on the user's computer and that people can use as interactively as they want, and in fact we think people will start using it very interactively and then kind of onboard a teammate, they will learn how to use it less interactively. That became our strong product thesis and the strategy we started executing against in August.

In August, okay.

Yeah. So look, obviously it took us some time to realize the strategy, right?

Yeah, yeah, yeah.

But that's why we were building CLI. We had this idea of, it's open source. So funnily, by the way, we actually shipped the CLI even before Codex Cloud, but that was a very small side project, done heroically by two people. But around this time after Codex Cloud, like August.

Like it'll get it right more than Claude will.

You couldn't even use the Codex model in the CLI.

That's interesting.

As a company, we have a very conservative safety stance. And we actually had to do a lot of work to figure out how to get comfortable deploying these, that level of capability.

Mm.

So initially you couldn't even use this really capable model in the CLI. You had to use, I forget what, maybe o3. I just don't remember. But you had to use some other model that was just not designed for that purpose. But around the time of August is when we were like, "No, we're gonna bet really hard on the CLI and the interactive coding form factor." And basically our journey is gonna be—and this has been the product strategy that basically we've been executing against—okay, so I don't know, the title's probably Agents. And we're gonna start with ... Here's a two by two.

But it's good. I'm gonna ... When things are good, I give them credit. So it's like dev, non-dev. And then it's sync, async. And it's kinda like, all right. Shipper: [laughs]

That's a good breakdown, yeah.

We're just gonna start here [the dev, sync quadrant]. Right? And then we're gonna kind of move this way and also move this way. But you have to land here. Like both—

Why?

So—

'Cause you would imagine one way I could say is well, to be really good for devs, you have to be so smart and so good that we should start with consumers.

Yeah. So there's a lot of reasons that I think developers are the right place to start. And I mentioned this a bit during the talk, but I don't know if you arrived yet. Basically, I think that they as an audience are very interested in trying new tools. So you're just gonna get a lot more adoption. They are interested in trying open-ended tools, and they will figure out how to use it. They provide... They're, in my opinion, they are the best audience for providing actionable feedback for something that's still early. And then you can figure out how to productize from there. You can put a feature deep in config.

Yeah, yeah.

I think the second thing is actually that the tasks are way easier to build for. So coding tasks, first of all, okay, so this is a fun thing, right? Developers—

Coding tasks are verifiable.

Yeah. Coding. So first of all, developers, there's this old stat, which I don't have a citation for, but I'm sure we could find it, they only spend 30% of the time coding, and then they 70% of the time spent not coding. And I would say that actually it's now that we delegate to agents, maybe it's like 90% of the time is spent not coding. And so actually, developer software engineering work looks very similar to knowledge work. But let's start with the coding tasks. The interesting thing about them is they're verifiable. There is an existing place where the human is in the loop, right? I talk to a lot of enterprise customers today, and they're like, "Hey, we have like a regulated workflow. How do we make sure we trust the agent?" The truth is that a lot of coding is regulated too. It's just we already have established human practices. It's called code review. Right? So we already know how to do this—

Yeah, yeah.

for developers. Also, coding tasks are hermetic, right? You can do a coding task in a sandbox — and you might actually disagree with some of this, but you can do a coding task in a sandbox without access to the internet, and it'll work pretty well, right? Maybe, okay, some amount of testing and things will need sandbox access, but as you're getting started, you can literally limit it to a folder on your computer.

Yeah, yeah.

It can do its job. As soon as you get outside of coding to knowledge work, every task has a side effect on the internet. And okay, maybe only read actions. It's actually, there's no clean way to know if something is a read action. And actually, there's also no such thing as a read action on the internet. Everything has a side effect even if you get the task.

There's a very quantum physics thing there, where it's like you can't read something without modifying the world, you know? Yeah.

Exactly. Yeah, no, 100%. Right? So you have to think about the audience, the sort of the safety question of performing the tasks, the level of side effects, which is also a security question. And I'm missing one third point. Let me see if I can find it. Task specificity. Right? Basically, my view is that we are gonna progress. Actually, there's non-dev, and then there's straight up consumer. And so non-dev here includes there's work productivity, and there's also life productivity. I would put those both in here. Straight up consumer is like I don't even know what I want, right?

Yeah, yeah.

So also the specificity of the task you get is quite high here, and a developer knows how to change how they're specifying to give you what they want. Here [non-dev], the task specificity goes down. We actually see this. It's like less clear what I want, and then eventually we're gonna get here where they don't even know what they want, and we have to be useful. So that's why we want to start there, and kind of productize our way through.

That makes sense.

So you can start with this very natural strategy. We're gonna start with CLI, super open-ended, and see what people do with it. Very quickly we're like, we should build a great IDE extension. And then that became our most used surface, so we disrupted ourselves kind of, which is kind of crazy. And then the app actually now is the most used thing. And so I talked about this a bit earlier as well, but for us, moving to the app was a big part of how we got to ... It was kind of two things actually. The app helps us transition from sync to async. And it also helps us transition from dev to non-dev. Eventually when this app is running and we have this new architecture here and we're running the task in the cloud, the app will feel very ergonomic for that. You won't even care or know that anything changed.

I don't know how much you can tell me, but what did you figure out or what changed in the model that let you be like, “Okay, we can get to this point where it's gonna be okay for synchronous work, and it's gonna be okay for non-devs”?

Now it's working really well because there's a flywheel, right? Once we ship the CLI and GPT-5, well, mostly GPT-5 with the CLI as a light wrapper around it, it was just like it created this self-fulfilling flywheel—

Yeah. Yeah.

Of just people being really excited to work on this stuff, and obviously now we've climbed way further in intelligence. So the change, from my perspective, was that there was a researcher, Michelle Pokrass, who was really interested in pushing on this, obviously working with us, but mostly she was working with other customers we had that were asking us to improve our interactive coding capability. And so we were able to leverage that momentum and then ship our thing, which very quickly actually became a really significant user, and then the biggest user of these models. And then grew it from there.

So there's this really interesting thing that I'm observing that I think you're one of the most interesting or best examples of, which is, it's about how to do product strategy in AI as the models get better, and you use the word, like, reconstruct it ourselves, where it feels like every time there's a jump in models, there's a new way of bringing it to users that becomes important.

Mm-hmm. Mm-hmm.

And then your old surface, you have to figure out what to do with it, and there's different ways to figure that out. What it seems like you do is you have maybe parallel bets going on. You tell me if I'm wrong. You have parallel bets going on. When something works, you pour a bunch of energy into it, but then what happens is the models advance, and it is better to have, for example, with Codex, you had this new surface that you could play around on. Both a model line and a product surface that you could then move faster on to explore these new capabilities 'cause you're not held back by supporting the big thing that's already working. But then you launch it, and then you're like, “Well, what do I do with this old thing?” And so there's this interesting weirdness with you're building these products. As soon as they start to scale, they're also at risk of, you kind of have to disrupt yourself with something new. But then you have to figure out, does that new thing... For Anthropic, what they do is they just put it in a tab. So it's like, is the new thing a new product, or is the new thing a tab on the existing product? Talk to me about, you've touched on this a little bit, but I'm curious, where you started in thinking about how to do this and where you are now, and what do you think the best practice is for thinking about those decisions?

Yeah. I have to think about this a little bit. It's a great question. It's a very difficult one. I think to do a good job, you really do have to be trying to think in the future and sort of think ahead about what's going to work. And to the extent you can, it is far better to extend something that you have, if it can take advantage of the new capabilities. And then sometimes, through luck or lack of foresight, you will have a thing that just doesn't quite scale to what you need next, and then you have to go out, make a new thing. But that always introduces challenges, mostly for, I think for our users.

Mm-hmm. Yeah.

'Cause then they have to understand more stuff. So for instance, here's an interesting example. Like the Project Atlas, the browser. We had a lot of conversations about whether we should build this as an in-app browser for ChatGPT, or whether we should build it as a standalone browser. And there, the guidance, it's quite funny. I remember thinking we should build an in-app browser. But I could get behind the standalone browser too. But they're kind of different products. We had a pretty big steer on this, which is like, “Hey, I would love for you guys to at least explore building a standalone browser. Just at least explore it so that we can see just what happens if we're completely disconnected and open-ended. And then let's ship whatever's best.” So that was at the time that I was working on it. And then I stopped... I moved to Codex, so I wasn't there when we decided that, okay, that was actually the form factor to ship. But it was a very explicit guidance, like, “Let's give the idea as much room as it can. And then, if you decide to ship an in-app browser at the end of the day you can go for it.” So that was quite interesting there. I think in the case of Codex, we felt like when we were shipping Codex Cloud, we actually built it into ChatGPT as a tab.

Mm. Yeah.

'Cause it kinda made sense—

Yeah, yeah.

In there. But the moment we realized that we wanted to ship this, we adjusted our strategy. We're like, "We're gonna ship a very flexible tool on your computer." We realized that bundling that into ChatGPT desktop would just be kinda crazy. It would just be weird to understand how to use the product. It's a very different audience. So even though now we plan to bring all these capabilities to ChatGPT, I feel like for that idea to have room, it needed breathing room and it needed to be a standalone thing that you install with npm install or whatever, right? So there we had to go separate. And I think looking back, there are certainly some decisions that I would have loved to have made, to make it easier to bring them back together. For example, we built a really strong brand around Codex with a lot of investment.

But I guess my point is there's certainly some decisions we could've made better there, but I think we needed to create room for separate products. Now, if you look at the Codex planning, there we've been very oriented... An overriding principle we've had the whole time, that for me is a key thing in designing for AI, is we are building one agent, and actually we spend a lot of time talking about the agent and not the product. And often when I'm working with someone who hasn't been thinking about Codex as long as me, and they wanna talk about product and they start talking about all these features they wanna build, oftentimes the feedback I give is like, "I mean, these are very cool, but to me it feels like you're building product, but we shouldn't be building product. That's not our job."

Mm.

"Our job is to build an agent."

Mm.

We have to productize it. Yes, it is ultimately a product for users. Yes, ultimately it is a business that earns revenue for our company, but the way we should think about it is actually we're designing an agent.

Can you give me a concrete example?

Yeah. So I think in product land... These are nuanced, right? And maybe there's better words for this, but in product land, you use UI affordances. You put a lot of scaffolding around the model. You just do whatever you need to solve the user's problem. In agent land, you think much more about primitives, and you leave a lot more up to the model, and then your job is just how to make it ergonomic for the user and the models collaborate. Right? So for instance, let's see. Here's an interesting example: how to decide when to open the in-app browser, right?

I'm not saying these were super deeply thought about for a long time, but briefly some people were thinking that we should have some rules for when we open in-app browser, and you would write those rules in TypeScript.

Oh, interesting.

You know, like, we would write those rules.

Like code rules, not like prompt rules. Okay.

And I think to you and me, that is obviously the right way to do it, right?

Yeah, yeah.

We should just let the model decide.

I think the model also wants to do that by default. The model wants to write code for itself 'cause it thinks that that's what engineers would do.

Yeah. That's interesting. That's really interesting feedback. I need to think about that more, but you're probably right. So we're like, "No, we need to leave that up to the model," right? How do automations work? There's loads of ways you could try to do that. But at the end of the day, if you can keep it super simple and it's just like, "Hey, here's a way to schedule a task. It can be repeating or not repeating," and you can just let this be a primitive that the model can use, you do better. Another example would be, currently I think the UI in the app around Git workflows, it does its job for some people, but it does the job that we designed it for. So there was a lot of onus on the human designer, and that human designer was designing for some people, and that's not all people, right? So I actually view that as an area of improvement for the app. If that was more just model orchestrated, then you could create all these different workflows that people end up doing anyway, so just tell the model to use Git in the command line.

Mm-hmm.

So broadly, the way we think about the agent is you have to have very clear layers. So okay, model coming through the Responses API, open source harness. This harness we need to do our best to keep as simple as possible, and then have the right primitives for extensibility, and you let the model orchestrate as much as possible. So things like computer use, core capability people talk about all the time, built as a plugin. The browser use, that's also a plugin. Both of these plugins use the node runtime that we have to be able to execute code, local and computer. So that's a core primitive that you can take advantage of. A lot of the new things that we're building now we've forced to go through the plugin path so that they can maintain arm's length from the—

Mm.

From the core agent loop. And then if we wanna render UI, we also try to avoid, we try to be... I think we could do an even better job of this, but we try to avoid... You wouldn't believe how many teams want to add UI to the app. How many people, how many PRs we get for different things.

Sure. I see.

Yeah.

And we were kinda like, "No, we need to really avoid adding UI to the app." But we need to think about how to make sure that the app is extensible so that if you want to render UI as part of your thing, a plugin can be the way. Now the running joke is that Alexander goes around telling people that they're building plugins. But my point is more we need to really keep the core action loop simple, and then most things that you would normally go build should just be done as plugins. And generally speaking, we should try to not add too much between the model and the user. Sorry, a bit of a ramble. Shipper: [laughs]

So I think the Codex team and in particular, Tibo is the lead for the overall Codex team, we've done a really good job of just creating a team that has really clear conviction on what we're gonna do. Is willing to say no to a lot of side quests. And just move with intensity towards this goal.

Is there anything else that you wanted to get in that we haven't talked about?

So no, I think I just... We spent a lot of time talking about how we got here, and I think there's a lot of interesting stuff. 'Cause now I basically feel like this year, since Feb when we finally got the app out, I think the world can kind of see where we're going, and it's like finally things are starting to make sense. Like, oh, why is the team... I mean, you could critique this decision, by the way, but we have explicitly not invested as much in the CLI, and you can feel that, you know? And I still can easily counter-argue that decision. Because a lot of people who compare us to Claude Code try the CLI, and they're like, "This is worse." And I'm like, "Oh man, we need you to compare the app." Shipper: [laughs]

And then people are like, "This is better." So we need to reverse that narrative and stuff. But anyways, I don't know. So I don't have anything specific to say other than that we should definitely make sure we talk about how does that journey kind of ultimately get us back to some of the founding principles of the team, which were like, when we built cloud, we were like, "We're gonna build you a teammate that lives in the cloud and constantly does work for you." And now I feel like the pieces are all coming together, and it's gonna happen.