Andrew Ambrosino

I always like to check. Where do I even start? Okay. Katie actually just said something that I think is really interesting, and I would love your take, which is Anthropic just came out with this new model, and I still don't use it every day because it's not in the Codex app. And we have this—

Many such cases.

I think there's this underlying feeling that models are all that matter. And for sure, I guess, there are cases where a model jump is so big and so important that even if the harness sucks, you'd probably still use the model anyway. But harnesses seem to be becoming more and more important. Tell me about that and your perspective as someone who's focused on the app.

Yes. Many such cases. I see this feedback all the time. And I think one of the great successes of Codex as a team was pairing the product team and the research team together very closely, especially when it came to the harness, right? So we do training on the harness now. We use the harness for far more of our products, including upcoming ones. The Workspace Agents products that we have out uses this. And then it's not just a harness, it's also how the app works with that, right? So we don't necessarily have the concept of, like, open the browser tab in the harness, but the harness and the app work together really well to do this. There is a bit of a meme of model jumps stop mattering to you when they are smarter than you and you don't notice anymore. But I think it's sort of true and kind of funny. But the big deal, the big jumps that I've seen have been when it's easier to get more context to the model, especially automatically, which is app, it's connectors, it's computer use. When the model can verify more of what it has built or what it's done, right? So when it can click around in a browser or on a computer, right? Like, that to me has been, depending on the task, bigger, equal or larger of a jump than model jumps. And this isn't to say that we're not working on new models. We always are. But I think that's why you're seeing some of the feedback on this.

Why do you think people don't understand that?

I think it's a more boring topic. It's less new. It's like what software has always been, right? It's like the same thing with the terminal on prior eras of this. It's like, oh, yes, you can do more with the terminal. You hear this all the time from developers and such, but there's a reason why operating systems and browsers and applications have been the way things get to mainstream, right?

Yeah. I was just talking to Tibo about this, so I'm curious your perspective. When the Codex desktop app came out, it was at a time when TUIs were so hot. Can you just take me into the room of deciding to make a desktop app for Codex?

Yes. It was a very small room. It was a big room, but small group. Shipper: [laughs]

How many people were on that team?

We started with, like, three people.

Okay. And what was the breakdown of who did what?

We all did everything.

So—

I mean, we've heard exaggerated claims of role collapse in the industry. And I think, to extent they are a little bit overblown, but on the Codex team, role collapse has happened faster than the rest of the company. So designers are technical, and our engineers have product mind. So we had, I think there were four people. If you looked at the original team, it was two engineers, one product manager, and one designer. But we all kind of did very similar work in terms to—

How about on the research side?

On the research side?

'Cause I thought there was research together with—

Yeah, I mean, we were piggybacking off of the same harness that the CLI used, right? And so there was active research, and if you remember, the time of app development was, I think, mid-November to when we released it in February. A very special time in coding models research, right? That's when everything seemed to hit this inflection point. In fact, we often say that if we had finished the app to the quality it was in November and not in February, it would've been unreleasable because of the quality of the models at that point.

Hmm. Yeah.

It's like the models changed enough during—

Yeah, yeah.

this course of time that you could actually have an app that you weren't editing the code by hand. So back to the inception, so there's a room with four of us or maybe a little more if you count Tibo and such. And we didn't really know what it was gonna be. There were a few examples out in the wild of lighter weight things that were not IDEs.

Like Conductor?

Like Conductor, yep. We know Charlie — that's a great team over there. They have done great work. We knew that we wanted a surface that could be a daily driver, but that was more lightweight than an IDE, and that we could surface things that were not typically done, like we ended up doing with our plugins marketplace and putting a browser in this thing. And we kind of had the idea then that we would do this stuff, but we were trying to figure out, what does this look like? We spent a lot of time on the worktree model, we spent a lot of time on really basic things like how the sidebar's organized, how is your work organized? 'Cause it wasn't really — there was ChatGPT, there were the IDEs that had kinda started to dabble in multi-agents, but still, you look around the industry and everything looks like the Codex app now. But at the time, it was like all of these questions were still brand new. And I don't think we get it all right, which is funny to see people do the same thing that we did, even the things that we don't like. But it was interesting. Along the way, we had a few moments. One of the moments was when Antigravity came out, and we just kinda looked at each other in the office and we were like, “Did we make a huge mistake by not forking VS Code and trying to do our own thing?” And we felt very conflicted on this, and I don't think the team even agreed with each other. And we said, “You know what? Let's sit on it.” And we decided to commit and keep doing it.

This is before it had come out?

Before Codex had come out?

Before Codex had come out.

And was it being used internally at that point, or a little bit before?

Somewhat. Yeah.

Okay. Yeah.

The dogfooding story, I think, is incredibly important. And I think people have pointed out that you can feel the dogfooding of the Codex app in the way that, some of the competition, you can kind of feel that they don't use it. Our first mandate was that the team needed to get this into a place where it was our main thing day to day, right? And just the four of us. Once we did that, every day Alexander would come in and be like, "Let's go around the table. Are you maining this app? Are you maining this app?" And the answer, it was a full nos at first. And then as the time went on, it was like, all right, one person is now maining the app. One person—

You call maining, like, I use it as my daily driver? Yeah.

I am not opening VS Code. I am—

'Cause you build it from nothing. It can't do anything, and then all of a sudden it hits. And so once we were all yeses on maining the app, we released it to the company. And we said, "All right, if we can get PMF internally, then this is something we can release." And if we can't, then back to the drawing board. And then we got there, and now I think, if we need numbers, we can set it. But I think now 90% of the company uses Codex. Not 90% of engineers. 90% of everybody.

Yeah, yeah.

And then when Antigravity came out and you were looking at each other, how many of you approximately on the team were maining the app?

At that time? It might have been half, but it wasn't all of us yet.

And what was the argument for, like, we should just maybe just go fork VS Code versus this? And how did you decide to let the current version win?

Anytime you try to stand up an alternative to an IDE or a browser or even an operating system, to an extent, there's always this moment of, wow, there's more stuff than we—

I see. Yeah.

I think the file editing piece—VS Code is very much like a arrange your own panes type of situation, where it's like, yeah, I need all these things open at the same time. And I need to customize the layouts and the workflows and all this. I think that it wasn't clear at that point yet where the models would get to on what time horizon, and that's kind of when they started coming out monthly. And the thing that needed to happen was that most of the time you don't need to edit lines of code. And that you can steer them. But if the model's getting too much wrong or doing work that isn't up to your bar, then steering ends up being kinda slow, and you actually wanna dive back in and have, like, a tab model. But we were able to get to this point on the research side where it crossed some threshold that we felt that, yes, I do have to steer this a lot, but I don't have to edit it by hand. That was a big moment. And I don't remember the exact sequence there, but that was kind of the—the tab models have gotten really good. And so there was some cases early on that it was actually faster to be in the file, start typing and then tab, tab, tab. Right? And notably, we've never had a tab model. So.

Hmm. Interesting. You said that it wouldn't have succeeded if you had launched the same app in November when you first conceptualized it, which means that you sort of had to make a bet about model progress in order to do it. And you also had to convince other people that that bet was good before you could show them something that was working. How did that work? How did that happen? And why did you make the bet?

I think Codex has been a very good model at the company for how closely we work with research. And I think that closeness gives us a bit more sense of where things are going and which speed. I think it was still a bet. I think at this time, you sort of saw two form factors out in the wild. You saw this style application on the web which was what kind of was called vibe coding at the time, which was not production grade stuff. It was like, you wanna make a toy thing that you put on the internet, that's fine. You've got chat over here, you've got files over here. There are several versions of this. And so there was precedent for this type of vibe coding. It just wasn't quite at production grade. It wasn't even at the grade of a code base that we wanted for this app, and that was the thing that changed. So it's not like overnight, in this period, we went from not being able to code to being able to code. It was more of a quality bar. That in that time, we got to something where we could basically vibe code at the company and still meet the bar that we needed.

The idea I have of the Codex team and how this all happened is there is a small intrepid band of product people and researchers who got together and were able to split off from the big behemoth 800 million user ChatGPT and play around with a separate model and a separate product until you found something that was pretty sick. And then that sort of is, in some ways—and actually Greg said this earlier—it's like you're almost disrupting ChatGPT yourself. What are the generalizable best practices for when that should happen inside of a company? When do you need to split out like that and have that sort of playground? 'Cause it's a very different kind of company strategy than you would expect, like, 10 or 15 years ago. People didn't really do this that much.

Yeah. And it's interesting because you do actually hear about startups within the big company—

Yeah, but they never work.

And they don't work. Right? And I think that I hope that we keep doing this, by the way. I hope that at some point this team feels disrupted in a way that's good for progress. I don't know if I have a generalized hypothesis of when you do it and how you do it to be successful. I know that this one, I don't think that we would be here without having done this. And I assume there will be future versions of it.

What makes it different though than the bajillion big companies that are like, "Yeah, we're gonna disrupt ourselves. We're gonna make a product in a little team that does stuff," and it just never works?

One of the special things about OpenAI that I think is distinct even from the other labs is how bottoms-up the culture is. And so some days it is very frustrating to me because I will be like, "Hey, why are there 16 different efforts that are doing the [redacted] thing," right? Can we focus a little bit? It sometimes is a very unfocused situation we're in. But the good thing about that is that there's a whole lot of agency to prototype things. And I think that that's where there is complete freedom to prototype. There is complete freedom to put things out into the company to see what sticks. And if you can do that while also collaborating with research I think that it puts these little spin-out processes on steroids. Codex started before it was a formally different organization too. So it was a little thing that gained traction. It was actually two different teams that joined forces at some point and—

What were the two teams?

I don't know. It predates me. I also don't know if we share that, but I think we will see this happen again, where it's like, "Hey, there's this prototype," and then people start to use it, and then they join up with research to get some weight behind it on the model training. And all of a sudden it's taking off, right?

Yeah. It seems like the benefit of this strategy is because the landscape's changing all the time, you've got all these explorations happening, and something will randomly go right, and then it gets more oxygen in a way that if you're at the top of the org, you're not gonna be able to figure that out yourself. You need the sort of bottoms-up motion. But the downside is it's fucking messy. Especially towards when something starts to work and you're like, "Oh my God, I've got Codex and I've got ChatGPT." Tell me about that.

It is messy, and it's kind of one of those things too where you love it when you're the one prototyping and then, if you're running a product, you're like, "Why do we do all of this? Everybody should just listen to what I wanna do." Shipper: [laughs]

No, but I mean, I think when it's bad, this version at its worst is the version of it where convergence is not a competency, when it's just chaos, and then nobody knows how to bring this to the world. And I think that that's what we want to avoid here, right? There are all sorts of things that we have added to the Codex app that started as experiments that nobody on my team told anybody else to do. Like, computer use was one of these things where it's like, Ari's team is doing computer use. They're really good at this thing, and then one day they've got a prototype to work with the Codex app. Like, you've got... What else do we got that's like—

Pets is a good example.

Pets. Yeah, Pets started as this... And I wasn't totally convinced on Pets, and I was wrong about this thing.

Is Pets working?

I mean, people love it.

Really?

It was interesting 'cause it started as someone's onboarding project. And then decided, oh, it blew up internally. Everyone started making pets, and then once you could customize to it, it just further exploded. And everyone's like, "Oh." So then we have launched it, and I think we're at over 100,000 in the first... In the first two weeks of launch it was over 100K.

Yeah. What are the other Pets, are there new Pets metrics that I should know about? 'Cause I've never made a pet, to be honest.

I mean, it's fun.

I don't think the company publishes top-line Pets numbers to the shareholders.

[laughs]

We have approval for sharing Pets numbers. At least that 100K one I did get 'cause I thought that was just so—

Wild.

It shows that people still want something that's familiar.

It's the same OpenClaw kind of energy too. We loved our claws and now they're all dead, but you know.

Go grab Peter [Steinberger] if you need him.

I would love to talk to him about this at some point. That'd be really interesting, yeah. Katie, any questions on your mind?

She's a rabid Codex user.

I think the question, and I asked this to Tibo as well, is just why do I like Codex? What did you do that made someone like me who's not technical, English, German literature double major over here, why do I like Codex so much? Ambrosino: [laughs]

Why do you like Codex so much?

I love how it uses my context. I love that it always know... I set up my entire desktop to be like Codex friendly, so it has like my context folder and my voice MD for writing like me and all this stuff, but it did all that for me. I basically took a transcript of a call that I had with Dan and dropped it into Codex, and it set up my entire environment for me to be really user friendly. And every time somebody asks me, “How do you use Codex?” I'm like, “Tell Codex how you wanna use it and it'll set itself up for you.” So that's kind of the kernel of, I think, what I respond best to. It's just 'cause I don't... I skipped the whole no code, low code, no code era of Airtable and stuff because I did not wanna click around and—

Correct.

—connect things, and just being able to speak or type—but I mostly Monologue. Just being able to say I want this done and it gets done is just really compelling to me. And I just am so curious about, from a product design experience, how did that come to be?

Yeah. Well, I think one thing that's central to the current feel of Codex is that you can put together worlds in a way that with the chatbot era was a little bit harder, right? So you can say, “Hey, I want to have this, this—what do they call it? Mind palace of thousands of documents, and I want the memory organized like this, and the guidance for how I speak and write over here, and I'm gonna make these automations that loop over this set and loop over this context and then do this thing,” right? And I don't think that that's for everybody, but I think what that does in our minds is that is a... It's gamified, it's fun, it gives people control, and it lets us all—not to be too grand about this—but as a society figure out some of the patterns that work that I think then we want to bring to things like the ChatGPT experience for everybody. I think there was a while where ChatGPT has this library and it's got a certain way that memory works, but it's very much it is baked, right? It's something that we bring to a billion people. And I think the thing that people really love about Codex even when they're not writing code is you can put it together yourself in ways that are very experimental and kind of speak to something about how we... To me and to many people here, Codex reminds us of the tools we had growing up that we feel like kind of got sanitized as the years went on and—

Like what?

Like Lego Mindstorms, for example. I really liked Legos and I also really liked computers, and this was a combination where it was like, you build something, you put together the blocks.

That's sick.

There's so many stories.

What was your favorite Mindstorm?

I don't remember.

What was your favorite Mindstorm build?

When I was in the first grade I built a monorail for a science project that I programmed to have little... the rail would have electrical tape around it, and then the sensor would read it and stop and go to the next thing.

Oh, sick.

Yeah. But it feels—the Codex feels like that, and it feels like that to so many of us, even the— you know, dev—

You're the first person to say that. That's really... But it's so true, but it's weird because I wouldn't have... It's why I love it and I don't necessarily put it in that category because you're very good at making it very simple to start. Tell me about that.

I think this is the eternal push and pull about the text box product shape.

Yeah. Yeah.

And it's one that we are working on differently every week. We knew we wanted something simple. We knew that we didn't wanna lean too far into needing to know technical details, that this should feel like it draws a lot of inspiration from ChatGPT. More inspiration from chat than it does VS Code, which given the audience is a sort of an interesting choice. But we made it denser. We made it not quite as simple, but we still wanted this shape that felt like you could morph it into anything. I think that this is especially the case when you start to use the plugins, especially the role specific plugins, right? Where I'm doing financial modeling, or I'm doing sales and wanna keep notes on all my calls. The plugins start to change the way that the software feels for every person. I think the challenge here is the empty box problem. And I think we need to do a better job here, that the software is infinitely customizable, but not everybody has that time and appetite and, just free hours, to explore what they want it to be. They wanna say, “So and so set up theirs to do this,” and, I just want that.

One of the first things that I did, once I saw the light and I wanted to spread the gospel to the rest of the editorial team, was I just had Codex create a Proof doc with a setup guide that I could send to our other writer that would help her go through her process. But not my process—her process. Have it interview you about what your role is and what you need to have, and I just had Codex do it for her. But it is interesting where there seems like a slight difference between her and me, in terms of I was willing to just go in there and really kind of tinker myself, and she's a little bit more—needed a little bit more guidance, a little bit more possibility. So I'm curious how you think about, as you sort of expand this out to Codex for work for everyone, that customer education piece of the puzzle.

I've long been somebody who is skeptical about product education as a solution. I had a startup for a number of years. It was in finance and insurance for independent contractors, and people would come in and say, "You guys just need more education about how 1099s work and how the health insurance marketplace works and all this stuff." And our answer was always kind of like, "Actually, these systems are so complicated that we really want to abstract some of that instead." It's not about tool tips, it's not about guides. There's some amount of that that matters, but we really wanna figure out the end product story. One example that I really like to give is the deep research product on ChatGPT, which has been pretty popular and gone through a few iterations. And it was framed as like a top-level feature or even a product sometimes, right? In many ways, the Codex harness is a generic version of the thing that powered deep research. We don't go out of our way to say there's a deep research setting in Codex that you can do, but if you prompt it the right way and you use /goal or whatever, it'll kick off and it'll do just as thorough, if not more, than deep research. But what's interesting about this new generic version is that companies may have specific ways that they want artifacts written. They may have certain sources that they rely on, especially if you look at something like investment banks, right? They may say, "Hey, our reports need to look exactly like this in this format, and these are the proprietary connectors that we have in the app," right? How do you basically make that look like a turnkey feature for a certain user group inside of your company? So it's not a generic deep research feature for everybody. It's also not everybody's gotta know all the skills that they need to tag in the thing and exactly how to use it. It's, "Hey, I'm on this team, and I have this capability that's now just turnkey for me."

And that's just baked into the product, and you don't need people like me who are content marketers anymore.

No. It's that you can do infinitely more. And people don't come to you for incredibly basic things, right? They come to you for things that you are uniquely able to provide value on. Parrott: [laughs]

Codex feels like the first tool where, as a non-technical person, I'm being acknowledged that my workflow is complex. And that it's personalized, and I'm gonna want different things, and that's okay.

Who are the tabs for?

So in this release, we are trying to bridge a few different worlds, right? We're trying to bring Codex to the cloud in a meaningful way, right? So that you can say, "My laptop doesn't need to be open."

You're doing the hoist.

Right. Doing the grand hoist. Did somebody call it [that]?

Alexander. Yeah.

[laughs]

I think I gave him that name.

I'll credit you.

Yeah. We call it the grand hoist. And we're gonna have a lot more very interesting things here with all of Codex. But that's one world that we're trying to bridge. Another world that we're trying to join in this vision is all of the ChatGPT context that you've built up over the years. Bring that into the desktop experience that has worked so well, right? We've got a ChatGPT app. It's separate. It hasn't gotten a lot of love. We wanna bring it into here. All of your memory, all of your projects, all of your research reports, and let you go wild in Codex with that. Then we also have our Codex remote control, which is another world that we're bringing into this. So we're bringing these things together. How these evolve over time together will change, right? First version will look different than version two, three, four. And they will likely converge over time even further than they do now. But we're pretty happy with this.

What are you most nervous about with the great merge?

One of the things that I've always been nervous about here, just in terms of execution on products, is that ChatGPT serves a billion consumers and also a smaller amount of prosumers, and then also enterprise. And that it is quite difficult to build a cohesive product and even a cohesive brand around that whole spectrum. And that's something that we're gonna have to figure out. I think Codex has gotten off pretty easy with its focus. Maybe that's a template, maybe it's not. But that it's very difficult to build an everything product.