Tim Scarfe: belief

Transcript context

…Yeah. I'd say probably not. You see companies like Instagram and WhatsApp dominate their sectors whilst having 10 staff, and beating companies like Google and Microsoft in the process. I would argue this way of building software in very large companies is actually failing. And I think we're seeing a lot of these very large companies becoming, you know, increasingly desperate. And, you know, for example, the quality of Microsoft Windows and Mac OS has very obviously deteriorated greatly in the last 5 to 10 years. You know, back when Dave Cutler was looking at every line of the NT kernel and making sure it was beautiful, it was a elegant and marvelous piece of software, you know. And this I don't think there's anybody in the world who's gonna say that Windows 11 is an elegant and marvelous piece of software. So I actually think we do need to find these smaller components that we do fully understand, and that we need to build them up. And here's the problem. AI is no good at that. So and and so I say that empirically. They're really bad at software engineering. And then I think that's possibly always gonna be true, because, you know, we're we're asking them to often move outside of their training data, you know, if we're trying to build something that literally hasn't been built before and do it in a better way than has been done before, we're saying, like, don't just copy what was in the training data. So and again, this is a confusing point for a lot of people, because they see AI being very good at coding. And then you think like, that's software engineering. You know, it's like, it must be good at software engineering. But it's they're different tasks. There's not a huge amount of overlap between them. And there's no current empirical data to suggest that LLMs are gaining any competency at software engineering. Every time you look at a piece of software engineering they've done, like the browser, for example, which Cursor created, or the C compiler, which Anthropic compared created. Like I've read the source code of those things quite a bit. Chris Latner is much more familiar with the compiler example than me. But they're they're very very obvious copies of things that already exist. So that's the challenge, you know, is if you want to build something that's not just a copy, then you can't outsource that to an LLM. There's no theoretical reason to believe that you'll ever be able to, And there's no empirical data to suggest that you'll ever be able to. Yes. I think the punch line of this conversation is, and I'm sure you would agree of this, that we need to have the combination of AI and humans working together. Right? Because Right. The humans provide the understanding and all of the stuff we were saying about knowledge. But we can still use AIs as a tool. But we to design operating models or ways of working that make that we say we don't want to diminish our competence and understanding. Right. So it's very it's a very fine line. That's that's been our focus, and we both focus on that for teaching and for our own internal development. The stuff I've been working on for 20 years has turned out to be the thing that makes this all work. Stephen Wolfram should get credit for this. He was the guy that created the notebook interface. Although also lots of ideas kind of go back to Smalltalk and Lisp and APL. But basically, the idea that a human can do a lot more with a computer when the human can, like, manipulate the objects in inside that computer in real time, study them, and move them around, and combine them together. Yeah. That's what small talk was all about, you know, with objects, and APL was the same with arrays. Mathematica basically is a super powered Lisp, which then also added on this very elegant notebook interface that allowed you to construct kind of a living document out of all this. So I built this thing called nbdev a few years ago, which is a way of creating production software inside these notebook interfaces, inside these rich dynamic environments. And I found that made me dramatically more productive as a programmer. And like today, even though I've never been a full time programmer as my job, when you look at my kind of GitHub repo output, I think GitHub produced some statistics about it, and I was like, just about the most productive programmer in in Australia. You know, like it it's working. And a lot of the stuff I build has lots and lots of people use it, because it's such a rich, powerful way to build things. And so it turns out, we've now discovered that if you put AI in the same environment with a human, again, in a in a rich, interactive environment, AI is much better as well, which perhaps isn't shocking to hear. But the normal, like, you use Claude code, which I know you do and it's a very good piece of software, but the environment we give Claude code is very similar to the environment that people had 40 years ago, you know. It's a it's a line based terminal interface. You know, it can use MCP or whatever. Most of the times, it just nowadays uses bash tools, which again, very powerful. I love bash tools. I use them all the, you know, the CLI tools all the time. But it's still just it's using text files, you know, as its as its interface to the world. It's it's it's really meager. So so we put the human and the AI inside a Python interpreter. And now suddenly you've got the full power power of a very elegant expressive programming language that the human can use to talk to the AI. The AI can talk to the computer. The human can talk to the computer. The computer can talk to the AI. Like, you have this really rich thing, then we let the human and the AI in real time build tools that each other can use. And that's what it's about to me. Right? It's about, like, creating an environment where humans can grow and engage and share. It's like for me, when I use Solveit, it's the opposite of that experience you described with Claude Code.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.