- Hi, Jeremy Howard here with Chris Latner, a man who probably needs no introduction, but I'll give a bit of intro to you anyway. G'day, Chris, welcome. Thank you for joining. - Hey, Jeremy. It's great to be able to spend time with you and hang out and talk on this nice Sunday.

- Go on. Chris, how long have we known each other? I think it was the very first TensorFlow Dev Summit that we met. - Probably 2017, so it's been not long enough, but a good amount of time. We've been through a number of different projects together, and so we developed a mutual distaste for TensorFlow pretty early on.

I was trying to fix it at the time. - Yes. - And so I was making it better or trying to. - By the experience of those early days of that first TensorFlow Dev Summit, you were fresh, new to AI. Large percentage of the people there today are running big labs or well-known folks, and you brought in a very different background, to anybody else that was there.

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 at 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. And what I found interesting is when you then came into AI, you definitely didn't say, oh, cool, everyone's, everybody did use TensorFlow, and you went, everybody uses TensorFlow, call, I'll tweak TensorFlow.

you basically did the same thing, too. 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, that kind of has you starting at the bottom, and what did that look like when you hit the AI world?

Well, 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, 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, he 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 career. - That your underlying mission here is, or your kind of quest is to create higher level ways of talking to machines.

Like, 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 taking over everything. AI is the most recent manifestation of this, of course, right? 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 Fastmail and many other things. So what threw you into this and what makes you passionate about building things? - I mean, I'm not sure my quest is that different to yours. 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. 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 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, which is... So we worked together on a project called 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 of TensorFlow on that. But you also built out stuff for TPUs. And you also built out the TensorFlow runtime. And you did the whole thing again. And you built all these layers of abstraction. 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 know 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... ...to PyTorch. Back in like 0.3 kind of timeframes. And back before PyTorch was inevitable and obvious.

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 the person that you're solving the problem for, right? And so finding experts like yourself that actually understand not just what people are doing today, but also the frontier here.

And it was the lack of that integrated end-to-end system that was killing me. Because I remember when I first met you, I said like, "Oh, Chris, you're coming to work on TensorFlow. I need to warn you. It's kind of shit." 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 sounds very interesting. Let's fix it together." And because what I wanted for my students, for myself, for my research was 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, 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 3 kernel that was actually in Triton, but it's actually then being converted to this desert language, and then it was compiled and then…" Or some binary CUDA blob.

Yeah, I don't know what just happened. Yeah. And that just felt absolutely unacceptable to me. And even Swift for TensorFlow, I remember complaining to you about that, because I was like, "What about Autodiv? What's that written in?" And you're like, "C++." And I'm like, "What am I going to do about that, Chris?" Yep.

Yeah. So… Well, I think it's fair to say that. I learned a lot from that project. 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 when 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, just like intermediate representation for massive, multi-core, petrogynous compute, blah, blah, blah, processes and matrix manipulations and all that. It's the same things happened, you know?

Everything today is now getting built on MLIR, you know? So… Well, 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 able 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. The people that worked on them had an engineering culture that they came together and they rally 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.

But 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?

No, no, no, I don't think so. 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 2017, I was at Tesla working on self-driving cars and I was leading the autopilot software team.

So you were. And, uh, I was convinced that in 2020, those 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, I don't know, eight years later, nobody else to solve that problem either. 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, forming transportation.

Look at the TAM of all of the, uh, human capital that is being put into transportation and with one cute trick that will 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 that 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, uh, like if you're learning how to code or if you're, uh, um, you know, taking pride in what you're building, then you're not doing it right.

And I think that this is something I'm pretty concerned. Yeah. And, and it's, it's almost worse than that. Right. And the, the analogy there is actually really striking because 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 bitter 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, and if that was true. It's the whole question there about how would one live one's life, but it hasn't been true in the past and it, it doesn't, it doesn't feel, I don't know.

I don't know. What do you think, Chris? Yeah. 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 quick question for you and easy, easy slow ball for you is like, what is AGI made out of?

Is it just more layers in your transformer or is it just more parameters, more experts in your MOE, like, or is it something fundamentally different? And, and another way to spin it is like, is it actually next year or five years off, or is it actually maybe something that we'll not actually get to at least economically?

So, I mean, something I haven't talked about much is that maybe I should hear is, you know, as you know, I, I created the first LLM. And you're, you're a Melfit? 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 with 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, and so nowadays we use exactly the same three-step approach.

We train a big language model, we fine-tune it on introduction 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 a very big 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 us, and it will actually, like, the amount of things which are just interpolation… Everything's a remix. Sorry? Everything's a remix, right? Yeah, exactly. To a certain extent, that's actually quite valuable for a lot of different reasons.

Yeah. 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 because they're really 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 needed help. Well, so, as not the AI researcher, I'll say this, right?

So, I've been surprised multiple times with AI. I am a maximalist. I want AI into all of our lives, all the products. I am continuously delighted about 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 am not saying that. It's not my place to speculate. 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 it is tomorrow. Let me come back to that. I don't see it as a practical thing. A really good point. So, 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 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 it, 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, is five years away now or 30 years ago.

30 years ago. I thought it wasn't like it's, it's a different path. It could be like fusion, fusions always five years or 50 years away. It's a very useful path. But there's nothing particularly about it that says like, oh, this is an AGI path, you know? So if we had AGI in five years, I wouldn't be shocked.

30 years ago, if we had AGI in five years, I wouldn't have been that shocked then either. Like it, you know, but I'm not going to live my life differently because it doesn't feel any different. But 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 is 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, like I question myself and I've seen that at my company.

We, we had a few months there where we, I think 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,000 of lines of code a day. It's ridiculous that we're not, we're still writing. 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 shit out the door that people use.

Yeah. You know? So that's how I measure productivity too, right? Have you seen this, Chris? Like, I mean, you've got lots of people working for you. Super smart. Know a lot about AI. Did they find the trick to writing these 10,000 of lines of code a day, which transformed your company and, you know, 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. I feel like I get a 10 to 20% improvement, some really fancy code completion and autocomplete. And it's amazing for learning a code base you're not familiar with. And so it's great for discovery.

I do a lot of production code work, but it's, I, it probably is five or 10 X 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 mockup or air quote working, but there I can see major productivity ones.

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, not well factored code as a huge liability. 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 unit tests are their own potential tech debt.

Absolutely. Right. Because the test may not be testing the right thing. Um, if you're using, they might be testing a detail of the thing rather than the. Real idea of the thing. That's right. And if you're using a 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 that the question is not, how do you get to the most code?

Like I'm not a 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 people, 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 air quote, fix the bug, but it just was so wrong that if it had been merged and it didn't, but if it had been merged, then it would have just made the product way worse.

Because now suddenly you're placed 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. We also do code review, which is also a very important thing, by the way. 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, but you're not thinking about what you want to get. 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?

Because 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, 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 six 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 it. And that is made possible by an architect, Linus, who is driving consistency, driving, uh, abstractions and driving improvement and lots of different corrections. And so that longevity is made possible by that architecture question.

And requiring a high level of craft from everybody. Yes. And sometimes being an asshole about it, but in the end, that's because he cares so much, you know? Yeah. I don't think that's required, but the, uh, I mean, different, different... I don't think it's required, but it's like... Different paths are fine, but, but the, uh, but the thing that's required is for people to actually give a damn.

Yeah. Like, so people that care about what they're doing, people to 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 cue 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, Fast AI is all about, 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, you and I have a lot in common, but let me tell you one big difference between the two of us is that I always am obsessed with building things and chasing my interest and 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 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 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 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 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 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, I mentioned, 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. You're vibe coding things. And suddenly you're, what I've seen, another thing I've seen is that people that say like, okay, well, maybe it'll work.

And it's almost like a test. And you go off and you say, maybe the agentic thing will go crank out some code and spend all this time. It's like a gambling machine, right? Coaching it. And then, and then it's like, oh, it didn't. Yeah, 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 just, 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, uh, for example, coming out of school and they're very worried about, well, I'd 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. It seems like a career to me. Absolutely. And so if I were coming out of school and 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, because 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 are going to be some places to work that maybe you just shouldn't, um, but there are... 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 learn not to do in a previous generation.

What do you mean, Chris? Oh, also, I mean, the, uh, I'm not gonna name names, but right, there used to be that the, uh, Google or the Microsoft or the other meta, the big companies were the shining stars and, uh, 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 not seen 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 that 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 route, you know, unfulfilling. I'd love 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 very 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. 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. Cause 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 the kind of, um, Brett 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, very different set of tools, but I mean, you, you say, how do you create this tight, tight iteration loop?

Cause 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, I work on systems and systems are slightly different, but, um, 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 that 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, just a set of going to be 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 monitor repo in 30 seconds. Let me tell you that. Right. But when you're working on a component, you're not, you know, 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. So you can write large scale, efficient to run reusable tests. And so 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 code bases get bigger.

It's very rare that a production code base ever gets smaller, right? Usually they just grow and grow and grow until they start crumbling under their own weight. But, um, the, uh, this, this is quite important. And so I care a lot about that. And so, you know, we've both like, 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, 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. So I'm not the only developer on Mojo. Trust me. I am mostly an intern on the team that's helping out with, uh, 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, uh, cause for example, the IDE features and, and many of the things we had problems with 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 food, 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.

It 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 it's a completely different thing. It's like over half an alien, isn't it?

It's like, Yeah. Yes. Amazing. It's quite large. We're going to be open sourcing a lot more soon too. But the, uh, uh, 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 where 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, uh, the history of the tools that I admire, it's small talk, it's APL, it's Lisp, it's Mathematica. They're all environments where you have a workspace, you know, or, or 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 piece of.

It's kind of like you're, you're like pickling it and you're sending, you're sending the pickle almost. Yeah. You know, when you, when you start Emacs, 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.

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, but it's not. No, that's, that's, that's a fake. And actually, if you lean into these kind of small talk Lisp routes, there's an extraordinary thing there.

So nowadays, for example, we have a really cool AI bot, rather unimaginatively called Discord buddy. It sits in Discord and it has access to all of our GitHub repos and indexed versions of all our Discord messages and our lawyers use it, our accountants use it. We have a whole professional services subsidiary actually called Virgil, 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 you tell me about this particular client's most recent share thing or whatever? That is a piece of code we never deployed. It's, it's actually a live symbol table living in this piece of software we wrote called Solvent, where Eric, who wrote Discord buddy, just one at 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. Let'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, like you were, you know, the, the, really the first notable, yeah, let's go on. I was just talking about MB Dev.

I just want to say you were like the first notable supporter of MB Dev. Like you really understood this idea. Let me tell you something that I see in your work. Okay. So, because you, you and I, uh, 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, you're taking lessons learned from Jupiter notebooks, which then inspired MB Dev.

MB Dev is a really cool way of saying, let's build a Jupiter first development environment and let's actually make it so you could do production development in notebooks and take advantage of all the real times. Yeah, by manipulating this in steps. Yeah, exactly. And so all the things you're talking about there, but now what you're doing is you bring all those knowledge, 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 of 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 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 dumb. We shouldn't think about this anymore. Like if you're not just vibe coding, 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 teaching you new things. Like what is that new API? What is that, that data structure? I don't know. What is, um, what were four different ways of approaching this problem? Right. But then get making sure that you own the result and actually 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 a computer where I'm, you know, sort of 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, Eric Ries has been writing his new book in Solvert and he's the, the, the AI can see exactly, you know, he writes every line of, 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 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 a hundred 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.

It's this amazing thing. It's like a hundred lines of code. And by the next day, all of us, we're using it all the time. Like, so we've kind of found this like key theme behind how to work with AI that just so happens to perfectly fit with the NB dev kind of background now where it's like, yeah, bringing in a co-worker who always is pairing with us because they'd always can see everything we're doing and why we're doing it.

We also end up with better artifacts because it sounds like what you're doing is instead of bringing in a junior engineer, they can just crank out code. You're bringing in a senior expert, 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're, you know, the other day we were like, okay, this is clearly a bug in Jupyter 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, 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 yeah, no, the, 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 at that thing from stack overflow, I think is really quite profound.

I think this is, this is a good use. Yeah. The thing that I get concerned about is if you go so far 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 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 shit. 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 to learn helplessness and there's maybe a smaller group of people that everybody's like, oh, how does 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 do doom scroll Twitter a little bit, but I don't, I don't really, uh, sync myself into 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 the 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 10 X 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 because 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 10 X benefit this theoretically that are coming from and who does it accrue to?

And I think that maybe what we'll find out is that there's a very bimodal distribution, like the people building prototypes. It is actually transformative. I actually totally believe that, or the people that 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 this 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 saying like, that's great, but we can't run our whole company around this.

And, 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 eighties, everything's an object versus the internet wave and the two thousands. And now everything has to be online. Otherwise, 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 is 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 everybody else 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 just, I don't think the word done yet for sure. Right. But, uh, 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 that'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, uh, for sure. I think. Yeah. I respect people that are not into that. And I mean, it's totally reasonable to, uh, think about, uh, programming as just a means to an end and that's, that's fine.

And to that, I would say, if your end is building something that lives more than six months, then you do care about the maintainability and the evolution of the software architecture. So there's a air quote business read 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've recently put out my GitHub history. It's like, this is how you spell nights and weekends. Cause all the green dots are on the weekends. Right. But the, uh, um, but, uh, you know, there's lots of reasons that different people can weigh these factors in different. Yeah. 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 an 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 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. Um, 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, 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 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've 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, um, 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, they don't have to be perfect. Of course, I'm sure Mojo will have its own mistakes and some 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 being 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, well, 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. And I'm excited to read this 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 gonna happen. So I'm really excited. So, well, so, I mean, I think that that again goes both ways, right?

So on the one hand, 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 it be the angry person on hacker news, shaking their fist at whatever. Um, why didn't I just use Julia or, or whether, or whether it be an employee that's like, yeah, actually, you know, I'm, I'm, 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, it's not the 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.

Well, so, and Jeremy, one of the things that I'm, I'm fond of you for many reasons, but the, uh, 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. 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 all these people that say, uh, you know, your ideas are terrible and blah, blah, blah.

The world doesn't want X, Y, or Z. But that always happens. Like you should definitely not listen to those people. I mean, thank God. Now we have, 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 have learned AI through 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 this really warm, encouraging, deeply skillful community. And I think that's, everybody needs people around them that, yeah, they're supporting what they're doing.

Um, and what I've seen across my career is I've seen people that, you know, they might've 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 their lives and the 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. That's so inspiring. And I hope everybody takes that to heart. Thanks for your time today. Yeah. It's great to see it. All right. Cool. There you go.