2026: The Year the IDE Died

[upbeat electronic music] Hey, everybody.

I'm really happy to be here. I'm gonna be talking the first half. Co-author here, Gene Kim, is gonna talk second half. All right, looking forward to it. Cheers. All right, today I'm gonna...

Boy, we're gonna talk real fast. This time's gonna go down fast. Uh, I'm gonna 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 gonna, we're gonna fix that right now. All right, so here's what it's looked like. I'm gonna tell you right 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, and I'm gonna talk about why in this talk.

I'm gonna talk about what you can do about it and 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 wanna share with you is next year will be the year from 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, you, you're very precise, right?

We've been doing this for centuries, and we're not gonna stop this year.

One thing I hear people say is, "Well, 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 gonna take us a little time to harness it, but it's strictly an engineering problem at this point.

All code within a year, 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 ten 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 w- 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. "No, cheap," That's word for word, right? That's what they say. [laughing]

All right. Uh, 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 gonna look like?"

And it actually does kinda 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 tail lights and building command line interfaces anymore, all right? 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 this huge muscular ant that's just gonna 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 gitignore file still there?"

I've also gone to the expensive model, right? Everything that you say goes to the expensive model. So what's gonna happen? Whoa, what happened? Oh, gosh.

My slides are all messed up now. Can you guys see them?

No.

Oh, all right. This always happens to me, man. There's something, something going on. All right, 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, 'cause 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 gonna give him a bigger tank. One million tokens." He's still gonna run out- Oxygen. Like, you don't... Right, y- you should send a product manager diver down first. [laughs]

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 s- 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 gonna be built in the future, and it's gonna be built with lots and lots of agents, not just one agent.

All right, until then... I think we're out of time. So until then, learn Claude Code, give up your IDE. Swyx 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- [laughs]

... you're a bad engineer. [laughs] There's your hot take. [laughs] All right, folks. [applause]

All right, cheers. Well, that, that was actually my talk. Um, [clears throat] 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 org right here. This guy's not an outlier, okay? The backlash is very real against this, yeah?

And this is gonna be a problem that I'm not gonna sh- I'm not gonna 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 gonna 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. [applause]

Yeah. Thank you, Steve.

All right, buddy. You can do it.

Yeah, and by the way, um, I have... Uh, let me start off by introducing myself, and then I wanna share a little bit about, like, what it's been working like, uh, what it'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 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 want to understand, how did those amazing organizations make their good to great transformation so we can understand how to, how to 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 tests 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 of how in 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 must henceforth 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 Kronfeld says, uh, said number seven is obviously a joke because Bezos doesn't care whether you have a good day or not. And, uh, this is 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 'em was this, uh, love of AI and this sense that AI was gonna 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, you know, 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 gonna, 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 worry," [laughs] you know, uh, uh, it's happening again. This time it might be called NoDev, right? Not so funny now, right? [laughs] [laughs]

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 you 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 it 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, uh, I wrote a book called The Phoenix Project where it was all about the catastrophic deployment. Would you believe, uh, that it wa- 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. We, it was a cross-population study that spanned 36,000 respondents, uh, from tw- 2013 to 2019.

And what we found, uh, this was Dr. Nicole Forsgren and Jez 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 times 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 commonplace these days. In fact, if you want to have great reliability profiles, if you want to have short meantime to repair, you have to do smaller deployments more frequently.

And I think, uh, we're now seeing these kind of case studies 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 those of you who don't understand that, that's like sort of, uh, uh, typing in an IDE 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, love until, uh, Dario Amodei, 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 a code. And he said it's on 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? I just thought that was just a beautiful way to evoke, uh, how important, uh, vibe coding is.

Uh, this is Dr. Eric Meyer. Um, he's probably considered one of the greatest programming language designers of all time. Uh, he was part of Visual Basic, C Sharp, 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 when, uh, when 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

just seemed so strange, right? Um, you know, and so he's maxing out not just over, 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, let's think about like five hundred to a thousand dollars 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, uh, 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, FAFO, right? Uh, the most obvious one is F for faster, right? Now, 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 Claude Code team that I just loved was, uh, I think it was Katherine. 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 thirty 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 co-- uh, task. 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?

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 that 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 two or three 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 a- about Swyx is that, uh, he has a shared love of creating option value. Uh, he told us last night that the 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 is, gives us confidence that, you know, this is not just, uh, this is a very powerful tool. Um, uh, here's the quote from Andy Glover that, uh, Steve Yegge said is that, you know, as, um, for people who have this aha moment and are, and are in a position, uh, you know, I think the instinct

is how do we elevate everyone's productivity to be as productive a-as you are now being, um, you know, that 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 into this conference called the Enterprise Technology Leadership Summit for, uh, eleven years now.

And Swyx, we had, uh, the honor of having Swyx 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 in- their evolving experiment to elevate developer productivity across three thousand developers.

Um, and this is at, uh, booking.com, the world's largest travel agency. And, uh, they're finding that they're getting double-digit increase in productivity, right? Uh, merges 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 a 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 one point five billion dollar 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 s- 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, 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 gonna 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. Topabrata Pal. Uh, he helped drive the DevOps movement at Capital One, um, and he's 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 Log4j, 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 asks, like, "Can, can we build it?" His team would say, "It would take about five months, right?

And we'd hire... need to hire a, a 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, 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 production?"

And all the senior engineers are like, "Not me." So enter, uh, Swathi, the most junior engineer on the team, uh, who was helping maintain this application and probably out-learning, you know, everybody in the organization.

Uh, and int- interestingly, uh, he is 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 Roulser. He's senior director of engineering at Cisco Security, and he convinces 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. [laughs] Right? And so, um, you know, uh, 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 wanna do? And so we're gonna go in and study that.

And I just... I... my prediction is that we're gonna 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 fingerspitzengefühl, 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 o- every person 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 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 u- practice, right, so they get very, very good at it, so they can use every one of these amazing technologies to a- 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, uh, six weeks ago. And what was amazing to me was in the three hours, we had 100% completion rate.

Everyone built something. You know, they built a data visualization tool. In fact, uh, one person, uh, built a- an iOS app, and another person actually got it into the review queue in the Apple iOS App Store, [laughs] 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's helped him automate the process of getting checked into Southwest Airlines until the bot detection tools cut him off.

But look at, 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 wanna 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 wr- 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." [laughs]

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, [laughs] right? So this is maybe happening in your organizations. Um, "Our code velocity is so high, uh, we've all concluded that we can only have one engineer per repo," right, because of merge conflicts, right?

This is... We haven't figured out the coordination cost m- uh, mechanism yet. And so, like, all of these, uh, were some of the lessons that went into the Vibe Coding book.

Thank you s- 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, basically, uh, all the links that, uh, are in this presentation, just send an email to [REDACTED:email_address], 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're around all week.

Thanks, all. [applause] [upbeat music]