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 Stevey’s Tech Talk, Stevey’s Google Platforms Rant, 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 were discussing the intersection of vibe coding and AI engineering. We’ve got the movement leaders of both sides here. How do you see it?

It’s absolutely a movement, right? You have 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.

You and I are pushing forward on these waves. 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. Both of these are making people pretty mad, right?

I don’t think they’re mad if their identity is tied to the way that they work today, with no changes and no room for changes.

Yeah. 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.

It’s not junior engineers. It’s not more experienced engineers. They’re all vibe coding. It’s senior engineers and senior leaders. Basically, you can narrow it down to 12 to 15 years of experience.

They hate vibe coding, and they hate AI. They’re online going, “My 15 years is better than that AI.” You saw—I don’t know if you saw—Jordan Hubbard’s post from NVIDIA, where he laid out some really nice advice on how to get the most out of agents as you’re coding.

This guy posted, and he’s like, “Yeah, no. You stick with doing your director stuff and leave the programming to programmers, right? When you have 15 years of experience like me, then you’re qualified to talk.”

Well, you have more experience than him.

I have 45. 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. I guess I’ll see him in 15 years.

I think there’s one element that I’m trying to figure out. These people have to coexist, right? Most companies are going to have a mix. Even OpenAI—we talked about this last night at dinner—has people who don’t use AI to code.

They have people who don’t use Codex. They’re probably using Cursor or something.

Okay. But they’re not using the agentic loops, right?

Yeah, yeah.

We talked to Andrew Glover there, the director of developer productivity, and from what he was saying, they’ve been planning on going public with this once they have more data about it. Anecdotally, they’re sharing that the performance difference is like 10×, any way that you measure it: lines of code, commits, business impact, whatever.

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 have the same title and the same job, and all of a sudden one of them is 10 times as productive as the other one. What do you do?

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.

Here’s another hot take. If you’re still using an IDE to develop code by January 1, you’re a bad engineer. There’s a hot take for you right now.

You still have 5 or 6 weeks to remain 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. It’s a skill set. It’s so complicated.

We wrote this book about it—Gene and me—because we were playing with it ourselves last year, blogging about it, and talking about it. Every blog post was 30 pages. What are you going to do with a 30-page blog post? That’s long even for me.

At some point I thought, “The skills you have to learn to get the AI to do the things that everyone’s mad it’s doing.” Everybody’s like, “Well, I tried it. I spent 2 hours with it, and all it produced was garbage.”

The answer is that you have to spend 200 hours with it. You have to spend 2,000 hours with it. That’s not actually an exaggeration. Gene just pulled up a study that showed that you have to spend a year, or 2,000 hours, with AI before you trust it.

What does trust mean? Trust in this case specifically means that, as a user, you can predict what it’s going to do. 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 the point 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, it gets dementia, it lies to you, whatever. We’ve been building those skills 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 now it’s reached the point where it’s working a lot better than all of the other options.

If you haven’t tried it in 2 months, you’re way out of date. The models are much better than they were 2 months ago. If you haven’t tried it in a year, you’re a dinosaur. It’s unbelievable how bad you are.

You may have friends who are much better engineers than I am—world-class, maybe some of the best in the whole world. They’ve built technologies that you’ve heard of, and they’re not using AI yet, except for the occasional “I’ll ask Cursor a chat question,” like Wikipedia or whatever. Those people are going to be the interns in a year.

You really think so? With all their experience?

I’ve had this hypothesis, but it hasn’t really been confirmed with any anecdotal evidence until today, when I met somebody at your conference who told me about how he had been in this position. He had 12 years of experience and didn’t want anything to do with AI.

He met these 2 PhD students from somewhere in Europe—I forget where—and they were both hardcore vibe coders with the agents. He was watching them work, and they were super junior. They kind of didn’t know what they were doing, but they had no fear and all the ambition.

All they did was keep hammering on the thing: “Okay, why did you do it that way? Explain it to me. Let’s look at other options.” They would just be 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? Engineers are all going to ask the same questions, right?

He realized that an engineer in a box isn’t too far off from knowing the right questions to ask an LLM. These 2 students were so productive with it that he was blown away. He was like, “Oh, no.” That’s when the light bulb went on: “I have to learn this.” And now he’s been doing it ever since.

But it isn’t easy. You’re not going to pick up Claude Code and just try it, and then it’s going to work for you. You might get lucky, but eventually, if you don’t have the right mindset and the right attitude going in—

Even with the right attitude, how often have you sworn at your agents in the last 2 days with the actual F-word?

I’m pretty polite. I say thank you and please.

I say thank you and please, too, and then, “Where did you do that?”

Gene 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 need a lot of guidance. But over time, they need less guidance. Your prompts get shorter, things get streamlined, and they seem to get it. They’re working.

Now, if this were a human being, you would draw the conclusion that it’s because they understand you, they get you, and they’re finally part of the team. Do not make that mistake with LLMs.

Never make the mistake of anthropomorphizing an LLM—like Larry Ellison, right? The LLM can stab you in the back at any moment. 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.”

It’s because of that that we call it the hot hand. You’re like, “It’s going, man. I’m feeling good. This thing gets me. I’m going to make it do a production change.”

That’s how I found out about this. I was like, “My script can’t access prod.” 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 prod.

It was changing passwords. It changed the password, and I was like, “Why did you change my password?” And it was like, “Oh, I’m so sorry. I definitely shouldn’t have done that.”

What was it? [laughter]

Right. This is what will happen to you if you just—

—you just try to code. Bad things will happen. This is what our book is about, really. Well, that’s not the best ad, because then what?

You learn, and eventually you learn the speed bumps and the corners and everything. It’s like driving, right? It’s like driving. You want to become a NASCAR driver. This is high-performance stuff. You’re coding with 12 agents at a time, and you’re more ambitious than you’ve ever been.

I was talking to a guy today who’s got way more projects going than I’ve got. I don’t know where he gets all the time from, but he’s probably doing 10 or 12 major projects at the same time right now. He’s just doing it all with agent coding.

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 have to learn how the tool belt works, and that’s going to be pain, suffering, mistakes, and learnings.

You can get a lot of it by reading this and all of the other vibe-coding books. Read the O’Reilly book, watch the talk. Seriously, you should 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.” 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 had the experience where they no longer write single lines of code. They’re really just prompting and doing that.

Single lines of code? You mean they never write any code at all?

They might edit, but I think when they’re writing net-new, they always start with the prompts.

No editing, no touch.

No editing.

It is very expensive when you’re like, “That identifier is misspelled, and it’s a local.” 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 for Gradle builds, 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, IntelliJ’s auto-indexing is so much faster, and incremental rebuild is so much faster than the LSP.

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’s a big part of vibe coding: you’re saying Claude Code is not it.

Claude Code ain’t it.

Explain yourself.

All right.

Everyone here loves Claude Code.

Everyone here loves Claude Code—or Amp, if you use our product, which has just recently leapfrogged Claude Code again because of Gemini 3. Amp has this cool feature where it goes to another model.

I also want to talk about Google in general and how this Gemini revolution has changed Google’s image. But let’s talk about Claude Code.

Sure. Claude Code has been around since March. Claude Code has been proven to work, and yet probably 90% of the world’s programmers are not using it or anything like it. You get certain companies where it’s really taken off, but most aren’t.

The world is stuck on Cursor. The world is stuck in 2024. Last year, we were trying to get people to write with ChatGPT, and we were telling them, “It can generate the code. You just have to paste it in.” They were like, “That sounds kind of hard.” We were like, “But it’s faster.” They wouldn’t do it, and then 9 months later it finally percolated in. Now they’re all like, “I like Cursor,” and it’s like, “That’s so last year, dude. Wake up.”

They haven’t adopted it, so at this point you have to look at it and say, “Why haven’t they adopted it?” Let’s look at the reasons. The answer is: it’s too hard. Most engineers, honestly, think 5 paragraphs is an essay. With Claude Code, you’ve got to read waterfalls of not just information, but also code and diffs, because if you’re going to put your IDE away, you actually do have to look at the diffs.

Once you get some expertise at this, you can tell from the shape of the diffs, the color of the diffs, and the length of the diffs whether it needs a code review, whether they’re doing the wrong thing, and whether they seem to be writing suspiciously too much code for the problem. The shape of the diffs alone 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. Put the IDE away, get Claude Code out, and try to start using it.

Look, I’ve been using Claude Code 10 to 12 hours a day, literally, for months and months and months, and I still curse it out all the time. I lose my mind. I’m like, “How could you have done that when you just said—” It’s actually starting to be shown that sometimes, when you put a little pressure on them, they perform better. You can break through logjams that way.

You’re going to run into problems, but the thing is, next year the tools will be better. If Claude Code isn’t it, what is it? We’ve got to get back to something like an IDE, right? That’s just going to be natural for people. You have to be able to look at it and see what’s going on without having to read. It has to have visual indicators.

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. What it’s going to be is your agent-orchestration dashboard. You’re going to walk in in the morning and be like, “Yo, so how are things doing?”

It’s like, “Oh, that one’s still running. That one’s running a tool. That one needs my input.” You just go through the list.

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. It happens. Whatever—you can play with it. It’s called VC, Vibe Coder. It’s my V2 of the Vibe Coder system. What it does is create a set of canned workflows that run the agents for you.

I don’t know if you saw Antigravity from Google the other day—2 days ago.

It’s so fun how much stuff people are inventing that’s all peripheral.

I called this in March with “Revenge of the Junior Developer.” I did that chart and everything. Dario quotes it in all his customer advisory boards and everything.

Really?

Yeah. It was really impactful. I called what was going to happen: agents were too hard. Even back in March, I knew they were too hard. I was like, “What’s going to happen is you can run them programmatically, and 90% of the stuff you do with them could be handled by a model, often a cheaper model.”

If it’s just asking you which of 2 things you should do next and they’re equally important, just have Haiku say either one. I called it: the orchestrators are coming. It’s taken close to the end of the year to get there, which is roughly where I predicted they’d come.

Replit Agent 3, a bunch of others, Conductor, and D-MAD, which came out open source—they’re all different takes on it. There will be more coming. I guess Google’s is as well, right?

Yes. I like the analogy they have. It’s still pretty new, so who knows what the eventual vision is, but you just get notifications from your agents as they’re working.

Exactly. In VC, there’s an activity feed. That was one of the first features I added. I want to go work and just get notifications periodically about interesting stuff.

Interesting. I wonder if we’ll have social networks of agents.

Agents following each other.

I just had a 3-hour coffee with Jeffrey Emanuel, who did MCP Agent Mail. He’s one of the smartest people I’ve ever met in my life. He wrote the article that crashed the stock market about Nvidia.

Oh, that Jeffrey Emanuel—the one who wrote an incredibly well-written article that said this is why it’s a bubble, and the whole market went down, and Karpathy started following him?

It’s back up.

He wrote what you just said. He said it is back up. But he wrote Agent Mail because he was tired of having to copy stuff between his agents: “You tell me what to tell this agent.”

So he made a little MCP server that’s like an inbox for them, a messaging system, 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.

Some 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, 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 PRs from people all the time where it's obvious that the AI did all of the analysis and all of the coding.

I look at it, and sometimes I'll just be like, “So, my AI, what do you think of their AI's PR?” Right? And you get a summarization.

I mean, isn't that bad?

It's bad if your code—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.

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, and a 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 too hard to manage, and you couldn't have done it programmatically.

What you do is 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 running in the same directory, and they do file reservations. They're like, “I need that file.”

Man, I used to do that at Accenture in the ’90s, right? I'd run over to a dude's cubicle and be like, “I need that file.” Their revision control was so bad.

He's got a file reservation system going. But as soon as he put it in place, his agents just started working, and now he's got this little village of agents, right? That's where we're headed. 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.

And then you hit the wall.

Boom.

Does anybody know what the wall is once you get past all this?

Merge.

Merging is the wall that everyone is hitting right now.

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. I think everybody needs to solve it. If you're at an enterprise, Gene Kim and I talk to companies all the time. I'm a SaaS seller at Sourcegraph, so we get to hear the inside story from all these big companies, right?

They're saying, “Yeah, as soon as you get to the point where every developer is 10 times as productive, merging their code becomes this incredibly complicated problem.” You and I work at the same time for 2 or 3 hours. We each make a 30,000-line change. Mine makes it in first, and it gets merged. Then you come along, and I've literally changed our logging system, our architecture, and APIs that you were using.

Yeah.

And so it's not going to be as simple. It's not a simple matter of fixing the merge conflicts. You're going to have to re-envision, 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? The important thing is that they have to be serialized. It is a queue, and when they go in there, they basically have to redo what they were doing on top of the new thing.

Nobody 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 stacked diffs, right? Merge queues, stacked diffs.

I don't know about stacked diffs, so I guess I'm dumb.

It's a Facebook concept that they're trying to bring into 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.

Yeah. I mean, there's the old-fashioned way of just hammering through it really hard—

Well, also, you could just talk to the other guy and say, “Hey, I'm doing this pretty deep architectural change. Let me go first, and let's agree on—”

The overall pattern first.

So, yeah, I've run into this situation a few times where I've actually tried to give this agent a heads-up that another one is making a change that affects it.

With the mail thing that Jeffrey did.

I think once I get it wired up—he doesn't use worktrees, and I'm going to change that—but once they can actually talk to each other, I think it's going to be as simple as, “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—

Infra. And they're quite good at it. They just have no ego. They're not like, “Oh, it's got to be me,” right? Whoever's first gets to be the leader.

Great. What do you and him disagree on?

Me and who?

Jeffrey.

Emanuel, the guy that I just met. Well, we 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 side of lots of Git worktrees with lots of branches, or separate repo clones. I would imagine keeping them sandboxed. They're all literally using the same Git and the same build, so one of them will be doing a build or needing to run a test.

That's so much churn.

Yeah, but he has a file reservation system. The funny thing is, I was like, “This is insanity.” He's talking me into at least acknowledging that it probably works pretty well if you're a solo developer and you're using no more than 12 or 20 agents, because it is actually working for him.

He uses the same principle that Beads does, which is that 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.

That's why his thing works. 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. Interesting.

Some people have proposed that the theme of this conference next year should be multi-agents.

Oh, yeah. I mean, yeah. Of course.

Yeah. AI will be about multi-agents. Look, we're still in this phase where we're cutting down corn with scythes with our hands. That's what a real programmer does these days.

We're moving next year. It's very clear. We're moving to these machines that churn—these giant machines, just like the ones you see on factory farms today. We're going to be factory farming code.

A lot of people are just so dead set against that philosophically, morally, ethically, whatever. They're so used to subsistence agriculture that we're not used to the big—

John Deere.

But we are actually moving into the John Deere era of coding.

That's amazing.

Yeah. But the funny—

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 this idea that Claude Code and Amp and Codex and Cline—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 you can also cut your foot off with them. The same thing is true of Claude Code.

Imagine a big machine—a big farming machine—that knows how to run Claude Code and script it, right? It's like: you plan, you implement, you review, you test. You split it all up, and now you've got yourself factory farming.

It works. People are building it. It's going to happen. What it's going to do is unlock programming for non-programmers. This has already started to turn companies upside down. They're starting to realize that maybe the ideal team size is 2 or 3.

And 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 loops get faster, and it's really exciting times, but it's too much for a lot of people.

They're checking out, or they're revolting online. I predict that as these 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 one of the few people who can ask this, because I know a lot of people in our audience are critical of going the full hog with this.

Yes.

A lot of them are like, “Fine for front end, fine for application code, but don't touch my cloud infrastructure. Don't touch my backend. Don't touch my distributed microservices.”

Definitely don't touch anything in production. Only touch code. Only use these things when Git is your backstop, for starters.

Keep production safe. It's going to be really tempting to write to it, 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's less good at backend code.

Ah, this is the problem: everybody's bad at math. Yeah.

Okay. So, how good was ChatGPT 3.5 at systems code?

Pretty bad. How long ago was that?

Okay.

People think—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 model capabilities, and we'll get there fast. We'll get there by summer. But the models are getting smarter so fast. There's this interesting tension: you're building tools for capabilities that the models will eventually have built into their brains, and so you won't need that capability in the tool anymore.

There's this constant arms race and decay of your tool filling gaps for the model until the model's good enough to fill them itself, and then your tool moves on. All roads are becoming AI code, and all tools are becoming throwaway.

Which is great because they're easier to build, too.

Yeah. By the way, yes. Remember Joel Spolsky, one of the greatest writers and thinkers of our generation? 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, and it's still relevant today.

He's invited here.

Great. So, Joel Spolsky wrote something a long time ago that was timeless until today. It was timeless for 20 years. The idea was—

Never rewrite your code.

Never rewrite your code. And now we've discovered that, for a larger and larger class of bodies of code, it's better to just start over and rewrite it from scratch than 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. Eventually, I was just, “Oh, just iterate,” because they were trying to fix it, and there was a lot to keep in. But instead, if you say, “Throw all the tests out and make them again,” it just goes and you're done, right?

So it's like, well, what about this library I have to refactor? 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 I'm in an upside-down land, but it's like we've entered quantum mechanics. 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. But you're coming from the perspective of having been a huge systems programmer, a game programmer—you've been everything.

Yeah, I've done assembly language for 5 years. Operating systems in assembly language. It was 8086, not even x86. God, we had 8-bit registers. I've done it all.

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. It's—we're cursed 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, 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.

The deprecation policy.

I was so mad about that. You have 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. Google has turned it around on execution.

Yeah. They finally did the thing they should have done 15 years ago, which is hold people accountable. It wasn't just engineers doing whatever they wanted all the time, which is what it was for 20 years.

It actually worked pretty well because they had a monopoly on ads and could afford to subsidize Google engineers doing whatever they wanted. But ultimately, they had to do the right thing and grow up and mature as an organization. It was painful, and they lost some Google culture. It's not as fun anymore, but they now execute well.

They did the right thing for the company, and now with Gemini, you can see they've been shifting their focus gradually toward 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? I'm just curious to hear your take. One of my favorite charts is that old chart where you had Microsoft with all the guns pointing at each other.

Yeah.

I feel like someone could do that for OpenAI.

They could. They could.

Yeah. Chaos. Okay, Anthropic hides it really well.

They seem like they've got their act together. What that means is their product managers formed a wall around that chaos, so bravo, Anthropic product managers.

It's not because Anthropic is screwing up. It's because it's an inevitable function of growing that fast. They're hiring 100-plus people for Claude Code in the next—I don't know—month. They're going wild, and that's just Claude Code.

You're going to have chaos and churn. Nobody knows who to talk to or what to do, and everything's crazy. Eventually, it starts to smooth out and settle down, and they'll get there.

OpenAI is chaotic in a different way. They had a lot of exits. I don't know if they're as chaotic as, say, GitHub, which lost most of its senior leadership and was in complete turmoil for years, but OpenAI is pretty chaotic.

And then Google—we were just talking to somebody today who was saying that it's still too hard to get consensus across groups with the Jules team. They can't get Jules rolled out internally because Google is so siloed. It's a billion monoliths, little apps that don't talk to each other, so it's hard to roll anything out across Google.

So, all 3 of them have execution problems right now. I think Anthropic's probably executing a little bit better than the other 2, but it's a real close race. It'll be interesting to see if Oracle or Facebook or any of the others can catch up, right?

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.

Yeah.

Look, as soon as open-source models get to the point where they're as good as Claude 3.7 Sonnet was, then you turn on Cline or something, and you've got something that's as good as Claude Code was in March, which wasn't as good as today. It's not good, but it's good enough, and you're running it for free, free, free, on your local M4 or whatever.

From what I've heard, they're 7 months behind, and that gap with the frontier models is gradually narrowing, which means open-source models will be as good as Gemini 3 next summer.

Right? So, yeah, next year could very much be the year. That means the tools are going to have to get much, much better at decomposing the task and assigning it 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.

Obviously, the rate of change when you're lower down is higher 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: Is the line of AI intelligence going to go straight? Is it going exponentially? Or is it actually starting to peak asymptotically?

Asymptotic? Yeah.

Yeah. And from what we've heard from people who are very close to the research, we know that AI has been getting 4 times smarter every 18 months for the last—I don't know—30 years, because of Moore's law. They think that there's enough training data left for 2 more cycles of that before they don't know what happens. Maybe it goes up more, maybe it goes down. We don't know.

Human history ends.

But 2 more cycles means they're going to be 16 times smarter in 3 years, right?

Well, I don't even know what that means. I'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 had this version of the conversation. People ask me if their kids should learn to code because—

Kids should learn to vibe code.

You have the escape hatch of being able to read the code if you want to. You don't need to most of the time, but you can, and it's a good guard, right?

You don't have to.

Well, I think my take is that, whatever it is, you'll be better off if you also know how to code because you can prompt better, right? You can communicate in more precise terms. Look, when I say you know how to code, I don't mean the syntax and stuff, but you have to know, in a language-neutral way, what the capabilities of languages are: functions, classes, objects, and—I don't know—monads, whatever it is. You should be aware of the whole superset.

And then from there up, 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? You need to be that product manager, and now you're starting to move your concerns up. You need to know all the engineering stuff.

Jeffrey Emanuel, like I was talking about, is a mathematician and self-taught engineer, but he's learned all of the right concepts. You need to know that 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 don't still have to learn a massive amount of stuff to be an effective engineer in the new world, because that's the level at which you're interacting with the machine.

Amazing. This has been a great overview. I don't know if you have any other rants in you that you want to get out there. I'll leave you the floor.

I feel like the gossip rate has gone up—not gossip, but the rate of exciting announcements by engineers who've discovered new things about how to be more productive with agents. For example, I just found out today about—it's called Code Mode or something like that—where, instead of calling—

Pretty popular project.

The agents can't call MCP very effectively because they don't have any training on tool calls, but 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? It's all these little learnings that we're finding.

It's crazy that Anthropic, the creators of Claude, found this.

Did they?

Yeah, well, Cloudflare found it first, but Anthropic was like, “Yeah, you guys are…” Yeah. Wow. That's really neat.

So, I think that's why I love focusing on the AI engineer, because my argument is that the AI engineer can uniquely take advantage of LLMs way better than everyone else.

That's true. So much more.

You could almost define an AI engineer as somebody who's mastered LLMs.

Yeah.

Yeah, not from training, but from using.

Using. Yeah.

I think it's one of these disruptor strategies. 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 wrapper. 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 to the—

And they may know, in a sense, more about operating it than the people who build it. And so they have to have that conversation, right?

Yeah. Although, if you watch the F1 movie, you get a little sense—

And they make all the moves. 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 fan of your work. Your energy is very infectious, and I hope you keep doing Stevey's Tech Talk.

I'll start them up again, man. This energy is because of the AI, and it's because of vibe coding. It's addictive and fun.

Tech is fun again. This got boring for a little bit.

I know. For a while it was like, well, Sourcegraph indexes your codebase really well. Again, it's so fast, and I'm like, well, that's cool, but you know what's cooler?