The AI Architect — Bret Taylor

If you’re in SF, join us tomorrow for a fun meetup at CodeGen Night https://lu.ma/re2o79hh! If you’re in NYC, join us for AI Engineer Summit https://ti.to/software-3/aies-2025/! The Agent Engineering track is now sold out, but 25 tickets remain for AI Leadership and 5 tickets for the workshops. You can see the full schedule of speakers and workshops at https://ai.engineer https://ai.engineer/! It’s exceedingly hard to introduce someone like Bret Taylor. We could recite his Wikipedia https://en.wikipedia.org/wiki/Bret_Taylor page, or his extensive work history https://www.linkedin.com/in/brettaylor/ through Silicon Valley’s greatest companies, but everyone else already does that. As a podcast by AI engineers for AI engineers, we had the opportunity to do something a little different. We wanted to dig into what Bret sees from his vantage point at the top of our industry for the last 2 decades, and how that explains the rise of the AI Architect at Sierra https://pulse2.com/sierra-conversational-ai-company-raises-175-million-at-4-5-billion-valuation/, the leading conversational AI/CX platform. “Across our customer base, we are seeing a new role emerge - the role of the AI architect. These leaders are responsible for helping define, manage and evolve their company's AI agent over time. They come from a variety of both technical and business backgrounds, and we think that every company will have one or many AI architects managing their AI agent and related experience.” In our conversation, Bret Taylor confirms the Paul Buchheit legend that he rewrote Google Maps in a weekend https://news.ycombinator.com/item?id=37415124, armed with only the help of a then-nascent Google Closure Compiler https://developers.google.com/closure/compiler and no other modern tooling. But what we find remarkable is that he was the PM of Maps, not an engineer, though of course he still identifies as one. We find this theme recurring throughout Bret’s career and worldview. We think it is plain as day that AI leadership will have to be hands-on and technical, especially when the ground is shifting as quickly as it is today: “There's a lot of power in combining product and engineering into as few people as possible… few great things have been created by committee.” “If engineering is an order taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a maniacal focus on outcomes.” “And I think the reason why is if you look at like software as a service five years ago, maybe you can have a separation of product and engineering because most software as a service created five years ago. I wouldn't say there's like a lot of technological breakthroughs required for most business applications. And if you're making expense reporting software or whatever, it's useful… You kind of know how databases work, how to build auto scaling with your AWS cluster, whatever, you know, it's just, you're just applying best practices to yet another problem. "When you have areas like the early days of mobile development or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are and all the different people interacting with it and the capabilities of the technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself.” This is the first time the difference between technical leadership for “normal” software and for “AI” software was articulated this clearly for us, and we’ll be thinking a lot about this going forward. We left a lot of nuggets in the conversation, so we hope you’ll just dive in with us (and thank Bret https://twitter.com/btaylor/ for joining the pod!) Full YouTube Please Like and Subscribe https://youtu.be/0G1vd3Trj2U :) Timestamps * 00:00:02 Introductions and Bret Taylor's background * 00:01:23 Bret's experience at Stanford and the dot-com era * 00:04:04 The story of rewriting Google Maps backend * 00:11:06 Early days of interactive web applications at Google * 00:15:26 Discussion on product management and engineering roles * 00:21:00 AI and the future of software development * 00:26:42 Bret's approach to identifying customer needs and building AI companies * 00:32:09 The evolution of business models in the AI era * 00:41:00 The future of programming languages and software development * 00:49:38 Challenges in precisely communicating human intent to machines * 00:56:44 Discussion on Artificial General Intelligence (AGI) and its impact * 01:08:51 The future of agent-to-agent communication * 01:14:03 Bret's involvement in the OpenAI leadership crisis * 01:22:11 OpenAI's relationship with Microsoft * 01:23:23 OpenAI's mission and priorities * 01:27:40 Bret's guiding principles for career choices * 01:29:12 Brief discussion on pasta-making * 01:30:47 How Bret keeps up with AI developments * 01:32:15 Exciting research directions in AI * 01:35:19 Closing remarks and hiring at Sierra Transcript [00:02:05] Introduction and Guest Welcome [00:02:05] Alessio: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co host swyx, founder of smol.ai. [00:02:17] swyx: Hey, and today we're super excited to have Bret Taylor join us. Welcome. Thanks for having me. It's a little unreal to have you in the studio. [00:02:25] swyx: I've read about you so much over the years, like even before. Open AI effectively. I mean, I use Google Maps to get here. So like, thank you for everything that you've done. Like, like your story history, like, you know, I think people can find out what your greatest hits have been. [00:02:40] Bret Taylor's Early Career and Education [00:02:40] swyx: How do you usually like to introduce yourself when, you know, you talk about, you summarize your career, like, how do you look at yourself? [00:02:47] Bret: Yeah, it's a great question. You know, we, before we went on the mics here, we're talking about the audience for this podcast being more engineering. And I do think depending on the audience, I'll introduce myself differently because I've had a lot of [00:03:00] corporate and board roles. I probably self identify as an engineer more than anything else though. [00:03:04] Bret: So even when I was. Salesforce, I was coding on the weekends. So I think of myself as an engineer and then all the roles that I do in my career sort of start with that just because I do feel like engineering is sort of a mindset and how I approach most of my life. So I'm an engineer first and that's how I describe myself. [00:03:24] Bret: You majored in computer [00:03:25] swyx: science, like 1998. And, and I was high [00:03:28] Bret: school, actually my, my college degree was Oh, two undergrad. Oh, three masters. Right. That old. [00:03:33] swyx: Yeah. I mean, no, I was going, I was going like 1998 to 2003, but like engineering wasn't as, wasn't a thing back then. Like we didn't have the title of senior engineer, you know, kind of like, it was just. [00:03:44] swyx: You were a programmer, you were a developer, maybe. What was it like in Stanford? Like, what was that feeling like? You know, was it, were you feeling like on the cusp of a great computer revolution? Or was it just like a niche, you know, interest at the time? [00:03:57] Stanford and the Dot-Com Bubble [00:03:57] Bret: Well, I was at Stanford, as you said, from 1998 to [00:04:00] 2002. [00:04:02] Bret: 1998 was near the peak of the dot com bubble. So. This is back in the day where most people that they're coding in the computer lab, just because there was these sun microsystems, Unix boxes there that most of us had to do our assignments on. And every single day there was a. com like buying pizza for everybody. [00:04:20] Bret: I didn't have to like, I got. Free food, like my first two years of university and then the dot com bubble burst in the middle of my college career. And so by the end there was like tumbleweed going to the job fair, you know, it was like, cause it was hard to describe unless you were there at the time, the like level of hype and being a computer science major at Stanford was like, A thousand opportunities. [00:04:45] Bret: And then, and then when I left, it was like Microsoft, IBM. [00:04:49] Joining Google and Early Projects [00:04:49] Bret: And then the two startups that I applied to were VMware and Google. And I ended up going to Google in large part because a woman named Marissa Meyer, who had been a teaching [00:05:00] assistant when I was, what was called a section leader, which was like a junior teaching assistant kind of for one of the big interest. [00:05:05] Bret: Yes. Classes. She had gone there. And she was recruiting me and I knew her and it was sort of felt safe, you know, like, I don't know. I thought about it much, but it turned out to be a real blessing. I realized like, you know, you always want to think you'd pick Google if given the option, but no one knew at the time. [00:05:20] Bret: And I wonder if I'd graduated in like 1999 where I've been like, mom, I just got a job at pets. com. It's good. But you know, at the end I just didn't have any options. So I was like, do I want to go like make kernel software at VMware? Do I want to go build search at Google? And I chose Google. 50, 50 ball. [00:05:36] Bret: I'm not really a 50, 50 ball. So I feel very fortunate in retrospect that the economy collapsed because in some ways it forced me into like one of the greatest companies of all time, but I kind of lucked into it, I think. [00:05:47] The Google Maps Rewrite Story [00:05:47] Alessio: So the famous story about Google is that you rewrote the Google maps back in, in one week after the map quest quest maps acquisition, what was the story there? [00:05:57] Alessio: Is it. Actually true. Is it [00:06:00] being glorified? Like how, how did that come to be? And is there any detail that maybe Paul hasn't shared before? [00:06:06] Bret: It's largely true, but I'll give the color commentary. So it was actually the front end, not the back end, but it turns out for Google maps, the front end was sort of the hard part just because Google maps was. [00:06:17] Bret: Largely the first ish kind of really interactive web application, say first ish. I think Gmail certainly was though Gmail, probably a lot of people then who weren't engineers probably didn't appreciate its level of interactivity. It was just fast, but. Google maps, because you could drag the map and it was sort of graphical. [00:06:38] Bret: My, it really in the mainstream, I think, was it a map [00:06:41] swyx: quest back then that was, you had the arrows up and down, it [00:06:44] Bret: was up and down arrows. Each map was a single image and you just click left and then wait for a few seconds to the new map to let it was really small too, because generating a big image was kind of expensive on computers that day. [00:06:57] Bret: So Google maps was truly innovative in that [00:07:00] regard. The story on it. There was a small company called where two technologies started by two Danish brothers, Lars and Jens Rasmussen, who are two of my closest friends now. They had made a windows app called expedition, which had beautiful maps. Even in 2000. [00:07:18] Bret: For whenever we acquired or sort of acquired their company, Windows software was not particularly fashionable, but they were really passionate about mapping and we had made a local search product that was kind of middling in terms of popularity, sort of like a yellow page of search product. So we wanted to really go into mapping. [00:07:36] Bret: We'd started working on it. Their small team seemed passionate about it. So we're like, come join us. We can build this together. [00:07:42] Technical Challenges and Innovations [00:07:42] Bret: It turned out to be a great blessing that they had built a windows app because you're less technically constrained when you're doing native code than you are building a web browser, particularly back then when there weren't really interactive web apps and it ended up. [00:07:56] Bret: Changing the level of quality that we [00:08:00] wanted to hit with the app because we were shooting for something that felt like a native windows application. So it was a really good fortune that we sort of, you know, their unusual technical choices turned out to be the greatest blessing. So we spent a lot of time basically saying, how can you make a interactive draggable map in a web browser? [00:08:18] Bret: How do you progressively load, you know, new map tiles, you know, as you're dragging even things like down in the weeds of the browser at the time, most browsers like Internet Explorer, which was dominant at the time would only load two images at a time from the same domain. So we ended up making our map tile servers have like. [00:08:37] Bret: Forty different subdomains so we could load maps and parallels like lots of hacks. I'm happy to go into as much as like [00:08:44] swyx: HTTP connections and stuff. [00:08:46] Bret: They just like, there was just maximum parallelism of two. And so if you had a map, set of map tiles, like eight of them, so So we just, we were down in the weeds of the browser anyway. [00:08:56] Bret: So it was lots of plumbing. I can, I know a lot more about browsers than [00:09:00] most people, but then by the end of it, it was fairly, it was a lot of duct tape on that code. If you've ever done an engineering project where you're not really sure the path from point A to point B, it's almost like. Building a house by building one room at a time. [00:09:14] Bret: The, there's not a lot of architectural cohesion at the end. And then we acquired a company called Keyhole, which became Google earth, which was like that three, it was a native windows app as well, separate app, great app, but with that, we got licenses to all this satellite imagery. And so in August of 2005, we added. [00:09:33] Bret: Satellite imagery to Google Maps, which added even more complexity in the code base. And then we decided we wanted to support Safari. There was no mobile phones yet. So Safari was this like nascent browser on, on the Mac. And it turns out there's like a lot of decisions behind the scenes, sort of inspired by this windows app, like heavy use of XML and XSLT and all these like. [00:09:54] Bret: Technologies that were like briefly fashionable in the early two thousands and everyone hates now for good [00:10:00] reason. And it turns out that all of the XML functionality and Internet Explorer wasn't supporting Safari. So people are like re implementing like XML parsers. And it was just like this like pile of s**t. [00:10:11] Bret: And I had to say a s**t on your part. Yeah, of [00:10:12] Alessio: course. [00:10:13] Bret: So. It went from this like beautifully elegant application that everyone was proud of to something that probably had hundreds of K of JavaScript, which sounds like nothing. Now we're talking like people have modems, you know, not all modems, but it was a big deal. [00:10:29] Bret: So it was like slow. It took a while to load and just, it wasn't like a great code base. Like everything was fragile. So I just got. Super frustrated by it. And then one weekend I did rewrite all of it. And at the time the word JSON hadn't been coined yet too, just to give you a sense. So it's all XML. [00:10:47] swyx: Yeah. [00:10:47] Bret: So we used what is now you would call JSON, but I just said like, let's use eval so that we can parse the data fast. And, and again, that's, it would literally as JSON, but at the time there was no name for it. So we [00:11:00] just said, let's. Pass on JavaScript from the server and eval it. And then somebody just refactored the whole thing. [00:11:05] Bret: And, and it wasn't like I was some genius. It was just like, you know, if you knew everything you wished you had known at the beginning and I knew all the functionality, cause I was the primary, one of the primary authors of the JavaScript. And I just like, I just drank a lot of coffee and just stayed up all weekend. [00:11:22] Bret: And then I, I guess I developed a bit of reputation and no one knew about this for a long time. And then Paul who created Gmail and I ended up starting a company with him too, after all of this told this on a podcast and now it's large, but it's largely true. I did rewrite it and it, my proudest thing. [00:11:38] Bret: And I think JavaScript people appreciate this. Like the un G zipped bundle size for all of Google maps. When I rewrote, it was 20 K G zipped. It was like much smaller for the entire application. It went down by like 10 X. So. What happened on Google? Google is a pretty mainstream company. And so like our usage is shot up because it turns out like it's faster. [00:11:57] Bret: Just being faster is worth a lot of [00:12:00] percentage points of growth at a scale of Google. So how [00:12:03] swyx: much modern tooling did you have? Like test suites no compilers. [00:12:07] Bret: Actually, that's not true. We did it one thing. So I actually think Google, I, you can. Download it. There's a, Google has a closure compiler, a closure compiler. [00:12:15] Bret: I don't know if anyone still uses it. It's gone. Yeah. Yeah. It's sort of gone out of favor. Yeah. Well, even until recently it was better than most JavaScript minifiers because it was more like it did a lot more renaming of variables and things. Most people use ES build now just cause it's fast and closure compilers built on Java and super slow and stuff like that. [00:12:37] Bret: But, so we did have that, that was it. Okay. [00:12:39] The Evolution of Web Applications [00:12:39] Bret: So and that was treated internally, you know, it was a really interesting time at Google at the time because there's a lot of teams working on fairly advanced JavaScript when no one was. So Google suggest, which Kevin Gibbs was the tech lead for, was the first kind of type ahead, autocomplete, I believe in a web browser, and now it's just pervasive in search boxes that you sort of [00:13:00] see a type ahead there. [00:13:01] Bret: I mean, chat, dbt [00:13:01] swyx: just added it. It's kind of like a round trip. [00:13:03] Bret: Totally. No, it's now pervasive as a UI affordance, but that was like Kevin's 20 percent project. And then Gmail, Paul you know, he tells the story better than anyone, but he's like, you know, basically was scratching his own itch, but what was really neat about it is email, because it's such a productivity tool, just needed to be faster. [00:13:21] Bret: So, you know, he was scratching his own itch of just making more stuff work on the client side. And then we, because of Lars and Yen sort of like setting the bar of this windows app or like we need our maps to be draggable. So we ended up. Not only innovate in terms of having a big sync, what would be called a single page application today, but also all the graphical stuff you know, we were crashing Firefox, like it was going out of style because, you know, when you make a document object model with the idea that it's a document and then you layer on some JavaScript and then we're essentially abusing all of this, it just was running into code paths that were not. [00:13:56] Bret: Well, it's rotten, you know, at this time. And so it was [00:14:00] super fun. And, and, you know, in the building you had, so you had compilers, people helping minify JavaScript just practically, but there is a great engineering team. So they were like, that's why Closure Compiler is so good. It was like a. Person who actually knew about programming languages doing it, not just, you know, writing regular expressions. [00:14:17] Bret: And then the team that is now the Chrome team believe, and I, I don't know this for a fact, but I'm pretty sure Google is the main contributor to Firefox for a long time in terms of code. And a lot of browser people were there. So every time we would crash Firefox, we'd like walk up two floors and say like, what the hell is going on here? [00:14:35] Bret: And they would load their browser, like in a debugger. And we could like figure out exactly what was breaking. And you can't change the code, right? Cause it's the browser. It's like slow, right? I mean, slow to update. So, but we could figure out exactly where the bug was and then work around it in our JavaScript. [00:14:52] Bret: So it was just like new territory. Like so super, super fun time, just like a lot of, a lot of great engineers figuring out [00:15:00] new things. And And now, you know, the word, this term is no longer in fashion, but the word Ajax, which was asynchronous JavaScript and XML cause I'm telling you XML, but see the word XML there, to be fair, the way you made HTTP requests from a client to server was this. [00:15:18] Bret: Object called XML HTTP request because Microsoft and making Outlook web access back in the day made this and it turns out to have nothing to do with XML. It's just a way of making HTTP requests because XML was like the fashionable thing. It was like that was the way you, you know, you did it. But the JSON came out of that, you know, and then a lot of the best practices around building JavaScript applications is pre React. [00:15:44] Bret: I think React was probably the big conceptual step forward that we needed. Even my first social network after Google, we used a lot of like HTML injection and. Making real time updates was still very hand coded and it's really neat when you [00:16:00] see conceptual breakthroughs like react because it's, I just love those things where it's like obvious once you see it, but it's so not obvious until you do. [00:16:07] Bret: And actually, well, I'm sure we'll get into AI, but I, I sort of feel like we'll go through that evolution with AI agents as well that I feel like we're missing a lot of the core abstractions that I think in 10 years we'll be like, gosh, how'd you make agents? Before that, you know, but it was kind of that early days of web applications. [00:16:22] swyx: There's a lot of contenders for the reactive jobs of of AI, but no clear winner yet. I would say one thing I was there for, I mean, there's so much we can go into there. You just covered so much. [00:16:32] Product Management and Engineering Synergy [00:16:32] swyx: One thing I just, I just observe is that I think the early Google days had this interesting mix of PM and engineer, which I think you are, you didn't, you didn't wait for PM to tell you these are my, this is my PRD. [00:16:42] swyx: This is my requirements. [00:16:44] mix: Oh, [00:16:44] Bret: okay. [00:16:45] swyx: I wasn't technically a software engineer. I mean, [00:16:48] Bret: by title, obviously. Right, right, right. [00:16:51] swyx: It's like a blend. And I feel like these days, product is its own discipline and its own lore and own industry and engineering is its own thing. And there's this process [00:17:00] that happens and they're kind of separated, but you don't produce as good of a product as if they were the same person. [00:17:06] swyx: And I'm curious, you know, if, if that, if that sort of resonates in, in, in terms of like comparing early Google versus modern startups that you see out there, [00:17:16] Bret: I certainly like wear a lot of hats. So, you know, sort of biased in this, but I really agree that there's a lot of power and combining product design engineering into as few people as possible because, you know few great things have been created by committee, you know, and so. [00:17:33] Bret: If engineering is an order taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a. Maniacal focus on outcomes. [00:17:53] Bret: And I think the reason why it's, I think for some areas, if you look at like software as a service five years ago, maybe you can have a [00:18:00] separation of product and engineering because most software as a service created five years ago. I wouldn't say there's like a lot of like. Technological breakthroughs required for most, you know, business applications. [00:18:11] Bret: And if you're making expense reporting software or whatever, it's useful. I don't mean to be dismissive of expense reporting software, but you probably just want to understand like, what are the requirements of the finance department? What are the requirements of an individual file expense report? Okay. [00:18:25] Bret: Go implement that. And you kind of know how web applications are implemented. You kind of know how to. How databases work, how to build auto scaling with your AWS cluster, whatever, you know, it's just, you're just applying best practices to yet another problem when you have areas like the early days of mobile development or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are and all the different people interacting with it. [00:18:58] Bret: And the capabilities of the [00:19:00] technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself. And that's why I use the word conversation. It's not literal. That's sort of funny to use that word in the age of conversational AI. [00:19:15] Bret: You're constantly sort of saying, like, ideally, you could sprinkle some magic AI pixie dust and solve all the world's problems, but it's not the way it works. And it turns out that actually, I'll just give an interesting example. [00:19:26] AI Agents and Modern Tooling [00:19:26] Bret: I think most people listening probably use co pilots to code like Cursor or Devon or Microsoft Copilot or whatever. [00:19:34] Bret: Most of those tools are, they're remarkable. I'm, I couldn't, you know, imagine development without them now, but they're not autonomous yet. Like I wouldn't let it just write most code without my interactively inspecting it. We just are somewhere between it's an amazing co pilot and it's an autonomous software engineer. [00:19:53] Bret: As a product manager, like your aspirations for what the product is are like kind of meaningful. But [00:20:00] if you're a product person, yeah, of course you'd say it should be autonomous. You should click a button and program should come out the other side. The requirements meaningless. Like what matters is like, what is based on the like very nuanced limitations of the technology. [00:20:14] Bret: What is it capable of? And then how do you maximize the leverage? It gives a software engineering team, given those very nuanced trade offs. Coupled with the fact that those nuanced trade offs are changing more rapidly than any technology in my memory, meaning every few months you'll have new models with new capabilities. [00:20:34] Bret: So how do you construct a product that can absorb those new capabilities as rapidly as possible as well? That requires such a combination of technical depth and understanding the customer that you really need more integration. Of product design and engineering. And so I think it's why with these big technology waves, I think startups have a bit of a leg up relative to incumbents because they [00:21:00] tend to be sort of more self actualized in terms of just like bringing those disciplines closer together. [00:21:06] Bret: And in particular, I think entrepreneurs, the proverbial full stack engineers, you know, have a leg up as well because. I think most breakthroughs happen when you have someone who can understand those extremely nuanced technical trade offs, have a vision for a product. And then in the process of building it, have that, as I said, like metaphorical conversation with the technology, right? [00:21:30] Bret: Gosh, I ran into a technical limit that I didn't expect. It's not just like changing that feature. You might need to refactor the whole product based on that. And I think that's, that it's particularly important right now. So I don't, you know, if you, if you're building a big ERP system, probably there's a great reason to have product and engineering. [00:21:51] Bret: I think in general, the disciplines are there for a reason. I think when you're dealing with something as nuanced as the like technologies, like large language models today, there's a ton of [00:22:00] advantage of having. Individuals or organizations that integrate the disciplines more formally. [00:22:05] Alessio: That makes a lot of sense. [00:22:06] Alessio: I've run a lot of engineering teams in the past, and I think the product versus engineering tension has always been more about effort than like whether or not the feature is buildable. But I think, yeah, today you see a lot more of like. Models actually cannot do that. And I think the most interesting thing is on the startup side, people don't yet know where a lot of the AI value is going to accrue. [00:22:26] Alessio: So you have this rush of people building frameworks, building infrastructure, layered things, but we don't really know the shape of the compute. I'm curious that Sierra, like how you thought about building an house, a lot of the tooling for evals or like just, you know, building the agents and all of that. [00:22:41] Alessio: Versus how you see some of the startup opportunities that is maybe still out there. [00:22:46] Bret: We build most of our tooling in house at Sierra, not all. It's, we don't, it's not like not invented here syndrome necessarily, though, maybe slightly guilty of that in some ways, but because we're trying to build a platform [00:23:00] that's in Dorian, you know, we really want to have control over our own destiny. [00:23:03] Bret: And you had made a comment earlier that like. We're still trying to figure out who like the reactive agents are and the jury is still out. I would argue it hasn't been created yet. I don't think the jury is still out to go use that metaphor. We're sort of in the jQuery era of agents, not the react era. [00:23:19] Bret: And, and that's like a throwback for people listening, [00:23:22] swyx: we shouldn't rush it. You know? [00:23:23] Bret: No, yeah, that's my point is. And so. Because we're trying to create an enduring company at Sierra that outlives us, you know, I'm not sure we want to like attach our cart to some like to a horse where it's not clear that like we've figured out and I actually want as a company, we're trying to enable just at a high level and I'll, I'll quickly go back to tech at Sierra, we help consumer brands build customer facing AI agents. [00:23:48] Bret: So. Everyone from Sonos to ADT home security to Sirius XM, you know, if you call them on the phone and AI will pick up with you, you know, chat with them on the Sirius XM homepage. It's an AI agent called Harmony [00:24:00] that they've built on our platform. We're what are the contours of what it means for someone to build an end to end complete customer experience with AI with conversational AI. [00:24:09] Bret: You know, we really want to dive into the deep end of, of all the trade offs to do it. You know, where do you use fine tuning? Where do you string models together? You know, where do you use reasoning? Where do you use generation? How do you use reasoning? How do you express the guardrails of an agentic process? [00:24:25] Bret: How do you impose determinism on a fundamentally non deterministic technology? There's just a lot of really like as an important design space. And I could sit here and tell you, we have the best approach. Every entrepreneur will, you know. But I hope that in two years, we look back at our platform and laugh at how naive we were, because that's the pace of change broadly. [00:24:45] Bret: If you talk about like the startup opportunities, I'm not wholly skeptical of tools companies, but I'm fairly skeptical. There's always an exception for every role, but I believe that certainly there's a big market for [00:25:00] frontier models, but largely for companies with huge CapEx budgets. So. Open AI and Microsoft's Anthropic and Amazon Web Services, Google Cloud XAI, which is very well capitalized now, but I think the, the idea that a company can make money sort of pre training a foundation model is probably not true. [00:25:20] Bret: It's hard to, you're competing with just, you know, unreasonably large CapEx budgets. And I just like the cloud infrastructure market, I think will be largely there. I also really believe in the applications of AI. And I define that not as like building agents or things like that. I define it much more as like, you're actually solving a problem for a business. [00:25:40] Bret: So it's what Harvey is doing in legal profession or what cursor is doing for software engineering or what we're doing for customer experience and customer service. The reason I believe in that is I do think that in the age of AI, what's really interesting about software is it can actually complete a task. [00:25:56] Bret: It can actually do a job, which is very different than the value proposition of [00:26:00] software was to ancient history two years ago. And as a consequence, I think the way you build a solution and For a domain is very different than you would have before, which means that it's not obvious, like the incumbent incumbents have like a leg up, you know, necessarily, they certainly have some advantages, but there's just such a different form factor, you know, for providing a solution and it's just really valuable. [00:26:23] Bret: You know, it's. Like just think of how much money cursor is saving software engineering teams or the alternative, how much revenue it can produce tool making is really challenging. If you look at the cloud market, just as a analog, there are a lot of like interesting tools, companies, you know, Confluent, Monetized Kafka, Snowflake, Hortonworks, you know, there's a, there's a bunch of them. [00:26:48] Bret: A lot of them, you know, have that mix of sort of like like confluence or have the open source or open core or whatever you call it. I, I, I'm not an expert in this area. You know, I do think [00:27:00] that developers are fickle. I think that in the tool space, I probably like. Default towards open source being like the area that will win. [00:27:09] Bret: It's hard to build a company around this and then you end up with companies sort of built around open source to that can work. Don't get me wrong, but I just think that it's nowadays the tools are changing so rapidly that I'm like, not totally skeptical of tool makers, but I just think that open source will broadly win, but I think that the CapEx required for building frontier models is such that it will go to a handful of big companies. [00:27:33] Bret: And then I really believe in agents for specific domains which I think will, it's sort of the analog to software as a service in this new era. You know, it's like, if you just think of the cloud. You can lease a server. It's just a low level primitive, or you can buy an app like you know, Shopify or whatever. [00:27:51] Bret: And most people building a storefront would prefer Shopify over hand rolling their e commerce storefront. I think the same thing will be true of AI. So [00:28:00] I've. I tend to like, if I have a, like an entrepreneur asked me for advice, I'm like, you know, move up the stack as far as you can towards a customer need. [00:28:09] Bret: Broadly, but I, but it doesn't reduce my excitement about what is the reactive building agents kind of thing, just because it is, it is the right question to ask, but I think we'll probably play out probably an open source space more than anything else. [00:28:21] swyx: Yeah, and it's not a priority for you. There's a lot in there. [00:28:24] swyx: I'm kind of curious about your idea maze towards, there are many customer needs. You happen to identify customer experience as yours, but it could equally have been coding assistance or whatever. I think for some, I'm just kind of curious at the top down, how do you look at the world in terms of the potential problem space? [00:28:44] swyx: Because there are many people out there who are very smart and pick the wrong problem. [00:28:47] Bret: Yeah, that's a great question. [00:28:48] Future of Software Development [00:28:48] Bret: By the way, I would love to talk about the future of software, too, because despite the fact it didn't pick coding, I have a lot of that, but I can talk to I can answer your question, though, you know I think when a technology is as [00:29:00] cool as large language models. [00:29:02] Bret: You just see a lot of people starting from the technology and searching for a problem to solve. And I think it's why you see a lot of tools companies, because as a software engineer, you start building an app or a demo and you, you encounter some pain points. You're like, [00:29:17] swyx: a lot of [00:29:17] Bret: people are experiencing the same pain point. [00:29:19] Bret: What if I make it? That it's just very incremental. And you know, I always like to use the metaphor, like you can sell coffee beans, roasted coffee beans. You can add some value. You took coffee beans and you roasted them and roasted coffee beans largely, you know, are priced relative to the cost of the beans. [00:29:39] Bret: Or you can sell a latte and a latte. Is rarely priced directly like as a percentage of coffee bean prices. In fact, if you buy a latte at the airport, it's a captive audience. So it's a really expensive latte. And there's just a lot that goes into like. How much does a latte cost? And I bring it up because there's a supply chain from growing [00:30:00] coffee beans to roasting coffee beans to like, you know, you could make one at home or you could be in the airport and buy one and the margins of the company selling lattes in the airport is a lot higher than the, you know, people roasting the coffee beans and it's because you've actually solved a much more acute human problem in the airport. [00:30:19] Bret: And, and it's just worth a lot more to that person in that moment. It's kind of the way I think about technology too. It sounds funny to liken it to coffee beans, but you're selling tools on top of a large language model yet in some ways your market is big, but you're probably going to like be price compressed just because you're sort of a piece of infrastructure and then you have open source and all these other things competing with you naturally. [00:30:43] Bret: If you go and solve a really big business problem for somebody, that's actually like a meaningful business problem that AI facilitates, they will value it according to the value of that business problem. And so I actually feel like people should just stop. You're like, no, that's, that's [00:31:00] unfair. If you're searching for an idea of people, I, I love people trying things, even if, I mean, most of the, a lot of the greatest ideas have been things no one believed in. [00:31:07] Bret: So I like, if you're passionate about something, go do it. Like who am I to say, yeah, a hundred percent. Or Gmail, like Paul as far, I mean I, some of it's Laura at this point, but like Gmail is Paul's own email for a long time. , and then I amusingly and Paul can't correct me, I'm pretty sure he sent her in a link and like the first comment was like, this is really neat. [00:31:26] Bret: It would be great. It was not your email, but my own . I don't know if it's a true story. I'm pretty sure it's, yeah, I've read that before. So scratch your own niche. Fine. Like it depends on what your goal is. If you wanna do like a venture backed company, if its a. Passion project, f*****g passion, do it like don't listen to anybody. [00:31:41] Bret: In fact, but if you're trying to start, you know an enduring company, solve an important business problem. And I, and I do think that in the world of agents, the software industries has shifted where you're not just helping people more. People be more productive, but you're actually accomplishing tasks autonomously. [00:31:58] Bret: And as a consequence, I think the [00:32:00] addressable market has just greatly expanded just because software can actually do things now and actually accomplish tasks and how much is coding autocomplete worth. A fair amount. How much is the eventual, I'm certain we'll have it, the software agent that actually writes the code and delivers it to you, that's worth a lot. [00:32:20] Bret: And so, you know, I would just maybe look up from the large language models and start thinking about the economy and, you know, think from first principles. I don't wanna get too far afield, but just think about which parts of the economy. We'll benefit most from this intelligence and which parts can absorb it most easily. [00:32:38] Bret: And what would an agent in this space look like? Who's the customer of it is the technology feasible. And I would just start with these business problems more. And I think, you know, the best companies tend to have great engineers who happen to have great insight into a market. And it's that last part that I think some people. [00:32:56] Bret: Whether or not they have, it's like people start so much in the technology, they [00:33:00] lose the forest for the trees a little bit. [00:33:02] Alessio: How do you think about the model of still selling some sort of software versus selling more package labor? I feel like when people are selling the package labor, it's almost more stateless, you know, like it's easier to swap out if you're just putting an input and getting an output. [00:33:16] Alessio: If you think about coding, if there's no ID, you're just putting a prompt and getting back an app. It doesn't really matter. Who generates the app, you know, you have less of a buy in versus the platform you're building, I'm sure on the backend customers have to like put on their documentation and they have, you know, different workflows that they can tie in what's kind of like the line to draw there versus like going full where you're managed customer support team as a service outsource versus. [00:33:40] Alessio: This is the Sierra platform that you can build on. What was that decision? I'll sort of [00:33:44] Bret: like decouple the question in some ways, which is when you have something that's an agent, who is the person using it and what do they want to do with it? So let's just take your coding agent for a second. I will talk about Sierra as well. [00:33:59] Bret: Who's the [00:34:00] customer of a, an agent that actually produces software? Is it a software engineering manager? Is it a software engineer? And it's there, you know, intern so to speak. I don't know. I mean, we'll figure this out over the next few years. Like what is that? And is it generating code that you then review? [00:34:16] Bret: Is it generating code with a set of unit tests that pass, what is the actual. For lack of a better word contract, like, how do you know that it did what you wanted it to do? And then I would say like the product and the pricing, the packaging model sort of emerged from that. And I don't think the world's figured out. [00:34:33] Bret: I think it'll be different for every agent. You know, in our customer base, we do what's called outcome based pricing. So essentially every time the AI agent. Solves the problem or saves a customer or whatever it might be. There's a pre negotiated rate for that. We do that. Cause it's, we think that that's sort of the correct way agents, you know, should be packaged. [00:34:53] Bret: I look back at the history of like cloud software and notably the introduction of the browser, which led to [00:35:00] software being delivered in a browser, like Salesforce to. Famously invented sort of software as a service, which is both a technical delivery model through the browser, but also a business model, which is you subscribe to it rather than pay for a perpetual license. [00:35:13] Bret: Those two things are somewhat orthogonal, but not really. If you think about the idea of software running in a browser, that's hosted. Data center that you don't own, you sort of needed to change the business model because you don't, you can't really buy a perpetual license or something otherwise like, how do you afford making changes to it? [00:35:31] Bret: So it only worked when you were buying like a new version every year or whatever. So to some degree, but then the business model shift actually changed business as we know it, because now like. Things like Adobe Photoshop. Now you subscribe to rather than purchase. So it ended up where you had a technical shift and a business model shift that were very logically intertwined that actually the business model shift was turned out to be as significant as the technical as the shift. [00:35:59] Bret: And I think with [00:36:00] agents, because they actually accomplish a job, I do think that it doesn't make sense to me that you'd pay for the privilege of like. Using the software like that coding agent, like if it writes really bad code, like fire it, you know, I don't know what the right metaphor is like you should pay for a job. [00:36:17] Bret: Well done in my opinion. I mean, that's how you pay your software engineers, right? And [00:36:20] swyx: and well, not really. We paid to put them on salary and give them options and they vest over time. That's fair. [00:36:26] Bret: But my point is that you don't pay them for how many characters they write, which is sort of the token based, you know, whatever, like, There's a, that famous Apple story where we're like asking for a report of how many lines of code you wrote. [00:36:40] Bret: And one of the engineers showed up with like a negative number cause he had just like done a big refactoring. There was like a big F you to management who didn't understand how software is written. You know, my sense is like the traditional usage based or seat based thing. It's just going to look really antiquated. [00:36:55] Bret: Cause it's like asking your software engineer, how many lines of code did you write today? Like who cares? Like, cause [00:37:00] absolutely no correlation. So my old view is I don't think it's be different in every category, but I do think that that is the, if an agent is doing a job, you should, I think it properly incentivizes the maker of that agent and the customer of, of your pain for the job well done. [00:37:16] Bret: It's not always perfect to measure. It's hard to measure engineering productivity, but you can, you should do something other than how many keys you typed, you know Talk about perverse incentives for AI, right? Like I can write really long functions to do the same thing, right? So broadly speaking, you know, I do think that we're going to see a change in business models of software towards outcomes. [00:37:36] Bret: And I think you'll see a change in delivery models too. And, and, you know, in our customer base you know, we empower our customers to really have their hands on the steering wheel of what the agent does they, they want and need that. But the role is different. You know, at a lot of our customers, the customer experience operations folks have renamed themselves the AI architects, which I think is really cool. [00:37:55] Bret: And, you know, it's like in the early days of the Internet, there's the role of the webmaster. [00:38:00] And I don't know whether your webmaster is not a fashionable, you know, Term, nor is it a job anymore? I just, I don't know. Will they, our tech stand the test of time? Maybe, maybe not. But I do think that again, I like, you know, because everyone listening right now is a software engineer. [00:38:14] Bret: Like what is the form factor of a coding agent? And actually I'll, I'll take a breath. Cause actually I have a bunch of pins on them. Like I wrote a blog post right before Christmas, just on the future of software development. And one of the things that's interesting is like, if you look at the way I use cursor today, as an example, it's inside of. [00:38:31] Bret: A repackaged visual studio code environment. I sometimes use the sort of agentic parts of it, but it's largely, you know, I've sort of gotten a good routine of making it auto complete code in the way I want through tuning it properly when it actually can write. I do wonder what like the future of development environments will look like. [00:38:55] Bret: And to your point on what is a software product, I think it's going to change a lot in [00:39:00] ways that will surprise us. But I always use, I use the metaphor in my blog post of, have you all driven around in a way, Mo around here? Yeah, everyone has. And there are these Jaguars, the really nice cars, but it's funny because it still has a steering wheel, even though there's no one sitting there and the steering wheels like turning and stuff clearly in the future. [00:39:16] Bret: If once we get to that, be more ubiquitous, like why have the steering wheel and also why have all the seats facing forward? Maybe just for car sickness. I don't know, but you could totally rearrange the car. I mean, so much of the car is oriented around the driver, so. It stands to reason to me that like, well, autonomous agents for software engineering run through visual studio code. [00:39:37] Bret: That seems a little bit silly because having a single source code file open one at a time is kind of a goofy form factor for when like the code isn't being written primarily by you, but it begs the question of what's your relationship with that agent. And I think the same is true in our industry of customer experience, which is like. [00:39:55] Bret: Who are the people managing this agent? What are the tools do they need? And they definitely need [00:40:00] tools, but it's probably pretty different than the tools we had before. It's certainly different than training a contact center team. And as software engineers, I think that I would like to see particularly like on the passion project side or research side. [00:40:14] Bret: More innovation in programming languages. I think that we're bringing the cost of writing code down to zero. So the fact that we're still writing Python with AI cracks me up just cause it's like literally was designed to be ergonomic to write, not safe to run or fast to run. I would love to see more innovation and how we verify program correctness. [00:40:37] Bret: I studied for formal verification in college a little bit and. It's not very fashionable because it's really like tedious and slow and doesn't work very well. If a lot of code is being written by a machine, you know, one of the primary values we can provide is verifying that it actually does what we intend that it does. [00:40:56] Bret: I think there should be lots of interesting things in the software development life cycle, like how [00:41:00] we think of testing and everything else, because. If you think about if we have to manually read every line of code that's coming out as machines, it will just rate limit how much the machines can do. The alternative is totally unsafe. [00:41:13] Bret: So I wouldn't want to put code in production that didn't go through proper code review and inspection. So my whole view is like, I actually think there's like an AI native I don't think the coding agents don't work well enough to do this yet, but once they do, what is sort of an AI native software development life cycle and how do you actually. [00:41:31] Bret: Enable the creators of software to produce the highest quality, most robust, fastest software and know that it's correct. And I think that's an incredible opportunity. I mean, how much C code can we rewrite and rust and make it safe so that there's fewer security vulnerabilities. Can we like have more efficient, safer code than ever before? [00:41:53] Bret: And can you have someone who's like that guy in the matrix, you know, like staring at the little green things, like where could you have an operator [00:42:00] of a code generating machine be like superhuman? I think that's a cool vision. And I think too many people are focused on like. Autocomplete, you know, right now, I'm not, I'm not even, I'm guilty as charged. [00:42:10] Bret: I guess in some ways, but I just like, I'd like to see some bolder ideas. And that's why when you were joking, you know, talking about what's the react of whatever, I think we're clearly in a local maximum, you know, metaphor, like sort of conceptual local maximum, obviously it's moving really fast. I think we're moving out of it. [00:42:26] Alessio: Yeah. At the end of 23, I've read this blog post from syntax to semantics. Like if you think about Python. It's taking C and making it more semantic and LLMs are like the ultimate semantic program, right? You can just talk to them and they can generate any type of syntax from your language. But again, the languages that they have to use were made for us, not for them. [00:42:46] Alessio: But the problem is like, as long as you will ever need a human to intervene, you cannot change the language under it. You know what I mean? So I'm curious at what point of automation we'll need to get, we're going to be okay making changes. To the underlying languages, [00:43:00] like the programming languages versus just saying, Hey, you just got to write Python because I understand Python and I'm more important at the end of the day than the model. [00:43:08] Alessio: But I think that will change, but I don't know if it's like two years or five years. I think it's more nuanced actually. [00:43:13] Bret: So I think there's a, some of the more interesting programming languages bring semantics into syntax. So let me, that's a little reductive, but like Rust as an example, Rust is memory safe. [00:43:25] Bret: Statically, and that was a really interesting conceptual, but it's why it's hard to write rust. It's why most people write python instead of rust. I think rust programs are safer and faster than python, probably slower to compile. But like broadly speaking, like given the option, if you didn't have to care about the labor that went into it. [00:43:45] Bret: You should prefer a program written in Rust over a program written in Python, just because it will run more efficiently. It's almost certainly safer, et cetera, et cetera, depending on how you define safe, but most people don't write Rust because it's kind of a pain in the ass. And [00:44:00] the audience of people who can is smaller, but it's sort of better in most, most ways. [00:44:05] Bret: And again, let's say you're making a web service and you didn't have to care about how hard it was to write. If you just got the output of the web service, the rest one would be cheaper to operate. It's certainly cheaper and probably more correct just because there's so much in the static analysis implied by the rest programming language that it probably will have fewer runtime errors and things like that as well. [00:44:25] Bret: So I just give that as an example, because so rust, at least my understanding that came out of the Mozilla team, because. There's lots of security vulnerabilities in the browser and it needs to be really fast. They said, okay, we want to put more of a burden at the authorship time to have fewer issues at runtime. [00:44:43] Bret: And we need the constraint that it has to be done statically because browsers need to be really fast. My sense is if you just think about like the, the needs of a programming language today, where the role of a software engineer is [00:45:00] to use an AI to generate functionality and audit that it does in fact work as intended, maybe functionally, maybe from like a correctness standpoint, some combination thereof, how would you create a programming system that facilitated that? [00:45:15] Bret: And, you know, I bring up Rust is because I think it's a good example of like, I think given a choice of writing in C or Rust, you should choose Rust today. I think most people would say that, even C aficionados, just because. C is largely less safe for very similar, you know, trade offs, you know, for the, the system and now with AI, it's like, okay, well, that just changes the game on writing these things. [00:45:36] Bret: And so like, I just wonder if a combination of programming languages that are more structurally oriented towards the values that we need from an AI generated program, verifiable correctness and all of that. If it's tedious to produce for a person, that maybe doesn't matter. But one thing, like if I asked you, is this rest program memory safe? [00:45:58] Bret: You wouldn't have to read it, you just have [00:46:00] to compile it. So that's interesting. I mean, that's like an, that's one example of a very modest form of formal verification. So I bring that up because I do think you have AI inspect AI, you can have AI reviewed. Do AI code reviews. It would disappoint me if the best we could get was AI reviewing Python and having scaled a few very large. [00:46:21] Bret: Websites that were written on Python. It's just like, you know, expensive and it's like every, trust me, every team who's written a big web service in Python has experimented with like Pi Pi and all these things just to make it slightly more efficient than it naturally is. You don't really have true multi threading anyway. [00:46:36] Bret: It's just like clearly that you do it just because it's convenient to write. And I just feel like we're, I don't want to say it's insane. I just mean. I do think we're at a local maximum. And I would hope that we create a programming system, a combination of programming languages, formal verification, testing, automated code reviews, where you can use AI to generate software in a high scale way and trust it. [00:46:59] Bret: And you're [00:47:00] not limited by your ability to read it necessarily. I don't know exactly what form that would take, but I feel like that would be a pretty cool world to live in. [00:47:08] Alessio: Yeah. We had Chris Lanner on the podcast. He's doing great work with modular. I mean, I love. LVM. Yeah. Basically merging rust in and Python. [00:47:15] Alessio: That's kind of the idea. Should be, but I'm curious is like, for them a big use case was like making it compatible with Python, same APIs so that Python developers could use it. Yeah. And so I, I wonder at what point, well, yeah. [00:47:26] Bret: At least my understanding is they're targeting the data science Yeah. Machine learning crowd, which is all written in Python, so still feels like a local maximum. [00:47:34] Bret: Yeah. [00:47:34] swyx: Yeah, exactly. I'll force you to make a prediction. You know, Python's roughly 30 years old. In 30 years from now, is Rust going to be bigger than Python? [00:47:42] Bret: I don't know this, but just, I don't even know this is a prediction. I just am sort of like saying stuff I hope is true. I would like to see an AI native programming language and programming system, and I use language because I'm not sure language is even the right thing, but I hope in 30 years, there's an AI native way we make [00:48:00] software that is wholly uncorrelated with the current set of programming languages. [00:48:04] Bret: or not uncorrelated, but I think most programming languages today were designed to be efficiently authored by people and some have different trade offs. [00:48:15] Evolution of Programming Languages [00:48:15] Bret: You know, you have Haskell and others that were designed for abstractions for parallelism and things like that. You have programming languages like Python, which are designed to be very easily written, sort of like Perl and Python lineage, which is why data scientists use it. [00:48:31] Bret: It's it can, it has a. Interactive mode, things like that. And I love, I'm a huge Python fan. So despite all my Python trash talk, a huge Python fan wrote at least two of my three companies were exclusively written in Python and then C came out of the birth of Unix and it wasn't the first, but certainly the most prominent first step after assembly language, right? [00:48:54] Bret: Where you had higher level abstractions rather than and going beyond go to, to like abstractions, [00:49:00] like the for loop and the while loop. [00:49:01] The Future of Software Engineering [00:49:01] Bret: So I just think that if the act of writing code is no longer a meaningful human exercise, maybe it will be, I don't know. I'm just saying it sort of feels like maybe it's one of those parts of history that just will sort of like go away, but there's still the role of this offer engineer, like the person actually building the system. [00:49:20] Bret: Right. And. What does a programming system for that form factor look like? [00:49:25] React and Front-End Development [00:49:25] Bret: And I, I just have a, I hope to be just like I mentioned, I remember I was at Facebook in the very early days when, when, what is now react was being created. And I remember when the, it was like released open source I had left by that time and I was just like, this is so f*****g cool. [00:49:42] Bret: Like, you know, to basically model your app independent of the data flowing through it, just made everything easier. And then now. You know, I can create, like there's a lot of the front end software gym play is like a little chaotic for me, to be honest with you. It is like, it's sort of like [00:50:00] abstraction soup right now for me, but like some of those core ideas felt really ergonomic. [00:50:04] Bret: I just wanna, I'm just looking forward to the day when someone comes up with a programming system that feels both really like an aha moment, but completely foreign to me at the same time. Because they created it with sort of like from first principles recognizing that like. Authoring code in an editor is maybe not like the primary like reason why a programming system exists anymore. [00:50:26] Bret: And I think that's like, that would be a very exciting day for me. [00:50:28] The Role of AI in Programming [00:50:28] swyx: Yeah, I would say like the various versions of this discussion have happened at the end of the day, you still need to precisely communicate what you want. As a manager of people, as someone who has done many, many legal contracts, you know how hard that is. [00:50:42] swyx: And then now we have to talk to machines doing that and AIs interpreting what we mean and reading our minds effectively. I don't know how to get across that barrier of translating human intent to instructions. And yes, it can be more declarative, but I don't know if it'll ever Crossover from being [00:51:00] a programming language to something more than that. [00:51:02] Bret: I agree with you. And I actually do think if you look at like a legal contract, you know, the imprecision of the English language, it's like a flaw in the system. How many [00:51:12] swyx: holes there are. [00:51:13] Bret: And I do think that when you're making a mission critical software system, I don't think it should be English language prompts. [00:51:19] Bret: I think that is silly because you want the precision of a a programming language. My point was less about that and more about if the actual act of authoring it, like if you. [00:51:32] Formal Verification in Software [00:51:32] Bret: I'll think of some embedded systems do use formal verification. I know it's very common in like security protocols now so that you can, because the importance of correctness is so great. [00:51:41] Bret: My intellectual exercise is like, why not do that for all software? I mean, probably that's silly just literally to do what we literally do for. These low level security protocols, but the only reason we don't is because it's hard and tedious and hard and tedious are no longer factors. So, like, if I could, I mean, [00:52:00] just think of, like, the silliest app on your phone right now, the idea that that app should be, like, formally verified for its correctness feels laughable right now because, like, God, why would you spend the time on it? [00:52:10] Bret: But if it's zero costs, like, yeah, I guess so. I mean, it never crashed. That's probably good. You know, why not? I just want to, like, set our bars really high. Like. We should make, software has been amazing. Like there's a Mark Andreessen blog post, software is eating the world. And you know, our whole life is, is mediated digitally. [00:52:26] Bret: And that's just increasing with AI. And now we'll have our personal agents talking to the agents on the CRO platform and it's agents all the way down, you know, our core infrastructure is running on these digital systems. We now have like, and we've had a shortage of software developers for my entire life. [00:52:45] Bret: And as a consequence, you know if you look, remember like health care, got healthcare. gov that fiasco security vulnerabilities leading to state actors getting access to critical infrastructure. I'm like. We now have like created this like amazing system that can [00:53:00] like, we can fix this, you know, and I, I just want to, I'm both excited about the productivity gains in the economy, but I just think as software engineers, we should be bolder. [00:53:08] Bret: Like we should have aspirations to fix these systems so that like in general, as you said, as precise as we want to be in the specification of the system. We can make it work correctly now, and I'm being a little bit hand wavy, and I think we need some systems. I think that's where we should set the bar, especially when so much of our life depends on this critical digital infrastructure. [00:53:28] Bret: So I'm I'm just like super optimistic about it. But actually, let's go to what you said for a second, which is correct. [00:53:33] The Importance of Specifications [00:53:33] Bret: Specifications. I think this is the most interesting part of A. I. Agents broadly, which is that most specifications are incomplete. So let's go back to our product engineering discussions. [00:53:45] Bret: You're like, okay, here's a P. R. D. Product requirements document and there's it's really detailed mockups and this like when you click this button, it does this and it's like 100 percent you can think of a missing requirement that [00:54:00] document. Let's say you click this button And the internet goes out, what do you do? [00:54:04] Bret: I don't know if that's in the PRD. It probably isn't, you know, there's, there's always going to be something because like humans are complicated. Right. So what ends up happening is like, I don't know if you can measure it, like what percentage of a product's actual functionality is determined by its code versus the specification, like for a traditional product, Oh, 95%. [00:54:24] Bret: I mean, a little bit, but a lot of it. So like. Code is the specification. [00:54:29] Open Source and Implicit Standards [00:54:29] Bret: It's actually why if you just look at the history of technology, why open source has won out over specifications, like, you know, for a long time, there was a W3C working group on the HTML specification and then, you know, once web kit became prevalent. [00:54:46] Bret: The internet evolved a lot faster and it's not the expense of the standards organizations. It just turns out having a committee of people argue is like a lot less efficient than someone checking in code and then all of a sudden you had vector graphics and you had like [00:55:00] all this really cool stuff that, you know, someone who, in the Google maps days, a guy like, God, that would have made my life easier. [00:55:05] Bret: You know, it's like. SVG support, life would have been a breeze. Try drawing a driving directions line without vector graphics. And so, you know, in general, I think we've gone from these protocols defined in a document to basically open source code that becomes an implicit standard, like systems calls and Linux, like. [00:55:26] Bret: There is a specification. There is post X as a standard, but like the Colonel is the like, that's what people write against and it's both the documented behavior and all of the undocumented behaviors as well for better for worse. And it's why, you know, Linus and others are so adamant about things like binary compatibility and all that, like this stuff matters. [00:55:48] Bret: So one of the things that I really think about is like working with agents broadly is how do you, it's. I don't want to say it's easy to specify the guardrails, you know, [00:56:00] but what about all those unspecified behaviors? So so much of like being a software engineer is like, you come to the point where you're like the internet's out and you get back the error code from the call and you got to do something with it. [00:56:12] Bret: And you know, what percent of the time do you just be like. Yeah, I'm going to do this because it seems reasonable. And what percentage of time do you like write a slack to your PM and be like, what do I do in this case? It's probably more the former than the latter. Otherwise it'd be really fricking inefficient to write software. [00:56:27] AI Agents and Decision Making [00:56:27] Bret: But what happens when your AI makes that decision for you? It's not a wrong decision. You didn't say anything about that case. The AI agent, the word agent comes from the word agency, right? So it's demonstrating its agency and it's making a decision. Does it document it? That would probably be tedious to like, because there's so many implicit decisions. [00:56:44] Bret: What happens when you click the button and the internet's out? It does something you don't like. How do you fix it? I actually think that we are like entering this new world where like the, how we express to an AI agent, what we want [00:57:00] is always going to be an incomplete specification, and that's why agents are useful because they can fill in the gaps with some decent amount of reasoning. [00:57:07] Bret: How you actually tune these over time. And imagine like building an app with an AI agent as your software engineering companion, there's like an infinitely long tail. Infinite is probably over exaggerating a bit, but there's a fairly long tail of functionality that I guarantee is not specified how you actually tune that. [00:57:25] Bret: And this is what I mean about creating a programming system. I don't think we know what that system is yet. And then similarly, I actually think for every single agentic domain, whether it's customer service or legal or software engineering, that's essentially what the company building those agents is building is like the system through which you express the behaviors you want, esoteric and small as it might be anyway, I think that's a really exciting area though, just because I think that's where the magic or that's where the product insights will be in the space is like, how do you encounter that those moments? [00:57:56] Bret: It's kind of built into the UX [00:57:58] swyx: and it can't just be, [00:58:00] the answer can't just be prompt better, you know? No, no, it's impossible. [00:58:04] Bret: The prompt would be too long. Like, imagine getting a PRD that literally specified the behavior of everything that was represented by code. The answer would just be code. Like at that point. [00:58:14] Bret: So here's my point, like prompts are great, but it's not actually a complete specification for anything. It never can be. And so, and I think that's. How you do interactivity, like the sort of human in a loop thing, when and how you do it. And that's why I really believe in, in domain specific agents, because I think answering that in the abstract is like a interesting intellectual exercise. [00:58:39] Bret: But I, that's why I like talking about agents in the abstract kind of, I'm actively disinterested in it because I don't think it actually means anything. All it means is software is making decisions. That's what, you know, at least in a reductive way. But in the context of software engineering, it does make sense. [00:58:53] Bret: Cause you know, like what is the process of first you specify what you want in a product, then you use it, then you give [00:59:00] feedback. You can imagine building a product that actually facilitated that closed loop system. And then how is that represented that complete specification of both what you knew you wanted, what you discovered through usage, the union of all of that is what you care about, and the rest is less to the AI. [00:59:16] Bret: In the legal context, I'm certain there's a way to know, like, when should the AI ask questions? When shouldn't it? How do you actually intervene when it's wrong? And certainly in the customer service case, it's very clear, you know, and how, like how we, our customers review every conversation, how we. Help them find the conversations they should review when they're having millions so they can find the few that are interesting how when something is wrong in one of those conversations, how they can give feedback. [00:59:42] Bret: So it's fixed the next time in a way where we know the context of why I made that decision. But it's not up to us what's right, right? It's up to our customers. So that's why I actually think for right, you know, right now when you think about building an agent and domain to some degree, how you actually interact with the [01:00:00] people specifies behavior is actually where a lot of the magic is. [01:00:03] swyx: Stop me if this is a little bit annoying to you, but I have a bit of a trouble squaring. domain specific agents with the belief that AGI is real, or AGI is coming, because the point is general intelligence. And some part, some way, one way to view the bitter lesson is we can always make progress on being more domain specific. [01:00:22] swyx: Take whatever SOTA is, and you make progress being more domain specific, and then you will be wiped out. The next advance happens. Clearly, you don't believe in that, but how do you personally square those things? [01:00:34] Bret: Yeah, it's a really heavy question. [01:00:36] The Impact of AGI on Industries [01:00:36] Bret: And you know, I think a lot about AGI given my role at open AI but it's even hard for me to really conceptualize. [01:00:41] Bret: And I love spending time with open AI researchers and actually just like people in the community broadly just talking about the implications because there's the first order of fact and I effects of something that is super intelligent in some domains. And then there's the second and third order effects are harder to predict. [01:00:57] Bret: So first as I think that. [01:01:00] It seems likely to me that, you know, at first and something that is AGI will be good in digital domains. You know, because it's software. So if you think about something like AI discovering a new say like pharmaceutical therapy, the barrier to that is probably less the discovery than the clinical trial. [01:01:23] Bret: And, and AI doesn't necessarily help with a clinical trial, right? That's a process that's. Independent of intelligence and it's, it's a physical process. Similarly, if you think about the problem of climate change or like carbon removal, there's probably a lot of that domain that requires great ideas, but like whatever great idea you came up with, if you wanted to sequester that much carbon, there's probably a big physical component to that. [01:01:47] Bret: So it's not really limited by intelligence. It might be, I'm sure it could be accelerated somewhat by intelligence. There's a really interesting conversation with an economist named Tyler Cohen, California. And recently he just, I just watched a video [01:02:00] of him and he was just talking about how there's parts of the economy where intelligence is sort of the limited resource that will take on AI slash AGI really rapidly and will drive incredible productivity gains. [01:02:13] Bret: But there are other parts of the economy that aren't and those will interact. It goes back to these complex second artifacts like prices will go up in the domains that can absorb absorb intelligence rapidly, which will actually then slow down, you know, so it's going to, I don't think it'll be evenly spread. [01:02:28] Bret: I don't think it would be perhaps as rapidly felt in all parts of the economy as people think I might be wrong, but I just think you can generalize in terms of its ability to. Reason about different domains, which I think is what AGI means to most people, but it may not actually. Generalized in the world and tell, because there's a lot of intelligence is not the limiting factor and like a lot of the economy. [01:02:54] Bret: So going back to your, your more practical question is like, why make software at all of, you know, AGI is coming and [01:03:00] say it that way. Should we learn to [01:03:01] swyx: code? [01:03:01] Bret: There's all variations of this. You know, my view is that I really do view AI as a tool and AGI as a tool for humanity. And so my view is when we were talking about like. [01:03:14] Bret: Is your job as a maker of software to author a code in an editor? I would argue no just like a generation ago. Your job wasn't to punch cards in a punch card That is not what your job is. Your job is to produce digital something, whatever it is, what is the purpose of the software that you're making? [01:03:34] Bret: Your job is to produce that. And so I think that like our jobs will change rapidly and meaningfully, but I think the idea that like our job is to type in a. And an editor is, is an artifact of the tools that we have, not actually what we're hired to do, which is to produce a digital experience, to, you know, make firmware for a toaster or whatever, whatever it is we're [01:04:00] doing. [01:04:00] Bret: Right. Like that's our job. Right. And. As a consequence, I think with things like AGI, I think the certainly software engineering will be one of the disciplines most impacted. And I think that it's very, so like, I think if you're in this industry and you define yourself by the tools that you use, like how many characters you can type into them every day, that's probably not like a long term stable place to be, because that's something that certainly AI can do better than you. [01:04:33] Bret: But your judgment about what to build and how to build it still apply. And that will always be true. And one way to think about it's like a little bit reductive is like, you know, look at startups versus larger companies. Like companies like Google and Amazon have so many more engineers than a startup, but then some startups still win. [01:04:51] Bret: Like, why was that? Well, they made better decisions, right? They didn't type faster or produce more code. They did the right thing in the right market, the right time. [01:05:00] And, and similarly. If you look at some of the great companies, it wasn't the lack of they had some unique idea. Sometimes that's a reason why a company succeeds, but it's often a lot of other things and a lot of other forms of execution. [01:05:12] Bret: So like broadly, like the existence of a lot of intelligence will change a lot and it'll change our jobs more than any other industry, or maybe not, maybe it's exaggerated, but certainly as much as any other industry. But I don't think it like changes, like why the economy around digital technology exists. [01:05:29] Bret: And as a consequence, I think I'm really bullish on like the future of, of the software industry. I just think that like some things that are really expensive today will become almost free. And but I think that, I mean, let's be honest, the half life of technology companies is not particularly long as it is. [01:05:46] Bret: Yeah, I, I brought this anecdote in a recent conversation, but When I started at Google, we were in one building in Mountain View and then eventually moved into a campus, which was previously the Silicon Graphics campus. That was the first campus Google, I'm pretty sure it [01:06:00] still has that campus. I think it's got a billion now. [01:06:02] Bret: SGI was a company that was like really, really big, big enough to have a campus and then went out of business. And it wasn't that old of a company, by the way, it's not like IBM, you know, it was like. Big enough to get a campus and go to business in my lifetime, you know, that type of thing. And then at Facebook, we had an office in pallets. [01:06:18] Bret: I moved, I didn't go into the original office when I joined. It was the second office, this old HP building near Stanford. And then we got big enough to want to campus and we bought some microsystems campus. Sun Microsystem famously came out of Stanford, went high flying, was one of the. com darlings, and then eventually sort of like bought for pennies on the dollar by Oracle. [01:06:39] Bret: And you know, like all those companies, like in my lifetime were big enough to like go public, have a campus and then go out of business. So I think a lot will change. I don't mean to say this is going to be easy or like no one's business model is under threat, but. Will digital technology remain important? [01:06:56] Bret: Will entrepreneurs having good judgment about where to [01:07:00] apply this technology to create something of economic value still apply like a hundred percent. And I've always used the metaphor, like if you went back to 1980 and describe many of the jobs that we have, it would be hard for people to conceptualize. [01:07:13] Bret: Like imagine. I'm a podcaster. You're like, what the hell does that mean? Imagine going back to like 1776 and describing to Ben Franklin, our economy today, like let alone the technology industry, just the services economy. It would be probably hard for him to conceptualize just like who grows the food, just because the idea that so few people in this country are necessary to produce the food for so many people would defy. [01:07:39] Bret: So much of his conception of just like how food is grown, that it would just be like, it would probably take a couple hours of explaining. It's kind of like the same thing. It's like we, we have a view of like how this world works right now. That's based on just the constraints that exist, but there's gonna be a lot of other opportunities and other things like that. [01:07:57] Bret: So I don't know. I mean, it's certainly [01:08:00] writing code is really valuable right now and it probably will change rapidly. I think people just need a lot of agility. I always use the metaphor where like a bunch of accountants and Microsoft Excel was just invented. Are you going to be the first person who sets down your HP calculator and says, I'm going to learn how to use this tool because it's just a better way of doing what I'm already doing. [01:08:19] Bret: Or are you going to be the one who's like, you know, begrudgingly pulling out their slide rule and HP calculator and saying these kids these days, you know, their Excel, they don't understand, you know, it's been a little bit reductive, but I just feel like the, the probably the best thing all of us can do, not just in software industry, but I do think it's really. [01:08:38] Bret: Kind of interesting just reflection that we're disrupting our own industry as much as anything else with this technology is to lean into the change, try the tools, like install the latest coding assistance, you know, when Oh three mini comes out, write some code with it that you don't want to be the last accountant to embrace Excel. [01:08:57] Bret: You might not have your job anymore, so. [01:08:59] swyx: [01:09:00] We have some personal questions on like how you keep up with AI and you know, all that, all the other stuff. But I also want to, and I'll let you get to your question. I just wanted to say that the analogy that you made on food was really interesting and resonated with me. [01:09:12] swyx: I feel like we are kind of in like an agrarian economy of like a barter economy for intelligence and now we're sort of industrializing intelligence. And I, that really just was an aha [01:09:21] Alessio: moment for me. I just wanted to reflect that. Yeah. How do you think about. The person being replaced by an agent and how agents talk to each other. [01:09:29] Alessio: So even at Sierra today, right, you're building agents that people talk to, but in the future, you're going to have agents that are going to complain about the order they placed to the customer support agents all the way down. Exactly. And you know, you were the CTO of Facebook, you built OpenGraph there. [01:09:44] Alessio: And I think there were a lot of pros, things that were being enabled, then maybe a lot of cons that came out of that. How do you think about how the agent protocols should be built, thinking about all the implications of it, you know, privacy, data, discoverability and all that? [01:09:57] Bret: Yeah, I think it's a little early for a [01:10:00] protocol to emerge. [01:10:00] Bret: I've read about a few of the attempts and maybe some of them will catch on. One of the things that's really interesting about large language models is because they're trained on language as they are very capable of using the interfaces built for us. And so. My intuition right now is that because we can make an interface that works for us and also works for the AI, maybe that's good enough. [01:10:23] Bret: You know, I mean, a little bit hand wavy here, but making a machine protocol for agents that's inaccessible to people, there's some upsides to it, but there's also quite a bit of downside to it as well. I think it was Andrej Karpathy, but I can't remember. But like one of the more well known AI researchers wrote, like I spent half my day writing English, you know, in my software engineering I have an intuition that agents will speak to agents using language for a while. [01:10:53] Bret: I don't know if that's true. But there's a lot of reasons why there, that may be true. And so, you know, [01:11:00] when. Your personal agent speaks to a Sierra agent to help figure out why your Sonos speaker has the flashing orange light. My intuition is it will be in English for a while. And I think there's a lot of, like, benefits to that. [01:11:13] Bret: I do think that we still are in the early days of Like long running agents I don't know if you tried the deep research agent that just came up, [01:11:22] swyx: we have one for you. Oh, that's great. [01:11:25] Bret: It was interesting cause it was probably the first time I really got like notified by open AI when something was done and I brought up before the interactive parts of it. [01:11:34] Bret: That's the area that I'm most interested in right now. It just is like most agentic workflows are relatively short running and. The workflows that are multi stakeholder, long running and multi system we deal with a lot of those and, and at Sierra, but broadly speaking, I think that those are interesting just because I, I always use the metaphor that prior to the mobile phone, every time you got like [01:12:00] a notification from some internet service, you get an email, not because email was like the best way to notify you, but it's the only way. [01:12:08] Bret: And so you know, you used to get tagged on a photo in Facebook and you get an email about it. Then once. This was in everyone's pocket. Every app had equal access to buzzing your pocket. And now, you know, for most of the apps I use, I don't get email notifications. I just get, get it directly from the app. [01:12:25] Bret: I sort of wonder what the form factors will be for agents. How do you address and reach out to other agents? And then how does it bring you the, the operator of the agent into the loop at the right time? You know, I certainly think there's companies like, you know, with chat GPT, that will be one of the major consumer surfaces. [01:12:42] Bret: So there's like, there's a lot of like gravity to those services. But then if I think about sort of domain specific workflows as well, I think there's just a lot to figure out there. So I'm less. The agent agent protocols. I actually think I could be wrong. I just haven't thought about a lot. Like it's sort of interesting, but actually just how it engages with all [01:13:00] the people in it is actually one of the things I'm most interested to sort of see how it plays out as well. [01:13:04] Alessio: Yeah. I think to me, the things that are at the core of it is kind of like our back, you know, it's like, can this agent access this thing? I think in the customer support use cases, maybe less prominent, but like in the enterprises is more interesting. And also like language, like you can compress the language. [01:13:20] Alessio: If the human didn't have to read it, you can kind of save tokens, make things faster. So yeah, you mentioned being notified about deep research. Is there a open AI deep research has been achieved internally notification that goes out to everybody and the board gets summoned and you get to see it. Can you give any backstory on that process? [01:13:40] Bret: OpenAI is a mission driven nonprofit that I think of primarily as a research lab. It's obviously more than that, you know, in some ways like chat GPT is a cultural defining product. But at the end of the day, the mission is to ensure that artificial general intelligence benefits all of humanity. So a lot [01:14:00] of our board discussions are about. [01:14:02] Bret: Research and its implications on humanity, which is primarily safety. Obviously, I think the one cannot achieve AGI and not think about safety as a primary responsibility for that mission, but it's also access and other things. So things like deep research, we definitely talk about because it's a big part of, if you think about what does it mean to build AGI, but we talk about a lot of different things, you know, so it's like Sometimes we hear about things super early. [01:14:26] Bret: Sometimes if it's not really related, if it's sort of far afield from the core of the mission, you know, it's like more casual. So it's pretty fun, fun to be a part of that just because it's my favorite part of every board discussion is just hearing from the researchers about. How they're thinking about the future and just like the next, next milestone and creating AGI. [01:14:44] swyx: Well, lots of milestones. Maybe we'll just start at the beginning. Like, you know, there are very few people that have been in the rooms that you've been in. How do these conversations start? How do you get brought into opening? I obviously there's, there's a bit of drama that you can go into if you want. [01:14:56] swyx: Just take us into the room. Like what happens? What is it [01:15:00] like? [01:15:00] Bret: Was it a. Thursday or Friday when Friday was fired. Yeah. So I heard about it like everyone else, you know, just like saw it on, on social media. And I remember [01:15:12] swyx: where I was walking here and I was [01:15:14] Bret: totally shocked and messaged my co founder clay. [01:15:17] Bret: And I was like, gosh, I wonder what happened. And then. On Saturday, trying to just protect sort of like people's privacy on this. But I ended up talking to both Adam D'Angelo and Sam Altman and basically getting a kind of synopsis of what was going on and my understanding that you could, you'd have to ask them for sort of their perspective on this was just basically like they, both the board and Sam both felt some trust in me. [01:15:44] Bret: And it was a very complicated situation because the, the company was reacted pretty negatively, understandably negatively to Sam's being fired. I don't think they really understood what was going on. And so the board was, you know, in a situation where they needed to sort of figure [01:16:00] out a path forward and they reached out to me and then I talked to Sam and basically ended up kind of the mediator for lack of a better word, not really formally that, but fundamentally that. [01:16:10] Bret: And as the board was trying to figure out a path forward, you know, we, we ended up with a lot of discussions with like how to reinstate Sam is a CEO of the company, but also do a review of what happens so that the board's concerns could be fully sort of adjudicated, you know because they obviously did have concerns going into it. [01:16:29] Bret: So it ended up there. So I think broadly speaking, I was just like a known, like a lot of the stakeholders in it knew of me and, and I'd like to think I have some integrity, so it was just sort of like, you know, they were trying to find a way out of a very complex situation. So I ended up kind of meeting in that and have formed a. [01:16:48] Bret: A really great relationship with Sam and Greg and pretty challenging time for the company didn't plan to be, you know, on the board. I got pulled in because of the crisis that happened. [01:17:00] And I don't think I'll be on the board forever either. I, I posted when I joined that I was going to do it temporarily. [01:17:05] Bret: That was like a year ago. You know, I really like to focus on Sierra, but I also really care about, it's just an amazing mission. So [01:17:15] Navigating High-Stakes Situations [01:17:15] swyx: I've been maybe been in like high stakes situations like that, like twice, but obviously not as high stakes, but like, what principles do you have? When you know, like, this is the highest egos, highest amount of stakes possible, highest amount of money, whatever. [01:17:31] swyx: What principles do you have to go into something like this? Like, obviously you have a great reputation, you have a great network. What are your must do's and what are your must not do's? [01:17:39] Bret: I'm not sure there's a If there were a playbook for these situations, there'd be a lot simpler. You know, I just probably go back to like the way I operate in general. [01:17:49] Bret: One is first principles thinking. So I, I do think that there's crisis playbooks, but there was nothing quite like this and you really need to [01:18:00] understand what's going on and why. I think a lot of. Moments of crisis are fundamentally human problems. You can strategize about people's incentives and this and that and the other thing, but I think it's really important to understand all the people involved and what motivates them and why, which is fundamentally an exercise in empathy. [01:18:18] Bret: Actually. Like, do you really understand. Why people are doing what they're doing and then getting good advice, you know, and I think people What's interesting about a high profile crisis is everyone wants to give you advice So there's no shortage of advice, but the good advice is the one I think that really involves judgment Which is who are people based on first principles analysis of the situation based on your assessment? [01:18:41] Bret: Of what, you know, all the people involved who would have true expertise and good judgment, you know, in these situations so that you can either validate your judgment if you have an intuition or if it's an area that's like a area of like, say, a legal expertise that you're not expert and [01:19:00] you want the best in the world to give you advice. [01:19:02] Bret: And I actually find people often seek out. The wrong people for advice and it's really important in those circumstances. [01:19:08] swyx: Well, I mean, it's super well navigated. I have, I've got one more and then we can sort of move on on this topic. The the, the Microsoft offer was real, right? For Sam and team to move over at some, at one point in that weekend. [01:19:19] Bret: I'm not sure. I was sort of in it from one vantage point, which was actually, it's interesting. It's like, I didn't really have. Particular skin in the game. So like I came up with this, I still don't own any equity in open AI. I was just I was just a meaningful bystander in the process. And the reason I got involved and and it will get to answer your question, but the reason I got involved was just because I cared about open AI. [01:19:44] Bret: So. You know, I had left my job at Salesforce and by coincidence, the next month chat GBT comes out and, you know, I got nerd sniped like everyone else. I'm like, I want to spend my life on this. This is so amazing. And I wouldn't, I don't know if I'd be, I wouldn't, I'm not [01:20:00] sure I would have started another company if not for open AI, kind of inspiring the world with chat GPT, maybe I would have, I don't know, but it was like, it had a very significant impact on you, all of us, I think. [01:20:11] Bret: So the idea that it would dissolve in a weekend just like bothered me a lot. And I'm very, like, I'm very grateful for, for open AI's existence. And, and I, my guess is that is probably shared by a lot of the competing research labs to different degrees too. It's just like it kind of that rising tide lifted all boats. [01:20:27] Bret: Like I think it created the proverbial iPhone moment for AI and, and changed, changed the world. So there were lots of. Microsoft is an investor in open AI. It has a vested interest in it. The Sam and Greg had their interests. The employees had their interests and there's lots of wheeling and dealing. [01:20:49] Bret: And I, you know, you can't AB test decision making. So I don't know if like things had fallen apart with that. I don't, I don't actually know. And you also don't know, like what's real, what's not. I [01:21:00] mean, so you'd have to talk to, to them to know it was really real. So. [01:21:03] swyx: Mentioning advisors. I heard it seems like Brian Armstrong was. [01:21:07] swyx: surprisingly strong advisor on during, during the whole journey, which is [01:21:10] Bret: the my understanding was both Brian Armstrong and Ron Conway were really close to Sam through it. And I ended up talking to him, but also tried to. Talk a lot to the board to, you know, trying to be the mediator. I was trying to, you obviously have a position on it. [01:21:25] Bret: Like, and I, I felt that, you know, from the outside looking in, I just really wanted to understand, like, why did this happen? And the process seemed, you know perhaps, you know, to say the least. But I was trying to remain sort of dispassionate because one of the principles was like, if you want to put Humpty Dumpty back together again, you can't be a single issue voter, right? [01:21:45] Bret: Like you have to go in and say like, so it was a pretty sensitive moment. But yeah, my, I think Brian's one of the great entrepreneurs and a true true, true friend and ally to, to Sam through that he's [01:21:55] swyx: been through a lot. As well. The reason I bring up Microsoft is because, [01:22:00] I mean, obviously Huge Backer. [01:22:01] swyx: We actually talked to David Juan who pitched, I think it was Satya at the time, on on the, the first billion dollar investment in OpenAI. The understanding I had was that the best situation was for Open OpenAI, for Microsoft was open. The As is second best was Microsoft Echo hires Sam and Greg and, and whoever else. [01:22:19] swyx: And that was the relationship at the time. Super close, exclusive relationship and all that. I think now things have evolved a little bit. And you know, with, with the evolution of Stargate and there's some, some uncertainty or FUD about the relationship between Microsoft and OpenAI. And I just wanted to, just kind of bring that up. [01:22:38] swyx: Because like, we're also working, like, one, Satya's, we're fortunate to have Satya as a subscriber to InSpace. And we're working on an interview with him. And we're trying to figure out. How this has evolved now, like what, what is, how would you characterize the relationship between Microsoft and OpenAI? [01:22:52] Bret: Microsoft's, you know, the most important partner of OpenAI, you know, so we have a really like deep relationship with them on many [01:23:00] fronts. [01:23:00] Bret: So I think it's always evolving just because the scale of this market is evolving and in particular the capital requirements for infrastructure. Are well beyond what anyone would have predicted two years ago, let alone whenever the Microsoft relationship started. Well, what was that six years ago? I actually don't, I should know off the top of my head, but it was a long time long in this, in the world of AI, a long, longer time ago. [01:23:24] Bret: I don't really think there's anything to share. I mean, it's I don't, I think the relationships evolved because the markets evolved, but the core tenants of the partnership have remained the same. And it's, you know, by far open eyes, most important partner. [01:23:36] swyx: Just double clicking a little bit more, just like a lot of, obviously a lot of our listeners are, you know, care a lot about the priorities of OpenAI. [01:23:43] swyx: I've had it phrased to me that OpenAI had sort of five Top level priorities, like always have frontier models always be on the frontier sort of efficiency as well. Be the first in sort of multi modality, whether it's video generation or real time voice, anything like that. How would you characterize the top priorities of [01:24:00] OpenAI? [01:24:00] swyx: Apart from just the highest level AGI thing. [01:24:02] Bret: I always come back to the highest level AGI as you put it, it is a mission driven organization. And I think a lot of companies talk about their mission, but OpenAI is literally like the mission defines everything that we do. And I think it is important to understand that if you're trying to like. [01:24:20] Bret: Predict where open AI is going to go, because if it doesn't serve the mission, it's very unlikely that it will be a priority for open AI. You know, it's a big organization, so occasionally you might have like side projects, you're like, you know what, I'm not sure that's going to really serve the mission as much as we thought, like, let's not do it anymore. [01:24:36] Bret: But at the end of the day, like people work at open AI because they believe in the benefits the AGI can have to humanity. Some people are there because they want to build it. And the actual act of building is incredibly intellectually rewarding. Some people are there because they want to ensure that AGI is safe. [01:24:55] Bret: I think we have the best AGI safety team in the world. And there's just [01:25:00] so many interesting research problems to, to tackle there as these models become increasingly capable, as they have access to the internet, it has access to tools. It's just like really interesting stuff, but everyone is there because they're interested in the mission. [01:25:13] Bret: And as a consequence, I think that. You know, if you look at something like deep research, that lens, it's pretty logical, right? It's like, of course, that's if you're going to think about what it means to create AGI, enabling AI to help further the cause of research is, is meaningful. You can see why a lot of the AGI labs are working on. [01:25:34] Bret: Software engineering and code generation, because that seems pretty useful if you're trying to make AGI, right? Just because a huge part of it is, is code, you know to do it. Similarly, as you look at sort of tool use and agents right down the middle of what you need to do AGI, that is the part of the company. [01:25:51] Bret: I don't think there is like a. Top, I mean, sure, there's like a, maybe an operational top 10 list, but it is fundamentally about building AGI and [01:26:00] ensuring AGI benefits all of humanity. And that's all we exist for. And the rest of it is like, not a distraction necessarily, but that's like the only reason the organization exists. [01:26:09] Bret: The thing that I think is remarkable is if I had. Describe that mission to the two of you four years ago, like, you know, one of the interesting things is like, how do you think society would use AI? We'd probably think almost maybe like industrial applications, robots, all these other things. I think chat GPT has been the most. [01:26:26] Bret: Delightful. And it doesn't feel counterintuitive now, but like counterintuitive way to serve that mission, because the idea that you can go to chat, gpt. com and access the most advanced intelligence in the world. And there's like a free tier is like pretty amazing. So actually one of the neat things I think is that chat GPT, you know, famously was a research preview that turned into this brand, you know, industry defining brand. [01:26:54] Bret: I think it is one of the more key parts of the mission in a lot of ways because it is the [01:27:00] way many people will use this intelligence for their everyday use. It's not limited to the few. It's not limited to, you know, a form factor that's inaccessible. So I actually think that. It's been really neat to see how much that has led to there's lots of different contours of the mission of, of AGI, but benefit humanity means everyone can use it. [01:27:21] Bret: And so I do think like to your point on is cost important. Oh yeah. Cost is really important. How can we have all of humanity access AI if it's incredibly expensive and you need the 200 subscription, which I pay for it. Cause I think, you know, one promote is mind blowing, you know, but it's, you want both cause you need the advanced research. [01:27:41] Bret: You also want everyone in the world to benefit. So that's the way, I mean, if you're trying to predict where we're going to go, just think, what would I do if I were running a company to, you know, go build AGI and ensures it benefits humanity. That's, that's how we prioritize everything. [01:27:57] Alessio: I know we're going to wrap up soon. [01:27:58] Alessio: I would love to ask some personal [01:28:00] questions. One, what are maybe. I've been guiding principles for you one and choosing what to do. So, you know, you were Salesforce. You were CTO of Facebook. I'm sure you got it done a lot more things, but those were the choices that you made. Do you have frameworks that you use for that? [01:28:15] Alessio: Yeah, let's start there. [01:28:16] Bret: I try to remain sort of like present and grounded in the moment. So. No, I wish I, I wish I did it more, but I don't I really try to focus on like impact, I guess, on what I work on, but also do I enjoy it? And sometimes I think, yeah, we talked a little bit about, you know, what should an entrepreneur work on if they want to start a business? [01:28:38] Bret: And I was sort of joking around about sometimes like best businesses are passion projects. I definitely take into account both. Like I, I want to have an impact on the world and I also like, want to enjoy building what I'm building. And I wouldn't work on something that was impactful if I didn't enjoy doing it every day. [01:28:55] Bret: And then I try to have some balance in my life. I've got a [01:29:00] family and one of the values of, of Sierra's competitive intensity, but we also have a value called family. And we always like to say. Intensity and balance are compatible. You can be in a really intense person and I don't have a lot of like hobbies. [01:29:18] Bret: I basically just like work and spend time with my family. But I have balanced there. And but I, but I do try to have that balance just because, you know, if you're proverbially, you know, on your deathbed, what do you, what do you want, and I want to be surrounded by people I love and to be proud of the impact that I had. [01:29:35] Alessio: I know you also love to make handmade pasta. I'm Italian, so I would love to hear favorite pasta shapes, maybe sauces. Oh, [01:29:43] Bret: that's good. I don't know where you found that. Was that deep research or whatever? It was deep research. That's a deep [01:29:48] swyx: cut. Sorry, where is this from? [01:29:50] Alessio: It was from, [01:29:51] swyx: from, [01:29:51] Alessio: I [01:29:51] Bret: forget, [01:29:52] Alessio: it was, it was, [01:29:52] Bret: the source was Ling. [01:29:55] Bret: I do love to cook. So I started making pasta when my [01:30:00] kids were little because I found getting them involved in the kitchen made them eat their meals better. So like participating in the act of making the food. Made them appreciate the food more. And so we do a lot of just like spaghetti linguine, just because it's pretty easy to do. [01:30:15] Bret: And the crank is turning and the part of the pasta making for me was like, they could operate the crank and I could put it through and it was very interactive. Sauces. I do a bunch probably, I mean. I, the like really simple marinara with really good tomatoes and it's like just a classic, especially if you're a really good pasta, but I like them all. [01:30:36] Bret: But I mean, I just, you know, that's probably the go to just cause it's easy. So [01:30:40] Alessio: I just said to us when I saw it come up in the research, I was like, I mean, you have to weigh in as the Italian here. Yeah, I would say so. There's one type of spaghetti you called. I like it. That's kind of like they're almost square. [01:30:51] Alessio: Those are really good. We're like you do a cherry tomato sauce with oil. You can put undo again there. Yeah, we can do a different pockets on [01:31:00] head [01:31:00] swyx: of the Italian Tech Mafia. Very, very good restaurants. I highly recommend going to Italian restaurants with him. Yeah. Okay. So my question would be, how do you keep up on the eye? [01:31:10] swyx: There's so much. going on. Do you have some special news resource that you use that no one else has? [01:31:17] Bret: No, but I most mornings I'll try to sort of like read, kind of check out what's going on on social media, just like any buzz around papers. But the thing that I don't The thing I really like, we have a small research team at Sierra and we'll do sessions on interesting papers then. [01:31:36] Bret: I think that's really nice. And, you know, usually it's someone who like really went deep on a paper and kind of does a, you know, you bring your lunch and just kind of do a readout. And I found that to be the most rewarding just because, you know, I love research, but sometimes, you know, some simple concepts are, you know, surrounded by a lot of ornate language and you're like, let's get a few more, you know, Greek letters in there to make it [01:32:00] seem like we did something smart, you know? [01:32:02] Bret: Sometimes just talking it through conceptually, I can grok the, so what, you know, more easily. And so that's also been interesting as well. And then just conversations, you know, I always try to, when someone says something I'm not familiar with, like I've gotten over the feeling dumb thing. I'm like, I don't know what that is. [01:32:20] Bret: Explain it to me. And, and yes, you can sometimes just find neat techniques, new papers, things like that. It's impossible to keep up that, to be honest with you. [01:32:29] swyx: For sure. I mean, if you're struggling, I mean, imagine the rest of us. But like, you know, you, you have really privileged and special conversations. [01:32:36] swyx: What research directions do you think people should pay attention to just based on the buzz you're hearing internally, or, you know, [01:32:42] Bret: This isn't surprising to you or anyone, but I, I think the I think in general, the reasoning models, but it's interesting because two years ago, you know, the chain of thought reasoning paper was pretty important, you know, and in general, chain of thought has always been a meaningful thing from the [01:33:00] time I think it was a Google paper, right? [01:33:01] Bret: If I'm remembering correctly and Google authors. Yeah. And I think that. It has always been a way to get more robust results, you know, from models. What's just really interesting is the combination of distillation and reasoning is making the relative performance. And I'll say actually performance is an ambiguous word, basically the latency of these reasoning models, more reasonable, because if you think about say GPT 4, which was, I think, a huge step change in intelligence, it was. [01:33:33] Bret: Quite slow and quite expensive for a long time. So it limited the applications. Once you got to 4. 0 and 4. 0 mini, you know, it opened the door to a lot of different applications, both for cost and latency. We know one came out really interesting quality wise, but it's quite slow, quite expensive. So just the limited applications. [01:33:52] Bret: Now I just saw like someone post one of they distilled one of the deep seek models and just made it really [01:34:00] small. And, you know, it's doing these chains of thoughts so fast, you know, it's achieving latency numbers. I think sort of similar to like GPT four back in the day. And now all of a sudden you're like, wow, this is really interesting. [01:34:11] Bret: And I just think. Especially if there's lots of people listening who are like applied AI people, it's basically like price performance quality. And for a long, like for a long time, the market's so young, if you, you really had to pick which quadrant you wanted for the use case and. The idea that we'll be able to get like relatively sophisticated reasoning at like oh, three minutes has been amazing. [01:34:34] Bret: If you haven't tried, it's like the speed of it makes me use it so much more than oh, one, just because oh, one, I'd actually often craft my prompts using for, oh, and then put it into a one just because it was so slow, you know, I just didn't want to like the turnaround time. So I'm just really excited about them. [01:34:50] Bret: I think we're in the early days in the same way with the rapid change from GPT three to three, five to four. And you just saw like. Every, and I think with these reasoning [01:35:00] models, just how we're using sort of inference time compute and the techniques around it, the use cases for it, it feels like we're in that kind of Cambrian explosion of ideas and possibilities. [01:35:11] Bret: So I just think it's really exciting. And and certainly if you look at some of the use cases we're talking about, like coding, these are the exact types of domains where these reasoning models. Do and should have better results. And certainly in our domain, there's just some problems that like thinking through more robustly, which we've always done, but it's just been like, these models are just coming out of the box with a lot more batteries included. [01:35:35] Bret: So I'm super excited about them. [01:35:37] Alessio: Any final call to action? Are you hiring, growing the team? More people should use Sierra, obviously. [01:35:42] Bret: We are growing the team and we're hiring software engineers, agent engineers so send me a note, Bret at Sierra dot AI, we're growing like weed. Our engineering team is exclusively in person in San Francisco, though we do have some kind of forward deployed engineers and, and other offices like [01:36:00] London, so [01:36:00] Alessio: awesome. [01:36:01] Alessio: Thank you so much for the time, Bret. [01:36:03] Bret: Thanks for having me. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.latent.space/subscribe https://www.latent.space/subscribe?utm_medium=podcast&utm_campaign=CTA_2

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  Hello AI engineers. We're excited to bring you a special conversation with Bret Taylor, CEO of Sierra, the conversational AI platform now worth $4.5 billion, as well as chairman of the board of OpenAI, which needs no introduction. He has had a long-established career in tech, including co-creating Google Maps and the Facebook Like button, starting Quip, and serving as co-CEO of Salesforce and chairman of Twitter Inc. Through all his dizzying accomplishments, Bret is an AI engineer at heart and is incredibly passionate about the future of software development, arguing that we are moving forward from the autopilot era of software engineering to the autonomous era.

• 0:44Speaker 00

  He's also equally at ease talking about the internals of JavaScript React web apps as he is talking about the human side of negotiating high-stakes situations like the OpenAI board drama of 2023. He's observed the rise of the specialist AI architect role, which is a more senior technical AI leader complementing the AI engineer in the various high-level conversations with senior AI leaders in his roles at Sierra and OpenAI. Throughout Bret's career, we observed a strong formula of his success being the tight integration of product management and engineering in small teams, aligned with customers by A, and I quote, "maniacal focus on outcomes rather than exposing implementation details on the pricing chart."

• 1:31Speaker 00

  We organised this conversation in the lead-up to the AI leadership track at the AI Engineer Summit in New York City on February 20, where we have gathered CTOs and VPs of AI of major companies from Bloomberg to LinkedIn to talk about their AI strategy with a close grounding on technical detail. This is our last call for AI leadership attendees to join us. The engineering track is now sold out, and we expect our leadership slots to close soon. Apply for an invite at apply.ai-engineer. See you in two weeks. Watch out and take care.

• 2:09Alessio Fanelli?

  Hey everyone, welcome to the Lit in Space Podcast. This is Alessio, Partner and CTO at Decibel Partners, and I'm joined by my co-host swyx, founder of Small AI.

• 2:17Speaker 02

  Hey, and today we're super excited to have Bret Taylor join us. Welcome.

• 2:21Speaker 03

  Thanks for having me.

• 2:23Speaker 02

  It's a little unreal to have you in the studio. I've read about you so much over the years, like even before OpenAI effectively. I mean, I used Google Maps to get here.

• 2:34Speaker 02

  So like, thank you for everything that you've done. Like you like your storied history, like, you know, I think people can find out what your greatest hits have been. How do you usually like to introduce yourself when, you know, you talk about you summarize your career? How do you look at yourself?

• 2:47Speaker 03

  Yeah, it's a great question. You know, we, before we went on the mics here, we're talking about the audience for this podcast being more engineering. And I do think depending on the audience, I'll introduce myself differently because I've had a lot of corporate and board roles. I probably self identify as an engineer more than anything else, though. So even when I was COF Salesforce, I was coding on the weekends. So I think of myself as an engineer and then all the roles that I do in my career sort of start with that. Just because I do feel like engineering is sort of a mindset and how I approach most of my life. So I'm an engineer first, and that's how I describe myself.

• 3:24Speaker 02

  You majored in computer science, like 1998.

• 3:27Speaker 03

  And that was high school, actually. My, my college degree was O2 undergrad, O3 masters. Not that old.

• 3:33Speaker 02

  Yeah, well, I mean, I was going, I was going like 1998 to 2003. But like, engineering wasn't as, wasn't a thing back then. Like, we didn't have the title of senior engineer, you know, kind of like, it was just you were a programmer, you were a developer, maybe. What was it like in Stanford? Like, what was that feeling like, you know, was, were you feeling like on the cusp of a great computer revolution? Or was it just like a niche, you know, interest at the time?

• 3:57Speaker 03

  Well, I was Stanford, as you said, from 1998 to 2002. 1998 was near the peak of the dot com bubble. So this was back in the day where most people that they're coding in the computer lab, just because there was these Sun Microsystems Unix boxes there that most of us had to do our assignments on. And every single day, there was a dot com, like buying pizza for everybody. I didn't have to like, I would just, I, I got free food like my first two years of university. And then the dot com bubble burst in the middle of my college career. And so by the end, there was like tumbleweed going through the job fair, you know, it's like, cause it was. Hard to describe unless you were there at the time.

• 4:38Speaker 03

  The like level of hype and being a computer science major at Stanford was like a thousand opportunities. And then, and then when I left, it was like Microsoft, IBM, and then the two startups that I applied to were VMware and Google. And I ended up going to Google in large part because a woman named Marissa Meyer, who'd been a teaching assistant when I was what was called a section leader, which was like a junior teaching assistant, kind of for one of the big intro C S classes. She had gone there and she was recruiting me and I knew her and it was sort of felt safe, you know, like, I don't know, I thought about it much, but it turned out to be a real blessing. I realized like, you know, you always want to think you'd pick Google if given the option, but no one knew at the time.

• 5:21Speaker 03

  And I wonder if I'd graduated in like 1999 where I've been like, Mom, I just got a job at pets.com. It's good.

• 5:28Speaker 03

  But, you know, at the end, I just didn't have any options. So I was like, do I want to go like make kernel software at VMware? Do I want to go build search at Google? And I chose Google 50 50 ball. I'm not really a 50 50 ball, so I feel very fortunate in retrospect that the economy collapsed because in some ways it forced me into like one of the greatest companies of all time, but I kind of lucked into it, I think.

• 5:47Alessio Fanelli?

  So the famous story about Google is that you rewrote the Google Maps backend in one week after the MapQuest, Quest Maps acquisition. What was the story there? Is it actually true? Is it being glorified? Like, how, how did that came to be? And is there any detail that maybe Paul hasn't shared before?

• 6:06Speaker 03

  It's largely true, but I'll give the color commentary. So it was actually the front end, not the back end. But it turns out for Google Maps, the front end was sort of the hard part just because Google Maps was largely the first ish kind of really interactive web application. I say first ish, I think Gmail certainly was, though. Gmail, probably a lot of people didn't, who weren't engineers, probably didn't appreciate its level of interactivity. It was just fast. But Google Maps, because you could drag the map and it was sort of graphical, really in the mainstream, I think.

• 6:40Speaker 02

  Was it MapQuest back then? That was, you had the arrows up and down?

• 6:44Speaker 03

  There was up and down arrows. Each map was a single image and you'd just click left and then wait for a few seconds to the new map to load. It was really small, too, because generating a big image was kind of expensive on computers that day. So Google Maps was truly innovative in that regard. The story on it, there was a small company called Where2 Technologies, started by two Danish brothers, Lars and Jens Rasmussen, who are two of my closest friends now. They had made a Windows app called Expedition, which had beautiful maps. Even in 2004, whenever we acquired or sort of acquihired their company, Windows software was not particularly fashionable. But they were really passionate about mapping

• 7:26Speaker 03

  and we had made a local search product that was kind of middling in terms of popularity, sort of like a Yellow Pages search product. So we wanted to really go into mapping. We had started working on it. Their small team seemed passionate about it. It's really like, come join us, we can build this together. It turned out to be a great blessing that they had built the Windows app because you're less technically constrained when you're doing native code than you are building a web browser, particularly back then when there weren't really interactive web apps. And it ended up changing the level of quality that we wanted to hit with the app because we were shooting for something that felt like a native Windows application. So it was a really good fortune that we sort of,

• 8:08Speaker 03

  you know, their unusual technical choices turned out to be the greatest blessing. So we spent a lot of time basically saying, how can you make an interactive, dragable map in a web browser? How do you progressively load, you know, new map tiles, you know, as you're dragging? Even things like down in the weeds of the browser at the time, most browsers like Internet Explorer, which was dominant at the time, would only load two images at a time from the same domain. So we ended up making- In our map tile servers have like 40 different subdomains. So we could load maps in parallels, like lots of hacks. I'm happy to go into this.

• 8:44Speaker 02

  Oh, just for like HTTP actions and stuff?

• 8:46Speaker 03

  They just like, there was just maximum parallelism of two. And so if you had a map, set of map tiles of like eight of them.

• 8:53Speaker 02

  Oh, my God.

• 8:54Speaker 03

  So we just, we were down in the weeds of the browser. Anyway, so there's lots of plumbing. I can, I know a lot more about browsers than most people. But then by the end of it, it was fairly, there was a lot of duct tape on that code. If you've ever done an engineering project where you're not really sure the path from point A to point B, it's almost like building a house by building one room at a time. There's not a lot of architectural cohesion at the end. And then we acquired a company called Keyhole, which became Google Earth, which was like that three, it was a native Windows app as well. Separate app, great app. But with that, we got licenses to all this satellite imagery. And so in August of 2005, we added satellite imagery to Google Maps, which added even more complexity in the code base.

• 9:38Speaker 03

  And then we decided we wanted to support Safari. There was no mobile phones yet. So Safari was this like nascent browser on, on the Mac. And it turns out there's like a lot of decisions behind the scenes, sort of inspired by this Windows app, like heavy use of XML and XSLT and all these like technologies that were like briefly fashionable in the early 2000s and everyone hates now for good reason. And it turns out that all of the XML functionality in Internet Explorer wasn't supported in Safari. So people are like re-implementing like XML parsers. And it was just like this like pile of shit. And I had to say shit on your podcast.

• 10:12Speaker 02

  Yeah, of course.

• 10:13Speaker 03

  So it went from this like beautifully elegant application that everyone was proud of to something that probably had hundreds of K of JavaScript, which sounds like nothing now. We're talking like people on modems, you know, not all modems. It was, it was a big deal. So it was like slow. It took a while to load and just, it wasn't like a great code base. Like everything was fragile. So I just got. Super frustrated by it. And then one weekend I did rewrite all of it. And at the time, the word JSON hadn't been coined yet, too, just to give you a sense.

• 10:46Speaker 02

  It's all XML.

• 10:47Speaker 03

  So we used what is now you would call JSON, but I just said, like, let's use eval so that we can parse the data fast. And, and again, that's, it would literally is JSON, but at the time, there was no name for it. We just said, let's pass on JavaScript from the server and eval it. And then suddenly just refactor the whole thing. And, and it wasn't like I was some genius. It was just like, you know, you knew everything you wished you had known at the beginning. And I knew all the functionality because I was the primary, one of the primary authors of the JavaScript. And I just like, I just drank a lot of coffee and just stayed up all weekend. And then I guess I developed a bit of reputation and no one knew about this for a long time.

• 11:27Speaker 03

  And then Paul Buhi, who created Gmail, and I ended up starting a company with him too, after all of this, told this on a podcast. And now it's lore, but it's largely true. I did rewrite it. And my proudest thing, and I think JavaScript people appreciate this, like the un-GZipped bundle size for all of Google Maps. When I rewrote it was 20K. GZipped it was like much smaller for the entire application. It went down by like 10X. So what happened on Google, Google's a pretty mainstream company. And so like, our usage just shot up because it turns out like

• 11:57Speaker 02

  It's faster.

• 11:57Speaker 03

  Just being faster is worth a lot of percentage points of growth at a scale of Google. So.

• 12:03Speaker 02

  How much modern tooling did you have, like test suites, compilers?

• 12:07Speaker 03

  Actually, that's not true. We did have one thing. So I actually think Google, you can download it. There's a, Google has a

• 12:13Speaker 02

  Closure compiler?

• 12:14Speaker 03

  Yeah, closure compiler. I don't know if anyone still uses it.

• 12:16Speaker 02

  Oh, yeah, yeah.

• 12:17Speaker 03

  Yeah, it's sort of gone out of favor. Yeah, well, even until recently, it was better than most JavaScript modifiers because it was more like, it did a lot more renaming of variables and things. Most people use ES build now just because it's fast. And closure compilers built on Java and super slow and stuff like that. But so we did have that. That was it.

• 12:38Speaker 02

  Wow, okay.

• 12:39Speaker 03

  So, and that was traded internally. You know, it was a really interesting time at Google at the time because there's a lot of teams working on fairly Really advanced JavaScript when no one was. So Google suggest, which Kevin Gibbs was the tech lead for, was the first kind of type ahead autocomplete, I believe, in a web browser. And now it's just pervasive in search boxes that you sort of see a type ahead there.

• 13:01Speaker 02

  I mean, chat GPT just added it. It's kind of like a round trip.

• 13:03Speaker 03

  Totally. No, it's now pervasive as a UI affordance, but that was like Kevin's 20% project. And then Gmail, Paul, you know, he tells the story better than anyone, but he's like, you know, basically was scratching his own itch. But what was really neat about it is email, because it's such a productivity tool, just needed to be faster. So, you know, he was scratching his own itch of just making more stuff work on the client side. And then we, because of Lars and Jan, sort of like setting the bar of this Windows app, were like, we need our maps to be dragable. And so we ended up not only innovating in terms of having a big, what would be called a single page application today, but also all the graphical stuff. You know, we were crashing Firefox like it was going out of style because, you know, when you make a document object model with the idea that it's a document,

• 13:48Speaker 03

  and then you layer on some JavaScript, and then we're essentially abusing all of this. It just was running into code paths that were not well trodden, you know, at this time. And so it was super fun. And, and you know, in the building you had, you had compilers, people helping minify JavaScript just practically, but there is a great engineering team. So they were like, that's why Clojure compiler is so good. It was like a person who actually knew about programming languages, doing it, not just, you know, writing regular expressions. And then the team that is now the Chrome team believe, and I don't know this for a fact, but I'm pretty sure Google was the main contributor to Firefox for a long time in terms of code. And a lot of browser people were there. So every time we would crash Firefox,

• 14:31Speaker 03

  we'd like walk up two floors and say like, what the hell is going on here? And they would load their browser like in a debugger and we could like figure out exactly what was breaking. And you can't change the code, right? Because it's the browser, it's like slow, right? I mean, slow to update. So, but we could figure out exactly where the bug was and then work around it in our JavaScript. So it was just like new territory. Like it's a super, super fun time, just like a lot of, a lot of great engineers figuring out new things. And, and now, you know, the word, this term is no longer in fashion, but the word Ajax, which was. Asynchronous JavaScript.

• 15:08Speaker 02

  And execution.

• 15:09Speaker 03

  XML, because I'm telling you XML. But see, the word XML there, to be fair, the way you made HTTP requests from a client to server was this object called XML HTTP request because Microsoft in making Outlook web access back in the day made this, and it turns out to have nothing to do with XML. It's just a way of making HTTP requests because XML was like the fashionable thing. It was like, that was the, the way you, you know, you did it. But the JSON came out of that, you know, and then a lot of the best practices around building JavaScript applications was pre-React. I think React was probably the big conceptual step forward that we needed. Even my first social

• 15:51Speaker 03

  network after Google, we used a lot of like HTML injection and making real-time updates was still very hand-coded. And it's really neat when you see conceptual breakthroughs like React because it's, I just love those things where it's like obvious once you see it, but it's so not obvious until you do. And actually, well, I'm sure we'll get into AI, but I, I sort of feel like we'll go through that evolution with AI agents as well that I feel like we're missing a lot of the core abstractions that I think in 10 years will be like, gosh, how'd you make agents before that, you know? But it was kind of that early days of web applications.

• 16:22Speaker 02

  There's a lot of contenders for the React of Java, of AI, but no clear winner yet, I would say. One thing I would, I mean, there's so much we can go into there. You just covered so much. One thing I just observed is that I think the early Google days had this interesting mix of PM and engineer, which I think you are. You didn't, you didn't wait for a PM to tell you, these are my, this is my PRD, this is my requirements. Oh, okay.

• 16:44Speaker 03

  I wasn't technically a software engineer. I mean, by title, obviously.

• 16:49Speaker 02

  Right, right, right. But it's like a blend. And I feel like these days, product is its own discipline and with its own lore and own industry and engineering is its own thing. And there's this process that, that happens and they're kind of separated, but you don't produce as good of a product as if they were the same person. And I'm curious, you know, if, if that, if that sort of resonates in, in, in terms of like comparing early Google versus modern startups that you see out there.

• 17:16Speaker 03

  I certainly like, wear a lot of hats. So, you know, sort of biased in this, but I really agree that there's a lot of power in combining product design, engineering into as few people as possible because, you know, few great things have been created by committee, you know? And so. If engineering is an order taking organization for product, you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a maniacal focus on outcomes. And I think the reason why it's, I think for some areas, if you look at like software as a service five years ago,

• 17:59Speaker 03

  maybe you can have a separation of product and engineering because most software as a service created five years ago, I wouldn't say there's like a lot of like technological breakthroughs required for most, you know, business applications. And if you're making expense reporting software or whatever, it's useful. I don't mean to be dismissive of expense reporting software, but you probably just want to understand like, what are the requirements of the finance department? What are the requirements of an individual filing expense report? Okay, go implement that. And you kind of know how web applications are implemented. You kind of know how to, how databases work, how to build auto scaling with your AWS cluster, whatever. You know, it's just, you're just applying best practices to yet another problem. When you have areas like the early days of mobile development,

• 18:43Speaker 03

  or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are, and all the different people interacting with it, and the capabilities of the technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself. And that's why I use the word conversation. It's not literal, though it's sort of funny to use that word in the age of conversational AI. You're constantly sort of saying like, ideally, you could sprinkle some magic AI pixie dust and solve all the world's problems, but it's not the way it works. And it turns out that, oh, actually, I'll just give a interesting example.

• 19:26Speaker 03

  I think most people listening probably use Copilots to code, like Cursor or Devin or Microsoft Copilot or whatever. Most of those tools are, they're remarkable. I'm, I couldn't, you know, imagine development without them now, but they're not autonomous yet. Like, I wouldn't. Let it just write most code without my interactively inspecting it. We just are somewhere between it's an amazing co-pilot and it's an autonomous software engineer. As a product manager, like your aspirations for what the product is are like kind of meaningful. But if you're a product person, yeah, of course, you'd say it should be autonomous. You should click a button and program should come out the other side. The requirement's meaningless.

• 20:07Speaker 03

  Like what matters is like, what is based on the like very nuanced limitations of the technology? What is it capable of? And then how do you maximize the leverage it gives a software engineering team? Given those very nuanced trade offs, coupled with the fact that those nuanced trade offs are changing more rapidly than any technology in my memory. Meaning every few months you'll have new models with new capabilities. So how do you construct a product that can absorb those new capabilities as rapidly as possible as well? That requires such a combination of technical depth and understanding of the customer that you really need more integration of product design and engineering.

• 20:52Speaker 03

  And so I think it's why with these big technology waves, I think startups have a bit of a leg up relative to incumbents because they tend to be sort of more self actualized in terms of just like bringing those disciplines closer together. And in particular, I think entrepreneurs, the proverbial full stack engineers, you know, have a leg up as well. Because I think most breakthroughs happen when you have someone who can understand those extremely nuanced technical trade offs, have a vision for a product and then in the process of building it, have that, as I said, like metaphorical conversation with the technology. Like, gosh, I ran into a technical limit that I didn't expect. It's not just like changing that feature.

• 21:36Speaker 03

  You might need to refactor the whole product based on that. And I think that's that it's particularly important right now. So I don't, you know, if you're, if you're building a big ERP system, probably there's a great reason to have product and engineering. I think in general, the disciplines are there for a reason. I think when you're dealing with something as nuanced as the like technologies like large language models today, there's a ton of advantage of having individuals or organizations that integrate the disciplines more formally.

• 22:05Alessio Fanelli?

  That makes a lot of sense. I've ran a lot of engineering teams in the past and I think the product versus engineering tension has always been more about effort than like whether or not the feature is buildable. But I think, yeah, today you see a lot more of like, models actually cannot do that. And I think the most interesting thing is, on the startup side, people don't yet know where a lot of the AI value is gonna accrue. So you have this rush of people building frameworks, building infrastructure layer things, but we don't really know the shape of the compute. I'm curious at Sierra, like, how you thought about building an house, a lot of the tooling for evals, or like, just, you know, building the agents and all of that, versus how you see some of the startup opportunities that is maybe still out there?

• 22:46Speaker 03

  We build most of our tooling in-house at Sierra. Not all. It's, we don't, it's not like not invented here syndrome necessarily, though maybe slightly guilty of that in some ways. But because we're trying to build a platform that's enduring, you know, we really want to have control over our own destiny. And you had made a comment earlier that, like, we're still trying to figure out who, like, the reactive agents are, and the jury's still out. I would argue it hasn't been created yet. I don't think the jury's still out. To go use that metaphor, we're sort of in the jQuery era of agents, not the React era. And that's like a throwback for people listening.

• 23:22Alessio Fanelli?

  We shouldn't rush it, you know?

• 23:23Speaker 03

  No, yeah, that's my point is. And so, because we're trying to create an enduring company at Sierra that outlives us, you know, I'm not sure we want to like attach our cart to some, like, to a horse where it's not clear that, like, we've figured it out. And I actually want, as a company, we're trying to enable, just at a high level, and I'll quickly back to tech. At Sierra, we help consumer brands build customer-facing AI agents. So, everyone from Sonos to ADT Home Security to SiriusXM, you know, if you call them on the phone, an AI will pick up you, you know, chat with them on the SiriusXM homepage, it's an AI agent called Harmony that they've built on our platform. We're, what are the contours of what it means for someone to build an end-to-end complete customer experience

• 24:07Speaker 03

  with AI, with conversational AI? You know, we really want to dive into the deep end of all the trade-offs to do it. You know, where to use fine tuning? Where do you string models together? You know, where do you use reasoning? Where do you use generation? How do you use reasoning? How do you express the guardrails of an agentic process? How do you impose determinism on a fundamentally non-deterministic technology? There's just a lot of really like is an important design space. And I could say here and tell you, we have the best approach. Every entrepreneur will, you know? But I hope that in two years, we look back at our platform and laugh at how naive we were because that's the pace of change. Broadly, you talk about like the startup opportunities.

• 24:49Speaker 03

  I'm not wholly skeptical of tools companies, but I'm fairly skeptical. There's always an exception for every rule. But I believe that certainly there's a big market for frontier models, but largely for companies with huge capex budgets. So OpenAI, Microsoft, Anthropic and Amazon Web Services, Google Cloud, AI, which is very well capitalized now. But I think the the idea that a company can make money sort of pre-training a foundation model is probably not true. It's hard to, you're competing with just, you know, unreasonably large capex budgets. And I just like the cloud infrastructure market, I think, will be largely there. I also really believe in the applications of AI.

• 25:32Speaker 03

  And I define that not as like building agents or things like that. I define it much more as like you're actually solving a problem for a business. So it's what Harvey is doing in the legal profession or what Cursor is doing for software engineering or what we're doing for customer experience and customer service. The reason I believe in that is I do think that in the age of AI, what's really interesting about software is it can actually complete a task. It can actually do a job, which is very different than the value proposition of software was to ancient history, two years ago. And as a consequence, I think the way you build a solution and for a domain is very different than you would have before, which means that it's not obvious like the incumbents have like a leg up, you know, necessarily.

• 26:15Speaker 03

  They certainly have some advantages, but it's just such a different form factor, you know, for providing a solution. And it's just really valuable, you know, it's like, just think of how. How much money Cursor is saving software engineering teams, or the alternative, how much revenue it can produce. Toolmaking is really challenging. If you look at the cloud market, just as an analog, there are a lot of interesting tools, companies, Confluent, Monetized Kafka, Snowflake, Hortonworks. There's a bunch of them. A lot of them have that mix of sort of like, like Confluent or the open source or open core, or whatever you call it. I'm not an expert in this area.

• 26:58Speaker 03

  You know, I do think that developers are fickle. I think that in the tool space, I probably like default towards open source being like the area that will win. It's hard to build a company around this. And then you end up with companies sort of built around open source too that can work. Don't get me wrong. But I just think that it's nowadays, the tools are changing so rapidly that I'm like, not totally skeptical of toolmakers, but I just think that open source will broadly win. But I think that the capex required for building frontier models is such that it will go to a handful of big companies. And then I really believe in agents for specific domains, which I think will, is sort of the analog to software as a service in this new era.

• 27:42Speaker 03

  It's like, if you just think of the cloud, you can lease a server. It's just a low level primitive, or you can buy an app like Shopify or whatever. And most people building a storefront would prefer Shopify over handrolling their ecommerce storefront. I think the same thing will be true of AI. So I tend to like, if I have a, like an entrepreneur ask me for advice, I'm like, you know, move up the stack as far as you can towards a customer need broadly. But it doesn't reduce my excitement about what is the reactive building agents kind of thing, just because it is, it is the right question to ask. But I think it'll probably play out probably in open source space more than anything else.

• 28:21Speaker 02

  Yeah, and that's not a priority for you. There's a lot in there. I'm kind of curious about your idea maze towards. There are many customer needs. You happen to identify customer experience as yours, but it could equally have been coding assistants or whatever. I think for some, I'm just kind of curious at the top down. How do you look at the world in terms of the potential problem space? Because there are many people out there who are very smart and pick the wrong problem.

• 28:47Speaker 03

  Yeah, that's a great question. By the way, I would love to talk about the future of software too. Because despite the fact it didn't pick coding.

• 28:54Speaker 02

  Let's go there.

• 28:55Speaker 03

  But I can talk to you, I can answer your question though. You know, I think when a technology is as cool as large language models, you just see a lot of people starting from the technology and searching for a problem to solve. And I think it's why you see a lot of tools companies because as a software engineer, you start building an app or a demo and you encounter some pain points.

• 29:15Speaker 02

  It's too hard.

• 29:16Speaker 03

  I've seen a lot of people experiencing the same pain point. What if I make a thing to solve that? It's just very incremental. And you know, I always like to use the metaphor like you can sell coffee beans, roasted coffee beans, you can add some value. You took coffee beans and you roasted them. And roasted coffee beans largely, you know, are priced relative to the cost of the beans. Or you can sell a latte. And a latte is rarely priced directly like as a percentage of coffee bean prices. In fact, if you buy a latte at the airport, it's a captive audience. So it's a really expensive latte. And there's just a lot that goes into like, how much does a latte cost?

• 29:56Speaker 03

  And I bring it up because there's a supply chain from growing coffee beans to roasting coffee beans to like, you know, you could make one at home or you could be in the airport and buy one. And the margins of the company selling lattes in the airport is a lot higher than the, you know, people roasting the coffee beans. And it's because you've actually solved a much more acute human problem in the airport. And it's just worth a lot more to that person in that moment. It's kind of the way to think about technology too. It sounds funny to liken it to coffee beans, but you're selling tools on top of a large. Language model, yeah, in some ways your market is big, but you're probably gonna like be price compressed just because you're sort of a piece of infrastructure and then you have

• 30:40Speaker 03

  open source and all these other things competing with you naturally. If you go and solve a really big business problem for somebody that's actually like a meaningful business problem that AI facilitates, they will value it according to the value of that business problem. And so I actually feel like people should just stop. You're like, no, that's unfair. If you're searching for an idea, people, I love people trying things, even if I mean, most of the, a lot of the greatest ideas have been things no one believed in. So I like, if you're passionate about something, go do it. Like, who am I to say, yeah, 100%. Or Gmail, like Paul, as far, I mean, I, some of it's lore at this point, but like Gmail is Paul's own email for a long time. And then I am using the end, Paul can't correct me. I'm pretty sure he sent around a link and like the first comment was

• 31:25Speaker 03

  like, this is really neat. It would be great. It was not your email, but my own. I don't know if it's a true story. I'm pretty sure.

• 31:31Speaker 02

  Yeah, I've read that before.

• 31:32Speaker 03

  So scratch your own itch, fine. Like, it depends on what your goal is. If you want to do like a venture backed company, if it's a passion project, fucking passion, do it. Like, don't listen to anybody. In fact, but if you're trying to start, you know, an enduring company, solve an important business problem. And I, and I do think that in the world of agents, the software industries have shifted where you're not just helping people more, people be more productive, but you're actually accomplishing tasks autonomously. And as a consequence, I think the addressable market has just greatly expanded just because software can actually do things now and actually accomplish tasks. And how much is coding autocomplete worth? A fair amount. How much is the eventual, I'm certain we'll have it, the software agent that actually

• 32:15Speaker 03

  writes the code and delivers it to you? That's worth a lot. And so, you know, I would just maybe look up from the large language models and start thinking about the economy and, you know, think from first principles. I don't want to get too far afield, but just think about which parts of the economy will benefit most from this intelligence and which parts can absorb it most easily. And what would an agent in this space look like? Who's the customer of it? Is the technology feasible? And I would just start with these business problems more. And I think, you know, the best companies tend to have. Great engineers who happen to have great insight into a market. And it's the last part that I think some people, whether or not they have it's like people start so much in the technology.

• 32:59Speaker 03

  They lose the forest for the trees a little bit.

• 33:02Alessio Fanelli?

  How do you think about the model of still selling some sort of software versus selling more package labor? I feel like when people are selling the package labor, it's almost more stateless, you know? Like it's easier to swap out if you're just putting an input and getting an output. If you think about coding, if there's no IDE, you're just putting a prompt and getting back an app. It doesn't really matter who generates the app, you know, you have less of a buy in versus the platform you're building. I'm sure on the backend, customers have to like put on their documentation. They have, you know, different workflows that they can tie in. What's kind of like the line to draw there versus like going full, where your managed customer support team as a service outsourced versus? This is the Sierra platform that you can build on. What was that decision?

• 33:44Speaker 03

  I'll sort of like decouple the question in some ways, which is when you have something that's an agent, who is the person using it? And what do they want to do with it? So let's just take your coding agent for a second. I will talk about Sierra as well. Who's the customer of a, an agent that actually produces software? Is it a software engineering manager? Is it a software engineer? And it's their, you know, intern, so to speak? I don't know. I mean, we'll figure this out over the next few years. Like, what is that? And is it generating code that you then review? Is it generating code with a set of unit tests that pass? What is the actual, for lack of a better word, contract? Like, how do you know that it did what you wanted it to do?

• 34:27Speaker 03

  And then I would say like the product and the pricing, the packaging model sort of emerged from that. And I don't think the world's figured out. And I think it'll be different for every agent. You know, in our customer base, we do what's called outcome based pricing. So essentially every time the AI agent solves the problem or saves a customer or whatever it might be, there's a pre-negotiated rate for that. We do that because it's, we think that that's sort of the correct way agents, you know, should be packaged. I look back at the history of like cloud software and notably the introduction of the browser, which led to software being Delivered in a browser like Salesforce, who famously invented sort of software as a service, which is both a technical delivery model through the browser,

• 35:08Speaker 03

  but also a business model, which is you subscribe to it rather than pay for a perpetual license. Those two things are somewhat orthogonal, but not really. If you think about the idea of software running in a browser that's hosted data center that you don't own, you sort of needed to change the business model because you can't really buy a perpetual license to something. Otherwise, like, how do you afford making changes to it? So it only worked when you're buying like a new version every year or whatever. So to some degree, but then the business model shift actually changed business as we know it. Because now like things like Adobe Photoshop, now you subscribe to rather than purchase. So it ended up where you had a technical shift and a business model shift

• 35:50Speaker 03

  that were very logically intertwined, that actually the business model shift was, it turned out to be as significant as the technical, as the shift. And I think with agents, because they actually accomplish a job, I do think that it doesn't make sense to me that you'd pay for the privilege of like using the software. Like that coding agent, like if it writes really bad code, like fire it. I don't know what the right metaphor is. You should pay for a job well done, in my opinion. I mean, that's how you pay your software engineers, right? And, and.

• 36:21Speaker 02

  Well, not really. We paid, put them on salary and give them options and they vest overtime.

• 36:25Speaker 03

  That's fair, but my point is that you don't pay them for how many characters they write, which is sort of the token based, you know, whatever. Like there's that famous Apple story where we're like asking for a report of how many lines of code you wrote. And one of the engineers showed up with like a negative number because he had just like done a big refactoring. But it was like a big F you to management who didn't understand how software is written. You know, my sense is like the traditional usage based or seat based thing. It's just going to look really antiquated because it's like asking your software engineer, how many lines of code did you write today? Like, who cares? Like, because absolutely no correlation. So my whole view is I don't think it's be different in every category, but I do think that that is the, if an agent is doing a job, you should.

• 37:10Speaker 03

  I think it properly incentivizes the maker of that agent and the customer of you're paying for the job well done. It's not always perfect to measure. It's hard to measure engineering productivity, but you can, you should do something other than how many keys you typed, you know? Talk about perverse incentives for AI, right? Like I can write really long functions to do the same thing, right? So broadly speaking, you know, I do think that we're going to see a change in business models of software towards outcomes. And I think you'll see a change in delivery models too. And, and you know, in our customer base, you know, we empower our customers to really have their hands on the steering wheel of what the agent does. They, they want and need that, but the role is different, you know, at a lot of our customers, the customer experience operations folks have renamed themselves the AI architects,

• 37:54Speaker 03

  which I think is really cool. And, you know, it's like in the early days of the internet, there's the role of the webmaster. And I don't know whether, you know, webmaster is not a fashionable term, nor is it a job anymore. I don't know. Will AI architects stand the test of time? Maybe, maybe not. But I do think that, again, I like, you know, because everyone listening right now is a software engineer, like what is the form factor of a coding agent? And actually I'll, I'll take a breath because actually I have a bunch of pins on like, I wrote a blog post right before Christmas, just on the future of software development. And one of the things that's interesting is like, if you look at the way I use cursor today as an example, it's inside of a repackage visual studio code environment.

• 38:35Speaker 03

  I sometimes use the sort of agentic parts of it, but it's largely, you know, I've sort of gotten a good routine of making it autocomplete code in the way I want through tuning it properly. When it actually can write code completely, I do wonder what like the future of development environments will look like. And to your point on what is a software product, I think it's going to change a lot in ways that will surprise us. But I always use, I use the metaphor in my blog post of, have you all driven around in a Waymo around here? Everyone has. And there are these Jaguars, really nice cars, but it's funny because it still has a steering wheel, even though there's no, it's sitting there and the steering wheel is like turning and stuff. Clearly in the future, if, once we get to that be more ubiquitous, like why have the steering wheel?

• 39:20Speaker 03

  And also why have all the seats facing forward? Maybe just for carsickness. I don't know, but like you could totally rearrange the car. I mean, so much of the car is oriented around the driver. So it stands to reason to me that like, will autonomous agents for software engineering run through Visual Studio Code? That seems a little bit silly because having a single source code file open one at a time is kind of a goofy form factor for when like the code isn't being written primarily by you. But it begs the question of what's your relationship with that agent? And I think the same is true in our industry of customer experience, which is like, who are the people managing this agent? What the tools do they need? And they definitely need tools, but it's probably pretty different than the tools we had before.

• 40:04Speaker 03

  It's certainly different than training a contact center team. And as software engineers, I think that I would like to see particularly like on the passion project side or research side, more innovation in programming languages. I think that we're bringing the cost of writing code down to zero. So the fact that we're still writing Python with AI cracks me up just because it's like literally was designed to be ergonomic to write, not safe to run or fast to run. I would love to see more innovation in how we verify program correctness. I studied formal verification in college a little bit and it's not very fashionable because it's really tedious and slow and doesn't work very well.

• 40:46Speaker 03

  If a lot of code is being written by a machine, you know, one of the primary values we can provide is verifying that it actually does what we intend that it does. I think there should be lots of interesting things in the software development lifecycle, like how we think of testing and everything else. Because if you think about, if we have to manually read every line of code that's coming out of these machines, it will just rate limit how much the machines can do. The alternative is totally unsafe. So I wouldn't want to put code in production that didn't go through proper code review and inspection. So my whole view is like, I actually think there's like an AI native, I don't think, the coding agents don't work well enough to do this yet, but once they do, what is sort of an AI native software development lifecycle?

• 41:29Speaker 03

  And how do you actually enable the creators of software to produce the highest quality, most robust, fastest software? And know that it's correct. And I think that's an incredible opportunity. I mean, how much C code could we rewrite in Rust and make it safe so that there's fewer security vulnerabilities? Can we like have more efficient, safer code than ever before? And can you have someone who's like that guy in the matrix, you know, like staring at the little green things? Like where could you have an operator of a code generating machine be like superhuman? I think that's a cool vision. And I think too many people are focused on like autocomplete, you know, right now, and not, not even I'm guilty as charged.

• 42:11Speaker 03

  But I just like, I'd like to see some bolder ideas. And that's why when you were joke, you know, talking about what's the reactive, whatever? I think we're clearly in a local maximum, you know, metaphor, like sort of conceptual local maximum. Obviously, it's moving really fast. I think we're moving out of it.

• 42:26Alessio Fanelli?

  Yeah. At the end of 23, I wrote this blog post from syntax to semantics. Like if you think about Python, it's taking C and making it more semantic. And LLMs are like the ultimate semantic program, right? You can just talk to them and they can generate any type of syntax from your language. But again, the languages that they have to use were made for us, not for them. But the problem is like, as long as you will ever need a human to intervene, you cannot change the language under it. You know what I mean? So I'm curious at what point of automation we'll need to get, we're gonna be okay making changes to the underlying languages, like the programming languages. Versus just saying, hey, you just gotta write Python because I understand Python and I'm more important at the end of the day than the model. But I think that will change, but I don't know if it's like two years or five years.

• 43:11Speaker 03

  I think it's more nuanced, actually. So I think there's a, some of the more interesting programming languages bring semantics into syntax. So maybe that's a little reductive, but like Rust is an example. Rust is memory safe statically. And that was a really interesting conceptual, but it's why it's hard to write Rust. It's why most people write Python instead of Rust. I think Rust programs are safer and faster than Python, probably slower to compile. But like broadly speaking, like given the option, if you didn't have to care about the labor that went into it, you should prefer a program written in Rust over a program written in Python. Because it will run more efficiently, it's almost certainly safer, et cetera, et cetera,

• 43:55Speaker 03

  depending on how you define safe. But most people don't write Rust because it's kind of a pain in the ass and the audience of people who can is smaller, but it's sort of better in most, most ways. And again, unless you're making a web service and you didn't have to care about how hard it was to write, if you just got the output of the web service, the Rust one would be cheaper to operate, certainly cheaper and probably more correct just because there's so much in the static analysis implied by the Rust programming language, they probably will have fewer runtime errors and things like that as well. So I just give that as an example because Rust, at least my understanding, it came out of the Mozilla team because there's lots of security vulnerabilities in the browser and it needs to be really fast.

• 44:36Speaker 03

  So they said, okay, we want to put more of a burden at the authorship time to have fewer issues at runtime and we need the constraint that it has to be done statically because browsers need to be really fast. My sense is if you just think about like the, the needs of a programming language today, where the role of a software engineer is to use an AI to generate functionality and audit that it does in fact work as intended, maybe functionally, maybe from like a correctness standpoint, some combination thereof, how would you create a programming system that facilitated that? And, you know, I bring up Rust just because I think it's a good example of like, I think,

• 45:19Speaker 03

  given a choice of writing in C or Rust, you should choose Rust today. I think most people would say that, even C aficionados, just because C is largely less safe for very similar, you know, trade offs, you know, for the, the system. And now with AI, it's like, okay, well, that just changes the game on writing these things. And so like, I just wonder if a combination of programming languages that are more structurally oriented towards the values that we need from an AI generated program, verifiable correctness and all of that, if it's tedious to produce for a person, that maybe doesn't matter. But one thing like if I asked you, is this Rust program memory safe? You wouldn't have to read it, you just.

• 45:59Speaker 03

  Have to compile it. So that's interesting. I mean, that's like an, that's one example of a very modest form of formal verification. So I bring that up because I do think you have AI inspect AI, you can have AI review, do AI code reviews. It would disappoint me if the best we could get was AI reviewing Python and having scaled a few very large websites that were written on Python. It's just like, you know, expensive and it's like every, trust me, every team who's written a big web service in Python has experimented with like PyPI and all these things just to make it slightly more efficient than it naturally is. You don't really have true multi-threading. Anyway, it's just like clearly that you do it just because it's convenient to write. And I just feel like we're, I don't say it's insane. I just mean,

• 46:43Speaker 03

  I do think we're at a local maximum and I would hope that we create a programming system, a combination of programming languages, formal verification, testing, automated code reviews where you can use AI to generate software in a high scale way and trust it. And you're not limited by your ability to read it necessarily. I don't know exactly what form that would take, but I feel like that would be a pretty cool world to live in.

• 47:08Alessio Fanelli?

  Yeah, we have Chris Lattner on the podcast. He's doing great work with modular emoji.

• 47:12Speaker 03

  I love him.

• 47:13Speaker 02

  Yeah, basically merging Rust and Python.

• 47:15Alessio Fanelli?

  That's kind of the idea. But what I'm curious is like for them, a big use case was like making it compatible with Python, same APIs, so that Python developers could use it. And so I wonder what point.

• 47:26Speaker 03

  At least my understanding is they're targeting the data science and machine learning crowd, which is all written in Python. So still feels like a local maximum.

• 47:34Alessio Fanelli?

  Yeah, exactly.

• 47:35Speaker 02

  I'll force you to make a prediction. You know, Python's roughly 30 years old. In 30 years from now, is Rust going to be bigger than Python?

• 47:42Speaker 03

  I, I don't know this, but just, I don't even know this is a prediction. I just am sort of like saying stuff I hope is true. I would like to see. An AI-native programming language and programming system. And I use language because I'm not sure language is even the right thing. But I hope in 30 years, there's an AI-native way we make software that is wholly uncorrelated with the current set of programming languages. Or not uncorrelated, but I think most programming languages today were designed to be efficiently authored by people. And some have different trade-offs. You know, you have Haskell and others that were designed for abstractions, for parallelism and things like that. You have programming languages like Python, which are designed to be very easily written,

• 48:27Speaker 03

  sort of like Perl and Python lineage, which is why data scientists use it. It's, it can, it has a interactive mode, things like that. And I love, I'm a huge Python fan, so despite all my Python trash talk, I'm a huge Python fan. Wrote, at least two of my three companies were exclusively written in Python. MNC came out of the birth of Unix, and it wasn't the first, but certainly the most prominent first step after assembly language, right? Where you had higher level abstractions rather than, and going beyond go-to to like abstractions like the for loop and the while loop. So I just think that if the act of writing code is no longer a meaningful human exercise,

• 49:09Speaker 03

  maybe it will be, I don't know, I'm just saying it sort of feels like a, maybe it's one of those parts of history that just will sort of like go away. But there's still the role of the software engineer, like the person actually building the system, right? And what does a programming system for that form factor look like? And I, I just have a, I hope to be, just like I mentioned React. I remember I was at Facebook in the very early days and when, when what is now React was being created. And I remember when the, it was like released open source, I had left by that time. And I was just like, this is so fucking cool. Like. You know, to basically model your app independent of the data flowing through it just made everything easier. And now, you know, I can create like, there's a lot of

• 49:54Speaker 03

  the front end software is like a little chaotic for me, to be honest with you. There's like, it's sort of like abstraction soup right now for me. But like, some of those core ideas felt really ergonomic. I just want to, I'm looking forward to the day when someone comes up with a programming system that feels both really like an aha moment, but completely foreign to me at the same time, because they created it with sort of like from first principles, recognizing that like authoring code in an editor is maybe not like the primary like reason why a programming system exists anymore. And I think that's like, that would be a very exciting day for me.

• 50:28Speaker 02

  Yeah. I would say like, the various versions of this discussion have happened. At the end of the day, you still need to precisely communicate what you want. As a manager of people, as someone who has done many, many legal contracts, you know how hard that is. And then now we have to talk to machines doing that and AIs interpreting what we mean and reading our minds effectively. I don't know how to get across that barrier of translating human intent to instructions. And yes, it can be more declarative, but I don't know if it'll ever cross over from being a programming language to something more than that.

• 51:02Speaker 03

  I agree with you. And I actually do think if you look at like a legal contract, you know, the imprecision of the English language.

• 51:10Speaker 02

  It's shocking.

• 51:11Speaker 03

  Like a flaw in the system.

• 51:12Speaker 02

  How many holes there are.

• 51:13Speaker 03

  And I do think that when you're making a mission critical software system, I don't think it should be English language prompts. I think that is silly because you want the precision of a programming language. My point was less about that and more about if the actual act of authoring it, like if you, I'll think of some embedded systems do use formal verification. I know it's very common in like, security protocols now, so that you can, because the importance of correctness is so great. My intellectual exercise is like, why not do that for all software? I mean, probably that's silly, just literally to do what we literally do for these low level security protocols. But the only reason We don't is because it's hard and tedious and hard and tedious are no longer factors.

• 51:57Speaker 03

  So like, if I could, I mean, just think of like the silliest app on your phone right now. The idea that that app should be like formally verified for its correctness feels laughable right now. Because like, God, why would you spend the time on it? But if it's zero cost, like, yeah, I guess so. I mean, it'd never crash. That's probably good, you know, why not? I just want to like set our bars really high. Like, we should make, software's been amazing. Like, there's that Marc Andreessen blog post, software's eating the world. And, you know, our whole life is mediated digitally and that's just increasing with AI. And now we'll have our personal agents talking to the agents on the CRO platform and its agents all the way down. You know, our core infrastructure is running on these digital systems.

• 52:39Speaker 03

  We now have like, and we've had a shortage of software developers for my entire life. And as a consequence, you know, if you like, remember like healthcare, healthcare.gov, that fiasco. Security vulnerabilities leading to state actors getting access to critical infrastructure. I'm like, we now have like created this like amazing system that can like, we can fix this, you know? And I just want to, I'm both excited about the productivity gains of the economy. But I just think as software engineers, we should be bolder. Like, we should have aspirations to fix these systems so that like in general, as you said, as precise as we want to be in the specification of the system, we can make it work correctly now. And I'm being a little bit hand wavy and I think we need some systems.

• 53:22Speaker 03

  I think that's where we should set the bar, especially when so much of our life depends on this critical digital infrastructure. So I'm, I'm just like super optimistic about it. But actually, let's go to what you said for a second, which is specifications. I think this is the most interesting part of AI agents broadly, which is that most specifications are incomplete. So let's go back to our product engineering discussions. You're like, okay, here's a PRD, product requirements document. And there's, it's really detailed. There's mockups and this and like, when you click this button, it does this. And it's like, A hundred percent you can think of a missing requirement in that document. Let's say you click this button and the internet goes out. What do you do? I don't know if that's in the PRD. It probably isn't.

• 54:06Speaker 03

  You know, there's, there's always going to be something because like humans are complicated. Right? So what ends up happening is like, I don't, if you could measure it, like what percentage of a product's actual functionality is determined by its code versus its specification? Like for a traditional product. Oh. Ninety-five percent? I mean, a little bit, but a lot of it. So like code is the specification. It's actually why, if you just look at the history of technology, why open source has won out over specifications? Like, you know, for a long time, there was a W3C working group on HTML specification. And then, you know, once WebKit became prevalent, the internet evolved a lot faster. And it's not the expense of the standards organizations.

• 54:50Speaker 03

  It just turns out having a committee of people argue is like a lot less efficient than someone checking in code. And then all of a sudden you had vector graphics and you had like all this really cool stuff that, you know, someone who, in the Google Maps days, a guy like, God, that would have made my life easier, you know? It's like SVG support. Right. Life would have been a breeze. Try drawing a driving directions line without vector graphics. And so, you know, in general, I think we've gone from these protocols defined in a document to basically open source code that becomes an implicit standard, like systems calls in Linux. Like there is a specification, there is POSIX as a standard, but like the kernel is the, like, that's what people write against.

• 55:34Speaker 03

  And it's both the documented behavior and all of the undocumented behaviors as well, for better or for worse. And it's why, you know, Linus and others are so adamant about things like binary compatibility and all that. Like this stuff matters. So one of the things I really think about is like working with agents broadly is how do you, it's, I don't want to say it's easy to specify the guardrails you know, but what about all those unspecified behaviors? So, so much of like being a software engineer is like you come to the point where you're like, the internet's out and you get back the error code from the call and you gotta do something with it. And what percentage of the time do you just be like, I'm gonna do this because it seems reasonable?

• 56:17Speaker 03

  And what percentage of the time do you like write a Slack to your PM and be like, what do I do in this case? It's probably more the former than the latter, otherwise it'd be really fricking inefficient to write software. But what happens when your AI makes that decision for you? It's not a wrong decision. You didn't say anything about that case. The AI agent, the word agent comes from the word agency, right? So it's demonstrating its agency and it's making a decision. Does it document it? That would probably be tedious too, like, because there's so many implicit decisions. What happens when you click the button and the internet's out and it does something you don't like? How do you fix it? I actually think that we are like entering this new world where like the, how we express to an AI agent what we want is always going to be an incomplete specification.

• 57:02Speaker 03

  And that's why agents are useful, because they can fill in the gaps with some decent amount of reasoning. How you actually tune these over time? And imagine like building an app with an AI agent as your software engineering companion. There's like an infinitely long tail. Infinite is probably over exaggerating a bit, but there's a fairly long tail of functionality that I guarantee is not specified. How you actually tune that? And this is what I mean about creating a programming system. I don't think we know what that system is yet. And then similarly, I actually think for every single agentic domain, whether it's customer service or legal or software engineering, that's essentially what the company building those agents is building is like the system through which you express the behaviors you want, esoteric and small as it might be.

• 57:48Speaker 03

  Anyway, I think that's a really exciting area though, just because I think that's where the magic or that's where the product insights will be in this space is like, how do you encounter that, those moments?

• 57:56Speaker 02

  It's kind of built into the UX and it can't just be, the answer can't just be prompt better. You know.

• 58:03Speaker 03

  Yeah, no, it's impossible. The prompt would be too long. Imagine getting a PRD that literally specified the behavior of everything that was represented by code. The answer would just be code. Like at that point. So there's my point. Like prompts are great, but it's not actually a complete specification for anything. It never can be. And so, and I think that's how you do interactivity, like the sort of human loop thing, when and how you do it. And that's why I really believe in, in domain specific agents, because I think answering that in the abstract is like a interesting intellectual exercise. But I, that's why I like talking about agents in the abstract, kind of, I'm actively disinterested in it because I don't think it actually means anything.

• 58:46Speaker 03

  All it means is software is making decisions. That's what, you know, at least in a reductive way. But in the context of software engineering, it does make sense because you know, like, what is the process of first you specify what you want in a product? Then you use it, then you give feedback. You can imagine building a product that actually facilitated that closed loop system. And then how is that represented, that complete specification of both what you knew you wanted, what you discovered through usage? The union of all of that is what you care about and the rest is less to the AI. In the legal context, I'm certain there's a way to know, like, when should the AI ask questions? When shouldn't it? How do you actually intervene when it's wrong? And certainly in the customer service case, it's very clear, you know, and how, like, how we, our customers review every conversation?

• 59:31Speaker 03

  How we help them find the conversations they should review and they're having millions so they can find the few that are interesting? How, when something is wrong in one of those conversations? How they can give feedback so it's fixed the next time in a way where we know the context of why they, I made that decision. But it's not up to us what's right, right? It's up to our, our customers. So that's why I actually think for right, you know, right now, when you think about building an agent in domain, to some degree, how you actually interact with the people specifies behavior is actually where a lot of the magic is.

• 1:00:02Speaker 02

  Yeah. Stop me if this is a little bit annoying to you, but I have a bit of a trouble squaring domain-specific agents with the belief that AGI is real or AGI is coming because the point is general intelligence. And some part, some way, one way to view the bitter lesson is we can always make progress on being more domain-specific. Take whatever soda is and you make progress being more domain-specific. And then you will be wiped out. The next advance happens. Clearly, you don't believe in that. But how do you personally square those things?

• 1:00:34Speaker 03

  Yeah, it's a really heavy question. And, you know, I think a lot about AGI, given my role at OpenAI. But it's even hard for me to really conceptualize. And I love spending time with OpenAI researchers and actually like people in the community broadly, just talking about the implications. Because there's the first order effect and the effects of something that is super intelligent in some domains. And then there's the second and third order effects, which are harder to predict. So first, as I think that it seems likely to me that, you know, at first, and something that is AGI will be good in digital domains, you know, because it's software. So if you think about something like AI discovery and a new, say, like pharmaceutical therapy,

• 1:01:19Speaker 03

  the barrier to that is probably less the discovery than the clinical trial. And AI doesn't necessarily help with a clinical trial, right? That's a process that's independent of intelligence and it's a physical process. Similarly, if you think about the problem of climate change or like carbon removal, there's probably a lot of that domain that requires great ideas. But like whatever great idea you came up with, if you wanted to sequester that much carbon, there's probably a big physical component to that. So it's not really limited by intelligence. It might be, I'm sure it could be accelerated somewhat by intelligence. There's a really interesting conversation with an economist named Tyler Cohen, Cohen, recently. He just, I just watched a video of him and he was just talking about how there are parts of the economy where intelligence

• 1:02:04Speaker 03

  is sort of the limited resource that will take on AI slash AGI really rapidly and will drive incredible productivity gains. But there are other parts of the economy that aren't, and those will interact. It goes back to these complex second order effects like prices will go up in the domains that can't absorb intelligence rapidly, which will actually then slow down. You know, so it's gonna, I don't think it'll be evenly spread. I don't think it'll be perhaps as rapidly felt in all parts of the economy as people think. I might be wrong, but I just think you can generalize in terms of its ability to reason about different domains, which I think is what AGI means to most people.

• 1:02:44Speaker 03

  But it may not actually generalize in the world until, because there's a lot of intelligence is not the limiting factor in like a lot of the economy. So going back to your more practical question is like, why make software at all? You know, AGI is coming. I mean, you can say it that way.

• 1:03:00Speaker 02

  Should we learn to code? There's all variations of this.

• 1:03:03Speaker 03

  You know, my view is that I really do view AI as a tool and AGI as a tool for humanity. And so my view is whenever we're talking about like, is your job as a maker of software to author a code in an editor? I would argue no. Just like a generation ago, your job wasn't to punch cards in a punch card. That is not what your job is. Your job is to produce digital something. Whatever it is, what is the purpose of the software that you're making? Your job is to produce that. And so I think that like our jobs will change rapidly and meaningfully.

• 1:03:43Speaker 03

  But I think the idea that like our job is to type in a, in an editor is, is an artifact of the tools that we have, not actually what we're hired to do, which is to produce a digital experience to, you know, make firmware for our toaster, whatever, whatever it is we're doing, right? Like, that's our job, right? And as a consequence, I think with things like AGI, I think the, certainly software engineering will be one of the disciplines most impacted. And I think that it's very, so like, I think if you're in this industry and you define yourself by the tools that you use, like how many characters you can type into them.

• 1:04:23Speaker 03

  Every day, that's probably not like a long term, stable place to be because that's something that certainly AI can do better than you. But your judgment about what to build and how to build it still apply. And that will always be true. And one way to think about it's like a little bit reductive is like, you know, look at startups versus larger companies, like companies like Google and Amazon have so many more engineers than the startup. But then some startups still win. Like, why was that? Well, they made better decisions, right? They didn't type faster or produce more code. They did the right thing in the right market at the right time. And, and similarly, if you look at some of the great companies, it wasn't the lack of, they had some unique idea.

• 1:05:06Speaker 03

  Sometimes that's the reason why a company succeeds, but it's often a lot of other things and a lot of other forms of execution. So like broadly, like the existence of a lot of intelligence will change a lot and will change our jobs more than any other industry. Maybe not, maybe it's exaggerated, but certainly as much as any other industry. But I don't think it like changes like why the economy around digital technology exists. And, and as a consequence, I think I'm really bullish on like the future of, of the software industry. I just think that like some things that are really expensive today will become almost free. And, but I think that, I mean, let's be honest, the half life of technology companies is not particularly long as it is.

• 1:05:46Speaker 03

  Yeah, I, I brought this anecdote in a recent conversation, but when I started at Google, we were in one building in Mountain View. And then eventually moved into a campus, which was previously the Silicon Graphics Campus. That was the first campus Google, I'm pretty sure it still has that campus. I think it's got a billion now. SGI was a company that was like really, really big, big enough to have a campus and then went out of business. And it wasn't that old of a company, by the way, it's not like IBM, you know, that was like big enough to get a campus and go to business in my lifetime. You know, that type of thing. And then at Facebook, we had an office in Palo Alto. I moved, I didn't go into the original office. When I joined, it was the second office, this old HP building near Stanford. And then we got big enough to own a campus and we bought Sun Microsystems campus.

• 1:06:28Speaker 03

  Sun Microsystems famously came out of Stanford, went high flying. It was one of the dot com darlings. And then eventually sort of like bought for pennies on the dollar by Oracle. And you know, like all those companies, like in my lifetime, were big enough to like go public, have a campus, da, da, da, and then go out of business. So I think a lot will change. I don't mean to say this is going to be easy or like no one's business model is under threat. But will digital technology remain important? Will entrepreneurs having good judgment about where to apply this technology to create something of economic value still apply like a hundred percent? And I've always used the metaphor, like if you went back to 1980 and described many of the jobs that we have, it would be hard for people to conceptualize.

• 1:07:13Speaker 03

  Like imagine I'm a podcaster, you know, like what the hell does that mean? Imagine going back to like 1776 and describing to Ben Franklin, our economy today, like let alone the technology industry, just the services economy. It would be probably hard for him to conceptualize just like who grows the food, just because the idea that so few people in this country are necessary to produce the food for so many people would defy so much of his conception of just like how food is grown, that it would just be like, it would probably take a couple hours of explaining. It's kind of like the same thing. It's like, we, we have a view of like how this world works right now. That's based on just the constraints that exist, but there's going to be a lot of other opportunities and other things like that. So I don't know.

• 1:07:58Speaker 03

  I mean, it's certainly writing code is really valuable right now and it probably will change rapidly. I think people just need a lot of agility. I always use the metaphor where like a bunch of accountants, since Microsoft Excel was just invented, are you going to be the first person who sets down your HP calculator and says, I'm going to learn how to use this tool because it's just a better way of doing what I'm already doing? Or are you going to be the one who's like, you know, begrudgingly pulling out their slide rule in HP calculator and saying, Kids these days, you know, and their Excel, they don't understand. You know, it's been a little bit reductive, but I just feel like the probably the best thing all of us can do, not just in software industry.

• 1:08:36Speaker 03

  But I do think it's really kind of interesting, just reflection that we're disrupting our own industry as much as anything else with this technology is to lean into the change. Try the tools like install the latest coding assistance, you know, when oh, three mini comes out, write some code with it. That you don't want to be the last account to embrace Excel, you might not have your job anymore. So.

• 1:08:59Speaker 02

  We have some personal questions on like how you keep up with AI and you know, all the, all the other stuff. But I also want to, and I'll let you get to your question. I just wanted to say that the analogy that you made on food was really interesting and resonated with me. I feel like we are kind of in like an agrarian economy of like a barter economy for intelligence. And now we're sort of industrializing intelligence and I, that really just was an aha moment for me. I just wanted to reflect that.

• 1:09:23Alessio Fanelli?

  Yeah. How do you think about the person being replaced by an agent and how agents talk to each other? So even at Sierra today, right? You're building agents that people talk to. But in the future, you're going to have agents that are going to complain about the order they place to the customer support.

• 1:09:39Speaker 03

  Turtles all the way there.

• 1:09:40Alessio Fanelli?

  Exactly. And you know, you were the CTO of Facebook, you built Open Graph there. And I think there were a lot of pros, things that were being enabled, then maybe a lot of cons that came out of that. How do you think about how the agent protocols should be built? Thinking about all the implications of, you know, privacy, data, discoverability and all that.

• 1:09:57Speaker 03

  Yeah, I think it's a little early for a protocol to emerge. I've read about a few of the attempts and maybe some of them will catch on. One of the things that's really interesting about large language models is because they're trained on language is they are very capable of using the interfaces built for us. And so my intuition right now is that because we can make an interface that works for us and it also works for the AI. Maybe that's good enough. You know, I mean, a little bit hand wavy here, but making a machine protocol for agents that's inaccessible to people. There's some upsides to it, but there's also quite a bit of downside to. As well, I think it was Andrej Karpathy, but I can't remember.

• 1:10:39Speaker 03

  But like, one of the more well-known AI researchers wrote like, I spent half my day writing English, in my software engineering. I have an intuition that agents will speak to agents using language for a while. I don't know if that's true, but there's a lot of reasons why that may be true. And so, you know, when your personal agent speaks to a Sierra agent to help figure out why your Sonos speaker has the flashing orange light, my intuition is it will be in English for a while. And I think there's a lot of like benefits to that. I do think that we still are in the early days of like long-running agents. I don't know if you've tried the deep research agent that just came out.

• 1:11:22Speaker 02

  We have one for you.

• 1:11:23Speaker 03

  We deep research. Oh, that's great. It was interesting because it was probably the first time I really got like notified by OpenAI when something was done and I brought up before the interactive parts of it. That's the area that I'm most interested in right now, just is that like most agentic workflows are relatively short-running. And the workflows that are multi-stakeholder, long-running, multi-system, we deal with a lot of those in at Sierra. But broadly speaking, I think that those are interesting just because I always use the metaphor that prior to the mobile phone, every time you got like a notification from some internet service, you get an email. Not because email was like the best way to notify you, but it's the only way.

• 1:12:08Speaker 03

  And so, you know, you used to get tagged on a photo in Facebook and you get an email about it. Then, once this was in everyone's pocket, every app had equal access to buzzing your pocket. And now, you know, for most of the apps I use, I don't get email notifications. I just get it directly from the app. I sort of wonder what the form factors will be for agents. How do you address and reach out to other agents? And then how does it bring you, the operator of the agent into the loop at the right time? You know, I certainly think there's companies like, you know, with ChatGPT, that will be one of the major consumer surfaces. So there's like, there's a lot of like gravity to those services. But then if I think about sort of domain-specific workflows as well, I think there's just a lot to figure out there.

• 1:12:51Speaker 03

  So I'm less the agent-agent protocols. I actually think I could be wrong. I just haven't thought about a lot. Like, it's sort of interesting, but actually just how it engages with all the people in it is actually one of the things I'm most interested to sort of see how it plays out as well.

• 1:13:04Alessio Fanelli?

  Yeah, I think to me, the things that are at the core of it is kind of like our back. You know, it's like, can this agent access this thing? I think in the customer support use cases, maybe less prominent, but like in the enterprises is more interesting. And also like language, like you can compress the language if the human didn't have to read it. You can kind of save tokens, make things faster. So.

• 1:13:23Speaker 03

  Speaking of.

• 1:13:26Alessio Fanelli?

  You mentioned being notified about deep research. Is there a OpenAI deep research has been achieved internally notification that goes out to everybody? And the board gets summoned and you get to see it. Can you give any backstory on that process?

• 1:13:40Speaker 03

  OpenAI is a mission driven nonprofit that I think of primarily as a research lab. It's obviously more than that, you know, in some ways like chat GPT is a cultural defining product. But at the end of the day, the mission is to ensure that artificial general intelligence benefits all of humanity. So a lot of our board discussions are about research and its implications on humanity, which is primarily safety. Obviously, I think the one cannot achieve AGI and not think about safety as a primary responsibility for that mission. But it's also access and other things. So things like deep research, we definitely talk about because it's a big part of if you think about what does it mean to build AGI? But we talk about a lot of different things, you know?

• 1:14:23Speaker 03

  So it's like, sometimes we hear about things super early. Sometimes if it's not really related, if it's sort of far afield from the core of the mission, you know, it's like more casual. So it's pretty fun, fun to be a part of though, just because it's my favorite part of every board discussion is just hearing from the researchers about how they're thinking about the future and just like the next, next milestone in creating AGI.

• 1:14:45Alessio Fanelli?

  Well, lots of milestones. Maybe we'll just start at the beginning, like, you know, there are very few people that have been in the rooms that you've been in. How do these conversations start? How do you get brought into OpenAI? Obviously, there's, there's a bit of drama that you can go into if you want. Just take us into the room, like what happens? What, what is it like?

• 1:15:00Speaker 03

  Was it a Thursday or Friday when

• 1:15:03Speaker 02

  Friday.

• 1:15:03Speaker 03

  Sam was fired. Yeah. So I heard about it like everyone else, you know, just like saw it on, on social media and

• 1:15:12Speaker 02

  I remember where I was walking here.

• 1:15:13Speaker 03

  And I was totally shocked and messaged my co-founder Clay and I was like, gosh, I wonder what happened. And then on Saturday, trying to just protect sort of like people's privacy, but I ended up talking to both Adam D'Angelo and Sam Altman and basically getting a kind of synopsis of what was going on. And my understanding that you could, you'd have to ask them for sort of their perspective on this was just basically like they, both the, the board and Sam both felt some trust in me. And it was a very complicated situation because the, the company was reacted pretty negatively, understandably negatively to Sam's being fired. I don't think they really understood what was going on. And so the

• 1:15:56Speaker 03

  board was, you know, in a situation where they needed to sort of figure out a path forward. And they reached out to me and then I talked to Sam and basically ended up kind of the mediator, for lack of a better word, not really formally that, but fundamentally that. And as the board was trying to figure out a path forward, you know, we, we ended up with a lot of discussions with like how to reinstate Sam as a CEO of the company, but also do a review of what happened so that the board's concerns could be fully sort of adjudicated, you know, because they obviously did have concerns going into it. So ended up there. So I think broadly speaking, I was just like a known, like a lot of the stakeholders in it knew of me and, and I'd like to think I have some integrity. So it

• 1:16:38Speaker 03

  was just sort of like, you know, they were trying to find a way out of a very complex situation. So I ended up kind of meditating that and have formed a really great relationship with Sam and Greg and pretty challenging time for the company. Didn't plan to be, you know, on the board. I, you know, got pulled in because of the crisis that happened. And I don't think I'll be on the board forever either. I, I posted when I joined that I was going to do it temporarily. That was like a year, a year ago. You know, I really like to focus on Sierra, but I also So really care about.

• 1:17:12Speaker 02

  I mean, it's a fantastic mission.

• 1:17:13Speaker 03

  It's it's just an amazing mission. So.

• 1:17:15Speaker 02

  Yeah, I've in maybe been in like high stakes situations like that like twice, but obviously not as high stakes. But like, what principles do you have when you know like these? This is the highest egos, highest amount of stakes possible, highest amount of money, whatever. What principles do you have to to go into something like this? Like, obviously, you have a great reputation, you're a great network. What are your must do's and what are your must not do's?

• 1:17:39Speaker 03

  I'm not sure there's a if there were a playbook for these situations, they would be a lot simpler.

• 1:17:44Speaker 02

  Please share.

• 1:17:45Speaker 03

  So, you know, I just probably go back to like the way I operate in general. One is first principles thinking. So I I do think that there's crisis playbooks, but there was nothing quite like this. And you really need to understand what's going on and why. I think a lot of moments of crisis are fundamentally human problems. You can strategize about people's incentives and this and that and the other thing. But I think it's really important to understand all the people involved and what motivates them and why, which is fundamentally an exercise in empathy, actually. Like, do you really understand why people are doing what they're doing? And then getting good advice, you know? And I think people, what's interesting about a high profile crisis is everyone wants to give you advice.

• 1:18:30Speaker 03

  So there's no shortage of advice, but the good advice is the one. And I think that really involves judgment, which is who are people based on first principles? Analysis of the situation, based on your assessment of what, you know, all the people involved, who would have true expertise and good judgment, you know, in these situations? So that you can either validate your judgment if you have an intuition or if it's an area that's like a area of like, say, legal expertise that you're not expert and you want the best in the world to give you advice. And I actually find people often seek out the wrong people for advice. And it's really important in those circumstances.

• 1:19:08Speaker 02

  Well, I mean, it's super well navigated. I have I got one more and then we can sort of move on on this topic. The the Microsoft offer was real, right? For Salmon team to move over at some at one point in that weekend.

• 1:19:19Speaker 03

  I'm not sure.

• 1:19:20Speaker 02

  Okay.

• 1:19:20Speaker 03

  You know, I was sort of in it from one vantage point, which was, I actually, it's interesting is like, I didn't really have particular skin in the game. So like, I came at this as, I still don't own any equity in OpenAI. I was just, I was just a meaningful bystander in the process. And the reason I got involved, and I will get to answer your question, but the reason I got involved was just because I cared about OpenAI. So, you know, I had left my job at Salesforce and by coincidence, the next month, ChatGPT comes out and, you know, I got nerd sniped like everyone else. I'm like, I want to spend my life on this. This is so amazing. And I wouldn't, I don't know if I'd be, I wouldn't, I'm not sure I would have started another company if not for OpenAI, kind of inspiring

• 1:20:03Speaker 03

  the world with ChatGPT. Maybe I would have. I don't know. But it was like, it had a very significant impact on you, all of us, I think. So the idea that it would dissolve in a weekend just like bothered me a lot. And I'm very, I think I'm very grateful for, for OpenAI's existence. And my guess is that is probably shared by a lot of the competing research labs to different degrees too. It's just like, it kind of, that rising tide lifted all boats. Like, I think it created the proverbial iPhone moment for AI and changed, changed the world. So there were lots of, Microsoft is an investor in OpenAI and has a vested interest in, in the Sam and Greg had their interests.

• 1:20:45Speaker 03

  The employees had their interests and there's lots of wheeling and dealing. And that, you know, you can't A B test decision making. So I don't know if like, things had fallen apart with that. I don't, I don't actually know. And you also don't know like, what's real, what's not. I mean, so you'd have to talk to, to them to know what was really real. So.

• 1:21:03Speaker 02

  Mentioning advisors, I heard it seems like Brian Armstrong was a surprisingly strong advisor during, during the whole journey, which is.

• 1:21:10Speaker 03

  The, my understanding was both Brian Armstrong and Ron Conway were really close to Sam through it. And I ended up talking to them, but also tried to talk a lot to the board too, you know, trying to be the mediator. I was trying to, you obviously have a position on it. Like, and I felt that, you know, from the outside looking in, I just. Really wanted to understand like, why did this happen? And the process seemed, you know, perhaps hamfisted, you know, to say the least. But I was trying to remain sort of dispassionate because one of the principles was like, if you want to put Humpty Dumpty back together again, you can't be a single issue voter, right? Like, you have to go in and say like, so it was a pretty sensitive moment. But yeah, I think Brian's one of the great entrepreneurs and a true, true, true friend and ally to Sam through that.

• 1:21:55Speaker 02

  He's been through a lot as well. The reason I bring up Microsoft is because, I mean, obviously huge backer. We actually talked to David Loewen, who pitched, I think it was Satya at the time, on the first billion dollar investment in OpenAI. The understanding I had was that the best situation was for Microsoft was OpenAI as it is. Second best was Microsoft, Echo hires Sam and Greg and whoever else. And that was the relationship at the time, super close, exclusive relationship and all that. I think now things have evolved a little bit and, you know, with the, with Stargate. And there's some, some uncertainty or FUD about the relationship between Microsoft and OpenAI. And I just wanted to just kind of bring that up because like, we're also working like one Satya's,

• 1:22:40Speaker 02

  we're fortunate to have Satya as a subscriber to the InSpace and we're working on an interview with him. And we're trying to figure out how this has evolved now. Like, what is, how would you characterize the relationship between Microsoft and OpenAI?

• 1:22:52Speaker 03

  Microsoft's, you know, the most important partner of OpenAI, you know? So we have a really like deep relationship with them on many fronts. So I think it's always evolving just because the scale of this market is evolving. And in particular, the capital requirements for infrastructure are well beyond what anyone would have predicted two years ago, let alone whenever the Microsoft relationship started. What was that, six years ago? I actually don't, I should know off the top of my head, but it's a long time, long, sorry, in this, in the world of AI, a longer time ago. I don't really think there's anything to share. I mean, it's, I don't, I think the relationship's evolved because the markets evolved, but the core tenets of the partnership have remained the same. And it's, you know, by far OpenAI's most important partner.

• 1:23:36Speaker 02

  Just double clicking a little bit more, just like obviously a lot of our listeners are, you know, care a lot about the priorities of OpenAI. I've had it phrased to me that OpenAI had sort of five top level priorities, like always have frontier models, always be on the frontier of efficiency as well, be the first in sort of multimodality, whether it's video generation or real time voice, anything like that. How would you characterize the top priorities of OpenAI, apart from just the highest level AGI thing?

• 1:24:02Speaker 03

  I always come back to the highest level AGI, as you put it. It is a mission driven organization, but I think a lot of companies talk about their mission. But OpenAI is literally like the mission defines everything that we do. And I think it is important to understand that if you're trying to like predict where OpenAI is going to go, because if it doesn't serve the mission, it's very unlikely that it will be a priority for OpenAI. You know, it's a big organization, so occasionally you might have like side projects. You're like, you know what? I'm not sure that's going to really serve the mission as much as we thought. Like, let's not do it anymore. But at the end of the day, like people work at OpenAI because they believe in the benefits that AGI can have to humanity. Some people are there because they want to build it.

• 1:24:46Speaker 03

  And the actual act of building is incredibly intellectually rewarding. Some people are there because they want to ensure that AGI is safe. I think we have the best AGI safety team in the world. And there's just so many interesting research problems to tackle there as these models become increasingly capable, as they have access to the internet, if they have access to tools. It's just like really interesting stuff, but everyone is there because they're interested in the mission. And as a consequence, I think that, you know, if you look at something like deep research that lens, it's pretty logical, right? It's like, of course, that's if you're going to think about what it means to create AGI, enabling AI to help further the cause of research is meaningful.

• 1:25:30Speaker 03

  You can see why a lot of the AGI labs are working on software engineering and code generation, because that seems pretty useful if you're trying to make AGI, right? Just because a huge part of it is code, you know, to do it. Similarly, as you look at sort of Tool use and agents right down the middle of what you need to do AGI. That is the priority to come. I don't think there is like a top. I mean, sure, there is like a maybe an operational top 10 list, but it is fundamentally about building AGI and ensuring AGI benefits all of humanity. And that's all we exist for. And the rest of it is like, not a distraction necessarily, but that's like the only reason the organization exists. The thing that I think is remarkable is if I had described that mission to the two of

• 1:26:13Speaker 03

  you four years ago, like, you know, one of the interesting things is like, how do you think society would use AI? We'd probably think almost maybe like industrial applications, robots, all these other things. I think ChatGPT has been the most delightful and it doesn't feel counterintuitive now, but like counterintuitive way to serve that mission because the idea that you can go to chatgpt.com and access the most advanced intelligence in the world and there's like a free tier is like pretty amazing. So actually, one of the neat things I think is that ChatGPT, you know, famously was a research preview that turned into this like Very low key. Brand, you know, industry defining brand.

• 1:26:54Speaker 03

  I think it is one of the more key parts of the mission in a lot of ways because it is the way many people are use this intelligence for their everyday use. It's not limited to the few. It's not limited to, you know, a form factor that's inaccessible. So I actually think that it's been really neat to see how much that has led to. There's lots of different contours of the mission of AGI, but benefiting humanity means everyone can use it. And so I do think like to your point on is cost important? Oh yeah, cost is really important. How can we have all of humanity access AI if it's incredibly expensive and you need the $200 subscription, which I pay for because I think, you know, O1 Pro mode is mind blowing, you know?

• 1:27:38Speaker 03

  But it's you want both because you need the advanced research. You also want everyone in the world to benefit. So that's the way, and if you're trying to predict where we're going to go, just think, what would I do if I were running a company to, you know, go build AGI and ensures it benefits humanity? That's, that's how we prioritize everything.

• 1:27:57Alessio Fanelli?

  I know we're gonna wrap up soon. I would love to ask some personal questions. One, what are maybe I've been guiding principles for you, one in choosing what to do. So you know, you were COO of Salesforce, you were CTO of Facebook. I'm sure you've got it done a lot more things, but those were the choices that you made. Do you have frameworks that you use for that? Yeah, let's start there.

• 1:28:16Speaker 03

  I try to remain sort of like present and grounded in the moment, so.

• 1:28:20Alessio Fanelli?

  Meditation?

• 1:28:21Speaker 03

  No, I wish I did it more, but I don't. I really try to focus on like impact, I guess, on what I work on, but also do I enjoy it? And sometimes I think, we talked a little bit about, you know, what should an entrepreneur work on if they want to start a business? And I was sort of joking around about sometimes the best businesses are passion projects. I definitely take into account both, like I, I want to have an impact on the world. And I also like want to enjoy building what I'm building. And I wouldn't work on something that was impactful if I didn't enjoy doing it every day. And then I try to have some balance in my life. I've got a family and one of the values of Sierra is competitive intensity.

• 1:29:06Speaker 03

  But we also have a value called family and we always like to say, intensity and balance are compatible. You can be in a really intense person and I don't have a lot of like hobbies. I basically just like work and spend time with my family, but I have balance there. And but I, but I do try to have that balance just because, you know, if you're proverbially, you know, on your deathbed, what do you, what do you want? And I want to be surrounded by people I love and to be proud of the impact that I had.

• 1:29:35Alessio Fanelli?

  I know you also love to make handmade pasta. I'm Italian, so I would love to hear favorite pasta shapes, maybe sauces.

• 1:29:43Speaker 03

  Oh, that's good. I don't know where you found that. Was that deep research or whatever?

• 1:29:47Alessio Fanelli?

  It was. Sorry, where is this from?

• 1:29:50Speaker 03

  It was from, I forget. It was, it was, the source was linked. Chat GPT, holy shit. I do love to cook. So I started making pasta when my kids were little because I found getting them involved in the kitchen made them eat their meals better. So like participating in the act of making the food made them appreciate the food more. And so we do a lot of just like swinetti, linguine, just because it's pretty easy to do. And the crank is turning and the part of the pasta making for me was like they could operate the crank and I could put it through and it was very interactive. Sauces, I do a bunch, probably, I mean. I the like really simple marinara with really good tomatoes and is like

• 1:30:33Speaker 03

  just a classic, especially if you're really good pasta, but I like them all. But I mean, I just, you know, it's probably the good to just go. It's easy. So.

• 1:30:40Alessio Fanelli?

  I just said to us when I saw it come up in the research.

• 1:30:42Speaker 02

  Do you have one? I mean, you have to weigh in as the Italian here.

• 1:30:45Alessio Fanelli?

  Yeah, I would say so. There's one type of spaghetti you call alla chitarra. It's kind of like they're almost square. Those are really good. We're like you do a cherry tomato.

• 1:30:54Speaker 03

  Yeah.

• 1:30:54Alessio Fanelli?

  Sauce with oil you can put on do you in there? Yeah, we can do all different podcasts on.

• 1:30:59Speaker 02

  Alessio was like head of the Italian tech mafia. Very, very good restaurants. I highly recommend going to Italian restaurants with him. Yeah, okay. So then my question would be, how do you keep up on AI? There's so much going on. Do you have some special news resource that you use that no one else has?

• 1:31:17Speaker 03

  Or? No, but I most mornings I'll try to sort of like read, kind of check out what's going on on social media, just like any buzz around papers. But the thing that I don't, the thing I really like, we have a small research team at Sierra and we'll do sessions on interesting papers that I think that's really nice. And, you know, usually it's someone who like really went deep on a paper and kind of does a, you know, you bring your lunch and just kind of do a read out. And I found that to be the most rewarding just because, you know, I love research, but sometimes, you know, some simple concepts are, you know, surrounded by a lot of ornate language. And you're like, let's get a few more, you know, Greek letters in there to make it seem like we did something smart, you know?

• 1:32:01Speaker 03

  And sometimes just talking it through conceptually, I can grok the so what? You know, more easily. And so that's also been interesting as well. And then just conversations, you know? I always try to, when someone says something I'm not familiar with, like I've gotten over the feeling dumb thing. I'm like, I don't know what that is. Explain it to me. And, and yes, you can sometimes just find neat techniques, new papers, things like that. It's impossible to keep up that, to be honest with you.

• 1:32:29Speaker 02

  For sure. I mean, if you're struggling, I mean, imagine the rest of us, but like, you know, you, you have really privileged and special conversations. What research directions do you think people should pay attention to? Just based on the buzz you're hearing internally or, you know?

• 1:32:42Speaker 03

  This isn't surprising to you or anyone, but I think the, I think in general, the reasoning models, but it's interesting because two years ago, you know, the chain of thought reasoning paper was pretty important, you know, and in general, chain of thought has always been a meaningful thing from the time, I think it was a Google paper, right? If I'm remembering correctly and

• 1:33:03Speaker 02

  Google authors. Yeah.

• 1:33:04Speaker 03

  And I think that it has always been a way to get more robust results, you know, from models. What's just really interesting is the combination of distillation and reasoning is making the relative performance. And I'll say, actually, performance is an ambiguous word. Basically, the latency of these reasoning models more reasonable, because if you think about, say, GPT-4, which was, I think, a huge step change in intelligence, it was quite slow and quite expensive for a long time. So it limited the applications. Once you got to 4.0 and 4.0 mini, you know, it opened the door to a lot of different applications, both for cost and latency. When O1 came out, really interesting quality wise, but it's

• 1:33:48Speaker 03

  quite slow, quite expensive. So just the limited applications. Now, I just saw, like, someone post one of, they distilled one of the deep-seek models and just made it really small. And, you know, it's doing these chains of thoughts so fast, you know, it's achieving latency numbers, I think, sort of similar to like GPT-4 back in the day. And now all of a sudden, you're like, wow, this is really interesting. And I just think, especially if there's lots of people listening who are like, applied AI people, it's basically like price, performance, quality. And for a long, like, for a long time, the market's so young. If you, you really had to pick which quadrant you wanted for the use case. And the idea that we'll be able to get like relatively sophisticated reasoning at like,

• 1:34:33Speaker 03

  oh, 3.0 has just been amazing. If you haven't tried, it's like, the speed of it makes me use it so much more than O1, just because O1, I'd actually often craft my prompts using 4.0 and then put it into O1, just because it was so slow. You know, I just didn't want to like, the turnaround time. So I'm just really excited about them. I think we're in the early days and the same Way with the rapid change from GPT three to three, five to four. And you just saw like every and I think with these reasoning models, just how we're using sort of inference time compute and the techniques around it, the use cases for it, it feels like we're in that kind of can't bring an explosion of ideas and possibilities. So I just think it's really exciting. And and certainly, if you look at some of the use cases we're talking about,

• 1:35:18Speaker 03

  like coding, these are the the exact types of domains where these reasoning models do and should have better results. And certainly in our domain, there's just some problems that like thinking through more robustly, which we've always done, but it's just been like these models are just coming out of the box, a lot more batteries included. So I'm super excited about them.

• 1:35:37Alessio Fanelli?

  Any final call to action? Are you hiring, growing the team? More people should use here, obviously.

• 1:35:42Speaker 03

  We are growing the team and we're hiring software engineers, agent engineers. So send me a note, [email protected]. We're growing like weed. Our engineering team is exclusively in person in San Francisco, though we do have some kind of forward deployed engineers and and other offices like London. So.

• 1:36:00Alessio Fanelli?

  Awesome. Thank you so much for the time, Bret.

• 1:36:03Speaker 03

  Thanks for having me.