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

Channel: aiDotEngineer

Published at: 2025-12-06

YouTube video id: 7Dtu2bilcFs

Source: https://www.youtube.com/watch?v=7Dtu2bilcFs

[Music]
[Music]
Hey everybody. Um really happy to be
here. I'm going to be talking the first
half. Co-author here, Gene Kim, is going
to talk second half.
All right, looking forward to it.
Cheers. All right, today I'm going to
Well, we're going to talk real fast.
This time is 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
we're going to we're going to fix that
right now. All right, so here's what
it's looked like. I'm going to 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. 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 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
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, "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 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. Yeah, this this
slide. So, Gene and I talked to Andrew
Glover, who I don't know if he's here,
from OpenAI, and he said that 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?
8 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. No!
That's word for word, right? That's what
they say.
All right. I don't 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 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 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, 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, cuz 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 Right, you should send a
product manager diver down first,
and then a coding diver, right? And then
a review diver, and a test diver, and a
Git merge diver, etc., right? Nobody's
doing this. Everyone's building a bigger
diver. I don't know why my slides are
all messed up. My 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.
All right, until then, I think we're out
of time, but 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,
you're a bad engineer.
There's your hot take. All right, folks.
All right, cheers. Well, that that is
actually my talk.
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 who's at
Nvidia, and he tweeted
LinkedIn, 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
going to be a problem I'm not going to
share 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.
>> buddy. Here you go.
Yeah, and 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 what's
been like working with Steve on the Vibe
Coding book. 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 13 years. But
our mission was really to understand
these amazing high-performing technology
organizations. They had the best project
delivery performance and development,
the best operational reliability and
stability, and also the best posture of
compliance security and compliance. So,
we wanted to understand how did those
amazing organizations make their good to
great transformation, so we could then
understand how did how did other
organizations replicate those amazing
outcomes. And so, you can imagine in
that 26-year journey, there were many
surprises. Among the biggest surprises
was how it took me into the middle of
the DevOps movement, which is so
amazing because it reshaped technology
organizations. You know, it changed how
test and operations worked, information
security.
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 have read this memo of Jeff Bezos's
most audacious memo about an early 2000s
they transformed from a gigantic
monolith that coupled 3,500 engineers
together, so none of them had
independence of action. And he talked
about how all teams would henceforth
communicate and coordinate only through
APIs. No back doors allowed, right?
Anyone who doesn't do this will be
fired. Thank you, and have a nice day.
And the amazing person who chronicled
says,
"The number seven is obviously a joke,
because Bezos doesn't care whether you
have a good day or not." And this was
actually enforced by Amazon CIO then,
Rick Dalzell. And so, it turns out this
memo that I've been quoting for 11 years
was written by Steve Yegge, which was
meant to be a private memo on Google
Plus, which was made public, which
landed him on the front page of The Wall
Street Journal.
And so, I finally met him in June. And
it turns out that we had many things in
common, but one of them was this love of
AI and this sense that AI was going to
shape coding from underneath us.
And so, one of our beliefs is that 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.
And that these technology breakthroughs
not just reshape organizations, but they
reshape the entire economy. The entire
economy rearranged itself to take
advantages of these new and wild new
better ways of
producing things. And then uh so over
the last uh year and a half we've had a
chance to look at these case studies
that give us a glimpse of what these
what the shape of technology
organizations look like. And so I'm
going to 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 entire Netflix infrastructure from a
data center 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 no-ops, right? And
everyone laughed back then but he said,
"Oh, don't
you know
uh it's happening again. This time it
might be called no devs, 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 then that
reshapes technology organizations and
reshapes, you know, potentially the
entire economy. And so 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 now 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 across population studies that
spanned 36,000 respondents from 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 1 hour or less.
And you know, 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 complex these days. In fact,
if you want to have great reliability
profiles, you want to have short mean
time to repair, you have to do small
deployments more frequently. And I think
uh we're now seeing these kind of case
studies that show that there's 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 the you who
don't understand that, that's like sort
of
uh typing in 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
thought was a great definition we uh
loved 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 your 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, you know, how
important uh vibe coding is.
Uh this is Dr. Eric Meijer. Um he's
probably considered one of the greatest
programming language designers of all
time. Uh he was part of Visual Basic,
C#, LINQ, 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 Steve
and I started working on the book last
November was 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, you know, the uh the monthly
subscriptions, right? But he's actually,
you know, 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 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 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 acronym we came up with FAFO,
right?
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 that I uh the
uh interview of the Cloud Code team that
I just loved was 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 with
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 are 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 amazing new miraculous
technologies, you can do them by
yourself. Right? So that's one
coordination
uh tax. The other one is I think 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 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 this 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 said, vibe coding is addictive.
This is so true. I mean, I cannot 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 you know, I'm
having to force myself to go to sleep 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 I love about Swyx is that he has a
shared love of creating option value. 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 it's
because it creates option value. Uh and
so just the fact that you can have so
many more swings at bat and do so many
more parallel experiments, right? This
is what 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 Steve Yegge said is that, you know,
as um for people who have this aha
moment they're in a position uh you
know, I think the instinct is how do we
elevate everyone's productivity to be as
productive as you are now being um you
know, since you've had your aha moment.
So uh let me share with you maybe some
of 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 Enterprise Technology
Leadership Summit for uh 11 years now
and Swyx we had uh the honor of having
Swyx there talking about the rise of the
AI engineer. This is amazing
prognostication. Uh this year we had a
series of amazing uh case studies. One
was uh Bruno Pasqualis. He spoke this
year uh last year at this conference and
he presented on uh their 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
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
Shri Balakrishnan. Uh he was head of
product and technology at Traveloka. 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 6 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. 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? 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. Topobroto Pal. Uh he helped
drive the DevOps movement at Capital One
um and he's now at 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 asked like, "Can can we
build it?" his team would say it would
take about 5 months and we'd have to
hire and need to hire a front-end
person. And he got so frustrated that he
spent 5 days just vibe coding it
himself, right? 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
production?" And all the senior
engineers like, "Not me."
So, enter
uh Swathi, the most junior engineer on
the team, uh who is helping maintain
this application and probably
out-learning, you know, everybody in the
organization.
Uh And interestingly, uh he is also
getting more head count 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 Routhier, 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, etc. And
all those who completed, right? What was
it 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 I 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, one 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 would 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 a whole notion
of fingerspitzengefühl, right? Like, you
know, how many of the 10,000 hours that
requires to be good at anything have you
used to be 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 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, unlike the time on the X axis, a
very incomplete expression, right? It's
like frequency and intensity and how
many hours, but is there a the 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 you 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 uh 6 weeks ago. And what was
amazing to me was in the 3 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 a 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 Saffner.
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 at the look at the
expression on the face. And so, I think
what we're seeing is like what happens
when support shifts, right? And support
codes and shifts, when leaders code and
shift. 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 one from a technology leader.
"When I told my team that I wrote an app
that wrote 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 this legacy application 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 both 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 mechanism yet. And so,
like all of these were some of the
lessons that went into the vibe coding
book. Thank you for everyone who were at
the signing yesterday. And uh if you're
interested in any of the talk to you
reference and excerpts of our book and
uh yeah, basically uh all the links that
are in this presentation, just send an
email to realg and kim at
sendyourslides.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.
[Music]