Lenny's Podcast: Product | Career | Growth
00:02:47 · Simon Willison, Lenny Rachitsky
[00:02:47] S0: Hey, Lenny, it's really great to be here. [00:02:49] S1: I'm so excited to have you here. I've been such a fan of yours from afar for so long, I've learned so much from your blog. Even though every guest I have in this podcast is my favorite guest, you're my favorite kind of guest, because you're on the ground building with the latest tools, using it for real, you're very good at articulating what you experience, so we're going to get a lot of ROI out of your brain from this time that we have together. [00:02:50] S0: Absolutely. [00:03:15] S1: What I want to start with is essentially an AI State of the Union. You've written about this November inflection. [00:03:22] S0: Yes. [00:03:23] S1: So what I'm thinking as we start, just give us a brief history lesson of just what happened in November and where are we today? What's possible now?
00:03:31 · Simon Willison
[00:03:31] S0: Well, let's talk about all of 2025 very briefly. 2025 was the year that especially Anthropic and OpenAI realized that code is the application, like having these things generate code. I think partly because Anthropic came up with Claude Code back in February of 2025, and it took off like crazy, and a bunch of people started signing up for $200 a month accounts. So, suddenly, wow, it turns out people are willing to pay a lot of money for this stuff for that specific field. Both Anthropic and OpenAI spent the whole of 2025 focusing all of their training efforts on coding. If you look at what they were doing, it was all the reinforcement learning stuff. The reasoning trick, the thing where the models say they're thinking, that was new in late 2024. OpenAI's o1 was the first model to exhibit that, and now all of the models do it. So, that was the other big trend of last year was these reasoning models. Turns out reasoning is great for code. It can reason through code and figure out the root of bugs and all of that. So the end result of this, the end result of these two labs throwing everything they had at making their models better at code is in November we had what I call the inflection point where GPT 5.1 and Claude Opus 4.5 came along. They were incrementally better than the previous models, but in a way that crossed a threshold, where previously if you had these coding agents you could get them to write you some code and most of the time it would mostly work, but you had to pay very close attention to it. Suddenly we went from that to almost all of the time it does what you told it to do, which makes all of the difference in the world. Now, you can spin up a coding agent and say, "Hey, build me a Mac application that does this thing." You'll get something back, which still leads some back and forth, but it won't just be a buggy pile of rubbish that doesn't do anything. That was fascinating, because all of the software engineers who took time off over the holidays and started tinkering with this stuff got this moment of realization where it's like, "Oh, wow, this stuff actually works now. I could tell it to build code, and if I describe that code well enough, it'll follow the instructions and it'll build the thing that I asked it to build." I think the reverberations of that are still shaking us.
00:06:34 · Simon Willison
To software engineering, a lot of people woke up in January and February and started realizing, "Oh wow, this technology, which I'd been kind of paying attention to, suddenly it's got really, really good." And what does that mean? I can churn out 10,000 lines of code in a day and most of it works. Is that good? How do we get from most of it works to all of it works? There are so many new questions that we're facing, which I think makes us a bellwether for other information workers. Code is easier than almost every other problem that you pose these agents, because code is obviously right or wrong. It produces code, you run the code, either it works or it doesn't work. There might be a few subtle hidden bugs, but generally you can tell if the thing actually works. If it writes you an essay or if it prepares a lawsuit for you, it's so much harder to derive if it's actually done a good job to figure out if it got things right or wrong, but it's kind of happening to us. So software engineers, it came for us first and we're figuring out, okay, what do our careers look like? How do we work as teams when part of what we did that used to take look most of the time doesn't take most of the time anymore, what's that look like? It's going to be very interesting seeing how this rolls out to other information work in the future. I write so much of my code on my phone, it's wild. I can get good work done walking the dog along the beach, which is delightful.
00:08:29 · Lenny Rachitsky
[00:08:29] S1: Yeah, I had Boris Cherny on the podcast and he's doing the same thing, and I was just like, "Is that even coding anymore?" He's like, "Yeah, it's just another level of abstraction, just like engineering has always gone." Talk about maybe just what else is there around just what is possible now with AI in terms of building that people may not fully recognize? And what's the next leap? Is there anything beyond this?
00:08:50 · Simon Willison
[00:08:50] S0: Let's talk about the two, there's the vibe coding side of things and then there's the ... and I like Andrej Karpathy's original definition of vibe coding, which is when you don't even look at code and you basically just go on the vibes. You say, build me something that does X, and it builds it and you play with it. If it looks good, then great, and if it doesn't quite do it, you keep on going back and forth with it. But it's very hands-off, you're not looking at code, it's ... so he originally said, "This is great for having fun and prototyping," and it then exploded way out of that. I think today vibe coding is effectively it's ... the definition I use is it's when you're not looking at the code, you don't care about code and maybe you don't understand the code. Non-programmers can now tell Claude what to build and it can build them a little app, and I love that. I absolutely love that we're democratizing the art of getting a computer to do stuff for you, of automating tedious things in your life by knocking out these little tools. Of course, the problem is that there is a limit on how much you can do with that responsibly. I like to tell people, if you're vibe coding something for yourself where the only person who gets hurt if it has bugs is you, go wild. That's completely fine. The moment you're vibe coding code for other people to use where your bugs might actually harm somebody else, that's when you need to take a step back and say, hang on a second, this is not a responsible way of using these tools. The challenge is that understanding what's responsible and what isn't is in itself a expert level skill, so knowing that once you start dealing with scraping other people's websites, maybe you'll damage their websites by hitting them too hard. There are so many ways that you can cause damage if you don't know what you're doing. But I love that liberation and I love that people can come to meetings with a prototype that they knocked up of that idea that illustrates the idea. I think those things are wonderful. The ongoing debate has been what do we call it when a professional software engineer uses these tools to write real code that's production-ready that they've reviewed and they've checked all of the details of? A lot of people call that vibe coding as well.
00:10:55 · Simon Willison
I think that devalues vibe coding as a term, 'cause it's useful to say, "I vibe coded this," as in I haven't even looked at how it works, it's not production-ready, but it's kind of a cool prototype. The moment vibe coding mean everything that touches AI, it effectively ends up needing programming, because we're all moving in a direction where our code is mediated through AI at some point. So, what do we call it for professionals? I've gone with agentic engineering, because I think the thing to emphasize is these coding agents, right? If you're asking ChatGPT to knock out some code, that's a different thing from if you're running Codex and having it write the code, debug the code, test the code, all of that. I think that agentic engineering is such a deep and fascinating discipline, because the art of getting really good results out of this, the art of having them help you build software you could deploy to a million people, that's never going to be easy, that's never going to be trivial. That's always going to require a great deal of depth of experience in how software works and how these agents work, and I love that. I'm kind of writing a book about it now that I'm publishing a chapter at a time on my blog. The best form of writing, because I don't have an editor or any pressure from a publisher, is just when I feel like writing another chapter I can do that, but there's so much to discuss. But yeah, so I think right now the frontier is how do we build professional software using coding agents? How do we build software that is ... I don't just want to build software that's good, I want us to build software that is better than we were building before. If the agents let us move a bit faster, but we're still churning out the same quality of software, that's less interesting to me than if the software we're producing has less bugs, more features, it's higher quality, it's better software, because we're harnessing these tools. The really interesting future is something which some people have been calling the dark factory pattern or software factories. This is the idea where right now if you're a professional using these tools, the way you do it is you tell them what to build and then you look at the code and you review that code really carefully and make sure it's doing the right thing.