Host Intro (Gene Kim)

What can I say about my friend Steve Yegge that you don't know already? He spent 20 years at Amazon and Google. He helped lead one of the first two-pizza teams to reduce customer friction of contact at the behest of Jeff Bezos. He helped create Grok and Code Search, one of the most beloved dev tools at Google.

And he co-authored the Vibe Coding book with me, and I found him to be as hilarious, irreverent, brilliant, and generous as one would hope him to be. And one of the big surprises in writing the Vibe Coding book — and I think the reason why I love the book so much — is that the book is really about two guys who both thought their best days of coding were behind them, but in actuality, it's actually ahead of them. Here's Steve Yegge.

Steve Yegge

Hey, everyone. I'm so glad to be back. I'm Steve.

Thank you. Thank you.

I don't have a huge long talk today, just a couple of observations for you.

We have a clicker problem today. First, I want to thank Gene for everything. I want to thank Gene for adopting me for ETLS. What a wonderful community, and for dragging a book out of me, which was pretty amazing. Gene and I figured a lot of this stuff out before anyone else did, and he introduced me to a bunch of you wonderful people, and I've had lasting relationships from it. I'm just so happy to have been — I don't know — part of Gene's experience. It's just been amazing. And he's just a wonderful human being. And when he said it was the time of his life writing that book, it was the time of my life at the time, too. It's really picking up.

One thing that I didn't realize when I wrote this slide is that Gene also picked my favorite game in the entire world for competition tonight. Is there anyone in this room who thinks that they can beat me at Smash Ultimate? Raise your hand. One, two. Okay, you're game on.

So — wow, we're at this slide already? Previous slide.

I just want to make sure. I started programming in 1986, which was 40 years ago. When Gene says you're legendary, it actually means old. I'm sure some of you folks have me beat here, but boy, a lot has happened in 40 years. All right, next slide.

I'm going to tell you folks a really interesting observation. Credit 100% to my friend at Google — he shared with me Google's AI adoption footprint, their sort of curve of the early adopters, the agentic coders, the token maxers versus the skeptics and the ones that aren't using it at all. And interestingly enough, Google's adoption footprint right now, as far as I can tell, is identical to John Deere's from what Amy told me about. So congratulations to John Deere for being as good as Google at this. Really.

Why? So, the industry's been in a hiring freeze for 18 months. Maybe Google's using Claude because that's the enemy, and so they don't know actually how good the models are. Gemini was never really that great, and so it didn't take off, and so the engineers aren't agentic coding there. And there's nobody coming into the company to tell them otherwise, because they're in a hiring freeze. There's nobody who will come in and go, "Whoa, this is John Deere level." Which is really good, by the way, because it actually is.

The great siloing is that all of the wisdom and the cross-pollination that happens between companies has stopped, and every company on Earth is operating in a big silo right now with blinders on, and they have no idea how they're doing relative to everyone else. And we know this. Gene and I talk to these companies all the time, and it's just amazing to see how far distributed they are along the spectrum — the continuum of adoption — from big companies that are doing barely anything at all to medium-sized companies where, well, amazing stuff is happening. Next slide.

So — oh yeah, I wanted to talk really briefly. What I'm going to tell you about today is the ninth box in this diagram. Uh-oh, it's getting cut off. But I think you all remember it. It came out with my Gas Town post on January 1st, and this alone was more viral than the Gas Town thing. Everyone was like, "Oh." It was — I don't know, man. It really threatened people because they could see where they were right on this thing. And there were eight boxes where the last one was: you're building your own orchestrator because you're trying to deal with so many agents, you need to corral them somehow.

So we know what the ninth box is now. Next slide. Tell you about it.

Oh, yeah. Do you guys — I don't know if you really want to hear about Gas Town. I don't think we have that much time. Gas Town was a really fun adventure. I built it in 17 days. It was the fourth orchestrator in a series — I threw the first three out. But still, it came together really, really, really fast. And a lot of it was because it was building on top of Beeeds. Who here uses Beeds? I'm just dying to know. Actually, yeah, a pretty good number.

If you use agentic coding — any agent, Codex, Gemini CLI, whatever, Amazon's one, Q Developer — they all often use Beeds, and they will all be better because of Beeds. It's a memory system, and the industry is building memory systems because that's kind of all we have since all of the thinking is being done by the frontier models. Next slide.

I did want to say Gas Town has been — I'm really pleased with how successful it's been. A bunch of people ignoring the first two rules of Gas Town: do not use Gas Town. People are going nuts with Gas Town. You should see the stuff people are doing with it at big companies. They find these really cool use cases where it's okay if they make mistakes, it's okay if they don't finish, whatever — because the company needed to do 18,000 things with humans, and now they only have to do the last 5% of it with humans.

Well, Tim Bradley here — my old buddy from Geoworks, there he is — he runs his house with Gas Town. I didn't have time last night to screenshot his LinkedIn because he just shared it, but he made Gas Town figure out all the connectors of all this tech in his house that he didn't know about because he bought the house. And it wired it up and got it all working for him. Crazy. Next slide.

All right. I want to tell you about what's next for Gas Town, because we just hit version 1.0 and we're just about to deprecate it. Am I Google or what? I learned a lot at Google.

Okay, so that was actually ad-libbed, by the way. The reason that we're deprecating it soon-ish — in a month or whatever — is when Gas City becomes GA. Because Gas City is a rewrite of Gas Town, to be sort of like an SDK, like Legos, like building blocks. Gas Town has a bunch of pieces to it. Agents have mail and identity and messaging and cost tracking and token tracking, and they have handoffs and seances and all of these 25 or 30 individual building blocks — you're going to want to put them together, and this is really the thesis of my talk today: you're going to want to put them together in your own shapes that don't look like Gas Town. Gas Town had its own sort of shape, the names of the roles and the funny costumes they were wearing. Well, what if you want your own funny costumes? Next slide.

I want to just see if we — yeah. So it's built on Beeds and Dolt. This is really important. There is only one group of people in this room who can look smug right now, and that's Nubank. Okay, first of all, anyone else here using Dolt? You can be smug too. You — smug. All right.

Everyone else, you've got to understand the situation we're in here. All work is about to start being done by agents. Agents make mistakes. Agents need a backstop. Gene and I have been telling people since we wrote our book: "Please do not use agents in production" — get a backstop, right? To go, "Oh, God, I got to rewind." Well, they're coming to production, and so you need the backstop. And the answer is you need a versioned database. Dolt and Datomic are both versioned databases. They do it differently. They do it very well. Either one of them is fine. And if you're using anything else — Postgres, Oracle, MySQL, whatever — with your snapshots, you're doing it wrong. You're doing it wrong because every step that an agent takes when it's monitoring your systems and making changes and updating database tables, all of it needs to be on an audit log for forensics, for troubleshooting, for recovery.

Go next slide, but please go look into Dolt. All right. Next slide.

Agent crews — or I don't know what they're going to be called. Maybe squads, maybe teams, maybe crews. They are little deployments of agents — say two or three of them, or maybe four or five — in a specific shape with specific names and specific identities, and they have prompting and sandboxes and all the stuff you set up, and they do a thing.

Like what? Because Gas Town is for building code. Now we're talking about using agents for actually running your business. So the thing that your little agent team might do could be anything. It could be an ETL or a data processing pipeline, a porting effort or refactoring, or it could be monitoring. Anything that requires an agent to basically process signals or data and make decisions and then have outputs is a mini orchestration team. It's a unit that gets deployed by an engineer, it's in prod, and it has to be governed and compliant and all that other stuff.

Gas City is built for this. And the Dolt and the stack that you get gives you all that auditing for every one of those teams. And they're going wild with it, and I'm excited about it.

I actually gave up Beeds and Gas Town because I want to go be the number one user of Gas City, because it's pushing us into a new space where we're going to be able to have dozens to hundreds to thousands — what they're calling fleets of agents — running your business for you. In my video game, which I'm working on — it's 30 years old, I've been working on it literally 30 years, a half million lines of code, a lot of legacy debt — I can go in and have agents that onboard players, do the tutorials for me, upload custom player artwork, handle all the ticket queues. Well, what happens when I have 50 of those and then I need to upgrade some of them or do a patch or something? There is a control plane up there that hasn't been built yet. Nobody knows what it looks like, and it's missing. And we're all going to get there this year.

Well, actually — next slide — we're actually not all going to get there this year because things are going really slow.

How many minutes do I have, Gene? Five? Two? We're at 15? Plenty of time. Okay.

So — Revenge of the Junior Developer. Anybody remember "Death of the Junior Developer"? That was kind of a downer, yeah. Turns out they didn't die. I was wrong about that.

It is really, really interesting what's going on, though. Some junior developers — most, maybe — are just saying, "Well, this is what the world is, I'm just going to learn it." And they just dive in and they figure it out. But Gene and I know a couple of companies. We were talking to two companies that were very similar late last year, where at one company, the seniors adopted AI and the juniors rejected it. The junior developers were not having it. They were like, "No." And at the other company, it was flip-flopped — the juniors adopted it and the seniors didn't.

And it was very interesting because the ones who rejected it rejected it for completely different reasons. Junior engineers rejected it at that one company because they believe the AI is good and they think it's going to take their job, and they're scared of it — so they're like, "I don't want to have anything to do with this." It was just kind of a panic response. The senior engineers are the opposite. They don't want to use AI because they don't believe it can do their job.

So you have two different trust vectors hitting each other in your org. And your principal engineers, as Annie Velis told me last time, cast a long shadow over your org. And so really, the whole industry is in a hump right now where we've got to get everybody up to this little spot in my drawing from last year. I predicted all this was going to happen, and it happened exactly on the schedule that I predicted, and it's just because all I did was believe Andrej Karpathy and Dario Amodei when they said that stuff's going to go up exponentially. And sure enough, it did. Next slide.

SaaS is lava. Okay, so we're going to finish with SaaS and the death of SaaS — or maybe not really.

About three weeks ago, I was convinced that SaaS is in real trouble, and I'm not as convinced anymore. But there are definitely two groups of people looking at it from completely different lenses. One group is looking at the top — they're looking at Datadog and Salesforce and all the big ones. "Nobody's going to rewrite Gmail," they say. So SaaS is fine. Okay, that's probably true.

And then if you look at the bottom, every single company we talk to — Gene and I were talking to a company, I probably can't say who it was, but it was a really lovely company. And a communications major who was four years out of school told Gene and me that, a couple of weeks after Gas Town came out, she picked up Gas Town and decided to re-implement some SaaS — domain-specific SaaS. Think legal, medical, farming, whatever — domain-specific niche SaaS that they're charging $30,000 a year for. And she's like, "Well, maybe I could just write this." And so she got it written, and now they're switching to it. Vibe-coded SaaS. It's happening. It's getting eaten up from the bottom.

Everybody wants to get rid of their crummy — a lot of it's not even SaaS, it's disks in a closet that they have a license for. They want to rewrite this, and they're going to rewrite this one way or another. They're rolling up their sleeves like, "We're doing it."

So, who's right? Is SaaS a mountain, a pyramid that's getting eaten up from the bottom?

Previous slide. I guess that isn't a very good slide for this.

I think what's going to happen — I think Reid Hoffman has a pretty good take on it, the LinkedIn guy. It's called "Notes from the SaaS Funeral," and it's a very balanced take, which is that SaaS, in addition — it's not just the software, it's the service. It's the concentration of expertise and scaling and people, and to keep a giant service like Datadog up that people don't want to have to — because anyone can build a replacement for some SaaS they're paying for. But maintaining it — do you really want to maintain it? You've got to come at it from the right perspective, which is: we're paying X million, let's convert that to salaries and then turn it into engineers who will write it and then maintain it for us.

So the thing that's missing from this analysis is — the poster child for dead SaaS is Zendesk. I apologize if anybody here is from Zendesk. Is anyone from Zendesk? Okay. The poster child — everyone says, "Well, Zendesk is going away," because it seems like it would be a really easy thing for an AI to handle ticket queues. But if you actually look at Chatwoot, which is the open source one, it has all the features of Zendesk. So how come they haven't switched already? And it's because, well, it's like I said — you've got to maintain it, or you've got to pay someone to maintain it.

I think Zendesk is totally fine, but SaaS is going to have to become operated by agents. And SaaS is going to have to become marketed to agents. In other words, the only people that are going to be using SaaS are agents. And so you need to make your SaaS super sexy to agents. You've got to change your SaaS so that agents look at it and go, "Whoa, I wouldn't want to re-implement that."

And it can be done, but you have to come at it from that perspective. And it's honestly back to the platform rant from 10 years ago: you need to turn your SaaS into a platform. SaaS to PaaS. You need to make all those underlying back-end systems that you're providing available to the agents to mix and match, so people can build their own dashboards and their own UIs for your system of record, and then do the whole system integration thing themselves. You need to enable that for them.

Okay, great. I think you all get that.

So, forward-looking companies — I just want to talk briefly about what I see and what I think you should do, and then I'll wrap.

I canceled my IntelliJ subscription three weeks ago, two weeks ago. So painful. And I was talking to a company and I shared this with them, and they laughed and laughed because they had just canceled their entire IntelliJ 1,000-seat license. And you can imagine how the engineers felt about that. Or can you? They were pissed. Come on — we're taking your IDE away, go use AI. They were mad. But actually, it was a really smart thing for them to do. They let a few people hold onto it who really needed it for whatever legit reason, but they are phasing it out.

And even Cursor has given up on the IDE, right? I mean, there's not much left in it.

Look, we're in a really weird spot right now. Really weird spot. That adoption curve — the Google, the John Deere that I told you about — that is everybody. Everybody has 5, 10, 15% of their engineers token maxing, 20% of the engineers not using AI at all, and everyone else is still stuck in Cursor, Copilot, and Chat. The state of the industry right now today is: we just enabled Copilot for everyone. That's what I hear from people. And that is code for: we are really bad at AI adoption at our company.

And it pains me deeply when people say it, because it means their engineers are getting terrible tools, and it means that they're not getting the learnings — the organizational learnings — because the first thing that happens is your engineers can lean in to learn this stuff, but then your business needs to catch up. I got told by a buddy in Australia that they actually managed to speed their engineers up by 5X, and guess what happened? The business couldn't handle the pace. And so the business is like, "We gotta do our campaigns, you gotta slow down." And so they said to the business people, "We're going to use AI together, and we're going to speed you up 5X so that you can keep up with the engineers." And you know what they said? "F**k you." They said, "Wait, let me get this straight — you're saying that you want me to do five days of work in one day? No, thank you."

And so this is a serious problem. When your business can't respond just because they have a pivot to make — I went through this at Grab. It takes time, it takes patience, it takes empathy. Lots of it. But it takes patience and persistence. You've got to get there.

And nobody knows how to do it, by the way, and you're all in silos and not talking to each other. But that's a really important observation for you all to take away today, because if the cross-pollination isn't happening in the industry because of the hiring freeze, you're the pollinators. We're the pollinators. The stuff that we share — take those learnings back to your company. We've got people who are just amazing, amazing speakers here from the military, from giant companies, and they're all telling you the same thing. Somebody here was just telling me it gives you leverage to go back to your company and nudge them and say, "Actually, Copilot really ain't it."

So be the pollinators. Next slide. I think we're almost done.

Yeah. So this is it. You gotta do your devs, you gotta do your non-devs, you gotta do your business owners, and you gotta get to the point where everyone's building these little agent orchestrators. Next slide.

What to do now? I went and said it. I'm just mad at them because they yelled at me for making fun of Copilot on Gerry Geiss's podcast. A bunch of VPs at Microsoft DM'd me and were bullying me because I made fun of Copilot. They said, "We're closing the gap." And I said, "You guys know that closing the gap means failing at taillight chasing, right?"

Don't get me started. All right. Well, you can do hackathons. You can do two-pizza teams. I know one company that's firing up 100 two-person teams. No joke. No joke. People are out there grabbing the bull by the horns. That's what you gotta do. You gotta just go all in. You gotta be like, "Okay, we understand there's risk. We're going to write those risks down, and we're going to do the experiments, and we're going to learn the learnings." Next slide.

Is that it? Are we done? Yay. Wait, didn't I have a final slide? All right. Well, so that's it for my slides. You can imagine one with our book on it or something.

What I would recommend, actually, is you should seriously consider getting me and Gene to come talk at your company. If any of you guys did the vibe coding workshop at ETLS, there's a company over here now that's doing them — and good for them. The whole industry needs this. Getting over that hump to where all the developers are actually using it, and all the non-developers are using agentic coding — this is going to be a 12 to 18-month very painful process: a lot of grieving, a lot of re-skilling, a lot of anger and angst. You're going to have to have the empathy and the leadership. This is a rough time that we're headed into.

So if it would help, I actually spend my time going to companies and telling them that it will be okay and telling them how it will be okay. And Gene and I have been doing this, and we're getting pretty good at it. So give us a ring. All right. Thanks, all.