Build to Last — Chris Lattner talks with Jeremy Howard

Hi, Jeremy Howard here, with Chris Lattner, a man who probably needs no introduction, but I'll give you a bit of intro to anyway. Good day, Chris. Welcome. Thank you for joining us. >> It's great to be able to spend time with you and hang out and talk on this nice Sunday. Yeah. Um Chris, how long have you known each other? I think it was the very first TensorFlow Dev Summit that we met. >> Yeah, probably 2017. So, it's been uh not long enough, but a good a good amount of time. We've been through a number of different projects together, and so we uh developed a mutual distaste for TensorFlow pretty early on. I was trying to [laughter] trying to fix it at the time. >> fixing it. >> Yes. Yeah, and so I was making it better or trying to. Um But, the experience of those early days of that first that first TensorFlow Dev Summit, you were fresh new to to AI. A large percentage of the people there today are >> [snorts] >> running big labs or, you know, uh world-known folks. And you brought in a very different background to anybody else that was there. Your your PhD project turned into LLVM, which today is at the heart of most of the world's most successful programming languages. You built a C++ compiler on top of that, which is very widely used, including Google. You built an Objective-C compiler. And then you thought, what the hell, it's all too easy. So, you built a new programming language called Swift, which is running all the stuff I'm using right now to talk to you. Um And what I found interesting is when you then came into to AI. You definitely didn't say, oh cool, everyone's everybody did use TensorFlow, and you went, everybody uses TensorFlow, cool, I'll tweak TensorFlow. You basically did the same thing. To like, what is this mission that you've been on for the last you're a young man, what is that, two or three years? Um that kind of has you starting at the bottom, and and what did that look like when you hit the AI world? Well, so so Jeremy, you and I have some things in common. I think you know this, but other people may not. We like to build things, and we like to build things from the fundamentals. We like to understand them. We like to ask questions, right? And so, for me, my journey has always been this uh like trying to understand the fundamentals of what makes something work. And then when you do that, you start to realize that a lot of the existing systems are actually not that great. Right? And so, for me, at least, you then feel compelled to say, well, how about we make it better? At least for the ones that matter. And so, AI systems, programming languages, compilers, and systems, and tools, there's a lot of things out there, and none of them were really great. And so, I have thrown myself into trying to make this better. And through all of that, I've been doing a lot of coding. So, I've been a developer my whole whole career. >> you that your underlying mission here is or your kind of quest is to create higher-level ways of talking to machines. Like, what why are you trying to do that? And how on earth does creating LLVM, the lowest possible layer of talking to machines, help in that mission? Well, so I think that computing is a big part of our lives, right? And we see it through the products we use. We see it even if you're not a programmer, in the widgets, and the devices, and the connected components that are all just ticking over everything. AI is the most recent manifestation of this, of course, right? But but that doesn't happen unless programmers, developers can actually build these experiences. And so, I'm curious about your background, too, Jeremy. Like, so you've built a few things. You built fast.ai and many other things. So, what what threw you into this, and and what makes you passionate about building things? I mean, I'm I'm not sure my quest is that different to yours. Um You're interested in creating higher-level ways of talking to machines. I think I'm pretty interested in the whole conversation of like also higher-level ways of machines talking to us. Um Unlike you, I don't have a fancy PhD, and so I never had the tools in my toolkit to go and start at the bottom and build it from from there. So, I think I've kind of come in the opposite direction of starting at the top and gradually going down. And interestingly, we've met in the middle. Um which is So, we worked together on a project called Swift for Swift for TensorFlow, which had nothing to do with TensorFlow, but was actually one part of you saying, okay, we have to throw away everything and restart. So, you built MLIR, which is kind of like LLVM, but for the modern world, and then you built Swift for TensorFlow on that, but you also built out stuff for TPUs, and you also built out the TensorFlow runtime, and you you did the whole thing again. You built all these layers of abstraction. And and I had kind of come from the opposite direction, and we were both there saying like, okay, we need a better way >> Because you actually know AI, right? So, you you know the the use case. You understand the researcher pain points. You understand what was beautiful about PyTorch. I think you were one of the first people and Andre We were the first people on PyTorch, yeah. back in like 0.3 kind of time frames, and back before PyTorch was inevitable and obvious. And so, um and so you brought a lot of the domain expertise. And so, as a tool builder myself, right, the thing that you need is you need who's who's the person that you're solving the problem for, right? And so, finding experts like yourself that actually understand um not just what people are doing today, but also the frontier sheer. And it was the lack of that integrated end-to-end system that was killing me, cuz I remember when I first met you, I said like, oh Chris, you're coming to work on TensorFlow, are you? Need to warn you, it's kind of And I spent half an hour telling you all the ways it was terrible. And then you didn't yell at me. Instead, you said that that sounds very interesting. Let's fix it together. Um And cuz what I wanted for my students, for myself, for my research, was to to never get stuck where I'd be like, how does that work? How does that work? How does that work? Until I get to the point where it's like, okay, that's the thing I need to fix. And with like PyTorch or TensorFlow, you don't get very far at all before it's like, oh, this is inside, you know, the flash attention three kernel that was actually in Triton, but it's actually then being converted to this different language, and then it was compiled, and then Or some binary CUDA blob. Yeah, I don't know what just happened. Um >> Yeah. And that just felt absolutely unacceptable to me. And even Swift for TensorFlow, I remember complaining to you about that, cuz I was like, what about auto diff? What's that written in? You're like, C++. I'm like, what am I meant to do about that, Chris? Yeah. Yeah. So, >> Well, I think I I I think it's fair to say that I learned a lot from that project. >> [laughter] >> Um but, you know, interestingly, just like LLVM, how long ago was that, Chris, that you wrote it? It was actually more than two or three years. >> 25 years ago. I started it over Christmas break in 2000. 25 years. So, there's a project that the world has been using, you know, and still uses everywhere. And interestingly, when you kind of reinvented that with MLIR, you know, which is like a intermediate representation for massive multi-core heterogeneous compute blah blah blah processes and matrix manipulations and all that, it's it's the same thing's happened, you know? Everything today is now getting built on on MLIR, you know? Um so, Well, so so the question of the day is, how do you build a system that actually can last more than six months? Right? Because the reason that those systems were fundamental and that they became scalable and were enabled to be successful and then grow, but then didn't crumble under their own weight, is because the architecture of those systems actually worked well, right? They were well designed. They were scalable. Uh the people that worked on them had an engineering culture that they came together, and they rallied behind because they want to make them technically excellent, right? And so, I think that that's something that enables systems to actually be more than just, you know, a solution to a today problem. In the case of LLVM, for example, it was never designed to support the Rust programming language or Julia or something like this, or even Swift, right? But, because it was designed and architected for that, you could build programming languages. Snowflake could go build a database optimizer, which was really cool, and a whole bunch of other applications of the technology came out of architecture, right? And I think that's something that today, you know, architecture and some of the craftsmanship that goes into building things is at risk. Like, it's under threat today. Really? I was I was hearing I was thinking the same thing as you said it. I was thinking like, okay, the things you're describing feel very different to the culture that I feel is being pushed very hard by the world around me. Like, I'm feeling this pressure to say, screw craftsmanship. Screw caring. You know, we hear VCs say, oh, my founders are telling me I can they're getting out 10,000 lines of code a day. Are we crazy Chris are we are we are we old man men yelling at the clouds being like, back in my day, we cared about craftsmanship, you know, or >> No, no, it's I think it's a I mean, so to me, I think that there's a thing going on, and it's kind of driven by sometimes VCs, but but moreover by the world that's eager for progress. Let me tell you a story. In In 2017, I was at Tesla working on self-driving cars and I was leading the autopilot software team. >> So you were. And I was convinced that in 2020 these cars would be everywhere and it would be solved and it was this desperate race to go solve autonomy. Um in fact, my job, which I failed at by the way, was to get a Tesla to drive coast to coast from LA to New York. Of course, here we are uh 8 years later. Nobody else has solved that problem either but not that I know. >> to get that working? Yeah, a little bit less than that. Okay. But uh at the time nobody even knew how hard that was. But what was going around, what was in the air is trillions of dollars are at stake. Job replacement, farming, transportation. Look at the TAM of all of the uh human capital that is being put in transportation and with one cute trick that'll be replaced. And I think that today exactly the same thing is happening. Today it's not about self-driving, although yes, it's making progress. I think a little bit less gloriously and immediately than people thought but it is making progress. But now it's about programming, right? And so I think a lot of people are saying, "Oh my gosh, tomorrow all programmers are going to be replaced by AGI and therefore we might as well give up, go home. Why are we doing any of this anymore? Uh code is like if you're learning how to code or if you're um you know, taking pride in what you're building then you're not doing it right. And I think that this is something that I'm pretty concerned of. Yeah, and and it's it's almost worse than that, right? And the the analogy there is actually really striking cuz I remember when you were at Tesla, it wasn't just like we're on the cusp. It was very specifically all Tesla needs is a bit more data because data is the oil and you just grab the data and instantly you have yourself a self-driving car. And that's now what we're hearing, you know, that's the bit of lesson which Rich Sutton is now saying is being totally misunderstood. Um is like, "Oh, you just need more data and and AGI is inevitable and it's around the corner. And if that was true it's a whole question there about how would one live one's life but it hasn't been true in the past [laughter] and Yeah. it it doesn't it doesn't feel I don't know. I don't know. What do you think, Chris? Yeah, it's like >> Well well so so Jeremy, I'm I'm not the AI researcher. So I'm going to spin this phone around and ask you this, right? But to me, I believe that progress looks like S-curves, right? And pre-training was a big deal. It seemed exponential but actually it S-curved out and got flat as things went on. I think that we have a number of piled up S-curves that are all driving forward amazing progress. But I at least have not seen that spark. And so I guess a a quick question for you, an easy easy slowball for you is like, "What is AGI made out of? Is it just more layers in your transformer? Is it just more parameters, more experts in your MoE? Like or is it something fundamentally different?" And and another way to spin this is like, "Is it actually next year or 5 years off or is it actually maybe something we'll not actually get to at least economically?" So I mean, something I haven't talked about much is that maybe I should here is, you know, as you know, I I created the first LLM. And you you melt it? Uh-huh. Yeah, and I can tell you why I created it and I can tell you what it's looked like since then. I didn't create it to create AGI. And everything that's happened since then is exactly what I hoped and expected would happen um with the LLMs. Which is to say I was telling everybody in 2017 you know, and 2018 this approach and in fact I was talking in academic conferences before that even. This is an approach which by learning the next word of a sentence predictor, it must build internal abstractions that would allow it to solve a wide variety of problems quite concisely and crisply with a smaller amount of data and so fine-tuning is the key thing. Um and so nowadays we use exactly the same three-step approach. We train a big language model, we fine-tune it on instruction tuning nowadays and then you fine-tune it on a classifier which is RLHF nowadays. Yeah, none of that process was ever designed to create AGI. There's no reason to believe it would. It's um it it it's a very big uh pattern predictor machine and it's funny for years I was the one telling people you're deeply underappreciating how important a big pattern recognizing machine in natural language is. It can actually solve all kinds of problems and you can actually talk to it and it will actually like the amount of things which are just which are interpolation. Sorry? Everything's a remix, right? Yeah, exactly. The amount of To some extent that's actually quite valuable for a lot of different reasons. If you could interpolate between everything in the internet that's a lot. But like you and I both know that when you're literally on the cutting edge of anything. And some of those things I find you hit very quickly cuz they're very small things. Suddenly GPT-5 or Sonnet 4.5, whatever, become incredibly stupid. Like they just start saying things that you're like ah you actually had no idea what you're talking about the whole time. It was all a big pretense. Well, the big pretense was very helpful actually when I Yeah. needed help but Well so so as as not the AI researcher, I'll say this, right? So I have I've been surprised multiple times with AI. I am a maximalist. I want AI into all of all of our lives, all the products. I am continuously delighted by what we can do. However, the thing I don't like is I don't like the people that are making decisions as though AGI or ASI were here tomorrow. Right? Because if you're going to live your life in fear and if it isn't actually coming or maybe it's 20 years from now or it's 30 years from now or something, who knows? And I I'm not saying that. It's not my place to speculate but but being paranoid, being anxious, being afraid of living your life and of building a better world seems like a very silly and not a very pragmatic thing to do. And so again, I can't tell. Maybe come back tomorrow. But but I don't see it as a practical thing. A really good point. So if I mean first I'll say people often ask me you know, where where is AGI? And I've been doing AI for a bit over 30 years and I tell people I I can't tell you with any more certainty than I could 30 years ago or 20 years ago or 10 years ago. Been fantastic. Interest in a lot of investment, a lot of improvements. But there's nothing particularly about that that makes me think oh AGI is closer you know, it's 5 years away now whereas 30 years ago I thought it wasn't. Like it's it's a different path. >> It could be like fusion. Fusion's always 5 years or 50 years away. >> very useful path but there's nothing particularly about it that says like oh this isn't AGI path. You know, so if we had AGI in 5 years, I wouldn't be shocked. 30 years ago if we had AGI in 5 years, I wouldn't have been that shocked then either. Like it you know, but I'm not going to live my life differently cuz it doesn't feel any different. But it it it in my heart it kind of does because being able to use a user interface with a computer which is actually the language I speak does feel really different. And it feels even more different to people that aren't AI researchers. And so everybody else around the world is doing this like AGI's around the corner. If you're not doing everything with AI, you're an idiot. And honestly, Chris, it does get to me. Like I I like I question myself. And I've seen that at my company. We we had a few months there where we I think we'd I'd have to say we we struggled to continue to believe in our vision. But everybody was like agents, agents, agents. And so a lot of us just did end up being like we can't not do this. Everybody else is doing this. They're writing 10,000s of lines of code a day. It's ridiculous that we're not. Are we doing Are we doing something wrong because we're not getting the 10x wins that everybody else is claiming they're getting? So we really invested in it. You know, and all of my team is amongst the best in the world at practical usage of AI. And the results were just terrible. We we our productivity fell off a cliff. Our morale fell off a cliff. I was unhappy. How do you measure productivity? Is it number of lines of code written? Or is it product progress? Or is it something else? >> It's getting out the door that people use. Yeah. So that's how I measure productivity, too, right? And so >> seen this, Chris? Like I mean, you've got lots of people working for you, super smart, know a lot about AI. Did Did they find the trick to writing these 10,000s of lines of code a day which transformed your company and you're now going twice as fast or a thousand times as fast or Well so so no. No, I mean, I I use AI coding. I think it's a very important tool. Um I feel like I get a 10 to 20% improvement, some really fancy code completion and auto complete and it's amazing for learning uh a code base you're not familiar with. So it's great for discovery. I do a lot of production code work but it's I it probably is 5 or 10x productivity for prototypes. I think that's that's a place where it can be a huge deal if you're just saying crank out five different theories and you can get to a working mock-up or air quote working, but there I can see major productivity wins, but for the kinds of work that we do, um it's not that great. And the reason is is that I don't measure progress based on number of lines of code written. In fact, I see code as or verbose redundant code. I mean, take take one example of this, which is unit tests. So, AI is really great at writing unit tests. This is one of the things that nobody likes to write tests. It feels super productive to say just crank out a whole bunch of tests and look, I've I've got all this code. Amazing. But there's a problem, right? Because [clears throat] unit tests are their own potential tech debt. Absolutely. >> the test may not be testing the right thing. Um if you're using mocking >> a detail of the thing rather than the real idea of the thing. And if you're using mocking, now you get all this like super tightly bound uh implementation details in your tests, which make it very difficult to change the architecture of your product as things evolve, right? And so tests are just like the uh code in your main application, where you should think about them. Also, lots of tests take a long time to run, and so they they impact your future development velocity. There's like all these things, and so um so to me, the the question is not how do you get to the most code? Like I'm not uh CEO bragging about the number of lines of code written by AI. That's I think a completely useless metric. The question is like how productive are people at getting stuff done, at making the product better. This is what I care about. And what have you seen? Like if you have you seen I mean, there must be people using these kind of trying out these highly agentic workflows, vibe coding style things in your company? Like what how has that gone? So, I'll give you some negative examples first, right? So, I've seen somebody a senior engineer who you know, a bug gets reported and it's like let the agentic loop rip, go spend some tokens and maybe it'll come up with a bug fix and create a PR and go. Get this PR and it's completely wrong. It made It made the symptom go away, so it air quote fixed the bug, but it just was so wrong that if it had been merged and it didn't, uh but if it had been merged, then it would have just made the product way worse because now suddenly you replace one one bug with a whole bunch of other bugs that are harder to understand, a ton of code that's just in the wrong place doing the wrong thing, and so that is deeply concerning. And to me, the actual concern is not this engineer because fortunately, they're a senior engineer, they're smart enough not to just say like, "Okay, it passes tests, merge." Uh we also do code review, which is also a very important thing, by the way. Um but the concern I have is that it's this culture of, "Okay, well, I'm not even going to try to understand what's going on. I'm just going to like spend some tokens and maybe it'll be great, and now I can not have to think about it." This is a huge concern because a lot of evolving a product is not just about getting the results, it's about the team understanding the architecture of the code. Yeah. Right? And so if you're delegating knowledge to hopefully an AI, uh but you're now just you know, reviewing the code. >> not thinking about I think that's very very very concerning. Yeah, it's it's missing the whole point of the the the craft of software engineering, isn't it? Cuz software engineering has always been about trying to get a product that gets better and better, and your ability to work on that product gets better and better, and things get easier and easier, and things get faster and faster. And that's about you building better and better abstractions and better and better understandings in your head, and I mean, to fundamentally what you're trying to do with again, there's lots of different kinds of software projects. Uh software generally lives for more than 6 months or a year, right? And so the kinds of things I work on and I think the kinds of systems that you like to build also are things that you continue to evolve. Right? You look at the Linux kernel, right? The Linux kernel has existed for decades now with tons of different people working on that. made possible by an architect, Linus, who is driving consistency, driving uh abstractions, and driving improvement in lots of different directions. And so that longevity is made possible by that architecture question. And >> a high level of craft from everybody. >> Yes. And sometimes being an about it, but I don't think that's because he cares so much, you know. I don't think that's required, but the uh I mean, different different >> I don't think it's required, but it's >> Different tasks are fine, but but the but the thing that's required is for people to actually give a damn. Like so people that care about what they're doing, people that be proud of their work, and as you say, the craftsmanship. Software craftsmanship, I think, is the thing that AI code threatens, not because it's impossible to use properly. Again, I use it, I feel like I'm you know, doing it well, and I care a lot about the quality of the code, but because it encourages folks to not take the craftsmanship and the design and the architecture seriously, instead just evolve to get my bug queue to be shallower and just make the symptoms go away. And I think that's the thing that I find concerning. Yeah. Yeah, our focus at at Answer AI and fast.ai is all about it's a you know, despite being a very long-running AI research lab, the focus has always been the humans, you know. fast.ai's original first goal was can we make it so that people without a PhD can use AI. And that was absolutely unheard of. Absolutely insane. You know. So Jeremy, let me that we you and I have a lot in common, but let me tell you one big difference between two of us is that I always am obsessed with building things and chasing my interests and like understanding the next the next thing and and digging into things. You actually take time to teach people things. This is one of the reasons you've had so much impact on the world, particularly with fast.ai, but with many of your other projects, is that you don't just do a thing and fill your head with knowledge and build systems, you then actually take it back and do the hard work of trying to get other people to understand it, which is a completely next next level next level problem, by the way, because humans are complicated. And so I think that that that approach is something that you've brought uh to Answer AI, but also it's what enables the tools, the technologies, the ideas to actually get out. And I wish I had spent more time doing that. I I disagree with the implication you haven't, Chris. I mean, with stuff like the VLM foundation and the way you've built these open source communities and you've created you've I I actually think you're much more patient with humans than I am. But yeah, I mean, I I do think that you know, that that idea of teaching is important and and at at Answer AI now, you know, I I always tell my staff I'm much more interested in if you spent the day learning a lot more about a thing or getting much better at a thing than producing one extra bug fix or one extra feature because then tomorrow you'll be twice as good at that thing. And those things uh just like gain this momentum, right? And you get better and better at doing stuff, and you can do more and more as a human. And the feeling is magnificent of being good at something, like being really good at something, and and being able to branch out and be using that to get good at other things. And I think that was part of our mention, like we had these kind of months where we went off and doing stuff with the agentic loops and whatever, and I was miserable. I was not improving. >> vibe coding things, and suddenly you're what what I've seen another thing I've seen is that people that say like, "Okay, well, maybe it'll work." It's almost like a test, and you go off maybe the agentic thing will go crank out some code and spend all this time waiting >> a gambling machine, right? >> coaching, and then and then it's like, "Oh, it didn't." >> [laughter] >> It's like pull the lever again. Try again. >> Yeah, exactly. Exactly. And and again, I'm not saying the tools are useless or bad or something like this, right? But when you take a step back and you look at where is it adding value and how, right? I mean, I think that there's a little bit too much enthusiasm, and they're like, "Okay, well, when when AGI happens, it's going to solve the problem." Um I'm waiting and seeing. Um well, so here's here's another aspect of it, right? So, the anxiety piece. So, I see a lot of a lot of junior engineers that are for example, coming out of school, and they're very worried about, "Will I be able to get a job?" And I think a lot of things are changing, and I don't really know what's going to happen. Um but uh to your point earlier, a lot of them say, "Okay, well, I'm just going to vibe code everything." Right? Because this is productivity, this is air quotes expected. But I think that's also a significant problem. Seems like a career killer to me. Absolutely. And so if I were coming out of school, my advice is don't pursue that path. Particularly if everybody is zigging, it's time to zag. Um what you want to get to, particularly as your career evolves, is you want to get to mastery, so you can be the senior engineer, and so that you can actually understand things to a depth that other people don't, and that's how you kind of escape out of that um the thing that everybody can do to get more differentiation. Which might require finding the right company, you know, cuz some CEOs are doing this like we're going to judge people based on how much AI they use, you know, and how many lines of code they have AI create and you know, I guess there're going to be some places to work that maybe you just shouldn't. Um, but Well, there's outside of AI, there's a lot of reasons why certain companies are career dead ends. And so, I don't think that's actually particularly new. It's just that now it's some of the shinier tech companies are trending towards some of the other things that people were not to do in a previous generation. What you mean? >> Chris. Oh, also, I mean the I'm not going to name names, but right, there it used to be that the Google or the Microsoft or the other meta, the big companies were the shining stars and career progression and then there's other other like less Silicon Valley companies that were in the Midwest or something, they're not as shiny and awesome and we're not seen as as prestigious. Um, and so, you know, you could theoretically have a faster career growth if you went to Silicon Valley or something like that, but um, but I think the the question is really about progress. It's about you as an engineer, what are you learning? How are you getting better? How much mastery do you develop? Why is it that you're able to solve problems that other people can't solve? And if everybody's using the same tools, you need to find a way to differentiate yourself and figure out either domain expertise or a portfolio of what you've done or ideally the ability to build things that actually are sustainable and scalable and actually work well. Um, and so, if everybody's, you know, just using the same AI coding tool, like you need to figure out how to like break past that a little bit instead of just doing the that wrote, you know, unfulfilling button pushing. >> to I'd love to tell you a bit I mean, I know you know a bit about it, but I'd love to tell you a bit about the, you know, AI coding tool that we're building because because you've been part of that journey for many years and have been an inspiration for some of it. Um, I remember when we were sitting next to each other, working together, um, that we both had something in common, which is we both had a very tight iteration loop and we had different ones. Uh, my one >> important to me. Yeah. Um, yeah, I I remember the first thing I said to you and your team is like, okay guys, if we're going to work together on this Swift thing, I'm going to need a notebook, you know, and you immediately were like, of course you do. You do. Right. We're and like a week later, you're like, here's a Swift kernel, all the AI stuff works, you know, and I was straight into it then cuz I could like I can type, see the result, type, see the result, and I'm manipulating the data through a process step by step and watching it. And you know, very much that kind of, um, Bret Victor style, you know, his his inventing on principle of like you want to be close, you know, you want to be crafting the the the thing through the steps and watching it. And you had a very different set of tools. But I mean, you you say, how do you create this tight tight iteration loop? Because it's it in statically, you know, compiled things and low-level things, it's probably a bit different. I'm not an expert on it. Yeah, so I work on systems and systems are slightly different, but what I care about is I care about that that that loop of edit the code, compile, run it. Get a get a test that fails and then debug it and iterate on that loop. And so, there's a number of things go into that. One is uh, just the build system. Make sure you can incrementally build just the target that you care about, just the executable or just the set of >> like seconds. Yes, exactly. Um, the next is running tests. Running tests should take less than a minute, ideally less than 30 seconds. And so, you're not going to run all of the tests in the modular mono repo in 30 seconds, let me tell you that, right? But when you're working on a component, you're not you're running all of the tests, you're working on one piece. Now, what that means is that you actually have to design your test suite. You have to design the architecture. You have to design and build uh, testing specific tools. This is something that I think LLVM has been quite good at. And so, it's one of the things that was very unusual, it's very different than what GCC, for example, did before, where LLVM has a number of tools that are not the C compiler, but they're just the optimizer or they're just the uh, the parser or they're a small piece of a larger system, so you can write unit tests and actually investing into the test harness, you can but write large-scale, efficient run, reusable tests instead of just doing like G tests for everything is a is a big piece of that. And so again, this comes back to the software craftsmanship. Like thinking about the big picture as things evolve, as naturally codebases get bigger, it's very rare that a production codebase ever gets smaller, right? Usually they just grow and grow and grow until they start crumbling under their own weight. Um, this this is quite important. And so, I care a lot about that and we've both really deeply invested in our tools, you know, like we've written you know, so now at Mojo, you know, I know that's something else you've been working on. It's like I was I was quite surprised at how quickly you had a full VS Code development environment with all the niceties, but then I kind of thought, well, of course Chris would focus on making, you know, having his team do that first because without tools that let you create quick iterations, Yeah. all of your work is going to be slower and more annoying and more wrong. Yeah, well, so in the case of Mojo, I think there's two things going on. One is fortunate to have an amazing team. >> [laughter] >> So, I'm not the only developer on Mojo, trust me. I mostly an intern on the team that's helping out with obscure things. Um, but the second piece is the experience of having done it before. Right? And so, building Swift, I learned tremendous number of lessons about what to do that worked out well, but also what not to do. And so, the the tooling piece of this, the using your own product piece of this is actually really important. One of the big things that caused, for example, the IDE features and and many of the things we had problems with Swift is that we didn't really have a user. We were building it and we but before we launched, we had one test app that was kind of air quotes dog fooded, but not really. And so, we weren't actually using it in production at all and by the time it launched, it you could tell. Like the tools didn't work, was slow to compile, crashed all the time, lots of missing features. And so, with Mojo, you know, we consider ourselves to be the first customer. We have hundreds of thousands of lines of Mojo code. It's all open source. >> It's amazing. And so, that's a completely >> half a million, isn't it? It's like >> Yeah. Yes. Amazing. >> large. We're going to be open sourcing a lot more soon, too. But the but that approach is very different. And so, this is a product of experience, but it's also a product of like we're we're building Mojo to solve problems and so, we're learning from the past. We're we're taking best principles and if we're going to make a mistake, let's make a new mistake. And so, this is this is a big piece of it. Yeah, it's interesting. So, you know, my my background is um, so different, um, but wanting to achieve the same tight iteration loop is my number one goal as well. And it's interesting, you know, when you look at the history of the tools that I admire, it's Smalltalk, it's APL, it's Lisp, it's Mathematica. They're all environments where you have a a workspace, you know, or or >> You're you're manipulating the code. You have a symbol table. Yeah, and every line of code you run is manipulating objects inside that workspace. So, like with APL, you don't ship somebody the compiled piece of code, you ship somebody the state of the workspace when you're done. You know, you're typing at the repl, you're solving things, and then you're like, yeah, this is working nicely and you just that's what Emacs was, you know, Emacs originally was a a piece of It's kind of like your You're like pickling it and you're sending you're sending the pickle almost. Yeah, you know, when you when you start it was basically just pulling out, you know, what Richard Stallman's local RAM looks like at the point when he was like, okay, I'm happy with these sets of manipulations. And people don't realize Python is is that, you know, it's not that far from being a Lisp. People have done everything they can in the recent years to make it look like Java, you know, um, but it's not. You know, that's that's that's a fake. And actually, if you lean into these kind of Smalltalk Lisp roots, there's an extraordinary thing there. So, nowadays, for example, we have a really cool AI bot, um, rather unimaginatively called Discord Buddy, that sits in Discord and it has access to all of our GitHub repos and uh, indexed versions of all our Discord messages and our lawyers use it, our accountants use it. We have a whole professional services uh, subsidiary actually called Virtual, they all use it. And we just ask it questions about like, hey, you know, how does this fit into our strategy around that or can tell me about this particular client's most recent share of thing or whatever. Um, that is a piece of code we never deployed. Um, it's it's actually a live symbol table living in this piece of software we wrote called Solvent, um, where um, Eric, who who wrote Discord Buddy, just one after a time typed commands to like edit that symbol table, you know, to say like, okay, let's create a dictionary. Let's put this in here. Let's do this." And like, "Oh, that was a good set of things. Let's wrap that up into a function." That's And you just read it top to bottom. And when he wants to fix a bug or add a feature, he doesn't like pull it out and go here and go here and go here. He's just like, "Okay, I'm going to manipulate that route or that dictionary." And he does it and it's it's just there, you know? And and this way of working that you were you know, the really the first notable Yeah, it's going going. I was going to talk about nbdev. I just want to say you were like the first notable supporter of nbdev. Like you really understood this idea. Let me tell you something that I see in your work. Okay. So, because you you know, I do have many commonalities, right? And so, I'm basically reinventing stuff I built 15 years ago, but for the modern AI and GPU era. Uh you, what I see, you're you're taking lessons learned from Jupyter notebooks, which then inspired nbdev. nbdev is a really cool way of saying, "Let's build a Jupyter first development environment. Let's actually make it so you could do production development in notebooks and take advantage of all the real-time and steps. Exactly. And so, all the things you're talking about there. But now, what you're doing is you bring all those know- all that knowledge and all that experience forward to solve it. Where you're saying, "Let's actually solve a couple of new problems. One is take advantage of that category technology. Let's bring in LLMs and AI coding. And let's make it so people actually can build products while retaining mastery of their code. And learning as they go. Learning more and more. Exactly. And so, the work product there is not just the outcome, but it's also something you can work with, you can manipulate, you can maintain, you can evolve. I think this is what makes it to me so exciting and so fundamentally new. Because again, you can go back to the top of the discussion, there's so many entrenched interests that want to convince everybody in the world that coding is done, we shouldn't think about the same more. Like if you're not just vibe coding, then then you're doing it wrong. But in reality, okay, you're making a lot of disposable code. You don't know how anything works. You're not developing and growing as an engineer. You're not creating something with durable value. And I think to create something with durable value, you need to both get the benefit of AI coding. It's amazing for discovering and finding new ideas. It's amazing for uh teaching you new things. Like what is that new API? What is that that uh data structure I don't know? What is um what are what are four different ways of approaching this problem, right? But then get making sure that you own the result and actually can evolve it and work with it and be proud of it. Yeah, yeah. And we discovered this amazing thing that um when you when you you know, so previously I've always I always felt like I had a dialogue with the computer where I'm you know, so so supercharged REPL. I'm you know, typing in things and seeing results. Now I've got a third-person thing in this dialogue, which is the AI. And so, we've kind of developed this uh key rule behind everything we do with AI, which is the AI should be able to see exactly what the human sees. And the human should be able to see exactly what the AI sees at all times. And so then um Jeremy Reese has been writing his new book in Solve It. And he's the the the AI can see exactly you know, he writes of the book, but he's always asking the AI you know, like, "Hey, does this paragraph align with this mission that we did in the last paragraph? Or hey, have have we discussed this case study before? Or hey, can you go into my um editor's notes and check whether we have any comments on this thing?" And the AI doesn't need any claw.md file or whatever. Like it's it's there with you, you know? It's in the trenches doing doing the work and watching the progress. So, we've got this thing called um Shell Sage, um built by one of our great team members, Nate, who used to um co-run the LLM stuff at Stability AI. And he was like, "Okay, I'm going to take this idea and I'm going to put it into Bash into the shell." And it was like 100 lines of code. He was like, "Wait, tmux already shows everything that's happened. So, if I just add a command which you can type while you're using tmux that talks to an LLM, the LLM can see all of my previous commands, all of my previous questions, all of my output. This is amazing thing." He was like 100 lines of code and by the next day, all of us were using it all the time. Like so, we kind of found this like key thing behind how to work with AI that just so happens to perfectly fit with the nbdev kind of background now where it's like, yeah, bringing in a a co-worker who always is pairing with us cuz they'd always can see everything we're doing and why we're doing it. We also end up with better artifacts because >> so that it sounds like what you're doing is instead of bringing in a junior engineer that can just crank out code, you're bringing in a senior expert and you're a senior engineer advisor somebody that can actually help you make better code and teach you things. Yeah, we exactly we you know, so we still have some agentic pieces, you know, for the stuff that you know it's good at. So, sometimes we'll we'll you know, the other day we were like, "Okay, this is clearly a bug in Drupal here. It hasn't sent this thing across." And you just say like, "Hey, use your tools to go in and have a look to see what printed out this warning, what called that, why it called that, how you know?" And it came back and it said like, "Okay, >> [snorts] >> here it all is." I could have done it myself. Would have taken 15 minutes. Would have been boring and annoying. So, that was nice, you know? But then >> the the automation features of AI are super important, right? I mean, I think this is something where uh getting us out of writing boilerplate, getting us out of memorizing APIs, getting us out of uh you know, looking up that thing from Stack Overflow. I think it's really quite profound. I think this is this is a good use. Yeah. But the thing that I get concerned about is if you go so far to to not caring about what you're looking up on Stack Overflow and why it works that way and things like this and not learning from it, that's that's the concern. It it feels like we're going to have a bifurcation of skills because people who use AI the wrong way are going to get more and more And the people who do use it to learn more and learn faster are going to like they're going to outpace the speed of growth of AI capabilities because they're a human with the benefit of that. It's going to be interesting. I feel like there's going to be this group of people that have got a learned helplessness. And there's maybe a smaller group of people that everybody's like, "Oh, how is this person know everything? How are they so good?" you know? So, so to me, just like as I reflect on my my personality and how I work, um I don't watch the evening news. I don't you know, I I do doomscroll Twitter a little bit, but I don't I don't really uh sink myself in the social media and things like this. And so, there's so much of the noise of the world that's going on that I'm completely unaware of. And guess what? That makes me happier. But what it does is it frees up brain cell and brain capacity for other things. I don't care who who Elon's fighting with, trust me. Like that's not something that I really want to care about. Um but I think that AI coding can be the same thing, right? If if you get sucked into, "Okay, well, I need to figure out how to make this thing make me a 10x programmer." It may be a path that doesn't bring you to developing at all, right? It may actually mean that you're throwing away your own time cuz we only have so much time to live on this Earth, right? And so, what that can do is it can end up retarding your development and preventing you from growing and actually getting stuff done. And so, I think to your point earlier about the team and losing productivity, I think that what it would be great to do would be to actually have some kind of objective metric in terms of productivity and like, can we actually look at, okay, well, where where is this 10x benefit that's theoretically there coming from and who does it accrue to? And I think that maybe what we'll find out is that there's uh a very bimodal distribution. Like the people building prototypes, it is actually transformative. I actually totally believe that. Or the people who don't know code being able to get something done that they otherwise couldn't do, that is actually transformative. Completely convinced. But for other other kinds of programming, maybe it's not actually the thing that you should be aspiring to. And if we can actually define these things as two different terms, define these worlds, get some of the BS and the overhype out of the equation, and get people to be more rational about this, maybe we can find a better way to use the tools for what they're good at. And I think that could lead to a more productive and happier world for people. And we've done that before, right? Like I feel like we've had the same conversation about giant Excel spreadsheets and Microsoft Access databases and and VB scripts. And you know, folks in business groups quite correctly say like, "This has genuinely transformed our department." And people in IT genuinely say like, "That's great, but we can't run our whole company here on this." Well, okay. So, technology waves like cause massive hype cycles and over drama and oversell. And whether it be like object-oriented programming in the '80s, everything's an object versus uh the internet wave in the 2000s. And now, everything has to be online and otherwise, you know, you can't buy a shirt or something, right? Or dog food, right? I mean, there's truth to the technology, right? But what ends up happening as things settle out and it's less dramatic as as initially promised. And so, the question is is that when things settle out, like if you as a programmer, where do you stand? Like have you lost time? Have you lost years of your own development because you've been spending it the wrong way and now suddenly a rail is much further ahead of you in terms of being able to create productive value for the world. Right, I think that's the question. And so I do do expect some amount of correction. Also do expect the tools get way better and I do I don't think that we're done yet for sure. Right, but but the real question I think we all weigh is like how do we actually add value to the world? How do we actually do something meaningful? How do we move the world forward and and for me personally it's about how am I proud and happy and doing something that I feel like it's contributing. Yeah, and in the end like you and I enjoy the process of software craftsmanship and so we enjoy putting the time in and we enjoy getting better at it. I guess I feel like a lot of folks can enjoy that if they put in the time to get good at it, but not everybody has to for sure. I think Yeah, I respect people that are not into that. I mean this tool is reasonable to uh think about programming as just a means to an end. That's that's fine. And to that I would say if your end is building something that lives more than 6 months then you do care about the maintainability and the evolution of the software architecture. So there's a air quote business reason to do that. But I also admit that I don't program because I have to. It's definitely not my day job. You recently pointed out my GitHub history. It's like this is how you spell nights and weekends cuz all the green dots are on the weekends, right? But the um but you know, there's lots of reasons that different people can weigh these factors in different and what's right for them. Yeah, for sure. And I think your comment about the news and Twitter and stuff is pretty relevant here which is just you know, by choosing not to put yourself in environment where you've got all this sloshing over you all the time. You don't have to fight it, you know, because it's not being thrown at you. That's right. I'm I'm very much focused on taking the next hill. So that's what I'm always looking at and that's why I climb hills. Yeah, well you've done an amazing job of it Chris and I think uh I think it's actually quite clear now Mojo is going to be hugely successful. You just just raised how much money? I think other people are starting to understand this too. Yeah, we raised $250 million from some folks that believe in us very strongly. Yeah. So obviously I've believed in you since before you did. Um and it's great to see, you know, that other people are now seeing how successful this is going to be. Um Well, so I mean I would I would say that a couple of different ways. I mean this is all to plan of course and so raising money is an artifact of being able to build things and being able to be successful. And so it's a great validation and I'm very excited to work with these new folks. Um but honestly it's about building the right thing. And to me what I struggle with and again come back to software craftsmanship is that when you build a new programming language and I I agree with you now Mojo is inevitable. Yes, it will be open source. Yes, we're planning all this stuff and it will do amazing things for sure. Um but because of that I have a huge burden of responsibility. Like it will happen. And so the question is is it actually good or not? And so this is where design matters, architecture matters. This is where tools matter. This is where things fitting together and being able to evolve quickly and be able to make mistakes and fix them matters. And so this is why I care about building these things is because I do believe that the things we build can have an impact, but they can only have an impact if they're built well. And they don't have to be perfect of course. I'm sure Mojo will have its own mistakes and its own bugs and problems and that's guaranteed. But if we care then we can get closer to the mark and if we don't care then you're probably never going to get there. Look, it's built around a strategy and a vision and that's been consistent and that's you know, I think that's the key thing, you know, it's it's channeling where you you know, you've got an amazing team, but it's channeling the direction that you've figured out, you know, that you've spent years figuring out and so that's actually something I should put in a pitch for Eric Reese's upcoming book. Like this is kind of the key thesis of his is like people who lead projects need to be believed in, you know, and need to be given the room to keep at it and he's developed ways to make sure that happens. Um and I'm excited to read his book. Yeah, well I mean you've got it sorted out already, you know, you've you've you've been able to stick with your vision and it's clearly going to happen. So I'm really excited. Well, so I mean I think that that again goes both ways, right? So on the one hand um this is my life's work, right? I mean this is what I was put here to do and Mojo and Max and solving AI compute and making it so people can program all the chips and people have choice. Like this is this is what I'm about and I haven't been too shy about that. Um but on the other hand that doesn't mean everybody believes. And so that's okay with me. Like a lot of people haven't believed for various reasons whether be the angry person on Hacker News shaking their fist at whatever. Why don't I just use Julia? Oh, so much or or whether or whether be an employee that's like yeah, actually you know, I don't I don't believe in X and Y and Z and whatever and it's like okay, cool. This is the wrong place. There are other people that would love to join and so I'd love to work with them. And if you're the such a right fit then please leave because it's better for both of us. You know, it's about making sure that you're working with the people that can get to success and making sure they're rewarded and people can be a part of the success if they believe in it, but not trying to have to make everybody happy because trying to make everybody happy is how you get watered down committee things and you can't really make you know, a big bold bet if you do that. And so you have to actually as you say have a hypothesis. Have have have a core of belief and it may be directional. It may not have all the digits of precision, but you have to stick to it otherwise you won't get to it. Yeah, for sure. Well, thank you Chris. I think you know, so before we wrap up I just want to ask people watching that if you're interested in seeing the vision that I'm trying to create, please come along to solve.it.com and have a look. It's kind of crazy. It's very different, but it's really working. We've got so many people now that have literally said their life has changed dramatically for the better thanks to it. And definitely don't sleep on Mojo because it's got it's what we're all going to be using pretty soon. So Well, so and and Jeremy one of the things that I'm I'm fond of you for many reasons, but the your your generosity with your time. Not many people particularly with your background and your incredible talent and capabilities would spend their time building tools to teach people and allow them to grow. You've taught me so much. I feel very thankful to you for that. Um but a lot of other people wouldn't do that. And so I think that the the even trying to move the world forward in this place it can be very um isolating sometimes and there's always people that say you know, your ideas are terrible. I'm going to eat you blah blah blah. The world doesn't want X Y or Z. But that always happens. You should definitely not listen to those people because those are the people that aren't building anything themselves, right? >> No, exactly. And thank God now we have our community, you know, we've got what's you know, 4 million people that learned AI from fast.ai. They're still with us. A lot of them are running labs and stuff nowadays and they're in our Discord and they're you know, we support each other and we have a this really warm, encouraging, deeply skillful community and I think that's everybody needs people around them that Yeah. are supporting what they're doing. Um well, and and what I've seen across my career is I've seen people that you know, they might have been an intern for me 20 years ago now. Somehow this happens. Um but what I see is the story arc of different people's careers, their passions, where they drive. And the people that I see doing really well uh in their careers and in their lives and in their development are the people that are pushing. They're not complacent. They're not just doing what everybody tells them to do. They're actually asking hard questions and they want to get better. And so investing in yourself, investing in your your tools and techniques and really pushing hard so that you can understand things at a deeper level I think is really what enables people to grow and and achieve things that they maybe didn't think was possible a few years before. I couldn't agree more. Thank you Chris. It's so inspiring and I hope everybody takes it to heart. Thanks for your time today. Yeah, it's great to see you. All right. Cool. Now you got it.