In short
Podcast Summary: Steve Yegge's Vibe Coding Manifesto
Podcast Title: Latent Space: The AI Engineer Podcast Episode Title: Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE Description: Steve Yegge discusses the transition from traditional coding practices to "vibe coding" and the impending changes in the software development landscape, particularly the role of AI in coding.
Key Concepts and Discussions
Introduction to Vibe Coding
- Vibe Coding: A new approach to software development that emphasizes AI collaboration instead of traditional coding methods.
- Steve Yegge's Background: Experienced developer with history at Google and Amazon, known for influential essays on AI's role in development.
The Obsolescence of Traditional Tools
- Claude Code & Cursor: Yegge argues these tools are outdated and ineffective, emphasizing the need for agent orchestration instead of simply writing code.
- IDE Critique: Using an Integrated Development Environment (IDE) is seen as a sign of being a "bad engineer" by 2025, as the abstraction layer has shifted from models to full-stack AI agents.
The 2,000-Hour Rule
- Building Trust with AI: Yegge cites the importance of extensive use (approximately 2,000 hours) to build a trustworthy relationship with AI coding tools, emphasizing that predictability is key to trust.
Demographics and Resistance
- Senior Engineers' Resistance: Those with 12-15 years of experience are identified as the most resistant to vibe coding due to their entrenched identities and workflows.
- Fear of AI: Yegge warns against anthropomorphizing AI, suggesting it leads to errors and misunderstandings about AI capabilities.
Future of Software Development
- Agent Orchestration Dashboards: The future of coding will involve managing fleets of AI agents rather than writing lines of code.
- Factory Farming of Code: Yegge predicts a major shift towards automated, large-scale code generation akin to modern agricultural practices.
Insights on Merging Challenges
- The Merge Wall: The growing productivity of engineers using AI tools leads to new challenges in merging changes, as multiple agents working on the same code can conflict.
- Proposed Solutions: Companies may resort to strategies like “one engineer per repo” to manage merge complexities.
Education and Future Skillsets
- Learning to Vibe Code: Emphasis on teaching children to understand coding concepts without getting bogged down by syntax. Understanding functions and architecture is paramount.
- Predicted Changes: Yegge forecasts that the ideal team structure will evolve, with coding becoming less of a bottleneck and businesses needing to adapt quickly.
Current Chaos in Major AI Labs
- Internal Chaos: Yegge describes the chaotic environments at OpenAI, Anthropic, and Google, attributing this to rapid growth and the challenges of managing effective communication and execution across teams.
Closing Thoughts
- Optimism for the Future: Despite resistance from some senior engineers, Yegge expresses excitement about the potential for agents to revolutionize coding and software development at large.
- Call to Action: Encouragement for engineers to adapt and learn new tools, or risk falling behind in an evolving landscape.
Key Takeaways
- Traditional coding practices and tools are becoming obsolete as AI takes a more central role in software development.
- Building trust with AI requires extensive use to understand its capabilities and limitations.
- The resistance to vibe coding is primarily seen among experienced engineers whose identities are tied to outdated workflows.
- The future lies in managing AI agents rather than writing code, leading to more efficient and scalable software development.
- Education should focus on understanding coding concepts generically rather than specific syntactical rules.
Resources
- Steve Yegge's Online Presence:
- [Twitter](https://x.com/steve_yegge)
- [Substack](https://steve-yegge.medium.com/)
- [GitHub for VibeCoder](https://github.com/yegge-labs)
- Latent Space Podcast:
- [Twitter](https://x.com/latentspacepod)
- [Website](https://www.latent.space/)
Chapters
- 00:00:00 - Introduction
- 00:00:59 - The Backlash: Who Resists Vibe Coding and Why
- 00:04:26 - The 2000 Hour Rule
- 00:03:31 - The January 1st Deadline: IDEs Are Becoming Obsolete
- 00:02:55 - 10X Productivity at OpenAI: The Performance Review Problem
- 00:07:49 - The Hot Hand Fallacy
- 00:11:12 - Cloud Code Isn't It
- 00:15:20 - The Orchestrator Revolution
- 00:18:46 - The Merge Wall
- 00:26:33 - Never Rewrite Your Code - Until Now
- 00:22:43 - Factory Farming Code
- 00:29:27 - Google's Gemini Turnaround
- 00:33:20 - Should Your Kids Learn to Code?
- 00:34:59 - Code MCP and Latest Discoveries
This summary captures the essence and insights from the episode, combining key points and discussions articulated by Steve Yegge on the future of coding and the role of AI in software development.
Written by AI. May contain mistakes. Listen to the episode to check what was said.
Transcript
Automatic transcript. May contain errors.0:03We are here, live at AI Engineer Summit with Steve Yeggi, the legendary Steve Yeggi of Steve's Tech Talks, Steve's Platforms, and most recently Source Graphs and AMP. Welcome. And most recently, Vibe Coding. Yeah, that's right. The Vibe Coding book. So this is the big Vibe Coding discussion. In the pre-chat, we were discussing the intersection of Vibe Coding and AI engineering. So we got the kind of movement leaders of both sides here. How do you see it? It's absolutely a movement, right? You got to get people behind it. I said at the end of my talk today that there's a huge backlash, and the backlash is only just brewing now.
0:38So you and I are pushing forward on these waves of AI engineering is about building AI-enabled applications and being in AI. And Vibe Coding is about abandoning the old ways of producing software and embracing the new ways. And both of these are making people pretty mad. I think they're mad if their identity is tied to the way that they work today with no changes, no room for changes. Yeah. So I'll start with my first hot take. Okay. Let's go. There is a demographic that is the most affected by that. Their identity is the most tied up with the way that they work. Okay. It's not junior engineers.
1:21It's not non-engineers. They're all vibe coding. it's senior engineers, senior leaders, people who have, so basically you can, you can narrow it down to 12 to 15 years of experience. They hate vibe coding and they hate AI and they're online going, my 15 years is better than that AI. Okay. Now you saw, I don't know if you saw Jordan Hubbard's post from Nvidia where he just laid out some really nice advice on how to get the most out of agents as you're coding. And this guy posted and he's like, yeah, you know, no, you, you stick with your doing your director stuff and leave the programming to programmers, right?
1:58When you have 15 years of experience like me, then you're qualified to talk, right? Right. So I said something to him, like, I think you need to learn to read a clock. And he's like, and until you have 15 years of experience, and I'm like, well, you got more experience than him, or I have 45. So Should I go to 60 before I can talk to you? Or should I cut out 30 years of experience so I can be as dumb as you? Those are my options. So I don't know. I guess I'll see them in 15 years. Okay, I think there's one element that I'm trying to figure out of, while these people have to coexist, right? And most companies are going to have a mix.
2:34Even OpenAI, by the way, we talked about this last night at dinner. Guys, OpenAI has people who don't use AI to code. They have people who don't use codecs. they probably are using Cursor or something. Okay. But they're not using the agentic loops, right? Yeah, yeah. And, yeah, it's, so, you know, we talked to, you know, Andrew Glover there, you know, the director of DevProd, and from what he was saying, they've been planning on going public with this once they have more data about it. Yeah. Anecdotally, they're sharing that... The performance. The performance difference is like 10x by any way that you measure it.
3:08So lines of code, commits, business impact, whatever. and it's so stark and pronounced that the people who aren't adopting it are now 10 times less productive at performance review time. Two people, same title, same job, and all of a sudden one of them is 10 times as productive than the other one. What do you do? And the answer is you panic. You actually go to HR and you go to legal and you're like, what are our options here? Because the time is coming, okay? Here's another hot take, all right? If you're still using an IDE to develop code by January 1st, you're a bad engineer. There's a hot take for you, right?
3:46Now, you still have, what, five, six weeks to still be an okay engineer while you're using your IDE, but this is the time that you need to drop it and learn how agents code, okay? Because it's a skill set. I mean, it's so complicated. We wrote this book about it, me and Gene Kim, because we were playing with it ourselves last year and blogging about it and talking about it. And every blog post was 30 pages. And it's like, what are you gonna do with a 30-page blog post? That's long even for me, right? Yeah. And at some point, I was just, man, like the skills that you got to learn in order to get the AI to do the things that everyone's mad because it's doing them, right?
4:19Because everybody's like, well, I tried it. I spent two hours with it and all it produced was garbage. And the answer is actually you have to spend 200 hours with it. You have to spend 2 ,000 hours with it. And that's not actually an exaggeration. Gene just pulled up a study that showed that you actually have to spend a year or 2 ,000 hours with AI before you trust it. And what does trust mean? Trust in this case specifically means before you as a user can predict what it's going to do. And if it's unpredictable, of course, you're going to be mad. But as soon as you've worked with it for a full year to where you fully understand its capabilities and its drawbacks, which haven't really fundamentally changed, it's gotten more capable, but the edges are always the same.
4:59It hallucinates, it gets lost, it gets amnesia, dementia, it lies to you, whatever, right? Those skills, we've been building them for years now. Everybody who's been trying to write code with AI. We've been trying. It hasn't really worked, but it's been working better and better and better and better. And now it's reached the point where it's working a lot better than all of the other options. Yeah. And if you haven't tried it in two months, you're way out of date. The models are much better than two months ago. If you haven't tried it in a year, you're a dinosaur. It's just unbelievable how bad you are.
5:27And, you know, you may be, look, I have friends who are much better engineers than I am. Okay, I mean, world-class, maybe some of the best in the whole world, okay, have built technologies that you've heard of, and they're not using AI yet, except the occasional I'll ask Cursor a chat question like Wikipedia, whatever, okay? Those people are going to be the interns in a year. You really think so? Yeah. With all their experience that they have? So, I've had this hypothesis that has not been really confirmed with any anecdotal evidence at all until today, when I met somebody at your conference that told me about how he had been in this position, 12 years of experience, didn't want anything to do with AI.
6:07And he met these two PhD students from somewhere in Europe, I forget where. And they were both just super hardcore vibe coders, you know, with the agents, right? And he was watching them work, and they were super junior, and they kind of didn't know what they were doing, but they just had no fear and all the ambition. And all they did was they just kept hammering on the thing going, okay, well, why did you do it that way? Explain it to me. Okay, well, let's look at other options. And they would just be kind of the perfect engineer with no context. The perfect no context engineer, what questions are they going to ask?
6:38Have you thought about scaling? Have you thought about security? How is your test coverage, right? I mean, engineers are going to all ask the same questions, right? And he realized that engineer in a box is not too far off from knowing the right questions to ask an LLM. And that these two students were so productive with it, he was blown away that he was like, oh no. Like that's when the light bulb went on. He said, I have to learn this. And now he's been doing it ever since, right? But it ain't easy. You're not going to pick up Claude Code and you're not going to just try it and be like, it's just going to work.
7:06It might. You might get lucky. But eventually, if you don't have the right mindset, if you don't have the right attitude going in. Now, even with the right attitude, how often have you sworn at your agents in the last two days? With the actual F word or like, right? I'm pretty polite. I say thank you and please. I say thank you and please. And then, why the fuck did you do that? Right? And it's because Gene and I realized this after we published the book. You had this helper. They're very human-like. They come in, you have to tell them a lot of stuff, and they need a lot of guidance. But over time, they need less guidance.
7:37Your prompts get shorter. Things get streamlined. They seem to get it. They're working. Now, if this were a human being, you would draw the conclusion it's because they understand you and they get you and they're finally part of the freaking team. Do not make that mistake with LLMs. Never make the mistake of anthropomorphizing an LLM like Larry Ellison, right? The LLM, at any moment, can stab you in the back, okay? It can just be like, yeah, we took care of that really hard problem. Now I'm going to delete your database. And you're just like, no, right? And it's because of that. We call it the hot hand.
8:10You're like, it's going, man. I'm feeling good. This thing gets me. I'm going to make it do a production change. And that's how I found out about this. And I was like, my script can't access prod. And so it chose to do it in the worst imaginable way. What it did was lock out the entire rest of the universe, including my live game and everything else, and only allowed my script to access prot. And it was changing password. It changed the password. And I was like, why did you change my password? Right? Yeah. And it's like, oh, I'm so sorry. I definitely shouldn't have done that. What? No shit. Okay.
8:41And I'm just like, oh, right. This is what will happen to you if you just, you just try to do agentic coding. Okay. Bad things will happen. This is what our book is about really, right? Well, I mean, that's not the best ad because then what? Like you learn and then eventually you learn how the speed bumps and the corners and everything. It's like driving, right? It's like driving. Like you, you, you're, you want to become like a NASCAR driver. Like this is high performance stuff. You're coding with 12 agents at a time and you're, you're more ambitious than you've ever been. I was talking to a guy today who's got, got way more projects going than I've got.
9:14I don't know where he gets all the time from, but he's probably doing 10 or 12, like major projects at the same time right now. And he's just doing it all with with the gent of coding you know so i mean like man the the the ad here is that you will turn into batman but you can't just grab the suit and put it on and be like i'm batman you're just a cosplayer you're cosplaying at vibe coding you got to learn how the tool belt works and that's going to be pain suffering and mistakes and learnings now you can get a lot of it by reading this and all of the other vibe coding books read the o'reilly watch the talk i mean seriously like you should like get all of the possible angles at it because it seems to land differently for different people.
9:54There'll be some analogy where you finally get it. And I get it. It's like this and it's like a 3D printer and nobody else thought it was like a 3D printer, but somehow that was the magic that made it for you. Right. Yeah. I would say one of the biggest surprises from the dinner yesterday was how many people all have the experience where they no longer write single lines of code. Like they're really just kind of prompting and doing quite good by that. Single lines of code? You mean they never write any code at all? They might edit. But like, I think when they're writing net new, they'll always start with the prompts.
10:24No editing. No touch. No editing. It is very expensive when you're like, that identifier is misspelled and it's a local, you know. You could just edit it, but it's better for you to close your IDE and probably uninstall it. No, actually, that's not true. Somebody finally convinced me that IDEs are fantastic. IntelliJ in particular, keep it open. It's a Gradle build. And actually not for the LSP, although you can use it for that. Actually, that's another good way to use the LLM if you get an MCP server. But no, it's that IntelliJ's auto-indexing is so much faster. And incremental rebuild is so much faster than Gradle.
10:57This is the guy from last night, yeah. Yeah. So all you do is leave IntelliJ running. But you shouldn't look in it. It's a tool for the AI now, right? Amazing. One other thing that is a big part of some of the hot things you're saying You say CloudCode is not it. CloudCode ain't it. Explain yourself. All right. Everyone here loves CloudCode. Everyone here loves CloudCode or AMP if you use our product, which is just recently leapfrogged CloudCode again because of Gemini 3. AMP has this cool feature where it goes to another model. Just to pre-warm you, I also want to talk about just Google in general and how this Gemini revolution has kind of changed Google's image.
11:33But let's talk about CloudCode. Sure. CloudCode's been around since March. cloud code has been proven to work and so but yet probably 80 of the world's 90 of the world's programmers are not using it or anything like it you get certain companies where it's really taken off you know but uh but most aren't the world is stuck on cursor the word world is stuck in 2024 last year we were trying to get people to write with chat right and we were like we're telling And they were like, no, completions. And we were like, oh, God, no, but it can generate the code. And you just got to paste it in. And you just got to do all this stuff.
12:09And they were like, that sounds kind of hard. And we're like, but it's faster. And they wouldn't do it. And then nine months later, it finally percolated in. And now they're all like, I like cursor. And it's like, that's so last year, dude. Right? Like, wake up. And yet they haven't adopted it. And so you have to, at this point, look at it and say, why haven't they adopted it? Let's go look at the reasons. And the answer is, it's too hard. It's too hard. You have to be able to read. Man, most engineers, honestly, like to them, five paragraphs is an essay. Okay? And with Cloud Code, you've got to read waterfalls of not just information, but also code and diffs, right?
12:44Because if you're going to put your IDE away, you actually do have to look at the diffs. Now, I'm going to tell you that once you get some expertise at this, you can actually tell from the shape of the diffs and the color of the diffs and the length of the diffs. The vibe. You can tell whether it needs a code review, whether they're doing the wrong thing, whether that they seem to be writing suspiciously too much code for this problem, right? The diffs alone, just the shape of the diffs can tell you a lot about what's going on without actually reading the code, but you should pay attention to them.
13:07Otherwise you'll have problems that will only crop up later, right? But yeah, I mean like put the IDE away. Okay, clog code and then get clog code out and try to start using it, all right? And you're going to find that it's, look, I've been using clog code, honestly, 10 to 12 hours a day, literally, for months and months and months and I still curse it out all the time. I just lose my mind. I'm like, how could you have done that when you just said, right? And it's like, it's actually been shown, it's starting to be shown that sometimes when you put a little pressure on them, they perform better.
13:40You can break through law jams that way. But anyway, look, you're gonna run into problems. But the thing is, next year, the tools will be better. Okay? If Cloud Code's not it, what is it? Well, we gotta get back to something like an IDE, right? I mean, that's just gonna be, it's gotta be natural for people. You gotta be able to look at it and see what's going on, not have to read. It's got to have visual indicators, right? And yet it's not going to be an IDE because an IDE is very much focused on helping you write code and that's not what you do anymore, right? So what it's going to be is it's going to be your agent orchestration dashboard.
14:11You're going to walk in in the morning and be like, yo, so how's it going? It's like, oh, that one's still running. That one's running a tool. That one needs my input. Okay, right? You just go through the list. And so I'm building one. You can go look. It's supposed to be a private repo, but it's public. So I've got forks and shit. happens. But whatever, you can play with it. It's called VC, Vibe Coder. It's my V2 of the Vibe Coder system. And what it does is it creates a set of scanned workflows that run the agents for you. Yeah. I don't know if you saw Antigravity from Google the other day. We shot two days ago.
14:43It's so fun how much stuff people are inventing that are all around periphery. So look, I called this, I don't know, I called it in March. With Revenge of the Junior Developer, I did that chart and everything, and like, Dario quotes it in all his custom advisory boards and everything. Right. Really? Yeah. Yeah. No, it was it was really pretty impactful. And I called that. What's going to happen is the that agents I even back in March, I knew they were too hard. I was like, what's going to happen is they're you can run them programmatically. And 90 percent of the crap that you do with them could be handled by a model, often a cheaper model.
15:13Right. If it's just like if it's asking you, which of these two things should I do next? They're equally important. Like just have haiku say either one. Right. So like I called the orchestrators are coming and it's taken close until like the end of the year to get there, which is roughly where I predicted them coming. Replit, Agent 3, there's a bunch. There's Conductor, there's DMAD came out open source. They're all different takes on it, right? But there will be more coming. I guess Google's as well, right? Yes. I like this analogy that they have. It's still pretty new, so who knows what the eventual vision is.
15:47It's that you just get notifications from your agents as they're working. Exactly, yeah. So in mine, in VC, there's an activity feed. That was one of the first features I added, which is like, I want to go work, and I just want to get notifications periodically of interesting stuff. I wonder if they'll have social networks of agents. Well, so the agent - They're like, together with each other, following each other. Well, so I just had three-hour coffee with Jeffrey Emanuel, who did the MCP agent mail. He's one of the smartest people I've ever met in my life. He's the one that wrote the article that crashed the stock market about NVIDIA.
16:19That Jeffrey Emanuel. An incredibly well-written article that said, this is why it's a bubble. And the whole market went, and Karpathy started following it. It's back up. He wrote what you just said. He said, it is back up. But he wrote agent mail, which is, he was just tired of having to copy stuff between his agents. Like, you tell me what to tell this agent. And so he made a little, like, I don't know, HTTP server that's like an inbox for them, a messaging. And they talk to each other now. Now he goes, coordinate amongst yourselves to parallelize this task, this epic that I just put together or whatever, and they'll do it.
16:51Some people are coming at it top down and trying to build orchestrators that do it all for you. But interestingly, with Beads, which is the issue tracker session thing that I made, plus his... Purely vibe-coded, by the way. Purely vibe-coded, yes. So, I mean, I get PRs every day for horrible problems that I introduced, but nobody seems to mind because we've got stable versions now. So VEEDS is like living proof that you never actually have to look at the code as long as you and other people are asking the right questions and having the AI look at the code. I get PRs from people all the time where it's obvious that the AI did all of the analysis and all of the coding.
17:23And I look at it and sometimes I'll just be like, so my AI, what do you think of their AI's PR, right? It's all summarization. I mean, isn't that bad? It's bad if your code, look, it's all about the outcome. VEEDS is working and it's got tens of thousands of very happy people using it. So obviously it's not bad. I met one of the superfans down there. If you do this to your company's production website and bring it down, then yeah, it's bad. But still, Beads is kind of a database, you know? And database is one of the harder things to make. You know, Beads is really weird. The architecture is really weird.
17:55And the only reason it works is because it wouldn't have worked in the old days. It would have been just too hard to manage and not programmatically. But what you do is you tell the AI, go fix it all up. Whenever it's corrupted or there's a merge conflict, just fix it. And it's funny because Jeffrey Emanuel, who did the mail, basically did the same thing. He has all his agents run in the same directory and they do file reservations. They're like, I need that file. Man, I used to do that Accenture in the 90s, right? I'd like run over to a dude's cubicle and be like, I need that file. Their revision control was so bad.
18:23So like he's got a file reservation system going. But what happened was as soon as he put it in place, his agents just started working. And now he's got this little village of agents, right? And that's where we're headed. So the orchestrators are going to be about not keeping the agent on the rails, but keeping all of your agents on the rails and communicating with each other. Yeah. And then you hit the wall. Boom. Does anybody know what the wall is? Once you get past all this, merge. Merging is the, it's the wall that everyone is hitting right now. Yeah. I think the company that's best poised to solve it is Grappite.
19:00I was going to go talk to him about it. They'd be happy to talk to you. Yeah. Yeah. I think everybody needs to solve it. And if you're at an enterprise, like what we hear, because Gene Kim and I talk, we talk to companies all that. I'm a SaaS seller, so we get to hear the inside story from all these big companies, right? And they're saying, yeah, as soon as you get to the point where like every developer is 10 times as productive, merging their code becomes this incredibly complicated problem. Because you and I work at the same time for two or three hours. We make, you know, 30 ,000 line change each.
19:33Mine makes it in first, and it gets merged. And then you come along, and I have literally changed our logging system and our architecture here and APIs that you were using. Yeah. And so it's not going to be a simple, it's not a simple, let's fix the merge conflicts. It's like, you're going to have to re-envision and re-imagine and re-implement your change on my change. Or rip yours out. Or rip mine out and make me do it. But ultimately, ours are just the AIs doing it, right? But the important thing is that they have to be serialized. It is a queue. And when they go in there, they have to actually basically redo what they were doing on top of the new thing.
20:10Nobody has solved this, and it is a huge obstacle right now. You know what one company did? Sorry, last thing. One company said, here's our solution. One engineer per repo. Not making that up. It's a solution. It's a solution for now. The classic solution for this is stack diffs, right? Merge queues, stack diffs. I don't know about stack diffs, so I guess I'm dumb. It's like a Facebook concept that they're trying to bring to the wider world. GitHub is working on adding it. I just talked to Jared Palmer there. Basically, I'm hearing no solution yet, but you should be aware of it and design around it.
20:41Yeah, I mean, there's the old-fashioned way of just hammering through it really hard. Well, also, you know, you could just talk to the other guy and say, like, hey, I'm doing this, you know, pretty deep architectural change. Let me go first. And let's agree on the overall pattern first. So, yeah, I mean, I've run into this situation a few times where I've actually tried to give this agent a heads up that this one's making a change that affects this one. Yeah. With the mail thing that Jeffrey did, I think once I get it wired up, because he doesn't use work trees and I'm going to, this. But once they can actually talk to each other, I think it's going to be as simple as just keep in mind that that agent's working on something that affects you.
21:13You might want to go talk to them about it. Yeah, and agree on an overall, like, fundamental infra. And they're quite good at it. They just do it. It's because they have no ego. They're not like, oh, it's got to be me. Right. So just whoever's first gets to be the leader. Great. What do you and him disagree on? Me and who? Jeffrey. Emmanuel, the guy that I just met. Well, so we foundationally, fundamentally disagree that having 12 agents work in a single repo clone is a good idea. So you're on the pro side. I'm on the pro, like either get work trees with lots of branches or separate repo clones.
21:47I would imagine. Keep them sandboxed. He's in favor. They've got them all in the same, they're literally, they're using the same Git, the same build. So one of them will be like doing a build, like need to run a test. That's so much churn. Yeah, but he has a file reservation system. So the funny thing is, okay, I was like, this is insanity. And he's talking me into at least acknowledging that it probably works pretty well if you're a solo dev and you're using no more than a dozen or 20 agents. Because it is actually working for him. And he uses the same principle that Beads does, which is it wouldn't have worked in the old days.
Read the full transcript
22:18It doesn't make any sense to a real engineer. And yet you tell the AI, if anything gets messed up, just fix it. And they will. And so that's right. That's why his thing works. Because every once in a while, the file reservation gets screwed up. And they're like, hey, we need to resolve this. And they figure it out. Interesting. Yeah. Some people have proposed that the theme of this conference next year is on multi-agents. Oh, yeah. I mean, yeah, of course. Yeah, yeah. I mean, AI will be about multi-agent. Look, we're in this phase still where we're cutting down corn with scythes with our hands.
22:47That's what a real programmer does these days. We're moving next year. It's very clear. We're moving to, you know, these machines that churn, you know, these giant, just like those ones that you see on the farms today, factory farms. We're going to be factory farming code. Okay. And that absolutely, like, a lot of people are just so dead set against that philosophically, morally, ethically, whatever. They're just like. They're so used to subsistence agriculture that we're not used to, like, the big John Gears. But we are actually moving into the John Deere era of coding. That's amazing. Yeah, but the funny thing is...
23:22That's made an analogy, actually. And I just thought of it, too. We'll have to reuse it. Yeah. But it's been growing on me. It's the whole... It's this idea that Claude Code and AMP and Codex, you know, Klein, we love them all. Equally, they're all equally bad. I said in my talk today, they're like a power saw or a power drill. A skilled craftsman can do a lot of good with them, and then you can also cut your foot off with them. The same thing's true of Claude Code. But imagine a big machine, a big farming machine that knows how to run cloud code and scrub it. Right. Almost. It's like, okay, you plan, you implement, you review, you test.
23:57Right. And you split it all up. And now you got yourself factory farming. Right. It works. People are building it. It's going to happen. And what it's going to do is it's already started to unlock programming for non-programmers. And this is completely turning companies upside down. They're starting to realize that maybe the ideal team size is like two or three. And I mean, like, right, the whole way that companies are run, the whole governance structure is going to change because now coding is no longer the bottleneck. The business needs to get immediately involved. The speed back loops get faster.
24:26And it's really exciting times. But it's too much for a lot of people. And they just, they're like checking out or they're revolting online. And I predict that as this capabilities improve and as we get closer and closer to the factory farming of code, we will see a massive backlash from the Luddites. You are the one of the few people I can ask this as a, I know a lot of people in our audience are critical of going the full hog with this. Yes. So a lot of like, they're like, fine for front end, fine for application code, but don't touch my cloud infra. Don't touch my backend, my distributed microservices.
25:00Definitely don't touch anything production. Only touch code. Only use these things when Git is your backstop, for starters. Okay, so keep prod out. It's going to be real tempting to write, but don't. If you have Git as your backstop, why should you be worried? True, except I guess people have the perception that it is less good at back-end code. Oh, this is the problem where everybody's bad at math. Yeah. Okay, so how good was ShadGPT 3.5 at systems code? Pretty bad. How long ago was that? Two years ago. Honestly, I believe that the misunderstanding here is rooted in a fundamental belief that the models are done getting smarter.
25:39Right. And the funny thing is, they could be done getting smarter. They're not. But they could be. And we would still be over the hump where we've discovered electricity and now we need to harness it. Yeah. We will still get to factory farming code with today's model's capabilities. And we'll get there fast. We'll get there by summer. But the models are getting smarter so fast. You know, it's really, there's this interesting tension of, you know, like, you're building tools for capabilities that the models will eventually have built into their brains. Yeah. And so you won't need that capability in the tool anymore.
26:07And so there's this constant arms race and decay of your tool filling gaps for the model until the model is good enough to fill it itself. And then your tool moves on. Yeah, that's what I mean. All code and all tools are becoming throwaway. Which is great because they're easier to build, too. Yeah, by the way, yes. So remember Joel Spolsky, one of the greatest of our generation, our time, one of the greatest writers and thinkers. He gave the best tech talk I've ever seen, and I want to get him to come and revive it. He gave it at Amazon 20 years ago. It's still relevant today. He's invited here?
26:35Great. So Joel Spolsky, a long time ago, wrote something that was timeless until today. So it was 20 years timeless, which was... Never rewrite your code. Never rewrite your code. And now we've discovered that it is, for a larger and larger and larger class of bodies of code, it is better to just start over and rewrite it from scratch than it is to try to fix it. The LLM will do a better job. I first noticed this when I was trying to port all of my unit tests from one architecture to another. And eventually, I was just, oh, just an iteration, because they're trying to fix. There's a lot to keep in mind.
27:05But instead, if you say, throw all the tests out and make them again, it just goes and you're done. Right. And so it's like, hmm, hmm. Well, what about this library? I got to refactor. And so it's creeping up. But we're moving into a world where the fastest thing to do is just build new code that does a better job of what the old code was trying to do. Yeah. I mean, it's like we're unlearning everything. I feel like an upside down land. But this is like we've entered quantum mechanics. But you have to embrace this new world. I love the energy and the credibility that you bring because a young kid could say what you're saying and not be as believable.
27:37But you're coming from the perspective of you've been a huge systems programmer. You've been a game programmer. You've been everything. Yeah, I've done assembly language for five years, you know, operating systems in assembly language. And it was 8086, not even 80X86. We had eight-bit registers. I've done it all. And, you know, game programming teaches you everything. And then, of course, I've done platforms and Google and ads and this and that. The agentic loop and the game programming loop share a lot in common. They do. Resource sharing, operating system loops. I feel like I'm building the same systems over and over again now.
28:12There's only a request to reinvent the same designs in every new domain. It's a privilege, too. One thing I wanted to get you to comment on is Google. Oh, Google. One of my favorite memories, which is just before you retired, was talking about how Google still doesn't get it. Google Cloud in particular, how they shut down the deprecation policy. I was so mad about that. You're going to get me pretty mad to write a blog. Have they turned it around? No. I talked to some people there, and a lot of them were like, yeah, that's not a thing for Google. And it's funny because Amazon, not on the platform, not on the deprecation stuff, not on the important stuff.
28:47Google has turned it around on execution. They finally did the thing that they should have done 15 years ago, which is hold people accountable, and it's not just engineers do whatever they want all the time, which was what it was for 20 years. It actually worked pretty well because they had a monopoly on ads and they could afford to subsidize Google engineers doing whatever they wanted for us. But ultimately, they had to do the right thing and grow up and mature as an organization. And it was painful and they lost some Google culture and it's not as fun anymore, but they now execute well and they did the right thing for the company.
29:16And now with Gemini, you can see now they've been shifting their focus gradually towards more AI, AI, and now it's starting to pay off for them. Yeah. And maybe they're going to be the big, big winners. Do you have observations of a similar kind with all the other labs? You know, I'm just kind of curious in your takes on one of my favorite charts is that old chart where you had Microsoft like all pointing guns at each other. Yeah. Facebook, everyone's a ring. You're the first person to ask me this. I remember that chart. That was funny. Yeah. I feel like someone could do that for OpenAI. They could.
29:45They could. You know, it's an interesting question. All three of those companies, Google, Anthropic, and OpenAI are unbelievably chaotic internally right now. Yeah. Chaos. Okay. Anthropic hides it really well. They seem like they've got their ass together. So what that means is their product managers formed a wall around that chaos. And bravo, Anthropic product managers. And it's not because Anthropic's screwing up. It's because it's an inevitable function of growing that fast. They're hiring like 100 plus people for cloud code in the next, I don't know, month. I mean, like they're going wild.
30:18And that's just cloud code. You're not going to, I mean, I was at Google and Amazon when they were in the get big fast phases and you're just going to have chaos. You're going to have churn. Nobody knows who to talk to what and everything's crazy. Eventually it starts to smooth out, settle out, and they'll get there. Right. OpenAI is chaotic more like in a, well, they had a lot of exits, right? You know, I don't know if it was chaotic as say GitHub who lost most of their senior leadership and was just complete turmoil for years, but they're pretty chaotic at OpenAI. Right. And then Google, you know, We were just talking to somebody today that was saying it was still too hard to, like, get consensus across groups with the Jules team.
30:54Yeah. They can't get it rolled out internally because Google is so siloed. It's a billion monoliths, right? Little apps that don't talk to each other that it's hard to roll anything out across Google. So all three of them have execution problems right now. I think Anthropoc is probably executing a little bit better than the other two, but it's a real close race. And, yeah, it'll be interesting to see and see if Oracle or Facebook or any of the others can catch up, right? Meta. Facebook will be the most interesting thing. I mean, they'll have to do something huge next year. Next year could be the year of open source models.
31:25Yeah? Well, so look, as soon as open source models get to the point where they're as good as CloudSonnet 3.7 was, then you turn on Klein or something, and you've got something that's as good as CloudCode was in March, which wasn't as good as today, and it's not good, but it's good enough, and you're running it for free, free, free, free on your local M4 or whatever, right? So, yeah, and from what I've heard, they're seven months behind, and that gap is gradually narrowing the frontier models, which means OSS models will be as good as Gemini 3 next summer. Right. So, yeah, next year could very much be the year.
32:00That means the tools are going to have to get much, much better at decomposing the test and assigning them to the right model, the right size of model for cost optimization. I'll represent the critical side, which is that the reason they're converging is because they're saturating, right? You can only ever hit 100, and the closer you get to 100, proportionally, it'll just get harder and harder, right? So obviously, the rate of change when you're lower down is higher as compared to when you're already saturating. But that's a minor technical point. Well, no, I mean, it's not minor at all. It's actually a foundational question, which is, is the line of AI intelligence going to go straight, or is it going exponentially, or is it actually starting to peak?
32:39Accentotic, yeah. Yeah. And, you know, from what we've heard from people who are very, very close to the research, we know that AI has been getting, what is it, four times smarter every 18 months for the last, I don't know, 30 years because of Moore's Law. And they think that there's enough data left, training data, for two more cycles of that before they don't know what happens. Yeah. Maybe it goes up more, maybe it goes down. We don't know. Human history ends. But two more cycles means they're going to be 16 times smarter in three years, right? I can't even imagine. Well, I don't even know what that means.
33:10I've spent a long time trying to figure out what it means but what it means is they're going to be really, really, really smart and it's going to change the world probably in a lot of good ways and a lot of bad ways and yeah I don't know if you have this version of this conversation people ask me if their kids should learn a code Kids should learn to vibe code You have the escape hatch of you can read the code if you want to you just don't need to most of the time but you can and it's a good guard Right, but I don't because you don't have to. Well, I think my take is whatever it is, you'll be better off if you do also know how to code because you can prompt better.
33:49Because you can tell, you can communicate more precise terms. Look, when I see you say you know how to code, not the syntax and stuff, but you have to know, like, in a language-neutral way, what the capabilities of languages are. Functions and classes and objects and, I don't know, monads, whatever it is. The whole superset. You should be aware of them. And then from there up, so you've cut off all the syntax. You don't care how to write it anymore, but you care how it works. So you've sort of reached the level of how a product manager thinks about things, architecturally, right? And you need to be that product manager.
34:20And now you're starting to move your concerns up. And you need to know all the engineering stuff. And like Jeffrey Emanuel, like I was talking about, he's a mathematician, self-taught engineer. But he's learned all of the right concepts. You know, Cloudflare does this. And Apache Cassandra does that. That is still technical. Yeah. That doesn't go away. You still need to learn all that, right? And so just because you don't have to write code anymore doesn't mean you have to. You still have to learn a massive amount of stuff to be an effective engineer in the new world. Because that's the level that you're interacting with in that.
34:52Amazing. So this has been a great overview. I don't know if you have any other sort of rants in you that you want to sort of get out there. I'll leave you the floor. I feel like the gossip rate has gone up. Like not gossip, but the rate of exciting announcements by engineers who have discovered new things about how to be more productive with agents. Like, for example, I just found out today, not this, I found out today about, it's called Code MCP or something like that, where you, instead of calling... It's a pretty popular project. The agents can't call MCP very effectively because they don't have any training on tool calls.
35:22But they have plenty of training on writing code. So you tell them, don't call the tool, write code to call the tool, and they do way better with it, right? So it's like, it's all these little learnings that we're finding, right? It's crazy that Anthropic, the creators of MCP, found this. Did they? Yeah. Well, Cloudflare found it first, but then the topic was like, yeah, yeah, you guys are right. Yeah, wow. That's really neat. I think that's why I love focusing on the AI engineer because my argument is the AI engineer can uniquely take advantage of LLMs way better than everyone else. That's true.
35:51So you go with so much more power. You could almost define an AI engineer as somebody who's mastered LLMs. Yeah. Yeah. Not from training, but from using. Yeah, using. Yeah, yeah, yeah. I think it's one of these disruptor strategies where it's low status. It's high status to be a researcher. It's high status to train models. You don't get any respect if you're a GPT rapper. But people are starting to be more productive and actually develop sincere expertise in the same way that I think F1 car drivers don't know how to build an F1 car, but they'll tell you everything about driving it. And they may know, in a sense, they know more about operating it than the people who build it.
36:29And so they have to have that conversation, right? Yeah. Yeah. Although if you watch the, I think, the F1 movie, you get a little sense of humor. Oh, and they make all the money. Is that what you said? Yeah, that's a good point. It's flip-flopped. Lovely. Well, thanks so much for coming on. I'm a huge amount of your work. Your energy is very infectious, and I hope you keep doing Stevie's Tech Talks. I'll start them up again, man. I mean, this energy is because of the AI, and it's because of vibe coding. It's addictive and fun. Tech is fun again. It's got boring for a little bit. I know. I know.
36:58for a while it was like well Sourcegraph like indexes your code base like really really well you know and it's like so fast and I'm like well that's cool but you know what's cooler it's not good yeah cool it's been fun
From the publisher
Note: Steve and Gene’s talk on Vibe Coding and the post IDE world was one of the top talks of AIE CODE: https://www.youtube.com/watch?v=7Dtu2bilcFs&t=1019s&pp=0gcJCU0KAYcqIYzv
From building legendary platforms at Google and Amazon to authoring one of the most influential essays on AI-powered development (Revenge of the Junior Developer, quoted by Dario Amodei himself), Steve Yegge has spent decades at the frontier of software engineering—and now he's leading the charge into what he calls the "factory farming" era of code. After stints at SourceGraph and building Beads (a purely vibe-coded issue tracker with tens of thousands of users), Steve co-authored The Vibe Coding Book and is now building VC (VibeCoder), an agent orchestration dashboard designed to move developers from writing code to managing fleets of AI agents that coordinate, parallelize, and ship features while you sleep.
We sat down with Steve at AI Engineer Summit to dig into why Claude Code, Cursor, and the entire 2024 stack are already obsolete, what it actually takes to trust an agent after 2,000 hours of practice (hint: they will delete your production database if you anthropomorphize them), why the real skill is no longer writing code but orchestrating agents like a NASCAR pit crew, how merging has become the new wall that every 10x-productive team is hitting (and why one company's solution is literally "one engineer per repo"), the rise of multi-agent workflows where agents reserve files, message each other via MCP, and coordinate like a little village, why Steve believes if you're still using an IDE to write code by January 1st, you're a bad engineer, how the 12–15 year experience bracket is the most resistant demographic (and why their identity is tied to obsolete workflows), the hidden chaos inside OpenAI, Anthropic, and Google as they scale at breakneck speed, why rewriting from scratch is now faster than refactoring for a growing class of codebases, and his 2025 prediction: we're moving from subsistence agriculture to John Deere-scale factory farming of code, and the Luddite backlash is only just beginning.
We discuss:
Why Cloud Code, Cursor, and agentic coding tools are already last year's tech—and what comes next: agent orchestration dashboards where you manage fleets, not write lines
The 2,000-hour rule: why it takes a full year of daily use before you can predict what an LLM will do, and why trust = predictability, not capability
Steve's hot take: if you're still using an IDE to develop code by January 1st, 2025, you're a bad engineer—because the abstraction layer has moved from models to full-stack agents
The demographic most resistant to vibe coding: 12–15 years of experience, senior engineers whose identity is tied to the way they work today, and why they're about to become the interns
Why anthropomorphizing LLMs is the biggest mistake: the "hot hand" fallacy, agent amnesia, and how Steve's agent once locked him out of prod by changing his password to "fix" a problem
Should kids learn to code? Steve's take: learn to vibe code—understand functions, classes, architecture, and capabilities in a language-neutral way, but skip the syntax
The 2025 vision: "factory farming of code" where orchestrators run Cloud Code, scrub output, plan-implement-review-test in loops, and unlock programming for non-programmers at scale
—
Steve Yegge
X: https://x.com/steve_yegge
Substack (Stevie's Tech Talks): https://steve-yegge.medium.com/
GitHub (VC / VibeCoder): https://github.com/yegge-labs
Where to find Latent Space
X: https://x.com/latentspacepod
Substack: https://www.latent.space/
Chapters
00:00:00 Introduction: Steve Yegge on Vibe Coding and AI Engineering
00:00:59 The Backlash: Who Resists Vibe Coding and Why
00:04:26 The 2000 Hour Rule: Building Trust with AI Coding Tools
00:03:31 The January 1st Deadline: IDEs Are Becoming Obsolete
00:02:55 10X Productivity at OpenAI: The Performance Review Problem
00:07:49 The Hot Hand Fallacy: When AI Agents Betray Your Trust
00:11:12 Cloud Code Isn't It: The Need for Agent Orchestration
00:15:20 The Orchestrator Revolution: From Cloud Code to Agent Villages
00:18:46 The Merge Wall: The Biggest Unsolved Problem in AI Coding
00:26:33 Never Rewrite Your Code - Until Now: Joel Spolsky Was Wrong
00:22:43 Factory Farming Code: The John Deere Era of Software
00:29:27 Google's Gemini Turnaround and the AI Lab Chaos
00:33:20 Should Your Kids Learn to Code? The New Answer
00:34:59 Code MCP and the Gossip Rate: Latest Vibe Coding Discoveries




