#244 - Gene Kim: Vibe Coding Solved What I Couldn't in 13 YEARS

[00:02:03] Introduction

Henry Suryawirawan: 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.

Gene Kim: 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.

[00:03:13] What shaped Gene Kim’s career in DevOps and technology?

Henry Suryawirawan: 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.

Gene Kim: 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.

[00:07:26] How did Gene Kim’s books like Phoenix Project come about?

Henry Suryawirawan: 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?

Gene Kim: 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.

[00:09:55] What’s the story behind the Phoenix Project graphic novel?

Henry Suryawirawan: 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.

Gene Kim: 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.

Henry Suryawirawan: 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.

[00:12:21] What was Gene Kim’s a-ha moment with vibe coding?

Henry Suryawirawan: 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.

Gene Kim: 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.

[00:14:41] How did Steve Yegge and Gene Kim collaborate on the book?

Gene Kim: 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.

Henry Suryawirawan: Wow.

Gene Kim: In fact, can I tell you a quick story on that?

Henry Suryawirawan: Yeah, definitely.

Gene Kim: 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.

Henry Suryawirawan: 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.

Gene Kim: 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.

[00:21:06] What is vibe coding and how is it different from regular coding?

Henry Suryawirawan: 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?

Gene Kim: 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.

Henry Suryawirawan: 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.

Gene Kim: 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.

[00:25:57] What is the FAAFO framework for vibe coding benefits?

Henry Suryawirawan: 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.

Gene Kim: 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?

Henry Suryawirawan: 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.

Gene Kim: 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.

Henry Suryawirawan: 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?

Gene Kim: 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.

[00:32:08] Will AI replace software developers?

Henry Suryawirawan: 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.

Gene Kim: 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, I 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.

Henry Suryawirawan: 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.

Gene Kim: 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.

[00:36:10] What are the risks and downsides of vibe coding?

Henry Suryawirawan: 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.

Gene Kim: 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?

Henry Suryawirawan: 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.

[00:41:51] What skills do developers need in the age of vibe coding?

Henry Suryawirawan: 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?

Gene Kim: 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.

Henry Suryawirawan: 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.

[00:46:56] Why are feedback loops critical when using AI for coding?

Henry Suryawirawan: 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.

Gene Kim: 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?

Henry Suryawirawan: 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.

Gene Kim: Oh very. Yeah, yeah.

[00:51:59] How can organizations adopt vibe coding as a culture?

Henry Suryawirawan: 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?

Gene Kim: 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.

[00:57:37] What should you look for when hiring developers in the AI era?

Henry Suryawirawan: 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?

Gene Kim: 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.

[00:59:45] 2 Tech Lead Wisdom

Henry Suryawirawan: 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.

Gene Kim: 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.

Henry Suryawirawan: 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?

Gene Kim: 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.

Henry Suryawirawan: 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.

Gene Kim: Oh, Henry, thank you so much for allowing me to be a part of this and keep up all your amazing work. – End –