2026: The Year The IDE Died — Steve Yegge & Gene Kim, Authors, Vibe Coding

Hey everybody, um, really happy to be here. I'm going to be talking the first half, co-author here at Gene Kim is going to talk the second half. Allright, looking forward to it. Cheers. Allright, today I'm going to— boy, we're going to talk real fast, the time's going to go down fast.

Uh, I'm going to talk to you about what tools look like next year. Last year I was talking to you all about chat, and everybody ignored me, and now everybody's using chat this year, and it's like, eh, we're going to— we're going to fix that.

Right now. Allright, so here's what it's looked like. I'm going to tell youright now, everyone's in love with Claude Code. There's probably 40 competitors out there. Claude Code ain't it. Completions wasn't it. I love Claude Code. I use it 14 hours a day.

I mean, come on. But it ain't it. Developers aren't adopting it. I'm going to talk about why in this talk. I'm going to talk about what you can do about it, and then what— what to look forward to.

But the reason is they're too hard, okay? Uh, cognitive overhead, uh, they lie cheat and steal. Gene and I talk a lot about this in our book, all the different ways that they can lie cheat and steal, and, uh, most devs just don't like this.

I have come to understand that Claude Code is very much like a drill or a saw, an electric one,right? How much damage can you do as an untrained person with a drill,right? Or a saw, yeah? How much damage can you do as an untrained engineer with Claude Code?

It's real similar. Yeah, you can cut your foot off.

But you can also be really, really skilled with it and do really precision work,right? Like a craftsman. The problem is software is infinitely large. Our ambition is infinitely large. And so the analogy that I want to share with you is next year will be the year for moving from saws and drills to CNC machines.

A CNC machine, you strap a drill on and you give it coordinates and it moves it around and you're very precise,right? We've been doing this for centuries and we're not going to stop this year.

One thing I hear people say is, "Whoa, the models are plateaued." This is real common. Your engineers are probably saying this, okay? Even if they plateaued, we have still discovered steam and electricity, and it's going to take us a little time to harness it, but it's strictly an engineering problem at this point.

All code within a year, a year and a half, will be written by giant grinding machines overseen by engineers who no longer actually look at the code directly anymore. Weird new world. That is where we are going. Oh my gosh.

Yep, this— this slide. So Gene and I talked to Andrew Glover, who, I don't know, is he here? From OpenAI. And he said that, uh, they have this incredible dichotomy unfolding at OpenAI where, you know, some percentage of their engineers are using Codex, and then some other percentage, a larger percentage, are not using Codex.

And the difference in productivity is so staggering that they're having now alarms going off at performance review time. Because how do you compare these two— these two engineers who are the same level, same title, same everything, and one of them is 10 times as productive as the other one by any measure?

And the answer is they're freaking out and they may have to fire 50% of their engineers. And this is unfolding at other companies too. Who is refusing it? It's the senior and staff engineers. How many minutes are we at?

Eight minutes.

We're perfect. This is just like what happened to the Swiss mechanical watch industry over a couple of— well, it was built up for a couple of centuries and then quartz killed it, you know, within a couple of years.

And what happened was the craftsmen were doing the same thing our staff engineers are doing today.

That's word for word,right? That's what they say.

Allright. I— I didn't know where to put this slide. This is— this is Claude's view of what next year looks like. And I— I was just like, what do you think it's going to look like? And it actually does kind of look like this.

Most of the words will be spelled correctly in— in next year. But this is a lot prettier than Claude Code. Yeah? This is what it has to look like. Some form of a UI. Not an IDE. This is the new IDE, okay?

And people are building it. In fact, I think the company that's the furthest along in this is Replit, who just talked to you. I think it's amazing what they're doing. It's absolutely bravo,right? We should not be all chasing taillights and building command line interfaces anymore, allright?

And— and more importantly, Claude Code and all of its, you know, competitors, they're all doing it wrong because they're building the world's biggest ant. Okay, this is my— my buddy Brendan Hopper at Commonwealth Bank of Australia,right? He's like, nature builds ant swarms, and Claude Code built a huge muscular ant that's just going to bite you in half and take all your resources,right?

I mean, it's a serious problem,right? If I say, please analyze this code base, I, you know, go to the expensive model. If I say, is my Git ignore file still there? I've also gone to the expensive model,right? Everything that you say goes to the expensive model.

So what's going to happen? Whoa, what happened? Oh gosh. My slides are all messed up now. Can you guys see them?

No.

Oh, allright. This always happens to me, man. There's something going on. Allright, so I thought of a really cool analogy called the diver— the diver metaphor, which is your context window is like an oxygen tank, okay? This is why these things are fundamentally wrong.

Because you're sending a diver down into your code base underwater to swim around and take care of stuff for you. One diver. And we're like, we're going to give him a bigger tank, 1 million tokens. He's still going to run out of oxygen.

Like, you don't— you should send a product manager diver down first, hmm? And then a coding diver,right? And then a review diver, and a test diver, and a Git merge diver, et cetera. Right? Nobody's doing this. Everyone's building a bigger diver.

I don't know why my slides are all messed up. My— my talk is almost done. But, um, what we do is, as engineers, task decomposition, successive refinement, components, black boxes. This is how it's going to be built in the future, and it's going to be built with lots and lots of agents, not just one agent.

Allright, until then— I think we're out of time. So until then, learn Claude Code, give up your IDE. Swix told me he wants some hot takes, so I'll give you one. If you're using an IDE starting on, I'll give you till January 1st, you're a bad engineer.

There's your hot take. Allright, folks.

Allright, cheers. Well, that— that was actually my talk. Um, uh, learn coding agents and, oh yeah, then there's this guy. Speaking of bad engineers, so this is— this is Jordan Hubbard, uh, who, uh, who's at Nvidia, and he tweeted, or, uh, LinkedIn.

He did a really nice post on how to get the most out of agents. And this guy responded with this,right? This is everyone in your org. This is 60% of your orgright here. This guy's not an outlier, okay?

The backlash is very real against this. Yeah? And this is going to be a problem that I'm not going to— I'm not going to share with you. I don't have time to share how to fix it, but it's something you should be aware of.

And anyway, I'm going to turn it over to my co-author, Gene. We had a lot to talk about. He's got a lot to go. So let's turn it over to Gene.

Yeah. Thank you, Steve.

Allright, buddy.

Yeah. By the way, um, I have— let me start off by introducing myself, and then I want to share a little bit about, like, what it's been working like. Uh, what's been like working with Steve on the Vibe Coding book.

Uh, and so just a little bit about myself. I've had the privilege of studying high-performing technology organizations for 26 years, and that was a journey that started when I was a technical founder, uh, of a company called Tripwire.

I was there for, uh, 13 years. But our mission was really to understand these amazing high-performing technology organizations. They had the best project due date performance and development, the best operational reliability and stability, and also the best posture of compliance, uh, security and compliance.

So we wanted to understand how did those amazing organizations make their good-to-great transformations so we could understand how did— how did other organizations replicate those amazing outcomes. And so you can imagine in that 26-year journey, there are many surprises.

Among the biggest surprises was how it took me into the middle of the DevOps movement, which is so, uh, amazing because it reshaped technology organizations. You know, it changed how test and operations worked, information security. Um, and I thought that would be the most exciting adventure I'd be on in my career, until I met Steve Yegge in person.

And so I've admired his work for over 11 years. And so some of you may, uh, have read this memo of Jeff Bezos's most audacious memo about how in the early 2000s they transformed from a gigantic monolith that coupled 3,500 engineers together so none of them had independence of action.

And, uh, he talked about how all teams with hands forth communicate and coordinate only through APIs. No backdoors allowed,right? Uh, anyone who doesn't do this will be fired. Thank you and have a nice day. And the amazing person who chronicled it said, uh, said number seven is obviously a joke because Bezos doesn't care whether you have a good day or not.

And, uh, this was actually enforced by Amazon, uh, CIO then Rick Dalzel. And so it turns out this memo that I've been quoting for 11 years, uh, was written by Steve Yegge, uh, which was meant to be a private, uh, memo on Google Plus, which was made public, which landed him on the front page of the Wall Street Journal.

Um, and so I finally met him in, uh, June. And it turns out that we had many things in common. Uh, but one of them was this, uh, love of AI and this sense that AI was going to shape coding from underneath us.

And so one of our beliefs is that, uh, the AI will reshape technology organizations. You know, maybe even 100 times larger than what Agile, Cloud, CI/CD, and mobile did, you know, 10 years ago. Um, and that these technology breakthroughs not just reshape organizations, but they reshape the entire economy.

The entire economy rearranges itself to take advantages of these wild new, better ways of, uh, uh, producing things. And, and, uh, so over the last, uh, year and a half, we've had a chance to look at these case studies that I think give us a glimpse of what these, uh, what the shape of technology organizations look like.

And so I'm going to, uh, share with that what we've learned. But here's maybe a hint. So some of you may know the work of Adrian Cockcroft. He was a cloud architect at Netflix,right? He was what— who drove, uh, the, uh, entire Netflix infrastructure from a data center, uh, back in 2009 to running entirely in the AWS cloud.

And so he wrote, uh, some months ago in 2011, some people got very upset in, uh, infrastructure and operations because they called it NoOps,right? And everyone laughed back then, but he said, "Oh, don't, you know, uh, uh, it's happening again.

This time it might be called NoDev,"right? Not so funny now,right? And so it's— it's interesting,right? Because we heard this amazing presentation from Zapier about, like, how support ships. And it turns out designers are shipping. UX is shipping,right? Anyone who's been frustrated by developers, uh, who, you know, say get in line and you have to wait quarters or years or maybe never,right, are now suddenly in a position where you can actually Vibe Code your own features into production,right?

And that reshapes technology organizations and reshapes, you know, potentially the entire economy. And so, uh, uh, Steve and I, we've had the privilege of watching what happens, you know, when we change, uh, you know, the way we, uh, deploy,right?

It wasn't so long ago. And 10 years ago, uh, I wrote a book called The Phoenix Project where it was all about the catastrophic deployment. Would you believe, uh, that it was, you know, 10 years ago, 15 years ago, most organizations shipped once a year,right?

And so I got to work on a project called the State of DevOps Research. It was a cross-population study that spanned 36,000 respondents, uh, from 2013 to 2019. And what we found, uh, this was Dr. Nicole Forsgren and Jess Humble.

Um, and what we found was that these high performers ship multiple times a day,right? They can ship in one hour or less. And, you know, uh, back in 2009, people thought, "Oh my gosh, multiple deployments per day,right? That's reckless and irresponsible, maybe even immoral,right?

What sort of maniac would deploy multiple times a day,right?" And yet it's very complex these days. In fact, if you want to have great reliability profiles, you want to have short meantime to pair, you have to do smaller deployments more frequently.

And I think, uh, we're now seeing these kind of case studies that show that this better way of coding,right, where you don't type in code by hand, might be, you know, just a vastly better way, uh, to create value.

And so our definition of Vibe Coding that we put into the, uh, Vibe Coding book was that it's basically anything where you don't type in code by hand. And so for some of you who don't understand that, that's like sort of, uh, uh, typing an ID hunched over,right?

And you're actually moving your fingers,right? That's sort of like how some people go into a dark room to develop photographs,right? Believe it or not, some people still do that. Um, and, and what I— that's a great definition that we, uh, loved until, uh, Dr.

Amode, uh, uh, CEO and co-founder of, um, Anthropic, he gave us an even better definition,right? Vibe Coding is really the iterative conversation, uh, that results in AI writing your code. And he said it's on the one hand a beautiful term because it evokes this different way of coding, but he said it's also somewhat misleading because it sounds jokey,right?

Uh, but he said, you know, at Anthropic, there's no other game in town,right? And I just thought that was just a beautiful way to evoke, you know, how important, uh, Vibe Coding is. Uh, this is Dr. Eric Meyer.

Um, you know, he's probably considered one of the greatest programming language designers of all time. Uh, he was part of Visual Basic, C#, Link, Haskell. He created the Hack programming language, uh, that migrated millions of lines of code at Meta, you know, within a year, uh, bringing static type checking to a bunch of PHP programmers.

And he said, "We are probably going to be the last generation of developers, uh, to write code by hand, so let's have fun doing it." Um, so one of the things that, uh, when, uh, Steve and I started working on the book last November was, uh, watching him spend hundreds of dollars a day on coding agents.

Uh, and it just seemed so strange,right? Um, you know, and so he's maxing out not just the, you know, the, uh, the monthly subscriptions,right, but he's actually, you know, uh, going way above and beyond that. And yet, uh, you know, things that we're hearing now is that as an engineer, part of my job is that I need to be spending as much on tokens per day as my salary,right?

So, you know, that's think about like $500 to $1,000 a day,right? Because this is the mechanical advantage, the cognitive advantage that these tools are giving us,right? And as an engineer,right, I'm going to challenge myself, you know, to get that kind of value, to deliver value to people who matter.

Um, and so in the book we talk about, you know, why people would do this,right? And the, uh, acronym we came up with is FAFO,right? Uh, the most obvious one is F for faster,right? You know, that's obviously true, but I think it's the most superficial and, um, part of why we do this.

Uh, because, uh, the second one is it lets us do more ambitious things,right? Uh, the impossible becomes possible. Uh, so that's one end of the spectrum. On the other end of the spectrum, you know, the, uh, the tedious and small tasks become free.

One of the things I, uh, the, uh, interview of the Cloud Code team that I just loved was, uh, I think it was Catherine, she said, um, uh, one of the things we've noticed is that, you know, when customer issues come up, uh, instead of putting them on a Jira backlog and, you know, arguing about it in the grooming sessions and so forth,right, we just fix it on the spot,right, and ship to production or whatever, um, you know, within 30 minutes,right?

And so yes, it gets recorded, but, you know, that whole sort of coordination cost, you know, just disappears,right? So again, the impossible becomes possible,right? And, uh, the annoying things just become free. Uh, the second A is, uh, um, you know, the ability to do things alone or more autonomously,right?

And so, um, you know, there's really two coordination costs that are being alleviated here. One is, you know, if you ever have to wait for a developer or a team of developers, you know, to do what you need to do,right, you have to communicate and coordinate and synchronize and prioritize and cajole and escalate, you know, do all sorts of things to get them to care about the problem just as much as you do,right?

And, you know, now, you know, with these, uh, amazing new miraculous technologies, you can do them by yourself,right? So that's one coordination, uh, tax. The other one is, like, even if you get someone to, uh, care about a problem as much as you, uh, they can't read your mind,right?

And what we're finding is that these LLMs are just amazing intermediation vehicles,right? Um, you know, just through an LLM, you can coordinate with, uh, other functional specialties,right, through a Markdown file,right? And that's not the end,right? But it's just this amazing way, uh, to have these high bandwidth coordination so that you can essentially read each other's minds, you know, because shared outcomes require shared goals and shared understanding.

The second F is fun,right? As Steve says, "Vibe Coding is addictive." This is so true. I mean, I cannot, uh, I think what I love about the book is that it's a story about two guys who both thought their best days of coding were behind them,right, and found that, you know, it's entirely the opposite.

Um, and I've had so much fun and, uh, you know, I'm having to force myself to go to sleep, uh, at night because otherwise I'd be up till 2:00 or 3:00 in the morning every night. Uh, and, you know, so it's not all great, but it certainly beats being boring or tedious or, you know, horrible.

And then optionality. You know, one of the things that, uh, I love, uh, about Swix is that, uh, he has a shared love of creating option value. Uh, he told us last night that, uh, option value is also important for poker players,right?

Because you never want to paint yourself in a corner. So option value is, um, one of the biggest creators of economic value,right? Modularity, the reason why it's so powerful is because it creates option value. Uh, and so just the fact that you can have so many more swings at bat.

You can do so many more parallel experiments,right? This is what, uh, Vibe Coding allows. So this gives us confidence that, you know, this is not just, uh, this is a very powerful tool. Um, uh, here's a quote from Andy Glover that, uh, Steve Yegge said is that, you know, as, um, for people who have this aha moment and are in a position, uh, you know, I think the instinct is, "How do we elevate everyone's productivity to be as productive, uh, as, uh, you are now being, um, you know, since you've had your aha moment?"

So, uh, let me share with you maybe some of, um, our top kind of, uh, exciting case studies that kind of give us a hint of the future. So, uh, I've run this conference called the Enterprise Technology Leadership Summit for, uh, 11 years now.

And Swix, we had, uh, the honor of having Swix there talking about the rise of the AI engineer, just this amazing prognostication. Uh, this year we had a series of amazing, uh, case studies. One was, uh, Bruno Passos.

He spoke this year, uh, last year at this conference, and he presented on, uh, their evolving experiment to elevate developer productivity across 3,000 developers. Um, and this is at, uh, Booking.com, the world's largest travel agency. And, uh, they're finding that they're getting a double-digit increase in productivity,right?

Uh, mergers are going in quicker, peer review times are, uh, smaller, and, and so forth,right? And so that's just, we feel like that's an incomplete view of, uh, what people are achieving. Uh, this is Sri Balakrishnan. Uh, he was, uh, head of product and technology at, uh, Travelopia.

Uh, so they're a $1.5 billion a year, uh, travel company. And one of the things that, uh, he said is that, uh, you know, they were able to, uh, replace a legacy application, uh, in six weeks with a pair of, uh, with a very small team.

In fact, one of his, uh, conclusions is that before we would need a team of eight people to do something meaningful,right? Six developers, a UX person, and a product owner. And he said, "Maybe these days it might be two, a developer and, you know, a domain expert."

In other words, as Kent Beck said, a person with a problem and a person who can solve it,right? Uh, and maybe, maybe a pair of those teams,right? And so that's going to reshape, I think, you know, how they can go further and faster.

Uh, so again, maybe just a hint of what teams will look like in the future. Uh, this is the one that excites me most. This is Dr. Topa Brada Pal. Uh, he helped drive the DevOps movement at Capital One.

Um, and he is now at, uh, uh, Fidelity. And so, um, among other things, he owns an application, uh, that is the application you go to ask which applications, you know, the 25,000 applications there have log 4J,right? And, uh, it's his team.

And he's had this vision of what this application should look like. Uh, but every time he asked, like, "Can we build it?" his team would say, "It would take about five months,"right? And we'd hire, need to hire a, uh, front-end person.

And he got so frustrated that he spent five days just Vibe Coding it by himself,right? Uh, you know, directly accessing read-only the Neo4j, uh, database, um, and put it into production,right? And so I think we're seeing a world where, um, you know, leaders, even leaders with their own teams are frustrated saying, "Hey, I can do this, uh, can I do this better myself?"

Not better, just, "Can I prove that it can be done?" And, uh, by the way, what happened afterwards? Um, he was looking around, "Who can help me maintain my application in production?" And all the senior engineers like, "Not me."

So enter, uh, Swathi, the most junior engineer on the team, uh, who was helping maintain this application and probably outlearning, you know, everybody in the organization. Uh, and interestingly, uh, he's also getting more headcount because the number of consumers of this application just increased by tenfold,right?

So who saw that coming,right? Um, so, uh, here's John Routher. He's senior director of engineering at Cisco Security. And he convinced his SVP to, um, require 100 of the top leaders inside of Cisco Security to Vibe Code one feature into production in a quarter.

That ended last month,right? And so, um, you know, we're actually getting a chance to be able to survey those people,right? Who finished? Uh, you know, uh, how many completed, didn't complete, partially completed, et cetera. And of those who completed,right, what was, what aha moment did they have?

Uh, as a leader, what's the magnitude and direction of what they want to do? And so we're going to go in and study that. And I just, my prediction is that we're going to see parts of that organization get reshaped as leaders realize kind of what's possible, everything from strategy to processes and so forth.

And so let me just share with you one, um, you know, thing that really excites me, which is, uh, I got a chance to, uh, get back into the state of DevOps research, the DORA study with, uh, um, the Google Cloud team.

And one of the things that didn't make it into the report that I just found really exciting was around this. It was like, "What how much do people trust AI?" And we're using a very strange definition of trust, which is, "To what degree can I predict how the other party will act and react?"

Right? Because the more you trust the other party,right, you can give them bigger requests, you can use fewer words, you have less need for feedback,right? It's the whole notion of finger spitting to fuel,right? Like, you know, how many of the 10,000 hours that it requires to be good at anything have you used to get good at AI?

And one of the stunning findings was that it's this line. So on the X axis is how long have you been using AI tools? Y is how much do you trust it,right? And the longer you use AI,right, the more you trust it,right?

So every person who says, "I tried it and it's terrible at coding,"right, on what basis did they make that conclusion after maybe using it for an hour or two? And what this shows us is that, uh, you know, it requires practice,right?

And, you know, this is probably a teachable skill. Um, so length of time on the X axis is a very incomplete expression,right? It's like frequency and intensity and how many hours, but it's a, it's a, there's a signal there.

So it just shows that, uh, you know, part of your job is to help other people have the aha moment and then help them practice,right, so they get very, very good at it, so they can use every one of these amazing technologies to achieve their goals.

So, uh, I'll leave you with one last kind of vision. Steve and I, we did a Vibe Coding workshop for leaders, um, uh, back six weeks ago. And what was amazing to me was in the three hours, we had a 100% completion rate.

Everyone built something. You know, they built a data visualization tool. In fact, uh, one person, uh, built an iOS app. Another person actually got it into the review queue in the Apple iOS app store,right, which is, which is absolutely astonishing.

Uh, and here's a guy named Roger Safner. He said, "I used to be a C# MVP way back in the day. I haven't coded in 15 years." Uh, and he's showing off an app that helped him automate the process of getting checked in to Southwest Airlines until the bot detection tools cut him off.

But look, look at the expression on his face. And so I think, uh, what we're seeing is like what happens when support ships,right? And support codes and ships, when leaders code and ship, there's no doubt in my mind that this will reshape, uh, technology organizations.

If you're one of those, Steve and I want to talk to you,right? Because you are on the frontier of something really, really important. I'll share with you a couple quotes. Here's from a technology leader. "When I told my team that I wrote an app that, you know, an AI wrote 60,000 lines of code and I haven't looked at any of it, they all looked at me as if they wished I were dead."

Um, we've, uh, we've had these stupid problems in legacy applications that have been there for over a decade. We got a group of senior engineers together. We used AI to generate a fix and we submitted PR and the team accepted it,right?

Unlike the time when they said it was AI generated and they rejected it as AI slop,right? So this is maybe happening in your organizations. Um, our code velocity is so high, uh, we've concluded that we can only have one engineer per repo,right?

Because of merge conflicts,right? We haven't figured out the coordination cost mechanism yet. And so like all of these were some of the lessons that went into the Vibe Coding book. Thank you, uh, for everyone who were at the signing yesterday.

And, uh, if you're interested in any of the talks we referenced and excerpts of our book and, uh, you know, basically, uh, all the links that, uh, are in this presentation, just send an email to realgenekim@singersloths.com, subject line Vibe, and you'll get an automated response in a minute or two.

So with that, Steve and I, thank you for your time and we were around all week. Thanks, all.