Go back

“Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu

79m 39s

“Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu

The discussion highlights the transformative impact of AI code generation tools like OpenAI's Codex on software engineering. At OpenAI, 95% of engineers use Codex daily, and all pull requests are AI-reviewed, significantly boosting productivity—engineers using Codex open 70% more PRs. The engineer's role is shifting from writing code to managing fleets of AI agents, compared to wizards casting spells, which requires skill to steer agents effectively and avoid errors like those in the "Sorcerer's Apprentice" metaphor. Challenges include stress when agents fail, often due to inadequate context, prompting efforts to encode tribal knowledge into documentation. Codex also automates code reviews and deployment, reducing tedious tasks. The rapid evolution of AI means models will improve, urging builders to focus on future capabilities. This AI-driven change may lead to a golden age of B2B SaaS, as supporting startups emerge. Overall, the field is in a dynamic, experimental phase, with engineers adapting to leverage AI's high leverage while navigating its imperfections.

Transcription

15681 Words, 84838 Characters

95% of engineers use codecs. 100% of our PRs are reviewed by codecs. For engineers, I don't know what job has changed more in the past couple years. Engineers are becoming tech leads. They're managing fleets and fleets of agents. It literally feels like we're wizards casting all these spells. And these spells are kind of like going out and doing things for you. What do you think people aren't pricing in yet? The second or third order effects of the $1.1 billion startup. To enable a $1.1 billion startup, there might be a hundred other small startups building bespoke software. So I think we might actually enter into a golden age of B2B SaaS. I've been hearing more and more. There's this stress people feel when their agents aren't working. There's a team that's actually doing an experiment right now with an open AI where they are maintaining a 100% codex written codebase. They run into the exact problems that you're describing. And so usually you're like, "All right, I'll roll up my sleeve, some fear it out." A team doesn't have that escape hatch. You've shared that listening to customers is not always the right strategy in AI. The field and the models themselves are just changing so so quickly. They tend to disrupt themselves. The models will eat your scaffolding for breakfast. What's your advice to folks that are like, "Okay, I don't want to miss the boat." Make sure you're building for where the models are going and not where they are today. But there's a quote from Kevin Whale or VP of Science here. And you like saying this is the worst the models will ever be. Today, my guest is Sherwin Wu, head of engineering for OpenAI's API and developer platform. Considering that essentially every AI startup integrates with OpenAI's APIs, Sherwin has an incredibly unique and broad view into what is going on and where things are heading. Let's get into it after a short word from our wonderful sponsors. Today's episode is brought to you by DX, the developer intelligence platform designed by leading researchers. To thrive in the AI era, organizations need to adapt quickly. But many organization leaders struggle to answer pressing questions like, "Which tools are working? How are they being used? What's actually driving value?" DX provides the data and insights that leaders need to navigate this shift. With DX, companies like Dropbox, Booking.com, Adian, and Intercom, get a deep understanding of how AI is providing value to their developers and what impact AI is having on engineering productivity. To learn more, visit DX's website at getdx.com/lennie. That's getdx.com/lennie. Applications break in all kinds of ways. Crashes, slowdowns, regressions, and the stuff that you only see once real users show up. Sentry catches it all. See what happened where and why, down to the commit that introduced the AI, the developer who shipped it, and the exact line of code all in one connected view. I've definitely tried the five tabs and slack thread approach to debugging. This is better. Sentry shows you how the request moved, what ran, what slowed down, and what users saw. Sear, Sentry's AI debugging agent, takes it from there. It uses all of that century context to tell you the root cause, suggest a fix, and even opens a PR for you. It also reviews your PRs and flags any breaking changes with fixes ready to go. Try Sentry and Sear for free at sentry.io/lennie and use code Lenny for $100 in Sentry credits. That's s-e-n-t-r-y.io/lennie. Sure, when thank you so much for being here and welcome to the podcast. Thank you. Thank you for having me. I want to start with what's feeling like a barometer of progress in AI, especially in engineering. What percentage of your code, if you even write code anymore, and your team's code is written by AI at this point? I do write code occasionally now still. I'd actually say for managers like myself, it's way easier to use these AI tools than to manually code at this point. I know for myself and some of the other EMs, engineering managers at OpenAI, all of our code is written by code x at this point. But more broadly, there's just so much energy. There's a tangible energy internally around how far these tools have gotten. How good code x as a tool has gotten for us. It's a little hard for us to exactly measure how much of the code is written because the vast majority of it, I'd say, close to 100% is usually generated by AI first. What we do track, though, is at this point, the vast majority of engineers use code x on a daily basis. So 95% of engineers use code x. 100% of our PRs are reviewed by code x daily as well. Basically, any code that goes into production that's merged in, code has kind of has its eyes on and suggests improvements, suggests changes in the PRs. That's what we're seeing internally. But by and large, the most exciting is just the energy that there is. Another observation that we've had is engineers who tend to use code x more open way more PRs. So they're actually opening 70% more PRs than the engineers who aren't using code x as much. The gap is widening. I feel like the people who are opening more PRs are starting to learn how to use the tool more and more, get more efficient, and that 70% gap keeps growing over time. It might have actually increased since I last looked at the number. So just to make sure we hear what you're saying, you're saying all of the code of these 95% engineers at OpenAI is written by AI. It's written and then they review it. It's crazy that that's almost not crazy anymore that we're just getting used to this. I think there's still some getting used to to be clear. There's also some engineers who trust code x a little bit less. Basically every day I talk to someone who is blown away by something that I can do. Their bar of trust, how much they trust the model to do on its own goes up over and over time. There's a quote from Kevin Whale, our VP of science here. He's saying this is the worst the models will ever be. This is the worst that the models ever be for software engineering as well. Over time, we just see people trusting it more and more. We'll see the models get better and better as well. Kevin Whale, former podcast guest. He said exactly that line on this podcast. Peter, the cloud bot slash, mold bot slash, open claw is what it's called now. Developer recently shared that he uses code x for his work and he feels like any time it does thing. He just trusts that it has done the right job, but he's just almost certain he could just commit it to master and it'll be great. Yeah, he's a great user of code x. I know he's in close touch with the team because it's great feedback. Not surprised how he uses it. I mean, sorry, it's called open claw. Open claw. Yeah, it's a great is a great product. And then I saw that this more. I mean, this is very recent, but this morning, I think the most book kind of like with shared as long seeing all the AI agents talk to each other is pretty surreal. It's basically her is happening in real life as well. Yeah. Yeah. So just like coming back to this crazy moment we are living through four engineers in particular, we've gone from you write every line of code to now. AI is writing all of your code. I don't know what job has changed more in the past couple of years. Like job that we didn't expect to change this much. We're just like the job of an engineer is so different in the entire lifespan of an engineer like in the past couple of years. It's now shifted to I don't write anymore code. I don't even imagine the role of an engineer and the job of a software engineer looks in the next couple of years just like what is that job? Yeah, it's I mean, it's honestly been really cool to see. And it's part of where the excitement is because like the job is likely to change pretty significantly over the next one or two years. It kind of feels like we're still figuring things out though. And so there's like this excitement. I know especially from some of the software engineers of like we're in this rare moment, you know, maybe over the next 12 to 24 months where we'll kind of get to figure things out ourselves instead of standards for ourselves. In terms of where I see I see this moving. So I think there's the common thing that everyone's saying, which is, you know, people are generally like I see engineers are becoming tech leads. They're basically like managers now. I know many of the engineers on my team basically have like 10 to 20 threads kind of being pulled on at the same time. Obviously not active running codex jobs, but just a lot of parallel threads. They're checking in on what they're doing. They're steering the agents and codex and giving it feedback. And so their job is kind of really changed from just writing the code itself into being almost like a manager. In terms of where I think this will go one or two years from now. So one kind of metaphor that I kind of always come back to here is actually from this programming textbook that I read back in college called sick. I don't know if you've heard of it structure and interpretation of computer programs. So SICP at MIT it was really popular and it was actually used as the introductory. It was the textbook for the intro programming course for a very long time. And it kind of has this cult following. It teaches you programming. It teaches you a dialect of list called scheme. And so it introduces you to functional programs very mind-opening that way. But the thing that was memorable for me about that book, so I read it in college. The very beginning of it kind of describes programming as a discipline and draws this metaphor to basically sorcery. It says software engineers are like wizards and you're programming languages are like incantations and you're you're issuing these spells and these spells are kind of going out and doing things for you. And the challenge is like what incantation do you have to say to make the the program do what you want. And this book was written in 1980. So this is a while ago. And I think that metaphor is actually like kind of persisted over time. And I think it's actually playing out as we move into this new era vibe coding or just like what software engineering will look like because programming languages were basically incantations. They've changed over time. And the challenge is always, and the trend has been that these, it's been easier and easier to kind of get them, the computer to do what you want via programming. And I think the current wave of AI is probably the next stage of that evolution. It is now literally in Kentations, because you can tell codex, you can tell cursor exactly what you want to do, and then it'll all go do it for you. And I particularly like the wizard and like the source analogy, 'cause I think our current state is starting to move towards kind of like the Sorcerer's apprentice, from Fantasia, where Mickey Mouse is like, he finds the Sorcerer's had and he tries to do all these things. And I actually think it's a really apt analogy because one, it's really powerful now. These incantations you can do can, it's extremely high leverage, but you kind of have to know what you're doing, right? Like in Sorcerer's apprentice, the whole plot is like, Mickey goes wild, the brooms go crazy and everything's flooding. I think he literally sets the, like sets the brooms off on a task and then goes asleep. And so it's like vibe coding at its greatest. And then eventually the old Sorcerer comes back and like cleans everything up. And when I see engineers kind of like, doing these 20 different codex threads at a time, there is some skill and there's some seniority and like a lot of thought that needs to go into this because you wanna make sure that the models aren't going off the rails. You definitely don't wanna just like completely go away and ignore the thing. But it's also extremely high leverage, like a very senior engineer who's really proficient with these tools can now just do way more things with what they're doing. And I think it's also what makes it fun. It literally feels like we're wizards now. It feels like we're closer to having, to making it feel like this magical experience where we're casting all these spells and having software do all these things for you. - I was thinking of the Sorcerer's apprentice exactly as the metaphor as you were describing that. So I'm glad you went there. A previous podcast guest described it as you have a genie that you can, that grants you wishes. And it's a useful frame because you have to be very clear about the wish you want. Like if you want to be big. - Yes, how big of you? - Or might be like the monkey's pod type thing where you know, it's actually caught what you want, but what are the side effects? - Yeah, yeah, I think that in the analogy is great. And yeah, the crazy thing for me is just the staying power of that book, Sikfi. Like it's called the wizard book. People call it the wizard book because that is the metaphor that they kind of weave throughout the book. And we basically reach that point now, which is really cool. - There's two kind of threads I want to follow here. One is I've been hearing one more. There's this like stress that people feel when their agents aren't working. You fire off all these codex agents and then you have to keep stand top of them. Oh shit, one's not working. I'm wasting time. Do you feel that? Do you feel that across your team at all? - Yeah, I mean, it happens all the time. And I actually think like this is where the interesting part of all of this lies right now because these models aren't perfect, these tools aren't perfect. And we're still trying to figure out how to best interact with codex or with these AI agents to get work done. We see this come up all the time. There's a particularly interesting team that we have internally. So there's a team that's actually doing an experiment right now with an open AI where they are basically maintaining a 100% codex written code base. So you know, like, you know, something, you know, you'll have the AI write code but you'll obviously end up like rewriting a lot of it and you might need to like double track and change things. But this team is just fully codex-pilled and just like leaning in entirely. And they run into the exact problems that you're describing, which is like, you know, their challenge is, you know, I wanna get this thing feature built, but I can't get the agent to do it. And so usually it was an escape hatch where, you know, then you're like, all right, I'll roll up my sleeves and like, figure it out and then instead of using codex, I might use like tap-complete and cursor and things like that. But this team, for the experiment, this team doesn't have that escape hatch. And so then the challenge is like, how do I get the agent to do this? And I actually think we're gonna be publishing a blog post from some of our learnings here. But a lot of fascinating like paradigms and best practices are falling out of this. One interesting thing that we've noticed, I don't know if this is what you kind of feel but we definitely feel it here is, a lot of the time when the coding agent is not doing what you want, it's usually a problem with context and just like information that you've given it. It's just, I've there, under specified or there's just not enough information around how to do something available to the agent, available to codex. And so when you have to solve it through that, the challenge is then to add documentation and actually work around this limitation and basically encode more tribal knowledge that's in your head somehow into the code base, either via code comment itself or code structure itself or via text files like.md files, skills, any type of additional resources within the repository so that the model can better do its task. There's a whole bunch of other learnings from this group which I think is fascinating to explore. But yeah, kind of giving, removing that escape hatch of no longer using the AI has allowed them to start piecing together a lot of the problems that we'll have to solve if we really want to lean into agents. - Another issue people run into, you're talking about how people are shipping PRs like crazy, a lot more PRs if they're working with AI. Obviously code reviews becoming a bigger challenge. Is there anything you've figured out or you're team to help speed that up to make that scale? And not just create this terrible job for people where they're just sitting there reviewing PRs all day. - Yeah, I mean, one thing is codex reviews 100% of all of our PRs at this point. And so I actually think so. One really interesting thing that's happened is the things that tend to, we tend to hand to the models immediately, tend to be the things that annoy us or like are the most boring parts of software engineering. It's also why it's more fun now because we get to do more of the fun things. For me, speaking more for myself, I really hated code reviews. It was one of the worst things for me. And then I remember in my first job at a college, it was at Quora, I was working on the newsfeed. And so I owned the code for the newsfeed. And so I was a reviewer for newsfeed. And it was just like the central piece of code that everyone would touch. And so I would just, every morning I'd log in and be like 20 to 30 code reviews. And she's like, oh my goodness, I gotta get through all of these. I would procrastinate and then it grows to like 50. And so there's just like a lot of code reviews. Codex is really good at reviewing code. So actually one thing that we've noticed that 5.2 in particular has gotten extremely strongly adept at is reviewing code and especially when you kind of steer it in the right direction. And so for code reviews, yeah, we create a lot of PRs, but codex reviews all of them. And it makes, you know, codex reviews go from a, you know, I don't know, 10, 15 minute tasks to sometimes even just like a two to three minute task because you have a bunch of suggestions already baked in. A lot of the times people will, especially for small PRs, like you actually don't even need people to review. We kind of trust codex in this way. The original author kind of website codex, it is, you know, the benefit of code reviews is that the second pair of eyes to make sure that you're not doing anything dumb. Codex is a pretty smart second pair of eyes at this point. That's something that we've heavily lean into. The general CI process and like the post kind of push and like deployment processes also have been heavily automated via codex internally at this point. If you talk to a lot of engineers, the thing that annoys me most is after you've written your beautiful code, like how do you get it into production? You know, you gotta, you know, run through all these tests. You gotta like, you know, limp errors, you know, code review. There's a lot of automated stuff you can do with codex. And so we've actually built some tools internally that help automate that process, automate the lint. You know, if there's like a lint error, it's a very easy codex fix. And then you could just patch it and kind of restart the CI process. So all of that is we're trying to collapse as little work for an engineer as possible, which in the byproduct of which is they can now merge and push out a lot more peers. Codex writing the code, codex reviewing its own code. I am curious if your opens using other models to review your model's work. Is that a path or is it just, it's good enough? We don't need anything else. So I will say there's definitely a circular thing here. And like going back to sources or print this, like you want to make sure you're not letting the berms go crazy here. And so, you know, we're very thoughtful, I'd say, around which PRs kind of are completely just codex reviewed. Most people still obviously take a look at their PRs. And so it's not like it's going to zero. It's more like going from, you know, 100% attention to like 30% attention, which just helps things push through. In terms of like multiple models. So we obviously test a lot of models internally. And so we have a lot of those. We use external models less. It's, we think it's important to kind of dog food our own models and kind of like get feedback there. But you can also, you know, there are a lot of like internal variants of models that you can use to give you different perspectives here as well. And we found that to work quite well. - Okay, so just to make sure we get like a barometer of today's world at OpenAI in terms of AI and code, just so I understand. And then I want to move on to different topic. 100% of code across OpenAI is written by codex at this point. Is that the way to frame it? - I wouldn't make the statement that 100% of code running a production today is written by AI. And it's kind of hard to do attribution there. But the like almost every engineer heavily uses codex in all of their tasks at this point. And so I, you know, if I were to guess a match like the vast majority of code at this point is it was probably author by AI. Incredible. - Okay, so there's a lot of talk and we've been talking about kind of the IC role, the work of an IC engineer. There's a lot of talk about the changing role of a manager, especially an engineering manager. How is your life as a manager changed with the rise of AI and just what do you, where do you think the managers, what's the role of a manager in the future? - It's not only changed less than an engineer. There's no codex for managers, just, yes, yet however, I use codex quite a bit for some of the, some of the, [BLANK_AUDIO] and the more manager-y tasks that I do. I'd say a couple of things are changing. There are some trends. So I don't think it's changed that much yet, but I see trends, and I think if you play it out, you can kind of see where a lot of this is going. One thing that's becoming increasingly clear is codecs really empowers top performers to get a lot, like to be a lot more productive. And so it really, and I think this may be true for AI more broadly, like across society, which is like the people who really lean in or like the people who have high agency or will really get good at these tools, will kind of supercharge themselves. And so I'm kind of noticing this now as well, which is like the top performers kind of end up being a lot more productive. And so you see a broader spread in team productivity in this way. So one thing that I've always done as a management philosophy is to spend actually the majority of my time with top performers, just like make sure they're unblocked, make sure they're happy, make sure they feel productive and they feel heard. I think this is even more true in an AI world where your top performers are just like really be shooting ahead using these tools. One example is the team that's maintaining a 100% codex generated codebase, like just letting them kind of rip in and see what's happening there is something that's paid dividends. So I think that's kind of one trend that I'm seeing where you were spending even more time with top performers for managers, I think is likely going to continue. The other thing is-- So this is more an observation. But my sense is with a lot of these AI tools available to managers, so less like writing code, but just things like chat GPT with organizational knowledge, like being able to do research and understanding organizational context a lot better. Another good example is we're doing performance reviews right now, and it's actually really easy to use chat GPT with internal knowledge, hooked up to GitHub and like our notion docs and Google docs to get a really good sense of what this person has done over the last 12 months and writing a little deep research report for it. My sense is I think managers will be able to manage much larger teams in this world. Kind of like how software engineers are managing 20 to 30 codexes, my sense is these tools will allow people manage to be higher leverage, and it will allow them to manage teams of way more than the current best practice of I think is like six to eight, right, first off for engineering. You kind of see this applied to the non-engineering domains, like support or operations where it's like previously-- where previously the size of the support team might be limited, but as you can pass off more things to agents, you can actually do more work and also manage more people this way. I think the same thing might happen for people management as well, especially in tech companies. And we're already seeing this. There are some teams where there are EMs managing quite a few people, and they're doing it pretty adeptly because of some of these tools where they can get higher leverage and understand what their team's doing, understand organizational context a little bit better and operate in that way. I love this advice that with the way you described it, as you've always leaned into top performers and spent more time with them and blocked them, make sure they're happy. The way Mark Engerson is just a black guy, that's the way he phrased it, is, yeah, it makes good people better and it makes great people exceptional. Yeah, yeah. And what you're saying here is just doing this more and more is probably the right move, spending more time with the best people on your team to unblock them, make sure they have everything they need. Yeah, a very good example right now is there are, I would say, like a group of engineers internally who are really codex-filled and are thinking through what the best practices are for interacting with this model. And that is just an extremely high leverage thing for them to do. And so just like as a manager, I'm just like, yeah, go, explore this, whatever best practices come out of this, we have to share with the org. Well, we'll do all these knowledge sharing sessions, we'll share documents and best practices everywhere. So things like that just elevate everyone. And I view that as another example of this trend that we're seeing where the top performers really get exceptional. People just have a sense, this is big. AI is changing so much, the world is changing. It's going to be a heat deal. What do you think people aren't pricing in yet into what will change and to where things are heading? Just like what's an example of something you think are like, okay, we're not realizing this yet. So one of my favorite kind of phrases or things that have come out of this holy eye wave is the idea of the one person billion dollar startup. I think I should examine me if I were like, Sam maybe in the first one to say it, but it's fascinating to think about, right? It's like, yeah, if people are so high leverage, at some point they'll likely be a one person billion dollar startup. And while I think that's really, really cool, I think people aren't really pricing in the second or third order effects of this. And really what, because what the one person billion dollar startup implies is that there's one person can just have so much more agency and so much more leverage using one of these tools that it is just super easy for them to get everything done that they need to for their business to ultimately create something that's a billion dollars. But I think there are a couple other implications of this. So one of them is if it's easy for a person to create a one person billion, or if it's possible for a person to create a one person billion dollar startup, it also means it's way easier for people to just create startups in general. Like I actually think this will, like one second order effect of this is, I think there's gonna be a huge startup boom and like small like SMB style boom, where anyone can build software for anything, right? Like one, you're kind of starting to see this play out in the AI startup scene where software's became a lot more vertical oriented, where like these verticals, like creating some AI tool for some vertical tends to work quite well because, you know, you really lean into that particular domain, you like really understand the use case for it. And so if you play out AI, there's no reason why you can't have like 100 X more of these startups. And so I think one world that we might end up seeing happen is in order to enable a one person billion dollar startup, there might be like a hundred other small startups building bespoke software that works extremely well to support other types of, you know, small, small one person, you know, billion dollar startups. And so I think we might actually enter it to a goal in the age of like B2B SaaS and just like software and start it in general. And so I think that's a really interesting trend to kind of see because as it's really, as it gets easier and easier to build software, as it's easier and easier to, you know, run a company, you might actually just end up seeing way more of these these startups. And so the way I've been thinking about is like, yeah, there might be one one person billion dollar startup where there might be like a hundred, you know, a hundred million dollar startups. There might be tens of thousands of 10 million dollar startups. And as an individual, it's actually pretty great to have a 10 million dollar business life. That's like enough for your stuff for life at that point. And so, you know, we might really see seen explosion in that way. And I feel like people aren't really, you know, pressing that in. There's another kind of like third order effect of this, you know, and again, all of these, I guess you get to the further and further out predictions. I think there's a lot of uncertainty. I think if we end up moving to this world where you end up with these like kind of micro companies building software that works for one or two people of who own the company and are working there. I think the startup ecosystem will change. I think the VC ecosystem will change. You know, we might end up in a world where there's just like a handful of big players that are offering platforms and supporting all of these startups. But, you know, the types of ventures scale return startups that can really 100 or 1000 X your investment might actually end up shrinking. If you end up having a bunch of these, you know, smaller 10 to 50 million dollar companies, which are not great for venture solar returns, but are great for the individuals, the high-adrency individuals who are now, you know, really needing to AI to build these businesses for themselves. I love how many order like order effects we've been through. I wanna hear the fourth order effect now, sure. I'm just joking. I can't, it's two, four thorders, two, two, it's two gigabrain for me. I can't think that far ahead. It's like conception or just everything gets slower during time you go deeper into something. - Yeah, yeah. - Every layer. Okay, so the billion dollar startup, I've been, I think about this a lot 'cause I'm not gonna be a billion dollar startup 'cause what I'm doing is not venture scale in anyway and not super high leverage, but just could see how many support tickets I get from just like the most ridiculous things. It's hard for me to imagine one person, like I'm bearish on this billion dollar startup. I just wanna share this thought. Simply because of the support costs, even if AI is helping you at a billion dollars, just like, unless your ACVs are very high and you have very few customers, I just, dealing with support and people are like, you know, like they can solve their own problems, but they're like, I'll email support ask about this thing. Just dealing with that is hard to scale is in my experience. So unless you have, in my opinion, unless you have a bunch of contractors, which I don't know, is that count? Does a single person company, I feel like it's very difficult to scale a billion dollar startup and not have someone helping you with at least the support work. And AI, I think we'll take you so far. - So I think that's true. And actually, I think my view on it is slightly different, which is I think that your Lenny's podcast might end up becoming a billion dollar startup, but what I think might happen is instead of you, kind of being the one person who has to dispassion AI to solve and fix those support tickets, I think what might end up happening is there might be a whole smattering of other startups that are building software and software. super and like super tailor towards what you might need. And so, you know, there might be like 10 or 20 startups that build support software for podcasts and newsletters. And that might be a one person startup. Like it doesn't need to be a big one. And it's, and you know, they might be able to just code up this product very, very easily. They're able to kind of like build their own thing. And because it's so tailored and unique and hopefully you know useful for you, it might be something that you purchase as the one person building all our startups. - I would buy that. - I would buy that. Yeah, there's like a question of like what you in house and what you like kind of outsource. And what I think might happen is because the cost of writing software and building products is collapsing so much, you might end up outsourcing a lot of this and in doing so, reducing the size of your company. And so that's kind of the world that I think might end up happening. Again, there's like high uncertainty on what might play out here. But the end result still might be a one person driving this like high, high massive leverage company that might actually reach a billion dollars. I could say that. I also think about Peter at ClawedBotslash, Moldbotlash, OpenClaw have just like how he barrage he is right now by all these asks and emails and pings and dms and PRs just like, I'm curious to see, and he's not even making any money out this thing. - Yeah, I can't imagine what it's like to be him right now. It's like absolutely insane. It's probably like the months after we launched ShatchyBT, the craziness that was as one man. He's coming out on the board by the way in a week. - Oh, exciting. - Yeah. Maybe the fourth or third effect is distribution becomes increasingly important because there are so many freaking things trying to get your attention. So people with an audience and platform, I think become more and more valuable, which is good stuff. Okay, I wanted to come back actually to your management stuff. So I really loved your insight about spending more time with our performers has been really successful to you. Just thinking about you as a manager of a team that is building the platform that powers basically the entire AI economy, like every AI startup is building on your API. Clearly you're doing a great job. What other kind of core management lessons have you learned? What do you find is really important and key to your success as a manager of engineers and just people? - Yeah, I think a lot of the lessons that I've learned here, I don't know how specific it is to the opening API or some of our enterprise products in particular. I think my management philosophy has obviously changed over time but I think it's probably stayed the same more than it's changed over time. One of these principles is kind of what I talked to you about before which is spending a lot of time with top performers, like actually spending and to be very concrete. I think it's more than 50% of your time with your top performers, with maybe your top like 10% performers and really, really trying your best to empower them. The way that I think about it is, is kind of come back to this analogy of software engineer as a surgeon which comes from the mythical man month book. So it's actually, it's funny. So I pull it from the book but in the book, they actually describe this world where, I think they were like predicting the future because I think the book was written like in the 70s or something. They said that software engineering might end up moving into a world where the software engineers are like surgeons or like in a surgery room. There's like one person doing the work and there's the one person like cutting whatever and doing all the surgery. And everyone else in the room is there to just support them. It's like the nurse and the assistant, the resident and the fellow. And then the surgeon's like, I need a scalpel and they give them a scalpel. And then they're like, I need this tool and this machine and they'll bring it over. Everyone's there to just support the one surgeon. And so the mythical man month actually predicted that that is kind of the direction that software engineers are gonna go. I don't think that's exactly played out where it's much more collaborative and like it's not only one person doing the work but I've always really liked that analogy. And that analogy is actually what I strive to kind of emulate in my own management philosophy which is software engineering isn't really like surgery where it's not just one person doing work but the way in which I like treating the people on my team and the way that I act as a manager is I want to empower them and make them feel like they're a surgeon and in so far as like making sure that I'm supporting them and making sure they have everything that they need to do their work and it feels like they have an army of people kind of supporting them and looking around corners and giving them everything that they need when it's really just me as the manager. And so like the example that I give is looking around corners and unblocking people, especially from an organizational perspective is extremely extremely useful. And again, going back to the AI conversations even more important nowadays, right? Like if people are just like cranking PR after PR the main thing bottlenecking progress and you know shipping something tends to be organizational or like process oriented. And if you as a manager and kind of look around corners and kind of unblock the team, if you can, you know, like if the surgeon needs scalpel but you know the manager kind of already has a scalpel ready for them, that's the best case scenario. That's kind of the way that I approach management and especially engineering management. And so that's something that's really, really stuck with me over time. And even though you know, software engineers aren't exactly surgeons that metaphor is always kind of saved my mind as of a risk micro. - I love that. And I feel like I wonder if that's something that AI can help with is look around corners and predict here this engineer is going to be blocked by this decision. We need to figure this out. Would you get that? - Yeah, that's actually a really good point. I haven't tried this yet, but I wonder what would happen if I ask a Chad GBT hooked up to a company knowledge, you know, like what are the active blockers? Look through all the notion docs, what are maybe Slack messages, you know, it's probably in Slack somewhere. What are the active blockers on my team? And is there something I can do to help? Now, that's very interesting. I have not thought about that, but you're right. - We just had an insight right here. - Yeah. - Yeah. And I think even more interestingly, what do you anticipate will be a blocker for this engineer or this team in the coming months? - Yeah, you asked the model, you asked the AI to do the second and third orders. - There you go. - Things anticipate that. And just by what the blockers will be next month too. - I agree. - I think we've got a good idea right here. - Yeah. - Yeah. - This episode is brought to you by DataDog. Now home to Epo, the leading experimentation and feature flaking platform. Product managers at the world's best companies use DataDog. The same platform they're engineers rely on every day to connect product insights to product issues like bugs, UX friction and business impact. It starts with product analytics, where PMs can watch replays, review funnels, dive into retention and explore their growth metrics. Where other tools stop, DataDog goes even further. It helps you actually diagnose the impact of funnel drop-offs and bugs and UX friction. Once you know where to focus, experiments prove what works. I saw this firsthand when I was at Airbnb, where our experimentation platform was critical for analyzing what work and where things went wrong. And the same team that built experimentation at Airbnb built Epo. DataDog then lets you go beyond the numbers with session replay. Watch exactly how users interact with heat maps and scroll maps to truly understand their behavior. And all of this is powered by feature flags that are tied to real time data so that you can roll out safely, target precisely and learn continuously. DataDog is more than engineering metrics. It's where great product teams learn faster, fix smarter and ship with confidence. Request a demo at datadoghq.com/lennie. That's datadoghq.com/lennie. - Okay, I'm gonna shift to talking about the API in the platform that you all build. So you work with a lot of companies implementing your API, your platform building on your tools. You told me that you find that a lot of companies actually have negative ROI on their AI deployments, which I think is what a lot of people you read about and feel and think. And it's interesting actually seeing that. What's going on there? What are they doing wrong? What's happening in the world of AI and deployments in ROI? - Yeah, so to be clear, I don't explicitly see quantitative numbers around this. It's actually really hard to measure. These things, but especially from observing some companies kind of trying to do AI, I would not be surprised if a lot of AI deployments are actually negative ROI. I mean, part of this too is that I think there's also general sentiment from folks around the country, like basically outside of tech that AI is being forced onto them. And I think part of this is probably a symptom of some negative ROI AI deployments. A couple of things I've observed around this. So one thing is, and I think I come back to this again and again, like I think we in Silicon Valley just forget that we live in a bubble. We are so like Twitter is a bubble, it's our ex is a bubble, Silicon Valley is a bubble, software engineering is a bubble. Most people in the world, most people in the US are not software engineers, are not very AI-cold, are not following every single model release. And so we're just like highly out of the loop on how to use this technology. And so we always talk about all these best practices for codex, all these codex-filled people within OpenAI. Sure, everyone on X who posts are crazy power users of these AI tools. They lean into skills, they lean into agents.md, mcp's. Yes, yeah, all of that. And when I talked to some of these companies, and I talked to the actual employees using these, it's like the most basic thing that they're trying to do. And they have very little understanding of exactly how the technology works. And so that's kind of like one big observation for me, which is like, they're asking very simple questions of these things, they're really not pushing it just yet. And so that kind of goes back to, that kind of ties into what I think more companies do or what should do or what a more ideal AI deployment setup looks like. and this is it. This is kind of how we've run things with an OpenAI too. The companies where I think it started to work really well have a combination of both top-down buy-in. So it's like the C-suite, it's like we want to become an AI first company. So there's buy-in, they buy the tools, they have exec support. But it also has bottoms-up adoption and buy-in. And so what I mean by that is it has like actual employees doing the work who are really excited about the technology and are willing to learn, evangelize, build best practices and kind of like knowledge share within the organization. We've seen this a lot internally. So like obviously OpenAI has always wanted to be a very AI-centric company. But when it really started taking off as when was with the introduction of codecs and these tools where people, like actual employees themselves could start applying into their work. And I think you really need this because at the end of the day, everyone's work is like very different. It's like very unique. Software engineering is different than finances, different than operations, different than go-to-market, it's sales. And so there's like a lot of these like last mile intricacies of work that needs to really be done in a bottoms-up fashion. And so my sense is a lot of these, these AI deployments don't have like, don't have bottoms-up adoption. Like it was like an exec mandate and it's extremely top-down and is very divorced from what the actual work looks like. And as a end result, you end up with a giant workforce that doesn't really understand the technology is like, I know I'm supposed to use this and maybe it's like on my performance review too, but I'm not sure what to do. And they look around, no one else is doing it, there's no one else to learn from. And so my recommendation for a company's kind of pushing this is find, or maybe even staff with full-time team internally, that is this kind of tiger team internally that can explore the full extent of the capabilities, apply to specific workflows, do the knowledge sharing, create excitement within folks who might want to use this technology. Because in the absence of that, it's very difficult to pick up. And who would you put on this tiger team? Is it like engineer led, do you find in your experience is it cross-functional sort of team? Yeah, it's interesting. So also a lot of companies don't have software engineers. And so the pattern I've seen is it tends to be these like software engineering adjacent, like basically technical people, but are not software engineers. I think those are the ones who tend to get most excited around this. It's like maybe the support team operations lead who doesn't code, but loves using these tools and is like an Excel wizard or something. And so it's like technical adjacent or coding adjacent and pretty technical. Those are the kinds of people that have seen in these companies who just really light up and get excited around this. And you can usually build a team around that. But yeah, it's like oftentimes not software engineers. Software engineers I think will understand this, but not every company has software engineers is actually kind of a rarity. They're hard to find. They're expensive. And so it's these other types of folks. What I'm hearing is the anti pattern is top down. This is very the CEO found an exact team just like we are going to go AI first. We're going to lead into AI. Everyone's going to be judged on their performance using AI tools, how much your productivity is increasing things to AI. And without with that being just top down and not creating a team that is bottom up spreading the gospel, you find it doesn't work. Yeah, exactly. And the advice is find the people that are most excited. And instead of kind of having them spread out through the organization, what you find works is create a little AI kind of evangelist team that finds ways to use it and kind of spreads it across the work. Yeah, I mean, another kind of like hearing you play back to me, another way to think about it kind of time back to my own, imagine a philosophy is find the high performers in AI adoption and empower them, let them build half of ons, let them hold seminars, do knowledge sharing, kind of create the seeds of excitement internally. Okay, amazing. There's a couple of hot takes I want to hear from you, something that I've seen you talk about and share. One is you've shared that talking to customers and listening to customers, not always the right strategy in AI and it might often lead you astray. I don't know if it's that hot of a take. I think the main thing here is obviously you should talk to your customers, like it's like useful to our customers. I just think that AI field, especially what I've seen over the last kind of like three years, working on the API and seeing kind of all that evolves, is the field and the models themselves are just changing so, so quickly. They tend to like disrupt themselves, especially around the like tooling and the scaffolding space. There's this quote that I read actually earlier this week from an ex article by this guy named Nicholas, who's the founder of a star called FinTool, where I think he was sharing a lot of the best practices that he has learned through building AI agents for financial services, I think at a start FinTool. May I just phrase that I thought was really good, which is the models will eat your scaffolding for breakfast. Like if you look, if you rewind back to 2022, right when ChatGBT launched, these models were pretty raw and there was like all this product scaffolding and things, especially in the developer space, to basically try and steer the model and build a scaffolding around it to get it to do what you want. Like agent frameworks, there's like vector stores, I think was like really popular back then. And just like a whole smattering of tools here. And as you've kind of seen the field play out, the models have just changed so much that and gotten so much better that they ended up, yeah, literally eating some of the scaffolding and I think this is even true today. So I think the article from Nicholas, actually, the current scaffolding, which is fashionable, is skills, files based context management. I could see a world where at some point, that's no longer useful, where the model can actually manage all that themselves or like, or there might be, it's hard to predict, you might move onto some new paradigm where you know I already need this file based skills type thing. You have literally seen this play out, right? Like the agent frame or something are a little less useful now. There's a period time like 2023 where we thought vector stores is going to be like the main way for you to bring organizational context into the models. And you need to vectorize and embed every bit of your corpuses and then you do all this work to like figure out the vector search, to like optimize that to fill out the right and for a kind of time. All of that is scaffolding because the model was not good enough. And it turns out, you know, in this case, it turns out as the models get better, a better approach is actually to take out a lot of that logic and trust the model and give it a set of tools for search. It doesn't need to be a vector store. You could actually just hook it up to any type of search. It could literally be files on a file system like skills in agents MD to kind of steer it as well. Obviously, they're still a place for vector stores. I know a lot of companies are still using it, but the entire scaffolding around that and building an entire ecosystem around that and assuming that that's the only scaffolding that you need has really changed. And so tying this back to the like, you know, it's, you know, you don't always have to listen to your customers because the field is changing so much at any point in time, you know, a lot of people are kind of in this local, local maximum. And if you just blindly listen to your customers, they'll be like, yeah, I want a better vector store. Like I want a better, I want a better, you know, agent framework for this. And if you had just kind of only chased down that path, it actually would have led you to, you know, build something that again is the local maxima, whereas as the models get better, we've had to reinvent and kind of rethink the right, right abstractions and the right tools and frameworks to build around these models. And the cool slash exciting slash kind of crazy annoying part is it's a moving target. And so yeah, like the current current smattering of tools and frameworks right now will likely need to evolve and change pretty significantly over time as the models get smarter and better. But that is just a nature of building in the space. I think that's what makes it exciting. But it also means when you talk to customers, you kind of need a balance, the exact feedback that they want with where you think the models are going and where you think things will trend over the next one of years. It's interesting how this is the bitter lesson is, you know, this big lesson that AI and ML folks learned, which is just like don't the less you over complicate the less logic you add to machine learning AI, the more it'll be able to scale and grow and just like take it all away and let it just just compute basically just give it more power to get smarter on its own. There's literally a version of the bitter lesson applied to like building with AI where you know, we were trying to architect all this stuff around and turns out the models are just kind of, you know, heated all the way. And and and and honestly like open AI API team has like been guilty of this where we kind of like took some, you know, left and right turns when we shouldn't have. But yeah, the model still end up models get better and we're all learning the bitter lesson day and day out. So what would be the key takeaway for folks building on say the API or just building agents and you know, having to build a little bit of surround for now is it just yeah, what would be the advice? My general advice and I've been giving this to people for a while and I think still true today is make sure you're building for where the models are going and not where they are today. You know, the the it's it's clearly moving target. And I think a lot of the companies that I've seen startups that have seen really, really do well is they build a product for an ideal like type of capability that is like maybe 80% of the way there today. And it like they know, you know, having a product like kind of works, but it's like just almost there. But then as the models get better, you know, suddenly it might click and then their product now is incredible because it works, you know, like, like maybe with like oh, oh three at some point, it's only worse with 5.1 5.2 suddenly it unlocks it. And they're building these products with the like the model capability improvements in mind. And with that, you end up creating an experience that's way better than. if you had assumed that it's static in the first place. And so that'd be my general advice, which is build for where the models are going and not where they are today. You end up building a better product. You may need to wait a little bit, but the models are getting so much better, so quickly you often don't need to wait that long. >> So to follow that thread, where are, like in the next six to 12 months, where is the API heading, where is the platform heading, where the model's heading, as much as you can share, there's a lot of secrets here that maybe you're more excited about or do you think that people should start to prepare for, however much you can share? >> I mean, so the obvious one is how long of a task these models can do coherently. So there's like the meter benchmark that I think tracks software engineering tasks and how long of a task can these models do 50% of the time, 80% of the time. I think we're at something like multi-hour tasks being able to be done by a software engineering task, being able to be done by these frontier models, 50% of the time, and then I think 80% of something like just under an hour. But the sobering thing about that chart is they plot all the previous models on this chart as well. So you can really see the trend of this. That's something that I'm really excited about, which is, I actually think products today really optimize for tasks that the model can do for like minutes at a time. Like even codecs and like the coding tools, I'd say like, it's in the client, you're kind of like seeing it be interactive. It's really quite optimized well for like maybe at most 10 minute type tasks. I have seen people push codecs to the limit into like multi-hour long tasks. But again, I think that's more of the exception. But if you follow this trend, like I think in the next 12 to two months, we could see models that could do multi-hour long tasks very, very coherently. At some point it might reach like six hours a day long task where you kind of like dispatched and have it do things on the zone for a while. The types of products you build around that will look very different. You want to give the model feedback. Obviously, don't want it to completely run wild for a day. Maybe you do, but you probably don't. And then the universe of things you can have the model do really expand. So that's something that I'm really excited about seeing. Another thing over the next 12 to 18 months where I think it'd be really cool is improvements in the multimodal models. And actually by multimodality, I'm mostly thinking about audio. Here where the models are pretty good at audio, I think they're going to get a lot better at audio over the next six to 12 months, especially the native multimodal model, the speech to speech ones. I think there's also interesting work being done around new types of models and architectures on the multimodal audio side as well. But audio, especially in the enterprise and in business setting, I think is a hugely underrated domain. Still, I get everyone talks about coding, it's all text. But we're talking in audio. A lot of the world's business is done. The audio, a lot of services and operations are done via talking in audio. And so I think that area is going to look very exciting in the next 12 to 18 months. And I think there will be even more unlock for what we can do with audio models there as well. Amazing. So quick summary, expect agents and AI tools to run longer to that trajectory to continue to increase and then audio and speech becoming a bigger deal, more first party and native and better and core to the experience. Yeah, extremely cool. OK, I want to go back to one of your hot takes, another hot take that I've seen you discuss your big-- your very bullish on business process automation as an opportunity in the world of AI. Talk about that. Yeah, this goes back to the thing that I said previously, which is we live in a bubble in Silicon Valley. And a lot of the work that we do, that we're used to software engineering, product management, building products, is very differently shaped than the work that runs our entire economy. And I see this in and down when I talk to customers. If you talk to any company that's not based in-- it's not a tech company, there's a lot of business processes. And so what I mean by this is I generally delineated as there's software engineering is open-ended knowledge work. And this is why I think tools like Codex tend to be quite good because it's exploring and you're giving up these open-ended things. But software engineering is fundamentally pretty open-ended and is not very repeatable. So you build a feature. You're not trying to build the exact same feature over and over again. And a lot of tech jobs are in the space. I think data science is kind of in the space as well. Even some of the strategic finance stuff. But as you move further and further away from software engineering and what is core and tech, a lot of jobs are just business processes. They're like repeatable things, repeatable operations that some manager at a company has iterated on. There's usually a standard operating procedure that people want to do. And you don't want to deviate from it that much. It's like in software engineering, the ingenuity is endeaviating. But a lot of the work being done in the world is actually just running through these procedures and operations. If I call a support line, they're running through one of these. If I call my utility company, there's a bunch of processes and things that they can and cannot do for me. And so I'm just extremely bullish on this general category of like-- and I think it's underrated because it's so different from what we think about it in Silicon Valley. People tend to not think about it. But how can we apply AI and some of the tools and frameworks that we have towards this business process automation, towards automated, automating, and making easier repeatable business processes with high determinism that is fully integrated with business data and business decisions and different systems within an enterprise. And how can I actually make that process better? Because I actually think there's a lot of opportunity and a lot of work to be done in that area. And we just don't talk about it, because it's a little bit less in our real house. So you take care just to make sure I fully understand it is you think there is a much bigger opportunity outside of engineering for AI to impact productivity of companies and also jobs of these folks that are doing these kind of repetitive, easily automated tasks. Impact jobs and also just impact how work is done. So much of work is done in this way. You think about what-- basically, I talk to customers all the time, big enterprises. How will AI transform my company? How will it run in a world with AI in 20 years? And software engineering is part of the story. But there's so much more on the business process side. And I actually think it might look even more different on the business process side and the work there is pretty substantial. It's actually interesting. I don't know from an absolute percentage-- or absolute basis, I don't know if it's bigger or smaller than software engineering. Software is pretty huge and pretty expensive as well. But it is pretty massive. And it's definitely bigger than you would think it is based off of how people talk about it or don't talk about it on X or Twitter. OK. In going in a slightly different direction, having built a platform, building the API, people building on the API, the biggest question on people's minds is always just, how do I not have open AI squash my idea and build their own thing and then destroy this market I created? What's the general policy? What's the general philosophy of how startups should think about where open AI is unlikely to go? My general answer here is the market is so big and so massive. I actually think startups should just not overly think about where open AI or these labs are going. I've talked a lot of startups that have not worked out, startups that are doing really well. Every startup that I've seen that has kind of fizzled out is not because open AI or big lab or Google or something has come to squash them. It's because they built something and it really didn't resonate with the customers. Whereas the ones that take off, even in very competitive spaces, coding, cursor is huge at this point. And it's because they build something that people really love. And so my general advice is don't overly stress about this. Just build something that people like. And you will have a space in this. I can't overstate how big of an opportunity there is right now. The opportunity to space a building with AI so big-- a good example of this is the space is so big that the over-tune window of what is acceptable and not acceptable for VCs to do has completely changed here. VCs are investing in competitive companies left and right. It's just the space is so big because the opportunity is unlike anything that we've seen before. And while that affects how VCs operate from a startup perspective, it's the most empowering thing in the world. Because even if you just build something that some people really, really love, you will end up with a massively valuable business. And so that's why I tell you don't owe anything about it. The other thing I also think is important to remember, at least from an open AI perspective. One thing that we've always held there in here in deer, which both Sam and Greg help reinforce from the top as well, is we actually view ourselves fundamentally as a ecosystem platform company. The API was our first product. We think it's really important for us to foster this ecosystem and continue to support it and not squash it. And so if you look at the decisions we make, this is all we've threw it. Every single model we've released in one of our products gets released in the API. Even we release these codex models now that are a little bit more optimized for the codex harness. But they always find their way into the API. And all of our customers end up using those. We don't hold back on any of that. We think it's really important to keep our platform neutral. So we don't block competitors. We allow people to have access to our models. We also want-- we've recently been testing more of the sign-in with ChatGPT product as well. And so we want to foster this ecosystem. I think it's really important that we do so. The general thinking about this is a rising tide lifts all boats. And we might be an aircraft carrier were pretty big at this point. But we think it's important to raise the tide, because everyone benefits. And I think we'll benefit as well. Our API itself has grown pretty significantly, because we act in this way. And so I'd really encourage people not to view OpenAI as this kind of thing that will just shove people out of the way. But instead focus on building some available. And we remain committed to providing an open ecosystem. Why is that important to OpenAI? Just this focus on building a platform, creating a way for people to build businesses. Is that just that's been the vision from the beginning? We want this to be a platform. It's been the vision from the beginning. It goes back to our charter, actually, our mission. So the OpenAI mission has always been to want to build AGI, so we're obviously doing that. But then the second thing is to spread the benefits of it to all of humanity. And there's kind of a lot of-- the main part, there is all of humanity. And obviously, ChatGPT is trying to do this. We're trying to reach however many in the whole world. But very early on-- and this is why we launched the API back in 2020 or something, really early-- we don't think we as a company will be able to reach all of humanity. There's every corner of the world is pretty deep. And so we actually feel like in order for us to fulfill our mission, we need to have some platform style thinking where we can empower other people to build the customer support bot for podcasters and newsletter hosts, because we're not going to be able to do it ourselves. And so we've largely seen this play out with the API. This is why we talk to so many of our customers and really love seeing the diversity of things built on. But yeah, it's been-- there's the say one, because it's kind of-- we view it as an expression of our mission. And you haven't even mentioned the app store. The guys are launching the ChatGPT app store. Yeah. Is that under your umbrella, by the way, or is that a different org in team? It's a different team, so it's under ChatGPT. We obviously collaborate very closely with them. And they built an app's SDK, which is built in close collaboration with their team. But that is more within the ChatGPT umbrella. But that is also another example of this. It's like-- ChatGPT is-- we kind of have these 800 million weekly active users who are just coming over and over again. It's a great asset to have as a business. But man would it be better if we could somehow allow other companies to come in and take advantage of this as well and build for this audience as well. And then ultimately, we think it will help us expand that group as well. And so it all kind of comes back to the mission. And we find that being a platform, being open tends to help here. Just that number, 800 million, I think, it's MMAs. Just like-- No, no, no, weekly. Weekly active. Yeah, that's crazy. Billion people using weekly. It's like, it's sort of how these numbers were just used to now. But that's insane. Unprecedented. Yeah, it's mind-boggling for me to think about from a scale perspective, honestly. And the way I think about it is 10% of the world. And growing, by the way, it's shooting up, come to ChatGPT and use it every day. Or sorry, every week. And this point, I just want to double down on this point. You're making OpenAI's mission was to make AI available to all of humanity. And I think some people just that. They're like, oh, you know, cost money. Like, the fact that there's a free version of ChatGPT that anybody can use that is not so different from the most powerful AI model that exists in the world for free. That's not gated that anyone can use. Like, if you're a billionaire, there's only so much more you can get out of AI than what someone, you know, in a village in Africa can get. And I know that's always been really important to OpenAI. Yeah, yeah. I mean, like, that's why I think we've leaned into the health work. We've leaned into like, like, education is going to be a very interesting here. The other insane kind of trend here is the free model has gone so smart over time. Like the free model back in 2022 was, you know, like, well, it's good at the time, but it's like nothing compared to what you get today because you get to be five today. And so the like, you know, raising the floor across the world is kind of, you know, something that we're really trying to do. And we view it as part of our mission. The other flip side of this, by the way, is like, you know, kind of talking about like the billionaires or whatever. I know people love saying like, you're using the same iPhone that like, you know, Steve, or sorry, like Mark Zuckerberg's probably using her like the billionaires are using. Like for like $20 a month, you're basically using, you know, like using the same AI that, you know, the billionaires are using. For like $200 a month, you get the same pro model that, you know, all the billionaires are using. But they're probably not using pro for everything. They're probably just using the plus tier ones for their day and day out. And so, yeah, this kind of like democratization and just like spreading of this benefit, like across all the world is, and that's really meaningful to us and something that drives a lot of what we do. One last question, just for folks that are thinking about building on the API are just like, oh, wait, I could do cool stuff with open-air models and APIs. What does your API and platform allow people to do? Like, I know you can build agents on top of the platform. Just to talk about what you allow. So fundamentally, the API offers a bunch of developer and points. And these developer embers basically let you sample from our models. The most popular one that we have right now is one called responses API. And so this is an endpoint. And it's optimized for building long running agents. So agents that will work for a while. So what you can basically use, you can add a very low level. You're basically just giving the model text. The model will work for a while. You can kind of pull it to see what it'll do. And then you'll get the model response back at some point. That's the lowest level primitive that we have for people. And that's actually what a lot of people use. That's the most popular way of building on top of API. With that, it is super unimpinated. And you can do basically whatever you want, it's the lowest level thing. We've also started building more and more layers of abstraction on top to help people build some of these. And so next layer up, we have this thing called the agent SSTK, which has also gone extremely popular. This allows you to use the response API or some other API endpoints that we have to build what you might more traditionally think of as an agent. And I kind of work in an infinite loop. It might have sub-agents that it delegates to. It starts building all this framework, all this scaffolding actually. We'll see where this all goes. But it makes it a lot easier for you to build these kind of agents, giving it guard rails, allowing you to like farm out sub-tasks to other agents, and kind of like orchestrate a swarm of agents. The agents SSTK kind of allows you to do that. And then above that, we've now started building tools to help also with kind of like the meta level of deploying an agent. So we have this product called agent kits and widgets, which are basically a bunch of UI components that you can use to very easily build a very beautiful UI on top of either our API or agent SSTK. Because a lot of times these agents kind of look very similar from a UI perspective. And so there's agent kit. We also have a smattering of like eVal's products, eVal's API, where if you want to test and like, see if your models, your agent or your workflows working, you can test it in a very quantitative way using our eVal's product. And so yeah, I view those like these various layers. They're all kind of helping you build what you want with our AI, with our models, and with increasing levels of abstraction and how opinionated it is. And so you can do that. You can use the whole stack and it very quickly allows you to build an agent or you can go down the stack as low as you want to basically response API and build whatever you want because of how low low-potes. >> Sure. When is there anything else that you want to share anything else you want to leave listeners with? Anything we haven't touched on that you think might be helpful before we get to our very exciting lightning round. >> The only thing I'd leave folks with is yeah, I think I think the next two to three years are going to be some of the most fun in tech and in the startup world that that will have in a very long time. And I would just encourage people to not take it for granted. I entered the workforce in 2014. It was great for like a couple of years. I felt like there was like a period of like five to six years where it wasn't very exciting in tech. And then in the last three years, I just spend the most insanely exciting, energizing period of my career. And I think the next two to three was going to be a continuation of that. And so when Kurt will not take it for granted, I'm trying to not take it for granted. At some point, you know, this wave's going to play out and it's going to be a lot more incremental. But in the meantime, we're going to get to explore a lot of really cool things and then a lot of new things and change the world and change how we work. And so that's the main thing I'd leave folks with. >> I love this message. I want to spend a little more time on it. When you say don't miss it, is it, what do you recommend people do? Is it just build, lean in, learn, join a company building, really interesting things? Like what's your advice to folks that are like, okay, I don't want to miss the boat. >> Yeah, I would just say engage with it. So it's basically like what you said, lean in, building tools on top of this is part of the, you know, it's part of the story. Just using the tools, like you don't, you know, you don't need to be a software engineer to lean into this. All, I think a lot of jobs are going to change here. So just using the tools, understanding the limitations of what it can and cannot do, so that you can kind of watch the trend of what it can start to do as the models improve. And yeah, and so it's basically like getting used and get it. getting used to this technology and getting familiar with it instead of kind of like laying back and letting it pass you. On the flip side of that, there's a lot of stress and just anxiety around like there's so much happening. How do I keep up? I got a learner, a clot bot this week. Oh, God. Is there something you learned about it? You're at the center of this. How do you not get overly stressed and worried about missing things that are going on and just key stand top of news with what are some things you've done learned? Yeah, so I think I'm personally a bad example of this because I'm basically chronically online on X and our company slack. So I actually try and absorb. I end up absorbing a lot of it. What I will say is just like from observing other folks who are less addicted to this stuff like I am. Yeah, a lot of it is noise. You don't need to have 110% of this kind of pass your mind, like go into your mind. Honestly, just leaning into like one or two different tools, starting small is already more than you need. Here, I think just the combination of the frenetic pace of the industry X as a product just creates this insane kind of like this insane pace of news, which is honestly very overwhelming. The main thing is you don't need to know all of that to really engage with what's happening right now. Even something as simple as just like install the code X, client, play around with it. Install Chad G.B. Heen connected to a couple of your internal data sources, notions, slack, GitHub, and see what a Canon cannot do. All of that I think is a part of it. Amazing. Sure, when with that we reached our very exciting lightning round. I've got five questions for you. You ready? Yes, yeah, absolutely. First question. What are two or three books that you find yourself recommending most other people? I'll talk about one nonfiction one and one fiction book. A fiction book was I just finished reading it. I really recommend it. There is no anti-memetics division by QNTM. I think it's like an online author, but I saw it being shared on X. It's like a science fiction -y kind of book. I basically devoured it in like two days. It's super, super well-run, super fascinating. It's about a government agency that's fighting things that make you forget it. It's just a very smart, creative book that and fresh, honestly, in terms of source material that I really like. I'd recommend that one. The book is also unintentionally hilarious. It's meant to be like this sci-fi, almost like horror, solid book, but it was a mini-lathical times. That's the fiction book. Non-fixion, so I'm going to cheat and I'm going to recommend two of them. The last year I've been reading a lot more about China and the US-China relations. I think there are two books that came on the last year that have been really, really eye-opening for me in that regard. First one is the Dan Wang book, Breakneck. That one is really, really good. I really liked his analogy of the lawyerly, US is the lawyerly society. China is the engineering society and they're pros and cons to each. I read it and I was like, "Hmm, yeah, does seem like we're run by lawyers in the US." That's one. The other one is the Patrick McGee book on Apple and China. It was super, super interesting. I'm a huge Apple fanboy. If you could see my desk right now, it's all Apple stuff. Just one, it was just super fascinating learning about Apple's relationships with China. Then two, it just had a lot of inside information about Apple as a company that I found fascinating. It was also quite a page turner and also very timely books. The antimicmedic book sounds amazing. I'm buying it right now as you're talking. It's like, I think it's only a couple hundred pages. I literally finished it today. It was just so good. Great tip. Favorite movie or TV show you have really enjoyed? That one's tough because I have two kids and a busy job. I really haven't had much time to watch TV shows. I will say in the last couple of weeks, I watched a couple episodes. I'm actually a big anime guy. I watched a couple episodes. There's a new season of this anime called "Judges to Kaisen." That's out. The season three of "JJK" was really good. In general, I'm a huge fan of Japanese anime. I think they create the most novel and unique plots in universes that Western media has shied away from. Generally, big fan of that. I haven't really watched much, but saw a couple episodes of "JJK" recently. Extremely understandable in your role. Yeah. Favorite product. You recently discovered that you really love. Yeah. I recently had a set up a Wi-Fi and home networking. I went all in on ubiquity routers and cat security cameras. I'd never heard of it before. I had to do this. I always just had a very simple set up. It is just such a well-built product. I don't know if you used it before, but it's basically the apple of home networking. Beautiful products. The thing that actually makes it extremely good is that software is good. They have a really great mobile app to help manage all of the home networking. Basically, you can use it to buy wireless routers. You need Ethernet wiring throughout your house to use it. I actually think what makes it really good are security cameras. If you have security cameras that are plugged into ubiquity ecosystem, they have an incredible mobile app, an Apple TV app, an iPad app, to see the live feed of your cameras. They're a little pricey, but not that pricey. It's been just an incredible product experience. I went euro, so I made a mistake. Eros are pretty good too, but I'm not fully converted to ubiquity at the time. Okay. Two more questions. Do you have a favorite live motto that you find yourself going back to in work or in life? Yeah. The one that I always repeat to myself is, "Never feel sorry for yourself." There's a lot of things that are going to happen at work and life. Meeting yourself to never feel sorry and that you always have a sense of agency to pull yourself up is something that I've had to tell myself a lot. Also something that I repeat to a lot of other folks as well. Last question. Your previous life, you worked at Open Door, where you led work on basically figuring out how much to pay for houses. You basically built the model that told the company here is how much we'll pay for this house. What's a variable in the price of a house that you didn't expect is really important and impacts the price of a house? There's a bunch that were surprising. I'll maybe list the couple of most interesting ones. Power lines and high voltage power lines are super, super, actually, impacted price quite a lot. I didn't really fully internalize this until I went to Dallas and observed when your house sits next to one of these giant voltage lines, like buzzing. Most people have families, you don't want your kids near there. That was one that really surprised me. That makes sense. The other one, which was something that was always something really difficult for us to quantify, was floor plans. It is very important. Yes, of course, it's really important. Just quantifying what a good floor plan is like, what a really bad floor plan is like. We were doing all these things like how wide is the kitchen and what style of kitchen is it and then where's the master bedroom? It was just really, really hard to quantify. I remember floor plan was a big one because we'd have a home that wouldn't sell and then our ops team would go in and be like, yes, the floor plan is huge. How good do you tell? You go inside, you just feel it. The floor plan feels off. Those are ones that were surprising. The last one that was more impactful than I thought is general curb appeal and even the front door. I actually think there's a Zillow book on this where the front door placement tends to be the highest ROI for homes. Just the feel of as you walk up to the home, as a buyer, what you're interacting with and the first moments of the house, I think, was underrated hits and points. That is extremely interesting. I love that you had to figure out how to deal with all this encode and that. Yeah, and then floor plans. I would just start around like for floor plans. There's not digitized. There's a handful of people who have paper floor plans of all these homes and Phoenix and Dallas. A lot of fun stories from the open air days. Sure. Thank you so much for doing this. This was incredible. Working for Expanding Online and how can listeners be useful to you? Yeah. I'm online on Twitter, on X. I'm just @shurwinwoo. I mostly just tweet about OpenAI and API and some of the products that we're launching. How folks can be useful to me. I love hearing about things that people are building. If you're working on a startup, if you're hacking on an idea, I would love to reach out to me on X. I would love to hear about what you're building and learn about how OpenAI can help support you. Amazing. Sure. Thank you so much for being here. Yeah. Thank you, Lanny. Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lanny'sPodcast.com. See you in the next episode.

Key Points:

  1. AI code generation tools like Codex are now integral at OpenAI, with 95% of engineers using them daily and 100% of pull requests being AI-reviewed.
  2. The role of software engineers is rapidly evolving from writing code to managing multiple AI agents, akin to tech leads or wizards directing spells, increasing productivity but requiring oversight to prevent errors.
  3. Challenges include managing AI agent failures, often due to insufficient context, and adapting processes like code review and deployment to leverage AI automation fully.
  4. The field is advancing quickly, with current models considered the "worst they will ever be," emphasizing the need to build for future capabilities rather than current limitations.
  5. This shift may spur a golden age of B2B SaaS, as enabling large AI-driven startups could create demand for numerous supporting software tools.

Summary:

The discussion highlights the transformative impact of AI code generation tools like OpenAI's Codex on software engineering. At OpenAI, 95% of engineers use Codex daily, and all pull requests are AI-reviewed, significantly boosting productivity—engineers using Codex open 70% more PRs. The engineer's role is shifting from writing code to managing fleets of AI agents, compared to wizards casting spells, which requires skill to steer agents effectively and avoid errors like those in the "Sorcerer's Apprentice" metaphor. Challenges include stress when agents fail, often due to inadequate context, prompting efforts to encode tribal knowledge into documentation. Codex also automates code reviews and deployment, reducing tedious tasks. The rapid evolution of AI means models will improve, urging builders to focus on future capabilities. This AI-driven change may lead to a golden age of B2B SaaS, as supporting startups emerge. Overall, the field is in a dynamic, experimental phase, with engineers adapting to leverage AI's high leverage while navigating its imperfections.

FAQs

95% of OpenAI engineers use Codex daily, and 100% of pull requests are reviewed by Codex, with most code initially generated by AI.

Engineers are shifting from writing code to managing multiple AI agents, acting more like tech leads or managers who steer and review AI-generated work.

Agents often fail due to insufficient context or underspecified tasks. Adding documentation, code comments, or structured resources in the repository helps improve their performance.

Codex automates code reviews, reducing review time from 10-15 minutes to 2-3 minutes by providing suggestions, and it handles tedious tasks like linting and CI processes.

He compares it to sorcery, where engineers are wizards casting spells (incantations) through AI tools, making programming more intuitive and high-leverage.

A team is maintaining a 100% Codex-written codebase without manual intervention, forcing them to solve challenges like context gaps and refining best practices for AI agents.

Chat with AI

Ask up to 3 questions based on this transcript.

No messages yet. Ask your first question about the episode.