Evolving DX at the Speed of Frontier AI

Dominik Kundel: So over the last two months or so, we shipped over 150 features for Codex alone. That is on top of around 26 or so models that we added since the beginning of the year and 36 or so features to the API. And that raises the question, how do you actually evolve a team and build, grow a team if everything below you is shifting? The product, the features, the capabilities of the technology you are trying to equip developers with, and most importantly, the company keeps growing. And so over the next 25 minutes or so, want to talk to you all about how we shaped the team over the last couple of months and how we dealt with all of these rapid changes.

But first, hi, everyone. My name is Dom. I lead developer experience. I am the tech lead of developer experience at OpenAI. And I also want to give a quick disclaimer.

Namely, that some of the assumptions our team can make don't apply to you right now. But hopefully, some of the lessons from how we dealt with these issues will still apply to your own team as you grow it.

How the team and its work changed

To set the context a bit more, I joined OpenAI around a year and a half ago, and we had primarily three developer surfaces. They were all APIs, and we had a couple of legacy APIs around DALL·E and Whisper, but mostly we were focused on these APIs. And the team was fairly lean, mostly focused on documentation, building occasional sample apps, and then helping out with launch moments.

Since then though, in those year and a half, we added more APIs, more SDKs. We added open weight models. We added significantly more models in all types of modalities. We added security products and various other types of APIs. But most importantly, we launched Codex.

And so Codex alongside other agentic coding options like Claude Code or Cursor has really shifted AI from this autocomplete AI mostly for autocompleting code to true agentic development where Codex can now run tasks for hours or days at a time completely independent. And with that, we saw three major impacts on our team and sort of how we are thinking about stuff. The first one is how people build. Like I think all of us know sort of there has been an impact on how developers are building things today, But also what we can do as a team has drastically changed. And then the last thing I want to talk about today is who we actually serve has changed.

This is probably the least controversial and has come up a bunch of times. I think we can all acknowledge now how developers build has changed. But this is also one of those moments where I want to give a disclaimer. I know that for us, if someone is trying to build with our APIs, chances are they have already in some level AI pilled or are using some version of an AI coding agent, whether that is actually Codex or Claude Code or Cursor. And so that allows us to do some level of assumptions and more drastic moves than some of you all can do.

From sample apps to experiences

For example, we kind of stopped building any sample applications, whether that is, you know, quick starts or general sample applications. We stopped building those and instead focused our energy in other places. And the reason for that is that they were already kind of a bottleneck. We often focused on having to figure out how do we reduce the same capability into a small application that is easy to learn but still useful, except that for something like an LLM, that is incredibly hard to do because there are so many different things you can do with it and you don't want to stamp out like 30 different sample applications. And so it was already hard for us to figure this out and make it something that feels truly native in the different programming languages.

And with agents now, chances are people are anyways just going to point their agent at it. There's other ways we can inform them about that context. And so instead, we shifted our focus on more inspirational aspects, like how do we build inspirational demos and often more hosted demos where people can experience the power of our technology and truly feel inspired of wanting to use it. We launched, for example, openai.fm as a way for people to test our text to speech models in a hosted way. We built a showcase where people can see different applications that are either built with Codex or with our APIs so they can experience those and test them out, understand capabilities of new models.

And then we shifted all of the actual empowerment and enablement into more agentic capabilities, whether that is having an agent on your docs platform that can help generate custom guides, for example, or answer questions, but also shipping an MCP and their respective plugins. And not just for Codex, but acknowledging the fact that folks are using other coding agents. We shipped one in Claude Code and as well. And then we put more energy into inspiring launch demos. We really leveled up our video production skills, and in this case I am not talking about agent skills, but really tried to double down on how quickly and how well we can produce videos to educate and inspire folks.

What agents let the team do

The by far more massive shift though was in what we can do as a team. And we try to, at any point in time, really question and push the technology to its limits. This has been the biggest ethos in our team is we are constantly trying to figure out how do we take the technology that we have and push its limits both on the model and the harness side to figure out what you can actually create with it and how do we most effectively dog food it to the level where the first sentence you will hear when you join our team is have you asked Codex? You cannot believe how quickly people get tired of it and then shift over to just saying it themselves because it so quickly becomes an integral part of what you do. But we still throughout this whole process try to question everything.

It is very important for us to not play by an existing playbook because a lot of the things we do don't really have a playbook. We have never been in a time where like things are evolving so quickly and things are changing so quickly. That is actually a good callout to how our team is structured. Most of the folks on our team, the overwhelming majority, has never done DevRel before. They have never been a developer evangelist, advocate, DX engineer, whatever you want to call What we have in common is everyone is an engineer and we have an incredibly high engineering bar.

But then outside of that, everyone has done a different job whether they were consultants, founders, product managers, solution architects, marketers, technical enablement folks for for the recruiting teams, a wide range of capabilities. And that allows us to really embed ourselves in the company more broadly. We can help, on the one hand, be the glue between different departments inside the company. And on the other hand, we can question the workflows of how these technologies are being used in every one of these workflows. So for example, my colleague, Brent Schooley, has really pushed what is possible with video editing in Codex.

This started off with like a late night prelaunch scramble back in February where he was trying to just add some markers to a video file and ended up rabbit holing into building a full on integration between Codex and Premiere for him to do various editing flows. And he just published a video that was completely generated, or like edited in partnership with Codex and DaVinci Resolve. But also things like maintaining docs, I know we have all kind of struggled with, but Codex has become an incredibly deep part of our flow. On the one hand, it helps us integrate feedback that comes through Slack or other channels. It also imposes our style guides, and we have put a lot of work into linters and other ways for us to actually enforce that style guide.

We have also gotten it to a point where we can ask it to draft docs almost entirely based on context that often lives across Slack, Notion, Google Drive, various emails, and it is often even hard for us to wrap our head around, let alone like trying to scramble leading up to a launch. And one of the things that is important for us as a team is to be close to the community and constantly engage with them. The problem with that is that, as probably all of you know, you quickly end up becoming support for a lot of them. And if you are like us, very active on Twitter, you get flooded with people tagging you all the time because they are frustrated with something. And so we invested in having a shared plugin for the team to help us investigate these issues.

We can quickly do an app shot which is like a hit both command keys in the Codex app and it takes like a rich screenshot. And we can just ask it to investigate it. It is going to find open SEVs. It is going to go through logs if they are available, try to figure out initial issues and help us both escalate to the engineering teams but also help the community and actually communicate with them more openly. But ultimately, the focus of whenever we try to figure out how we can bring Codex in and leverage AI is about creating more delight and a better experience for our users.

It is not about using it for the sake of it, but trying to find ways that we can actually deliver more delight for them. A good recent example is we revamped the docs around three weeks ago. And how many of you know the pain of updating screenshots for your apps, docs? Yep. It gets worse if your engineering team constantly changes the UI and you don't get any heads up.

At the beginning, or like three weeks ago, my colleague Katya had the great idea to push capabilities of 5.6 Sol as we are launching it. We have replaced most of our screenshots now with HTML versions of those screenshots by just giving it a reference screenshot and the access to the real code base of the app. This allows us to now more easily maintain these screenshots by just being able to tell it to check what has changed in the last week, and actually update these graphics. But it also allows us to add more delight. For example, we have this thing called Codex Pets.

You might have seen one. And you can have them as your little assistants fly around your screen. But we were also able to add them to the docs the same way. So you can engage with them, get to meet them, and it is just this little bit more delight. Or in a similar way, in a quick start, we wanted to teach how people can switch between ChatGPT and Codex in the desktop app.

And so we used the same animations and Bezier curves that the computer use cursor does when you use a computer use with Codex, and instead have it on the page so people can quickly see what is happening. And it is still real components. They can still toggle it. It is also accessible. But it makes it much easier for us to actually maintain things and create that delight for users.

One of the moments where I had this and it really clicked for me was 10PM that same, the night before that launch, and I had realized that one of the features we were about to launch had zero docs. And it was the visualize feature. It is a feature where the model can actually return to you an interactive element where it can visualize data for you and you can engage with it. It is one of those features where you really have to feel it and like see it and engage with it. But it is like 10 p.m. the night before the launch. I also want to go to bed eventually. So I already had five to six different Codex threads running. And this is the actual task.

I will step aside. This is the actual message I sent to I asked it to go through and create one more task for me to build docs for this visualize feature. I told it to just like figure it out. It knew how to go through Slack and other sources. But I also told it to check out the examples that were in the gated preview version of the blog post and they were all embedded as videos.

Now, had no idea whether this was going to work, but I thought it was a hail Mary, let's figure this out. And it blew my mind because what Codex did is it pulled down that blog post through browser use, it downloaded the video, and it actually figured out what were those demos. And then it accessed the code base of the app to figure out how to rebuild these demos so they were as authentic as possible. The result is a complete set of docs that has all the callouts and edge cases, but it also has these fully interactive demos that you can engage with that were previously just videos in the blog post. And that means now it is easier for us to both maintain these, but it is also better for the users to actually engage with them and understand how these features work.

And honestly, I would have cut otherwise. Like, I think it is a great feature. Am super excited about this page. But without leveraging Codex so heavily, we would have probably cut this. And so it is about creating more delight and not just trying to, like, throw it in for every purpose.

Who developer experience serves now

But the last there we go. The last thing that has changed for us is who we actually serve. And this was probably the biggest discussion we have had over the last couple of months and the biggest change. Because we started off being very focused on Codex, but Codex became this increasingly capable tool that actually ended up becoming for everyone. And so if you start using it for more use cases, it changes sort of how you're approaching things.

One of the first trends that we saw was inside the company. The company started to almost entirely adopt Codex by like June. And this goes beyond engineering. It goes into finance, biz ops, marketing, sales. Everyone was adopting Codex before we later on rebranded it for knowledge workers as ChatGPT Work.

But we saw all of these people embracing it. And with that, we saw a change in both what developers can actually do or what they do on a daily basis. We saw a change in who can actually build. And we saw a constant change in what the technology can actually do. I also realize I have been standing in front of these slides for some of you people.

Apologies. But one of the biggest changes for, like, what developers do has been the shift away from coding. Right? So, like, we have moved in the last couple of months, especially internally, but I think we are seeing this in the community as well, increasingly away from developers just watching an agent write code because these can now run for hours or days. So instead you run an agent in parallel.

You run multiple agents in parallel and you run them all in the background. So what do you do when all of the agents are running? You end up collaborating more with your team. You are trying to figure out what to build. Or more importantly, if you have the ability to build anything now, what not to build.

And then eventually you come back and you go and actually review the code and figure out whether you ship it or whether you continue in that loop. And so with that change, we wanted to make sure that all of the features and capabilities do not just serve you while you are writing code or building something, but they should serve you in every part of what a developer actually does. And if we are building those features, it means it makes it easier for other departments to adopt the same tool for their workflows. And you can see all of these different teams quickly adopting, often much faster adopting Codex than the engineering teams. But it is not just for their own workflows.

If engineers are spending less time just looking at code and changing code, we are actually seeing them behave much more similarly to other teams. So this was part of that same report as the other graphs that we released in June where you can see engineers are still spending the majority of their time building, So has every other team started building things. Similarly, engineers were starting to spend more time on other work. We are seeing this morphing of different responsibilities and how the roles of the different teams were changing. One of the examples, or two of the examples from the community that I love that shows sort of like how now anyone could build are one Hiroki who is a public servant in Japan or former public servant in Japan who started owning a broccoli farm and he used Codex to figure out how to actually improve the operations on his farm by building bespoke technology for his farm because operating a farm is incredibly expensive because you have all of this incredibly expensive gear.

And he was able to figure out with Codex and ChatGPT how to actually solve his problems and build that technology. On Michael Wall who is a musician and composer who has embraced Codex to help it work with him in Ableton to help him compose music. But more importantly, he now started building two apps in parallel that he had always dreamed of but never had the capabilities to do so. And the last part is what this technology can do. I think this is the fastest change and it is also the thing that makes our role so weird admittedly because what is possible constantly changes and we often don't know what is truly possible.

A good example of this is my now colleague Peter Steinberger back in January or so posted this picture. And I remember over the holidays reading some of the blog posts on how he was using Codex and saw this picture. And I thought to myself, like, this guy knows more about how to use Codex than most people at OpenAI. But the wild part is not that he knew all of these things. We all have power users.

What is wild is that at this point in time, I am convinced that everyone at OpenAI, including Peter and most of our community, know more and do more than Peter did in January. And this is just six months ago. And so it is changing so quickly, and we are regularly being out-probed by our own community, which makes educating folks much harder, and it means that we need to play an even more crucial role in that constant cycle between research and the community trying to figure out how we both turn the desire paths that the community are creating back into research and product flows, while keeping in mind where research is actually heading, which often we can't even fully disclose to folks. But the big change of all of this is who we actually serve. Because we had to go back and actually think, who do we serve?

Rethinking the audience

And so with all of these changes that have happened, we decided to throw the manual out of the window and go back to basics and question truly everything. The thing that we were confident about is a couple of key characteristics of our team. We are technology obsessed, or what we often call AGI pilled inside the team. We truly believe this technology can do a lot, and it has not reached its potential yet, and we constantly try to use it more. We are also all creatives at heart regardless of what background we have.

We love creating experiences for people and thinking through how do we best shape the experience folks. And we are educators. We love taking this technology to the limit, but we also love sharing with others how to use this technology. I promise you my wife is sick and tired of me talking about all the cool things that you can do with Codex. But developers was sort of this thing that was so tied to our identity.

It's in our name. It's everything we do. We own developers at openai.com. We increasingly noticed that even though we were trying to do things that were inclusive of others, we were running into issues. Not everyone identifies as a developer, and while everyone in our lives probably in this room would probably be a developer, they often don't identify themselves.

We saw this with the documentation we had for Codex where people often didn't even bother linking others to it or looking at it themselves because it said developers at the top. And so we actually have to change that. But that means if we are not serving developers because people don't identify as developers, clearly we are serving builders. My favorite term. But that doesn't work either because one, we already talked about that people do more than building now.

And two, other than Bob the Builder, I have not found someone who actually identifies as a builder. Apologies if you do, and please come and meet me afterwards. But instead, we actually went back and thought about like, what do these people actually do? And it is about pushing the frontier. It is about trying to change what is possible in this world.

And that was for the longest time developers. You had to know how to build stuff, use technology, write code to actually change what was possible. What has changed is that you don't have to be able to read code anymore, but you can now change what is possible and what stays is the curiosity, the persistence, and the creativity that developers always brought. And so we changed our mission. Our mission at OpenAI overall is to ensure that AGI benefits all of humanity, and we adapted our own mission to make sure that we highlight those people exploring what is possible with AI and build together towards a world where AGI broadly benefits all of humanity.

We started implementing some of these things. We started creating content for non developer features that we used the same playbook that we knew and applied it to educate people and inspire them what they can do with these technologies and features that might not be developer features per se. We also revamped our docs. The dirty secret is it is still the same docs. We just do a URL hack.

But we changed them and we updated some of the prose where we were still a bit developer heavy and updated things to learn.chatgpt.com to open it up to more folks. But we still keep the same level of craft and focus on that. And then we also applied our storytelling capabilities to more events than just developer events. For example, by teaching execs what you can do with agents. Alright.

Focus on craft and delight

That was a lot. Wrap things up, technology is changing faster than ever before. Everything is changing under our ground, but that means we can focus back on the basics. Ultimately, you should focus on the craft. It is what you already know, and we can apply this to the same new world that we are entering.

Create more delight. It is not about just using this technology to create more AI slop, but actually focus on what allows you to create better experiences and create more delight for your users, and question everything. If you want to have the slides, check out that QR code down there. With that, thank you so much. Thank you, Dominik.

Yeah, I will repeat the question. The worry about doing the inline HTML for a lot of these to replace images, what is with accessibility and making sure that all of those things are set correctly. So yeah, that was one of the worries that we had and so we made sure that everything is wrapped with the right ARIA tags and labels and descriptions to make sure that that is accessible as well as, like, making sure that you can't tap into it. If you run into issues, please let me know and we going fix it.

Audience questions

Audience member 1: I really appreciate that you guys have made some of these resources seem more open ended and less developer centralized. It is less socialized whether or not nondevelopers habitually go to what you would call docs or those resources that developers already know that are part of their process and exploring new tools. What are the ways we can socialize a new habit of referencing these resources to non developers? How have you guys crafted for that internally, externally?

Dominik Kundel: We are trying to still figure out some of these things ourselves where because ChatGPT had a very strong consumer background, we already had a lot of infrastructure there and we spent the last couple of weeks and months trying to make sure we are all working together and bringing some of these things there. I actually think in a lot of cases, what we have seen at least, there is a lot of excitement that we were releasing these docs and a lot of excitement from sales and go to market marketing and others to actually highlight these more and link to them more. I think a lot of people are actually like hungry for these resources. They are just often sort of scared of them being too technical for example. And so we are trying to also make sure that on the one hand some of the things that are still very developer centric we put off in the developer corner.

And then everything else, we started to change things into more of a progressive discovery mode where like we are not going to jump in immediately on like, this is the file path in Unix where you will find skills. But instead actually like talk about the benefit of skills and go down and like have more details either in disclosure elements or further down in the page so that they are still available for developers and you still get good quality. But you also, even if you are a developer who knows nothing about skills, you should feel welcome in the docs.

Audience member 2: Without saying everything and hopefully not starting a fight in the audience, I I use Claude code quite heavily. What should I be using Codex for that Claude code isn't doing? And is there anything is there anything that differentiates from Claude Code, like a specific use case?

Dominik Kundel: I mean, obviously we have other models. If you wanna if you wanna try out our models though, like we did launch our Claude Code plugin that connects to Codex so you're welcome to try that first if you don't want to fully pull off the ripcord. We also let you actually use your subscription in Claude Code if you set up an API proxy. So like that's a good starting point if you still really feel tight in there. I think one of the things that is truly magical with Codex and that is worth trying out is computer use, both in the browser extension as well as the macOS or Windows native computer use.

It is truly magical and on macOS it actually runs in the background. So I often have Codex do tasks completely in the background on multiple apps solving problems, and I'm just keep doing what I'm doing and we're sharing a computer. So I think that's the most magical thing you should try out.

Audience member 3: What I see is that people who are, let's say, at the front of the pack for new technologies are running even faster than before, and there's still a large group of people that are moving slowly. Have you found it challenging, or how have you addressed, like, making content for two very different audiences at really different places of their adoption life cycle?

Dominik Kundel: Yeah. Absolutely. Like, I I think it's a challenge, and I'm not gonna say that we have this solved right now. We're trying to solve this and create more content around, like, especially those folks that, you know, there is still a broad audience that like doesn't even trust AI with autocomplete and at the same time we have others that you know, like have not opened a code editor in like months and shipped production ready software. So like I think there is a lot still to educate and we are constantly trying to evolve that and create more content for those folks.

I think one of the interesting things to balance is like, and I haven't heard anyone talk about it and I'm happy to chat about this outside, but like it feels like the distribution channels for us to distribute a lot of this educational content have changed and are mostly very video heavy, and so we're trying to figure out how do we do this in a video format while still dealing with the fact that everything is changing all the time and especially that type of content you want to have more evergreen. Super. Well, let's thank Dominik. Thank you.