Hello guys. Welcome back to another new
episode of the Tech Lead Journal podcast.
Today I'm really excited to have one of my favorite authors in
the show today. His name is Gene Kim.
So he's the founder of IT Revolution and also the author,
co-authors of few, several popular DevOps books, starting
from The Phoenix Project which I really love, by the way when the
book came out. So since then he wrote Unicorn
Project, The DevOps Handbook, Accelerate, and so many other
books. And recently he just published a
book titled Vibe Coding, with Steve Yegge.
So I know that we all have heard about the term vibe coding.
Let's try to, you know, peel a little bit more from Gene's
point of view what vibe coding is.
So Gene, thank you so much for this opportunity.
Looking forward for our conversation.
Oh, Henry, thank you so much for having me.
And I was mentioning how much fun I had listening to your
episodes with Simon Wardley, John Willis and so many of the
IT Rev authors. And, yeah.
And the common passion that so many of us have around this
kinda the miracles that vibe coding allows us to do
especially for people who maybe stepped away from coding as part
of their daily work for, you know, years or maybe even over a
decade So, yeah, I'm so delighted to be here.
Right. So Gene, in the beginning, I
always love to ask my guests maybe sharing a little bit more
from your career, right? The turning points that you
think we all can learn from you. Yeah, for sure.
Yeah I've spent the last 26 years studying high performing
technology organizations. And that was a journey that
started back in '99 when I was a CTO and technical founder of a
company called Tripwire in the information security and
compliance space. And so the journey started when
we wanted to study these high performing organizations that
simultaneously had the best project due date performance and
development, the best operational reliability and
stability in ops, and as well as the best posture security and
compliance. So the reason was that we wanted
to understand how those amazing organizations made their good to
great transformation so that other organizations could
replicate those amazing outcomes.
And so I left Tripwire in 2010 and I spent three years working
on the Phoenix Project that came on 2013.
And it was just such a surprise and I was so grateful that it
led me to the middle of the DevOps movement which I think,
you know, kind of upended how technology organizations work,
right? It was, you know, Dev versus QA
versus Ops, right? And DevOps is really about how
do you get those organizations to work together towards a
common objectives. And, you know, I had so much fun
working on with Jez Humble and Dr. Nicole Forsgren on
understanding what are the technical practices and
architectural practices and cultural norms that allow us to,
you know, create great performance.
And what's kind of funny is that for the DevOps movement, you
know, as part of that journey I ran to Adrian Cockroft.
He led the Netflix cloud transformation.
You know, there he mentioned a term called NoOps, you know,
back 12 years ago. And, he recently made a post,
you know, on LinkedIn that said basically I'm the director of
running a bunch of cloud agents. And, you know, 12 years ago, we
talked about NoOps and now we should be talking about NoDev,
you know. So NoOps is not true back then
nor is NoDev true now. But I mean it just shows how
vibe coding is actually bringing, you know, coding
within the reach of so many people who haven't coded in
years or, you know, even decades.
It's been amazing to see how much excitement it generates and
how many people are building so many cool things.
And, I'm sorry, I skipped a step.
So the reason I got sucked into this incredible adventure, the
adventure of a lifetime, was meeting Steve Yegge last June.
And so I've been quoting him for over 11 years.
I've had so much admiration for his work.
And when we met, you know, it turns out like not only, you
know, did we have a common passion around engineering
practices and architecture as embodied by the famous, you
know, his depiction of the Jeff Bezos memo in the early two
thousands. But we had this common love of
using AI for coding. And the vibe coding book came
out a month ago and I love the book because it tells the story
of two people who both thought that the days of coding, the
best days of coding were behind them, but it's now actually
ahead of them. And this is despite Steve having
written over a million lines of production code at Amazon for
eight years, at Google for 13 years, as part of having written
clouds, Code Search, you know, the most popular tool inside of
Google. Anyway, so fun to be able to
chronicle how vibe coding has changed our lives, has made
things faster, more ambitious, we can do things alone and
honestly fun and optionality. I know we'll talk about more
about that later but, holy cow, that this has been the funnest
things I've ever gotten to work on in my entire career.
Yeah, thanks for sharing your story, right?
So I'm sure that we will learn a lot.
So maybe the first place, I saw that Phoenix Project was like
your first big, you know, popular books, I would say.
And it's written when the DevOps era is, you know, was kind of
like apparent. And I'm sure like vibe coding
might be the era as well when people are, you know, realizing
something big is going to, you know, revolutionize the software
engineering industry, right? You have written these so many
books that has sold over like million copies.
So anything that you learn like from people, you know, how did
you come up with those books in the first place?
Oh yeah. Well, I mean the Phoenix
Project, I had written actually a book called, in 2004 called
The Visible Ops Handbook. You know, how to create world
class operational processes using ITIL, of all things.
But like, you know, people laughed at ITIL, you know, maybe
these days. But it's like, you know, it was
the best we had to sort of describe operational processes,
and I thought that was very important back in 2004.
And, you know, a lot of those learnings are brought into the
Phoenix Project journey which was written by the same, you
know, author team as Visible Ops Handbook.
But in The Phoenix Project is really based on one of our
favorite books which was The Goal by Dr. Eliyahu Goldratt.
And so that book is somewhere behind me.
And it's a novel about a manufacturing plant manager who
has to fix his cost and due date issues in 90 days, otherwise it
shut the plant down. And we love that book so much.
And, we, Kevin Behr and I, we talked about it with Dr.
Goldratt. I mean he was so generous with
the time and, you know, he changed our careers.
And, you know, our goal was to see if we can write that book
but for the IT context, you know.
For hopeless situation that IT operations is in.
You know, if you can't create good working relationships with
QA and development. And one of the things that we
wanted to show was that IT operations looks so tactical,
right? I mean it looks like it's just a
very tactical activity. And yet if it is what's in
between, you know, your most important development projects
and your customers, well, then it's actually as strategic as
development. And so our goal was to really
try to elevate that cause. And I just, I cannot tell you
how delighted and honored I was that, you know, that that book
really became sort of like the flag of which, you know, so much
of the DevOps community rallied around.
And so we wrote a book called The DevOps Handbook after that,
you know, to really be the nonfiction guide, right?
The prescriptive guide to say, all right, how does one
actually, you know, go from deploying once a year which
everyone did back then, you know, to deploying multiple
times a day, right? Or even hundreds of thousands of
times a day. You know, certainly not unheard
of now, right? Many have, most great
organizations deployed multiple times a day.
Yeah. And I saw recently you also have
a series, like a graphic novels, a series of the Phoenix Project.
So tell us a little bit more about that project or that book.
Yeah, that, a couple people just had a tremendous amount of
passion for doing that And it has been really fun to work on.
In fact, it's been really fun to kind of go through, go back to
the Phoenix Project universe and it's been really invigorating
and fun. And I, you know, I guess
honestly, I have I'm a little bit in awe of the book just
because, I'm not sure I could have written that today.
I don't think I was as angry now as back then where I just felt
like, you know, the book really represented like a decade long
plus moral crusade of like, you know, getting people to see
something, right? And I'm just, I'll be honest I'm
a bit in awe of like the way that, you know, the story shows
that how, you know, critical operations is, right?
I mean there was one, scene that I remember where, it was so
good. The inventory management systems
went down, the order entry systems went down, and basically
it was the whole scene was designed to make sure that
everything that was reported on to the board in terms of the
quarterly financial report, they couldn't verify account balances
or values. And so we're like, all right,
what would need to go wrong to basically make sure that, you
know, they can't count what's in the inventory, what's sold,
what's not sold. And I just remember reading that
I was like man, that is a, that is a bad day.
And a lot of that was informed by working with the audit
community for so long. Anyway it was, the question was
like how did it feel to go through it.
And I was just like it was really really fun and to really
work with the graphic artist. He was a DC comics guy.
And so he does a lot of work with storyboarding for movies in
the UK. And so it's just really cool to
see kind of how critical it is, you know, to as storyboarding is
to, you know for any movie. If you can't have a good
storyboard, it is very unlikely that you're gonna have a good
movie just because it's often the one of the most primary
communication vehicles between the director's vision in their
heads, right? And, you know, all of the
costuming and the actors or production, lighting, right?
It's basically that's what is a primary communication vehicle.
Wow, sounds really cool working with the DC comic artist, right?
So. I'm sure when, if people are
interested in reading The Phoenix Project, you know, just
text, and you know, now that we have the graphics novel, I'm
sure it's gonna be more interesting and fun.
So let's move to, you know, the vibe coding thing that we wanna
talk about today. So maybe in the first place,
let's share your a-ha moments. Because in your book you
mentioned, that you actually got introduced to vibe coding and
loving it so much through, you know, your experience coding,
you know, a project that you did, that you didn't even
foresee you would work on, right?
So tell us a little bit more your a-ha moments.
You know, it's funny. So, you know, for me, this
problem I've been wanting to solve for almost 12, 13 years
was I listened to a lot of podcasts and videos.
And so every time I hear something interesting, I take a
screenshot of it. And, you know, in the hopes that
I would go back to it and maybe write about it or listen to it
again or write a citation, look something up.
And so it turns out I have like 3,500 photos in my camera roll
of just screenshots. And how many times have I
actually gone back and looked at them and tried to do something
with it? It's like five, because it's so
hard. And so I, um, I remember when
ChatGPT came out and, you know, I was marveling at the way that
you could just give it a YouTube screenshot and, you know, it
could actually detect where what the play time was right.
And once you have the play time you can go into the transcript
and you can auto extract a whole bunch of stuff.
But for YouTube often they don't show the current playtime,
right? They only show the red progress
bar, right? And I was like, ugh.
So I just as my first kind of non-trivial problem, I remember
going into ChatGPT, this is January 2024, and typing in I'm
gonna give you a, write a Clojure program, right?
A program that runs on the JVM, that takes a YouTube screenshot
and I want you to march up the left hand side of the image,
find the red, you know, RGB color.
And once you find it, march to the right, and, you know, so you
can compute the percentage complete of the video.
And it worked the first time. And it used Java Libraries I've
never used. I haven't done 2D programming in
25+ years. I mean last time I did it was in
C++ on Microsoft Windows. And so I, you know, I could and
it worked, right? And that would've taken me days,
right, to understand like, all right, how does one use the Java
AWT library, blah, blah, blah, right?
I mean it's just not worth it. And the fact that it worked, I
mean my jaw hit the floor, right?
And so, I mean, I just started reinvigorating my love of
programming and just increased the ambition of things that I
could actually do reasonably. And then I meet Steve Yegge.
Right after we talked, he published the Death of the
Junior Developer post. And one of the things that and
he talked to the conference early on called the Enterprise
Technology Leadership Summit about his learning since then.
You know, he had made these offers.
Like, hey, how about we pair program together?
So we did that in September and that just changed my life,
right? If someone like Steve Yegge, you
know, says let's pair together, you know, you say yes.
And he said, look, what problem would you like to work on?
And it was easy. It was like, all right.
I have a pile of these videos and transcripts and YouTube
videos. How about we make a something,
right, that could transform those into like little video
excerpts, you know, with captions overlaid that I could
post on social media. And we finished in 47 minutes.
I mean, it was just then, you know, the whole time he's giving
me advice. He's like, man, Gene, you're
doing an awful lot of typing. Stop typing.
Just lean on the AI more. And it was, I posted the
entirety of the video but that changed my life.
That too changed my life. And, you know, we started
talking almost a couple times a week after that.
And then, you know, the topic, you know, he said, Steve said
that he was interested in writing a book on what became
known as vibe coding back. We think it was gonna be called
chat oriented programming. And I just found, you know, like
whenever you finish a book, it takes a little time before you
ever want to get involved in another book project.
But when Steve mentioned that, I heard the words leaving my mouth
like I would love to help. And the best if you can, it was
the most fun I've ever had on a book project.
I learned so much and the fact it was happening in this
whirlwind of technology change, right, was incredible.
But I felt, I feel like... and I love some of the people who read
it who said, yeah, this is a somewhat, this is a book that
will not change so much with technology.
It has a shelf life of at least a couple years, right?
And so that's ideally the book we want to write is that
something that just can give the direction, stick to principles,
and practices, right, that is independent of the technology
used. But I will make this admission
that when Claude Code came out in January, we rewrote the book
from scratch. Or was it March?
Yeah I mean, you know, basically a lot of the book we had to
rewrite just because, you know, that was a future where the AI's
not telling you what to do and telling you what to type.
You are telling it to do the typing and it to do the running.
And that just changed everything for us.
Wow. In fact, can I tell you a quick
story on that? Yeah, definitely.
Yeah. I mean, I remember for the book
to manage all the research, for most books for the last 12
years, I've been using Trello to sort of like keep track of my
tasks and research files and so forth.
You know, I just wanted to have. Everything that I starred inside
of Twitter to show up as a Trello card.
That worked. But then I actually wanted to
summarize the articles and so forth.
And I was getting all these I was trying to create attachments
for the first time and I kept on getting these API errors.
And, you know, for 45 minutes I'm trying this, I'm trying
that, you know. I'm asking Claude Code, I'm
asking ChatGPT and it's like type this, type that, try this,
try that. And I was so frustrated.
I said screw you. You do it.
You've got a repo open. And 45 seconds later it had
tried five, six things. And it said oh I got it working.
And that also changes your life, right?
It's like it makes you recognize like your job is not to be
bossed around by the AI and type things for it.
Your job is to create this situation where it can see the
results of his work and it can loop around, right?
And it can iterate until you get to the goal.
And, you know, Steve had a very similar reaction when he was
using Puppeteer to, you know, do a TypeScript, React front-end
thing. And, you know, he described a
situation where suddenly it could see what it's doing and it
was like stop motion video where like all the elements were
starting to be fixed by itself with no human intervention.
And I think we both had a sense of awe right at that moment.
It's like I can't believe what is now possible.
Yeah, sorry for rambling but it's like, yeah, just so
exciting. Yeah, very exciting to hear, you
know, your sharing, right? Because I'm sure many developers
out there, including the, you know, senior ones who probably
have loved coding in the past, but they don't have time now to
actually start coding again. I'm sure we realize that the
power of AI can actually make programming fun again and you
kind of like reinvigorate, you know, your passion for coding.
Similar to me as well. So I think your story definitely
is quite fascinating, right? Especially the impact, right?
How you could write such a program that you didn't, you
know, think you would do before in just minutes, right?
in one day. So I think that's always very,
very exciting and eye opener. Yeah.
In fact, I mean you talk about eye-opening.
Yeah I think what's interesting to me, I love the first part of
the book because I think lovingly written and it
describes - you know, for me I got my graduate degree in
computer science in 1995. I was studying compilers and
high-speed networking. And I wrote my last line of
production code in 2001 after, you know, creating, co-founding
Tripwire, right? And as someone said, that we
quoted in the book, I was now in the Pew Stack – PowerPoint,
Word, and Excel, right? I mean it's yeah.
And like many technology leaders, right, that's their
path, right? And so although I fell in love
with programming again in 2016, you know, it was a tough slog,
right? And you know, everything was
hard. And so just to be able to write
all these tools that I wanna write like a PowerPoint viewer,
a PDF viewer, tools to help the writing process.
What did I just write today of? I wrote a mail merge tool,
right, these, all these tools it takes me less than 10 minutes to
build. And so Steve Yegge had the same
thing. He actually gave up code.
He told his doctor last January that he was done with coding.
His hands hurt, right? It was just, took too much time,
right, and the juice wasn't worth the squeeze.
He's been working on his game for 35 years.
And he looked at the, you know, person-centuries of work and he
said it is just not worth it. You got, there's this phrase
that he said that's really stuck with me.
He said, you know, when you get to be our age, right, in our
fifties, you gotta be picky about what you work on because
there's only so many five year projects that you have left in
you. But after Claude Code came out,
you know, suddenly everything became possible, right?
Like something that would've taken a year maybe might take a
week, right? You know, things that would've
taken months might take, you know, days, right?
And so that change as he wrote, that changed everything.
Yeah it's just difficult to overstate just how much changed
our perspective of like we're not coding again to now we're
coding more than ever. Yeah.
So let's go to, you know, the definition of vibe coding.
You mentioned that, you know, you had to change the title of
the book. Vibe coding was the term
introduced by Andrej Karpathy. And since then people are
talking, raving about it. I think your book has some
definition that probably not aligned to, fully to what
Andrej's, you know, citations, right?
So maybe tell us a little bit more from your perspective, what
do you mean by vibe coding? Yeah.
Our definition of vibe coding is anytime you're coding and not
typing by hand. And I think so much of this is
motivated by and inspired by Dr. Erik Meijer.
Oh, so you know that video that I did in 47 minutes.
The video I was using was Dr. Erik Meijer, a talk that he gave
last year. So Dr. Erik Meijer, he's
probably considered one of the greatest programming language
designers of all time. He was part of Visual Basic, C#,
very much contributed to Haskell, LINQ.
He was behind the Hack programming language at Meta,
you know, where it is a type-safe version of PHP.
And he said the days of writing code by hand are coming to an
end. And yeah I was just like, oh, it
it just made us it like it gave us confidence, right?
That it's like, yeah, if he can say it, someone who spent his
entire career designing programming languages to be used
by humans, what would make him say that the days of writing
code by hand are coming to an end?
And I think it's because, you know, he believes very much the
same things that we believed and he was very much like the totem
in our book. And so then when Dr. Karpathy
introduced the word vibe coding, brought to the universe in late
December, you know, we definitely, we thought that that
gave voice to what we're trying to do.
And so Dario Amodei, the CEO and co-founder of Anthropic, he
wrote the forward to the book and he gives this wonderful
definition. He said we don't write code by
hand. Instead it comes from an
iterative conversation with the AI and the AI is writing the
code for you. And I thought it was just a, and
he said it's, on one hand, it's a very wonderful term because it
evokes how different it is in like hunching over a computer
and typing things out. But he said, on the other hand,
it's kind of a terrible term because it sounds kind of jokey
like not a serious endeavor. But he said, you know, Anthropic
is like the only game in town. And I just thought it was such a
great definition. And so yeah, our definition is
like anytime when you are not typing out code by hand which is
like developing photos in a dark room, right, where you actually
go into a dark room that you're in and you have to dip into the
chemicals. So no one does that anymore.
And I think even since the book has come out, you know, Steve
and I have talked a lot to each other about like how we're
writing so much more, creating so many more things.
And we have such confidence, we've gained such confidence in,
you know, what the AI can generate.
And we're very cognizant of what it's bad at, right?
But, you know, with the right engineering mentality with the
right feedback loops with the right architecture, you know, it
is possible to do things safely. Right.
Interestingly some people even, don't even type the prompt these
days. They will just, you know,
transcribe, use a transcript, yeah, transcription tool.
And, you know, it's like, writing code through, you know,
the conversation with a computer, with the AI itself.
Oh my gosh, yeah. I was just got off a call with
John Rauser. He's a senior director of
security at Cisco. Senior director of engineering
at Cisco Security. And so he convinced his SVP to
basically mandate a hundred of the top leaders vibe code
something and put into production within a quarter.
So that ended 11 days ago. And so trying to generate a
survey like we did in the early days of the State of DevOps
research to understand, all right, how did it feel like?
What did you accomplish? I wanna know what the vector is.
What was their - Did they have an a-ha moment?
So vector is a direction and a magnitude.
So I wanna understand like to what degree are they excited and
what are they gonna do, right, the direction?
I started in ChatGPT saying all right, here's kinda the survey
instrument I want to design, right?
Here's kind of the, you know, vague idea of the instruments.
And it, you know, it was interesting.
But then I put it into the Claude Code and I said read all
this, right? You know, create a one pager of
the survey design and it showed me something.
I'm like, eh, not quite, you know, like...
And it just through conversational iteration, after
five rounds I had something I was ready to show John.
And we were so excited. And then I was like, okay, take
a first cut of the questions. And, you know, and it's just so
different than the way we did it 12 years ago, right?
And obviously I'm gonna go in there and I'm gonna, I'm... you
know, this is a we're gonna have a hundred people spend time, you
know, maybe 15 minutes going through the survey.
So I wanna make sure that it's right, that it counts, that it's
gonna take us and hopefully generate some interesting
research findings. But I'm responsible.
But am I actually writing every question by hand?
Am I making every Likert question on a scale of one to
seven, to what degree do you blah blah blah blah?
No. And it's just amazing to see,
like it's not just coding, right?
It's just even survey design and survey analysis.
It's just amazing how much AI can help you.
Yeah. In your book, you mentioned this
term, FAAFO, right, as the benefits of vibe coding.
So you've mentioned a lot of things, you know, making
programming fun, obviously faster generation of code,
right? So FAAFO kind of like summarized
the things that people could benefit by using, you know, AI
and vibe coding. So tell us a little bit more
about this FAAFO, because I'm sure some people might not, you
know, realizing the other elements of FAAFO apart from the
Fast and the Fun part, yeah. Oh, exactly.
I just, Steve and I, we did a lot of thinking around December
about, you know, how do you articulate the value of it.
And yeah we came up with the FAAFO construct which we just we
get endless delight out of. And interestingly and
conveniently, the first dimension is Faster.
And our claim is that that is actually the least interesting
dimension of value. But there's no doubt that like,
you know, whether it's the YouTube percentage complete
generator, whatever, like AI let you do things faster for sure.
But I think far more powerful is the notion of Ambitious is that
you can now do things that you could not have done before,
right? And I think there's actually two
extreme two parts of the spectrum for this.
Take that video excerpt generator.
It might have taken me three, four days if I'm feeling kind of
generous, right, and confident. But, you know, like anytime you
work with FFmpeg, you know, things take longer, right?
I mean it's like simple things can be very very difficult.
And so I think the... if you ask why have I never generated the
video generator, you know, despite the fact that it only
took 47 minutes using AI, I think economist would say that I
was making a conscious unconscious decision that the
juice wasn't worth the squeeze, right?
The effort wasn't worth the return.
It's not worth three days, right, this other thing they
should be working on. But when it takes 47 minutes,
right, suddenly that changes everything.
Like suddenly the impossible becomes possible.
I think that's the, really the point of Ambitious.
The other thing that's really interesting is that the small
things become free. The Claude Code team talked
about like there's one thing they're counting is how many
times does a customer issue come up and they just fix it on the
spot. They don't create a Jira ticket
and then debate about it and like, you know, prioritize and
triage it. They just do it.
And I think that is also very interesting, right?
So like impossible becomes possible, and the small things
become free. Especially we can launch a whole
bunch of agents in parallel. And so that just fundamentally
changes the economics of software.
So you got Faster you got more Ambitious and you got, oh,
Autonomous and Alone. One of the things that I find so
exciting doing these vibe coding workshops, you know, is that
everyone, everyone has things they want developers to do but
it's just not above the line. And so like, you know, so you
got software leaders, you got designers, you got UX people
like they're just pestering developers to try, please,
please solve this problem for me, right?
Or the Tableau people. Or somebody, right?
Someone, you know, is, they want something done but they, you
have to sort of cajole and politic and escalate, you know,
to get these things done. And suddenly you can do them by
yourself. Or, you know, maybe it's a team
and you just you've been trying to get the other functional
specialty to help. And, you know, suddenly you
don't need the, you know, the CI/CD expert or the Kubernetes
expert. You can just do it yourself.
And, you know, that significantly changes, again,
the economics of software, because there's two costs that
are being lessened. One is the coordination cost.
In other words, you don't have to prioritize and synchronize
and agree on priorities. And then, you know, code
together, deploy together, test together, right?
You can do it yourself. The other one is like even if
you get someone else to believe that a problem is as important
as you think it is, they can't read your mind.
And it turns out these LLMs are so good at intermediating, you
know, between multiple parties, you know, to work together.
And then so it's like that's, the both of those I think allow
Autonomous and Alone. And so that's FAAF.
The second F is for Fun. Like, oh my gosh.
There's something very addictive about vibe coding.
In fact, have you found that like once you're vibe coding,
creating things it's very difficult to stop?
Yes, yes it is. Especially once you can see, I
mean, coming back to the ambitious thing, right?
Once you can see the possibility and the amount of things that
you can do in such a short time, it's very addictive.
Definitely. Oh my gosh, yeah.
And, yeah. So like creating something that
you had in your head and it's working.
I mean, it's just incredible. And like even the unfun things
become sort of fun like, you know, reducing test times, like
injecting test data into a function so that it's not
hitting a database. Like even that's fun, right, you
know? It's just, yeah.
And it just shows us a dopamine release that is, I think, very
addictive. And, you know, good or bad that
changes the dynamics of how we create software.
And I'll take fun any day over boring or tedious or like
maddening. So that's awesome.
And then the last one's Option value.
You know, you can explore so much more of the decision space.
You know, you can try, you know, three four ideas where, you
know, you'd be, before you'd be lucky if you can get one.
And it's so expensive and unhappy making that you're just
kind of stuck with it. So just recently I tried
something three ways. What did I do?
It was like oh I need to increase the time to first
render. Like let's try one time by
delaying the generation of the vagal light.
Let's try another one by something, something, right?
And I just sent them all off in parallel and, you know, after
some exploration I decided to choose one of them.
And I don't even remember what it is.
Anyway so like Option value is actually what allows, they say
it is actually a huge creator of economic value.
In fact, Option value is what allows modularity to be so
powerful. And so there's just no doubt
that, you know, the more variations that you can try,
ideally in parallel, right, that is just one of the biggest
levers for economic value creation.
Yeah. And I would say also optionality
doesn't mean that all the options come from your head,
right? But AI itself can actually gives
you more options such that you can think which one is best for
your situations, right? Yeah.
Totally, right? It is on the one hand like you
got an infinite army of summer interns but it also is your
world class expert in almost every category, right?
And that is a what an amazing tool to have.
Yeah, you mentioned that a lot of people now can create, you
know, ambitious projects. Even you saying that small
things now could be free or people, non-coders can actually
solve issues. And obviously some people have
these concerns, right? So when a lot of people can do
vibe coding now to generate software and create, you know,
code, do you think that software developer's role will kind of
like be decreasing? Or do you think also like more
people would become a coder so to speak, right, vibe coder?
So tell us a little bit more on this because some, so many
people have different perspectives on this, and I
would love to hear from you what your thoughts are.
Yeah I was just earlier talking to Dr. Jeffrey Liker.
So he wrote the Toyota Way, I mean just very famous in the
Lean circles. And he actually said, Gene,
you're very, you're confusing me.
On the one hand, you say that it's just a typewriter, right?
I mean it's helping you do all these things, right?
And you also say that it is capable of, you know, helping
you be creative and so forth. Like they seem contradictory.
And I was like, no. Dr. Liker, it was like, no, no.
I don't see them as contradictory at all.
And, because to him, coming from the manufacturing space, I mean
I think when he hears automation, you know, the magic
typewriter can type, you know, 10,000 words a minute, you know,
that's reduction of jobs. And I think what I was trying to
convey to him was that, uh, you know, the notion of Jevon's
Paradox. The notion that if you reduce
the cost of software production, do you end up with 1/10th of
number of developers or do you end up with 10 times more
software? And I just, in my head, I just
cannot conceive of a world where we're like, oh, we're done
writing software. We just, we've had our, we've
had our appetite filled and we don't need any more software.
I just, I cannot conceive of that possibility at, like at
all. And so to me what that means is
that we're gonna end up with more developers and solving
bigger problems. And the people who will be doing
coding will be actually much broader than the, what, 28
million developers we have on the planet right now.
I mean it'll be anything adjacent to developers like, you
know, Kubernetes and operations and UX and product and design
and so forth. Yeah I just...
Am I a hundred percent certain that, you know, it's a good
times ahead? Uh, not entirely but I just I
feel like the notion that somehow we're gonna shed, we're
not gonna need developers anymore, I just find logically
impossible. Does this say that some
wrong-headed leaders are gonna say we're gonna cut 20% of
developers because we don't need them anymore?
I'm sure that's gonna come. Like, you know, that's a, you
know, assholes like that, you know, have always been around
and they're gonna suffer the consequences.
But yeah I think the right-headed leaders will
realize, you know, we need developers more than ever.
Yeah. In fact, so many organizations
are thinking, you know, by introducing AI, we will be able
to kind of like cut a number of people that we have.
And obviously the layoffs that are happening in some
organizations probably due to that.
And I think soon or maybe later they will realize that, oh,
probably we cannot just cut developers because we still need
developers. And like what you mentioned, the
amount of software, if it gets written by a lot, right?
Obviously sometimes when there are issues or you wanna change,
evolve the software, you'll need more developers to help you.
But this time probably a better developer that has a good skill,
right? Rather than a developer that
just do the mundane tasks. So I think that's a very
important thing to realize as well.
Yeah, in fact I was talking to Rodo at John Deere.
Apparently he is the number one token consumer inside John Deere
and I think the GitHub team told him that he might be in the
single digits of top token users on the planet which is amazing.
But yeah, he said, yeah developers were craftsmen, were
craftspeople, right? That it is a tool and the tool
is only as good as the person using it.
And so AI is great for juniors. But like what seniors need to do
is like every mistake that they're making, somehow we need
to make it impossible for juniors to make the same
mistake. Because like to really get great
leverage out of it, like not everyone can be a senior, right?
If everyone has to be a senior developer to get value out of
it, then, you know, like we're not there yet.
Yeah, so maybe in terms of the downsides, because we just talk
about the benefits, right? So I'm sure you have seen in the
news as well, you know, the downsides of vibe coding, you
know, production database gets deleted, you know, things that
should be private becomes public.
And so many other things, issues.
So tell us a little bit more some downsides, because I'm sure
there's a risk of vibe coding too much, especially if you
don't check the code that gets generated.
So tell us some of the, these things so that we can kind of
like manage our expectations better as well.
Oh yeah, yeah. So there are definite downsides
for using AI for coding. I mean it is well known that
there's like significant limitations.
They are, one of them is like, you know, context window
limitations, right? It's like, you know.
And unfortunately, and it is true that the more you put into
the context window, not only if you get to a certain point it
won't accept it but the dumber they get.
There's actually this benchmark that shows, it's called Fiction
Bench, that you give it a story and then you ask questions like
what happened to the character, you know, between chapter two
and chapter seven. And it turns out like, this
paper was from a year and a half ago, even above 3,000 tokens,
like performance degrades significantly.
So it's just really interesting to know that if you can't even
follow a character in a, you know, a moderate like novella,
if you can't do that then you should have, you know, don't
trust it. That's a limitation that's gonna
hit you when you're trying to code as well.
Another one is like AIs are actually bad at instruction
following. There are so many times when you
tell it to do something and it'll forget or it will, you
know, it will change the meaning of the instructions.
And then there's actually something called, like it's
actually prone to hacking its reward function.
In other words, aI are trained to be helpful, right, and
completing tasks. And often like as a context
window fills up, it will almost start to panic and just say,
okay, I'm done. I've made all your tests pass
but it doesn't tell you that it's actually disabled, the way
it did it was disabling a whole bunch of tests.
Like we highlight a whole bunch of disasters that happened to
us. One is Steve had a 80% of his
unit tests deleted one time and only found out like a week later
when his colleagues told him. I've created haunted code bases
that were impossible to understand, impossible to test
and almost impossible to rewrite.
Steve said, in fact, I've almost had a entire repos disappear,
right? In fact, Steve tells the story
about like the only surviving link to a repo of, you know, to
contain weeks of work, thousand volumes of tokens of work, was
in one window. And had he close that window the
inode would've been disappeared in the garbage collected away
and like it would've been all gone.
I've had it corrupt production databases.
You know, you might be asking why would you give it production
access. Because like it's so helpful,
right? It's like, oh my gosh.
I once asked it to the Google Photos API.
They deprecated something. In other words, you couldn't
retrieve photos, screenshots that it didn't upload.
And so they basically, it was useless to me.
I was relying on that for over a decade.
And so I said, hey go into my Apple Photos SQLite database and
just run it around and see if you can, you know, gimme a way
to download, you know, the full size image.
And that was scary. Startling.
Awe inspiring. Amazing, but scary, you know.
But, you know, anyway just sometimes I have to decide to
take a risk, right, because it's just something I really really
want. The lesson we try to give in the
book is that as an engineer you have to be aware of these
limitations. And as an engineer, right, it's
all about, what engineers do is we create reliable systems out
of unreliable technologies, right?
That's what cloud was, that's what Amazon S3 was, right?
Kubernetes, right? You know, same thing.
You know, they create the illusion, you know, that you
have a, you know, long lived, you know, container image
running in production, you know, that you don't have to worry
about things failing. And so I think it's all about,
in the book, we say it's all about taking all your same
engineering instincts but then turning up to 11.
There's this thing called the Nygard Stability Criterion that
says the control mechanism must be faster than what it's
controlling. And so when your code generation
time goes up by a 100x, your control systems have to go up by
at least a 100x. And so suddenly you're coming
into version control more, you are relying on tests more, you
have to have more modular systems because you can't let
small problems become huge problems.
You wanna be able to contain and isolate them.
So all, you know, these are not new but as we put in the book
like if the fastest you've ever gone is like 15 miles an hour on
horseback and someone gives you a keys to a car and says go 15
miles an hour or 500 miles an hour, you'll wreck the car.
And we write in explicit excruciating details how many
times have you wrecked the car, like how our instincts failed us
and like the new instincts that, you know, we need to replace it
with. So yes, there's definite
downsides but we believe that the same engineering principles
that, you know, we've learned over the last couple of decades,
we just need to speed them up even more, to create faster
feedback earlier, more frequently, and stronger because
you need to know when things are about to go off the rails.
Does that resonate with you? Yeah, definitely.
I mean like especially if you don't check the output, right?
And if you give it a big prompt such that, you know, it can
generate tons of code, obviously there's a lot of dangers in
doing that. And especially just accepting
and move on. And people these days also have
this, you know, auto accept. They didn't, they don't even
check, you know, the iteration that the AI agents are doing.
So definitely there are a lot of dangers.
And I love when I read about this hijacking reward function
that you mentioned in the book, because there are so many things
that you need to understand kind of like the, I don't know, like
the behavior of AI, the philosophy of AI, right?
You mentioned that AI tries to be helpful all the time, even
though it can cheat. It can achieve that by cheating,
right? So I think that's very
fascinating when I read that. So you also mentioned that now
we have to put a lot more guardrails, developers job
probably is changing, shifting, right?
It's not just the writing of the code, but now becomes like a
head chef you mentioned in your book, right?
So tell us some of these transition things that all
developers must be aware of, because I'm sure the role itself
is changing a lot with AI. And what are the important skill
sets that we need to invest in order to become a much better
developer equipped with AI? Yeah, the metaphor we use in the
book is you go from line cook to head chef, right?
Your job is not to cut every vegetable, sear every steak,
right, your job is to help create the systems, to allow all
these AI agents, you know, these line cooks to work for you.
And I guess what I love about the metaphor is that we're
saying that, you know, as it's your kitchen, your Michelin
stars, right, you are ultimately responsible for whatever comes
outta the kitchen. So if someone gets food
poisoning, right, if you get a health code violation, right,
it's not the AI's fault. It's your fault.
And I just love that because it extends to whether it's a small
kitchen with a, you know, one help, one or two helpers to, you
know, a large kitchen with 20 helpers.
Or maybe it's a chain of restaurants, you know, with a,
you know, hundreds of people, you know, who are all part of
this endeavor. You know, it's interesting.
At the conference, we had Stuart Pearce.
He's a group CTO of Hg. So they're a private equity
firm. He was saying that, you know,
he's met so many senior leaders, engineering, senior engineers
who he could just sort of tell if they're gonna be great vibe
coders or not. And he said it was like two
things. One was like are they good at
specification? Are they good at delegation?
And are they willing to jump in to finish the last 5% if the AI
can't get right? And I was like, yeah, that makes
a lot of, just I found that familiar.
And I was talking to another friend of mine Jason Cox that
he's a executive director at Disney.
And I told that to him and his eyes lit up.
He said, yeah, you know what? A whole bunch of engineers who
were very resistant to vibe coding.
And so he sort of he pulled their, the performance reviews
and he said the single theme that kept on coming up over and
over again was we want to give you more responsibility but you
need to delegate more. And he was just like...
And so delegation is a teachable skill.
And so I think, again, I just I love these anecdotes that I
really do believe are, you know, there's a basis for it.
And I think kind of through benchmarking, I think we're
gonna find these kind of predictors of whether people are
gonna be good at it or not, right?
And what are the skills that need to be taught to take full
advantage of this amazing new technology?
Yeah. So, head chef.
I think what it means is that sensibilities that I think
become more important than ever is are you creating a system
that has very effective feedback loops, where when something goes
wrong you get fast feedback right away.
It's a strong signal, you can stop the line, and you can fix
it. Or are you creating a system
that has very weak signals and you're not paying attention
anyway and, you know, you're just letting accept all you
know, dangerously, you know, allow anything, you know, you
are gonna have a bad time. I think another sensibility is
like architectural sensibilities.
I mean are you creating a system that agents can work on in
parallel without interfering with each other, right?
Or they all snarl together and every time you try to commit,
you end up with these horrendous merge conflicts which, you know,
has happened to me more often than I'd like to admit.
And, you know, what's interesting is that now you're
spending all your time not doing cool things.
All you're doing is like un-snarling, un-coordinating,
you know, coordinating, re-coordinating, and that's not
good. And so just those same
sensibilities that work for people, you know, also apply to
AI. Then I think another thing is
like you have to love learning. I think some people get
energized by, you know, the rate of change in what's happening
with coding agents right now and so forth.
Other people get frightened and sort of dig the heels in.
And I think it's fun to be part of the first group.
I think we have to have sympathy for the second group, because
eventually, right, we want them to be a part of the ride, right?
As Steve said, this is the big one, right?
You know, like imagine you're in Hawaii and the big wave is
coming. You gotta get ready, get the
surfboards out, practice so you can not just ride the big wave
but survive the big wave, right? And then the last one that we
say that you need to do is you have to love to cook, you know.
You love, have to love creating things, right?
If, you know, coding is just a job and you're just sort of
punching a ticket, maybe vibe coding is not gonna be the most
fun for you. Yeah.
So I think those are very important skills indeed, right?
I'll just try to summarize, like faster feedback loop, right?
And I think in fact it becomes much, much more important simply
for the guardrails reason that you mentioned.
And the modularity, the architecture thing, definitely
makes sense, because you still wanna come up with the code that
is designed well. Because the code will evolve
unless you're building like one time project where, you know,
once you use it, that's it, that's done, right?
And then, embrace learning. Definitely these days it can be
very overwhelming. Sometimes I feel overwhelmed as
well, like so many rapid advancements happening.
And sometimes you need to be patient as well about learning
those new things. Lastly is mastering the craft,
right? Like you need to learn like how
to enjoy your role, right? Like become a problem solver,
writing software and things like that.
So I wanna dive a little bit on the faster feedback loop,
because I feel feedback loop is such an important thing.
In the past, when in the DevOps world, especially like with
CI/CD, automated tests, and all that, feedback loop is very
important to give you like signals where you are heading
to, either are you heading to the right direction or wrong
direction? Now with AI, you mentioned that
you are given like a very fast car.
Things are churned out very, very fast.
Without fast feedback loop, I think it's much more dangerous.
So tell us about the importance of this feedback loop.
And you have this new cycle that gets introduced, like prevent,
correct, and detect those kind of things.
So maybe tell us a little bit more about these techniques such
that developer can benefit from that.
Yeah. Oh, you know, so I, you know, I
feel like all my entire career I gotten me ready to write this
book. And so I got to work on a book
called Wiring the Winning Organization with Dr. Steven
Spear. And so he is famous for many
things but among the thing he's famous for is writing the most
widely downloaded Harvard Business Review article of all
time called Decoding the DNA of the Toyota Production System.
And I remember reading it in 2001 and thinking like this is
amazing that, you know, he talked about how in any Toyota
manufacturing plant there are thousands of people working in
the community of scientists doing experiments every day and
continuously learning. And that's enabled by feedback.
And so feedback whether you're making cars or launching a
rocket or performing a surgery, you have to see what you're
doing, you know. And it's not like a one
screenshot, you know, per operation, right?
It's like you wanna see what you're doing at any given point
in time. And so it turns out like
feedback is like one of the most critical things in any
management system but also like in any engineering endeavor.
You know, to go into that Nygard, there's something called
the Nygard the Shannon Nyquist Theorem.
This, the provenance of this is not quite clear to me but
there's somewhere there's something that says the
controller must operate at at least twice the rate of what
it's controlling. And I think the Nyquist Shannon
Theorem actually says, you know, for measuring something, you
have to sample at twice the frequency, right?
Which I think is like, you know, you can correlate you can then,
the corollary is to control it, you have to be able to, you
know, measure it, et cetera. And so like what we're trying
to... what we it did in the book is said, alright, how do we have
to modify our inner, middle, and outer development loops, you
know, to use this amazing new technology.
And, you know, we had some reviewers say, oh, you're
actually breaking how the use of a term, right?
Inner is kinda like what you do in your laptop, outer is what
you do in CI/CD. It's like, yeah, you know what?
It's like, it is it is, yeah, we'll go there.
I mean it's just you have to change the way you work.
And the way we define it was inner is like what do you have
to do kinda like every second, every minute to prevent, detect,
and correct bad things from happening.
And then middle is, you know, what do you have to do every
hour or days. And outer loop is maybe days or
weeks. There's certain practices, you
know, are like, alright, you gotta check your stuff into more
versions more frequently. Whatever you're doing, you're
probably gonna be at least two to five to 10x more frequently.
It's funny. Steve Yegge, he allows his
coding agents to check in code all the time.
And I just thought it was like for me, I just, I let it do it
sometimes but I really wanna be the arbiter and decider about
what gets in and what isn't. There's sometimes emergencies
where I do let it do it but, for me, version control is my
ultimate fallback and I just, I don't want to, I just need to
keep that clear in my head. Another one is, yeah, like you
have to be aware of tests. Like you, the idea that you have
to have situational awareness. You have to know what branch
you're in, what window you're in, what project you're in.
You know, those are critical signals you need because how
many times - having a recall moment here - where you type in
the wrong prompt in the wrong window, right?
And so anyone who's done like server admin knows what it feels
like to drop a table when you thought you were in staging but
you're actually in production, right?
I mean I have similar moments inside of Claude Code.
Yeah, so there's certain things you gotta do like always, front
and center, like literally every second, and there are things
that you need to be doing kind of less frequently but, you
know, just as important. And where did that term come
from? It actually came from the audit
community. Like what are all the things,
bad things can happen? And we know from a personal
experience, you know, what are those bad things?
So now you need controls to either prevent that bad thing
from happening, and if it does happen you need to have
detection correction mechanisms. And so we have a whole section
on like, you know, the catalog of practices that we built up,
you know, all the disasters that we just talked about, you know,
how do you prevent, detect, and correct?
Yeah. So I think one key insights here
is like your controls must be in place, right?
And in fact, it must be greater than in the past.
Because now when code is very cheap to produce, you need more
controls to kind of like detect, right, if there's anything going
wrong, missing, or whatever that is, right?
And how to prevent that and how you correct that after that,
right? Sometimes the developers need to
be hands-on in order to be able to correct that.
Oh very. Yeah, yeah.
Yeah. So the last part of this
conversation, I wanna talk a little bit more because vibe
coding, a lot of discussions these days is more, you know, on
developers, individuals, right? Like everyone now can, you know,
vibe code. But I think the big potential is
actually to make vibe coding more kind of like a cultural
thing in an organization. And in your book, in the last
few chapters, you also mentioned like how can organization adopt
vibe coding as part of their culture?
So I know this probably a little bit more advanced for some
organizations who are still trying to adopt AI, like the
chat AI or some kind of other AI tools.
But vibe coding itself can be a powerful thing for organization
to actually innovate a lot more and produce something, you know,
that is more innovative. So tell us how can we start
creating this vibe coding culture?
What are the important things to set?
I don't know. But I mean, I think the way we
learn is by people sharing experience reports, which is the
reason why I've been running this conference for last 12
years. Yeah, and it was, I'll just
share some of the highlights that kind of really blew me
away. One was a guy named Sree
Balakrishnan. He's a head of technology and
product at Travelopia. So it's a $1.5 billion a year
travel company. And yeah, he was talking about
how they were able to rewrite a Drupal application in six weeks,
right, with a very small team of people using AI tools.
They only had the code, no documentation, but they did have
the users and they were able to reconstruct all the screens
needed to, you know, basically do everything outside of the
mainframe. Amazing!
You know, they rewrote the payment platform and there it
was like a race between kind of a typical dev team and a dev+AI
team. And, you know, the way he
described it was the dev team no AI was kind of this linear, one
dev+AI was more flat. But then it kind of hockey
sticked at the six week mark. They matched the progress of the
manual dev team. But he said the most important
thing is that the only team that was willing to go into
production was the dev+AI team. And then they basically shut
down the race after that. A company called Exabeam, they,
the head of product, he described how among many other
things, you know, they're a private equity owned firm.
And they said, you know, the classic playbook is that you
find an aging competitor or competitor adjacent and then you
acquire them for a hundred million dollars.
And then, you know, you grow the company that way.
And he said we did an experiment.
We got eight people together, we decided to instead of buying the
company which, you know, has balance sheet implications,
we're just gonna find an aging competitor and see if we can
create an MVP of exactly what they do.
And so the verdict isn't out yet but they said we learned so
much, we got so much further than we thought.
And the notion that product owners, designers can contribute
to a coding project was just so much higher than they ever
thought. The big challenge was how does
this product manager get someone to review their code when they
don't have those relationships, when you're not in the dev team,
you know, which is illuminating. And one thing that Shree talked
about was like he has a real sense that the team size is like
gonna change. It's not gonna be eight people
anymore. You don't need six developers
plus UX plus product. You just need a person with a
problem and a developer who can fix it, right?
And maybe a pair of those too can actually go further and
faster. That's super exciting.
But like one of my favorite presentations came from Dr. Topo
Pal, who I've known for over a decade.
He's a VP of Architecture at Fidelity.
And among one of the applications he's responsible
for is this application where you ask, you know, which of our
20,000 plus applications have Log4j in it, who's the
responsible manager, which business unit, and so forth.
And he's had this vision of what this application should be in
his head. But when he ever asked his own
dev team like what would it take to build it?
They would say eight months, and plus we need a front-end React
person, right? And he got so frustrated that he
decided to write it himself. He spent a whole weekend vibe
coding. 10 days later, right, he had something that followed all
of the Fidelity coding standards of which, you know, he's
partially responsible for. And it went into production last
month. The question is, all right,
who's gonna maintain it? You know, who's gonna help Topo
build the next set of functionality?
And her name is Swathi, the most junior engineer.
Because all the senior engineers are like no, no thank you.
And the surprising thing is he's getting more headcount because
the number of people using this tool is so much broader than
what it could do than before. And so like who saw that coming?
So... oh and he's saying the teams who are vibe coding, some
of them are saying for the, you know, for 20 plus years or what
however that long they've been using kind of Scrum-like
patterns, we've always been able to demo everything we need to
demo every two weeks. He's now consistently, there are
some teams who don't have time to demo everything they built
and now they're asking do we need to have these demos more
frequently? It just, it says, it just opens
up so many questions and I think this all very exciting.
I mean, it's not boring. So, yeah.
And then plus John Rouser, right?
He's presenting tomorrow about what happened when a hundred
leaders within Cisco Security, all have to vibe code.
And so, you know, the survey instrument that, you know, we
were working on is really designed to say, all right, who
is the most excited, right? Who is like we called it super
forward or something else. Like the early adopters
enthusiasts, the partial completers did not complete.
What are the critical enablers that allowed the high performers
to be high performers and what are they gonna do about it?
Like given all these a-ha moments, how do they wanna
change the way, you know, their engineering teams work.
I can't wait to learn. Yeah, and I think as you
mentioned, like the juniors now is being able to kind of like be
part of an active problem solver maybe in the organization.
And this I think also comes back to how you hire, right?
What are important traits these days that you think we should
look when hiring developers? Because now that everyone
potentially can write the same, you know, amount of code, maybe
the same quality, because AI is kind of like the leveler here.
So what are the important skills to look at when you hire?
Yeah, I don't know. But I mean I was at the Grace
Hopper Celebration last week so that was 14,000 women in
technology. And it was, I've never been to
anything like it in my life. It was people across all parts
of the, you know, career stages. You know, college students,
researchers, senior leaders. And like I don't think anyone
knows but I'll tell you what really caught my attention.
A couple students, they asked is what I'm learning here in
university still important? And I'm like I don't know.
But I do feel like and we put in the book some positions and this
mostly came from Steve, but I actually agree wholeheartedly.
It's like do we really need to be teaching data structures this
much? I mean is it really a semester's
worth of work or is it like a couple weeks, right?
I mean, I don't think very many people these days are gonna be
writing certainly not linked list or complex b-trees, right?
It's like that's, I don't think that's as relevant but I think
we need to be teaching more, right, things like software
architecture and how to create dynamic feedback loops and, you
know, tools like how do we use tools like vibe coding.
Yeah, it's super interesting and I just, you know, one of the
things that we put in the book was if we expect developers to
be using AI to solve problems, well then shouldn't we want
developers to be using AI as part of the interview process?
And so I, you know, there's a whole bunch of reasons that, you
know, if you have to be air gapped and, you know, working on
something sensitive and classified well then, you gotta
learn how to work on stuff without it.
However, right, I mean if the majority of problems will be AI
assisted, well then maybe that's the way we should be
interviewing as well. But then I totally understand
the risks of like all right you're not actually hiring.
You might be accidentally hiring an AI, not a person so, which is
a thing. Yeah, hiring an AI, paying for a
human salary. So I think that's a kind of
hilarious. So Gene, it's been a pleasant
conversation. Unfortunately, we have to wrap
up pretty soon. I have one last question that
I'd always love to ask my guests, right, to learn from
you. So I call this the three
technical leadership wisdom. Just think of it like an advice
you wanna give to the listeners here.
So maybe if you can share your version today that would be
great. Yeah I'll give one that's AI
specific and one that's not AI specific.
So I think AI specific, something that Dr. Ron Westrum
who so much influenced our work in the Accelerate book, DevOps
Handbook, around culture norms. You know, he introduced me to
the term the sociotechnical maestro.
And basically he says really five things: high energy, high
standards, great in the large, great in the small, and they
love walking the floor. And so, yeah, high energy, high
standards, that's obvious. Great in the large, that means,
you know, to me systems thinking, you know, being able
to see the larger picture. Great in the small means like,
yeah you're detail oriented, right, you, you know, care
about, you know, you don't just believe anything that people
tell you, right? You're willing to sort of dig on
the covers and really find out and then love walking the floor,
right? You love, you know, when you're
responsible for the work of others, you go to where the work
is being formed, you actually see how what's in their way.
You know, are you really creating the conditions, you
know, to enable people to do their work easy and well?
I think people engineers leaders who are that are, we all need
leaders, right? Any endeavor that takes more
than one person, you know, we need leaders for.
I think the second thing that I would add that's not AI specific
is like what is one piece of advice I would give to people
early in their careers. And I would say find someone
with lots of problems, right? Someone's working on important
problems and they can't solve all of them.
And I think what I found in my career, in fact where Tripwire
came from was me going to Professor Jean Stafford.
And he had a lot of research and funding and he had lots of
problems and projects he wanted to complete.
And I just, I was free labor as an undergraduate student and I
got to work on under him on graduate level problems.
And one of them became Tripwire which became the foundation of a
company that I was there for 13 years.
And we did our filing to go public and I'm just incredibly
grateful for that experience. And I think so often, right,
that's what it comes down to is like especially early in your
career, yeah, you don't know really what you're good at.
And the only way that you can tell is by asking someone with
more experience, you know, give me a problem to work on, right?
And you will learn a lot and you get a lot of feedback.
And I think that actually is applicable, you know, to all of
us. Wow, I think that's really two
great advice for people who listen, right?
So I love the first one as well like kind of summarize the kind
of leaders they should be, right?
The important attributes and especially like the walking
thing, right? Because some leaders are kind of
like detached from the day-to-day workers, employees,
right? And they kind of like think it's
easy to do a lot of stuff, right?
Because, yeah, think about the layoffs that happening, because
they think by introducing AI they can just replace people.
But sometimes it's not as easy as that.
So Gene, if people love this conversation, they would love to
connect with you or ask you more questions, is there a place
where they can find you online? Absolutely.
I'm on Twitter at @realgenekim. And the other place that I love
being on is LinkedIn. So just Gene Kim.
Just Google Gene Kim, vibe coding and you'll find me.
Right. And I would recommend people to
check out Gene's book, right? Vibe Coding.
I think it gives a very good overview of what is important,
especially these days when people can, you know, vibe code,
generate code a lot. And I think, there are important
lessons, especially the engineering practices that I
find very, very important for people to learn from that book.
So thank you again for your time today.
So it's been a pleasant conversation.
Thank you so much for writing the book as well.
Oh, Henry, thank you so much for allowing me to be a part of this
and keep up all your amazing work.