Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE

We are here live at AI Engineer Summit with Steve Yegge, the legendary Steve Yegge of Stevie's tech talks, Stevie's platforms, brands, and most recently Sourcegraph and AMP. Welcome. And most recently, vibe coding, I should. That's right, the vibe coding book. So this is the big vibe coding discussion. In the pre-chat, we're 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?

Steve Yegge: It's absolutely a movement, right? You got to get people behind it. I mean, there's a I said at the end of my talk today that there's a huge backlash and the backlash is only just brewing now. So, you and I are pushing forward, right, on these waves of, you know, AI engineering is about is about building AI enabled applications and being being in AI and vibe coding is about abandoning the old ways of producing software and embracing the new ways, right? And both of these are making people pretty mad, right? I don't I think they're mad if they're identity is tied to the way that they work today with no changes, no room for changes.

Host: Yeah. So, I'll start with my first hot take.

Steve Yegge: 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. It's not M0 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 are online going my 15 years is better than net AI. Okay, that 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? When you have 15 years of experience like me, then then you're qualified to talk, right?"

So I said something to him like, "I think you need to learn to read a clock." And he's like, "Until you have 15 years of experience." And I'm like, "Well, you got more experience than him. I have 45. or should I like go to 60 before I can talk to you or should I like cut out 30 years of experience so I can be as dumb as you right those are my options and uh so I don't know I guess I'll see him in 15 years I I okay I think there's one element that I'm trying to figure out of well these people have to coexist right and most companies are going to have a mix even Open AI by the way we talked about this last night at dinner guys Open AI has people who don't use AI to code they have people who don't use codec X they probably are using Cursor or something. Okay. But they're not using the agentic loops, right?

Host: Yeah. And uh yeah, it's uh so you know we talked to you know Andrew Glover there you know the director of dev prod and uh 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 uh performance the performance difference is like 10x any way that you measure it. So lines of code commits business impact whatever. And it's 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.

Steve Yegge: Okay, here's another hot take.

Host: All right, if you're still using an IDE to develop code by January 1st, you're a bad engineer. There's a there's a hot take for you right now. You still have a what, five, six weeks to 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 Jean Kim, cuz we were, you know, we were playing with it ourselves last year and blogging about it and talking about it, and every blog post was 30 pages. It's like, what are you going to 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? Because everybody's 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 at it 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. It 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 2 months, you're way out of date. The models are much better than 2 months ago. If you haven't tried it in a year, you're a dinosaur. It's just unbelievable how bad you are. And and and 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 with all their experience have I have had this hypothesis that has not been really confirmed with any 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.

And 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 with the 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 let's 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? Have 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 right the light bulb went on. I have to learn this. And now he's been doing it ever since. Right.

But it ain't easy. I I You're not going to pick up cloud code and you're not you're not going to just try it and be like it's just going to work for it. 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 swear 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 go where did you do that? Right. And it's it's because it's because Jean and I realized this after we published the book. You have this helper. They're very humanlike. They come in. You have to tell them a lot of stuff and they they they need a lot of guidance. But over time, they need less guidance. Your 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 anthropomorphicizing 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 and it's because of that it's we call it the hot hand. You you sort of like you're like, "It's going, man. I'm feeling good. I'm feel this thing gets me. I'm going to make it do a production change." And that's that's how I found out about this. And it's like 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. And it's like oh I'm so sorry. I I definitely shouldn't have done that. What was it? Okay. And I'm just right. This is what will happen to you if you just you just try to do a coding. Okay. Bad things will happen. This is what our book is about really. Right.

Host: 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 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 I've gotten. And I 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 a gent coating, you know? So, I mean, like, man, the 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. There will be some analogy where you finally get it. I get it. It's like this and 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?

Steve Yegge: Yeah. I would say one of the biggest surprises from the dinner yesterday was how many people all had the experience where they no longer write single lines of code like they they're really just kind of prompting and and doing that single lines of code.

Host: You mean they never write any code at all?

Steve Yegge: They might edit but like I think when they're writing net new they always start with the prompts.

Host: No editing, no touch. No editing.

Steve Yegge: It is it is very expensive when you're like that that identifier is misspelled and it's a local. You know, you could just addit 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 IDE are fantastic. IntelliJ in particular, keep it open. It's 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 autoindexing is so much faster and incremental rebuild is so much faster than last night. Yeah. Yeah. So you all all you do is leave IntelliJ running but you shouldn't look in it. It's a tool for the AI now, right?

Host: Amazing. One other thing that is a big part of Zonda hotics. You're saying you said cloud code is not it. Cloud code ain't it. Explain yourself.

Steve Yegge: All right. Everyone here loves cloud code. Everyone here loves cloud code or or AMP if you use our product which is uh is just recently leaprogged cloud code again because of Gemini 3. AMP has this cool feature where it goes to another model. And 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. But let's talk about cloud coding.

Host: Sure. Cloud code'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 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 tell 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 and they were like that sounds kind of hard and we're like but it's faster and they 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? Because 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. You can tell whether it needs a code review, whether they're doing the wrong thing, whether 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. Otherwise, you'll have problems that will only crop up later, right? But yeah, I mean like uh uh uh put the IDE away. Uh, okay. Cloud Code and then get Cloud Code out and try to start using it. All right? And you're going to find that it's Look, I've been using Cloud Code honestly 10 to 12 hours a day, literally, uh, for for months and 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 it's starting to be shown that sometimes when you put a little pressure on them, they perform better. You can break through law jams that way. But anyway, look, you're going to run into problems and and but the thing is next year the tools will be better.

Host: Okay, if cloud code's not it, what is it?

Steve Yegge: Well, we got to get back to something like an IDE, right? I mean, that's just going to be it's got to be natural for people. You got to 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 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. It's you're going to walk in in the morning and be like, "Yo, so how are things do?" Right? 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 Um, happens. But whatever, you can play with it. It's called VC, Vibe Coder. It's my B2 of the Vibe Coder system. And what it does is it creates a set of uh scanned workflows that run the agents for you.

Host: Yeah. I don't know if you saw anti-gravity from Google the other day. Uh which two days ago so it's so fun how much stuff people are inventing that are all periphery. Yeah. Yeah.

Steve Yegge: No. 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 uh Dario quotes it in all his customer advisory boards and everything, right?

Host: Really? Yeah. Yeah.

Steve Yegge: No, it was it was really pretty impactful and 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 gonna happen is they're you can run them programmatically and 90% of the crap that you do with them could be handled by a model often a cheaper model, right? 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 and like the end of the year to get there, which is roughly where I predicted them coming. Replit, agent 3, uh there's a bunch. There's the conductor, there's uh DMAD came out, open source. They're all different, you know, takes on it, right? And uh but there there will be more coming. I guess uh Google's as well, right?

Host: Yes. I like this analogy that they have. It's still pretty new, so who knows what the eventual vision is is that you just get notifications from your agents as they're working. Exactly. Yeah.

Steve Yegge: 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.

Host: Interesting. I wonder if we'll have like social networks of agents.

Steve Yegge: Well, agent each other, following each other. Well, so I just had three-hour coffee uh uh with uh Jeffrey Emanuel, who's who's he 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.

Host: Oh, that Jeffrey Emanuel, the one that an incredibly well-written article that said this is why it's a bubble and the whole market went and Karpathy started following is back up.

Steve Yegge: He wrote what you just said. He said it is back up. But he wrote uh 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 little like I don't know HB server that's like an inbox for them a messaging and they talk to each other now and now he goes coordinate amongst yourselves to paralyze this task this epic that I just put together or whatever and they'll do it some people are coming at it top down and trying to build orchestrators that you know do it all for you but interestingly with Beads right which is the issue tracker session thing that I that I made plus his purely vcoded by the way purely vcoded yes so I mean like I get PRs every day for horrible problems that I introduced but nobody seems to because we've got stable versions now. So, Beads 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 PR from people all the time where it's obvious that the AI did all of the analysis and all of the coding and I look at it and sometimes I'll just be like, "So, my AI, what do you think of their II's PR?" Right? And you all summarization. I mean, isn't that bad? Don't you want it's bad if your code if look it's all about the outcome Beads 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 there if you do this uh to your your 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 and 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 and not programmatically. But what you do is you tell the AI, go fix it all up and whenever it's corrupted or there's a merge conflict or just 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. So like he's got a file reservation system going. But but it all what happened was as soon as he put it in place his his agents just started working and now he's got this little village of agents, right? And that's 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.

Host: Yeah. And then you hit the wall. Boom. Does anybody know what the wall is once you get past all this?

Steve Yegge: Merge. Merging is the It's the wall that everyone is hitting right now.

Host: Yeah, I think the company that's best poised to solve it is Graphite. I was going to go talk to them about it. They'd be happy to talk to you. Yeah. Yeah.

Steve Yegge: I think everybody needs to solve it. And if you're at an enterprise like what we hear cuz Gene Kim and I talk, we talk to companies all the time. I'm a SAS seller. So, a Sourcegraph. So, we get to hear the 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 I you and I work at the same time for two or three hours. We make, you know, 30,000 line change each. Mine makes it in first." H and it gets merged and then you come along and I have literally changed our logging system and our like, you know, our architecture here and APIs that you were using. Yeah. And so it's not going to be as simple. It's not a simple let's fix the merge conflicts. It's like you're going to have to reinvision and reimagine and reimplement your change on my change or rip yours out or rip mine out and make me do it. But ultimately ours were just the AI doing it, right? But the the important thing is that they have to be serialized. It is a cue and that when they go in there, they have to actually like basically redo what they were doing on top of the new thing. Nobody has solved this and it is a huge obstacle right now.

Host: 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 the classic solution for this is stack diffs, right? Merge cues, stack diffs.

Steve Yegge: That I don't know about stack diffs, so I guess I'm dumb. It's a It's like a Facebook concept that they're trying to bring into the white ros. GitHub is working adding it. I just talked to Jared Palmer there. Basically, I I'm hearing no solution yet, but you should be aware of it and design around it. Yeah. I mean there's the oldfashioned way of just hammering through it really hard and 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 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 the heads up that this one's making a change that affects this one with the mail thing that Jeffrey did. I think once I get it wired up cuz he doesn't use work trees and I'm going to this but once 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. You might want to go talk to them about it. Yeah. And agree on an overall like fundamental ifra and they're quite good at it. I they just have no 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.

Host: What do you and him disagree on?

Steve Yegge: Me and who? Jeffrey. Emanuel the guy that I just met. Well, we uh so we foundationally fundamentally disagree that having 12 agents work in a single repo clone is a good idea.

Host: So you're on the pro side.

Steve Yegge: I'm on the pro lots of like either get work trees with lots of branches or separate repo clones. I would imagine keep them sandbox them all in the same they're all 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. It 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.

Host: Interesting. Uh I I some people have proposed that the theme of this conference next year is on multi-agents.

Steve Yegge: 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 we're cutting down corn with scythes with our hands. That's what a a real programmer does these days. We're moving next year. It's very clear. We're moving to uh you know um these 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 coat. Okay. And that absolutely like uh 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 we're not used to like the big John Deere. But we are we are actually moving into the John Deere era of coding. That's amazing. Yeah. Yeah, but the funny analog you actually and I just thought of it too. Well, we'll have to reuse it. Yeah, but it's been it's then it's been growing on me. It's the it's this idea that quad code and AMP and Codeex, you know, Klein, we love them all equally. They're all equally bad. I said in my talk today, they're like they're like a power saw or a power drill. A f 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 is true of cloud code. that imagine a big machine, a big farming machine that knows how to run cloud code and scrub it, right? Almost it's like it's like, okay, you plan, you implement, you review, you test, right? 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 time team size is like two or three. Yeah. 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 feedback back loops get faster and it's really exciting times but it's too much for a lot of people and they just they're they're like checking out or they're revoling 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 leadites.

Host: You are the one of the few people that can ask this as a I know a a lot of people in our audience are critical of going the full hog with this. Yes. So a lot like they're like fine for front end fine for application code but don't touch my cloud infra don't touch my my backend my distributed microservices. Definitely don't touch anything production only touch code only use these things when git is your back stop for starters.

Steve Yegge: Okay, so keep prod. It's going to be real tempting to write but don't. If you have git as your back stop, why should you be worried?

Host: True, except I guess people have the perception that it is less good at backend code.

Steve Yegge: Ah, this is the problem where everybody's bad at math. Yeah. Okay. So, how good was Chad GPT 3.5 at systems code? Pretty bad. How long ago was that? Okay. People think people think the honestly I believe that the misunderstanding here is rooted in a fundamental belief that the models are done getting smarter, right? 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. We will still get to factory farming code with today's models 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 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. And so there's this constant arms race and decay of your tool filling gaps for the model until the model's good enough to fill it itself and then your tool moves on. All road is becoming all code and all tools are becoming throwaway. Like which is great because they're easier to build too. Yeah.

Host: By the way, yes. So remember uh Joel Spolsky, one of the greatest, you know, of our of our 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. Great.