The Pragmatic Engineer - Amazon, Google and Vibe Coding with Steve Yegge

Episode Date: July 16, 2025

Supported by Our Partners•⁠ WorkOS — The modern identity platform for B2B SaaS.•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more.•⁠ Sonar — Code quality and code security for ALL code.—Steve Yegge⁠ is known for his writing and “rants”, including the famous “Google Platforms Rant” and the evergreen “Get that job at Google” post. He spent 7 years at Amazon and 13 at Google, as well as some time at Grab before briefly retiring from tech. Now out of retirement, he’s building AI developer tools at Sourcegraph—drawn back by the excitement of working with LLMs. He’s currently writing the book Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond.In this episode of The Pragmatic Engineer, I sat down with Steve in Seattle to talk about why Google consistently failed at building platforms, why AI coding feels easy but is hard to master, and why a new role, the AI Fixer, is emerging. We also dig into why he’s so energized by today’s AI tools, and how they’re changing the way software gets built.We also discuss: • The “interview anti-loop” at Google and the problems with interviews• An inside look at how Amazon operated in the early days before microservices  • What Steve liked about working at Grab• Reflecting on the Google platforms rant and why Steve thinks Google is still terrible at building platforms• Why Steve came out of retirement• The emerging role of the “AI Fixer” in engineering teams• How AI-assisted coding is deceptively simple, but extremely difficult to steer• Steve’s advice for using AI coding tools and overcoming common challenges• Predictions about the future of developer productivity• A case for AI creating a real meritocracy • And much more!—Timestamps(00:00) Intro(04:55) An explanation of the interview anti-loop at Google and the shortcomings of interviews(07:44) Work trials and why entry-level jobs aren’t posted for big tech companies(09:50) An overview of the difficult process of landing a job as a software engineer(15:48) Steve’s thoughts on Grab and why he loved it(20:22) Insights from the Google platforms rant that was picked up by TechCrunch(27:44) The impact of the Google platforms rant(29:40) What Steve discovered about print ads not working for Google (31:48) What went wrong with Google+ and Wave(35:04) How Amazon has changed and what Google is doing wrong(42:50) Why Steve came out of retirement (45:16) Insights from “the death of the junior developer” and the impact of AI(53:20) The new role Steve predicts will emerge (54:52) Changing business cycles(56:08) Steve’s new book about vibe coding and Gergely’s experience (59:24) Reasons people struggle with AI tools(1:02:36) What will developer productivity look like in the future(1:05:10) The cost of using coding agents (1:07:08) Steve’s advice for vibe coding(1:09:42) How Steve used AI tools to work on his game Wyvern (1:15:00) Why Steve thinks there will actually be more jobs for developers (1:18:29) A comparison between game engines and AI tools(1:21:13) Why you need to learn AI now(1:30:08) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:•⁠ The full circle of developer productivity with Steve Yegge•⁠ Inside Amazon’s engineering culture•⁠ Vibe coding as a software engineer•⁠ AI engineering in the real world•⁠ The AI Engineering stack•⁠ Inside Sourcegraph’s engineering culture—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Stevie's platform rant because it was a really good criticism of Google. It was a really realistic picturing of Amazon, including Jeff Bezos, not giving a shit about your day. He still doesn't. Did you write this kind of things all the time? I was fed up. I've been there six years and I still couldn't get a platform at anybody. I went nuts.

And then a bottle of wine later, I told him how it was. But you were actually right in hindsight. I was right about all of it. But they never said, sorry. Steve Yegy is widely known for his writing and rants in software engineering. His blog posts get that job that Google was circulated by Google HR for hiring purposes for 15 plus years, and his Google Platforms rant, written a decade ago, is still heavily cited across the industry. Steve worked for seven years at Amazon, 13 at Google, and is now building AI tools at Sourcegraph.

In this direct conversation with Steve, we cover the infamous Google Platform rant, and why Steve thinks Google is still terrible at building platforms. Why Steve, unretired from tech and coding, thanks to AI tools. why Steve thinks more deaf should vibe go together with AI and many more interesting topics. If you're interested in how AI tools will change how tech companies operate, how us developers can keep up with them, or why the core DNA of tech giants like Google and Amazon

seem to change very little over 20 years, then this episode is for you. If you enjoy the podcast, please subscribe to it on any podcast platform and on YouTube. So Steve, just welcome to the podcast. It's so nice to also meet you in person. Gary Gay, thanks for having me again. So the first time I ever came across your blog, it was was Stevie's blog rant. This was around 2010 because I read this article called Get That Job at Google.

Back then, I was trying to get my first job outside of abroad, basically the first job in the UK, and I look for the best preparation materials. And the two things that helped me most was, of course at Stanford about cracking the Google interview and your article, get that job at Google. And what really stuck with me, this article is still up there, and I just tweeted recently that I think after like almost 15 years,

it's still very relevant. One of the things I really liked is, is you put this important takeaway, is if you don't get an offer, you may still be qualified to work there, so don't blow your ego at all. What motivated you to write this article? Getting turned down by a bunch of places.

No, you know, it's true. Actually, a lot of my friends got turned down. I knew they were good, right? So I saw the false positives, or sorry, false negatives because they were so scared of a false positive. And they just, they were Google and they could just turn people away. Yeah. Turn great talent away.

This was Google in 2008. So like this was, they barely went public. They were the hottest thing. What are open IIS? I joined in 2005, actually. You joined in 2005? Yeah. So by the time I wrote that, I had seen three years of interviewing there.

And I knew what it took, right? And I don't think it's changed that much in the last 15 years or whatever. This episode is brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like Sammel authentication, skin provisioning, and fine-grade authorization. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand, and you can ship quickly and get back to building other features. WorkOS also provides a free user management solution called AuthKit for up to one million monthly active users. It's a drop in a replacement for Alt Zero and comes standard with useful features.

like domain verification, rule-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. You get limited as customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like cursor, Versel, and Perplexity. Check it out at Workos.com to learn more. That is WorkOS.com. If you want to build a great product, you have to ship quickly.

But how do you know what works? More importantly, how do you avoid shipping things that don't work? The answer? Statsig. Statsic is a unified platform for flags, analytics, experiments, and more, combining 5 plus products into a single platform with a unified set of data. Here's how it works. First, Statsc helps you ship a feature via feature flag or config. Then, it measures how it's working, from alerts and errors,

to replace the people using that feature, to make. measurement of topline impact. Then you get your analytics, user account metrics, and dashboards to track your progress over time, all linked to the stuff you ship. Even better, Statsic is incredibly affordable. With the super generous frees here, a startup program with $50,000 of free credits, and custom plans to help you consolidate your existing spend on flags, analytics, or AB testing tools. To get started, go to Statsic.com slash pragmatic.

That is, S-T-S-I-G-com slash pragmatic. Happy building. Yeah, and one thing that you wrote about is this thing called the interview anti-loop, which I never heard about until then. What is it? Does it still exist? I mean, I made it up, but I mean, it's a phenomenon that I observed that everybody knows about that it was the one thing in that post that recruiting and HR were a little, a little, you know,

I mean, worried about me publishing it. And I was like, well, there's no point in doing the post if we don't talk about it, right? Let's just be, it'll give us some credibility. Yeah. And I think it did ultimately, right? Which is, look, you could. just get unlucky and accidentally get the six people at the company who just disagree with you the most on everything technical. Yeah.

Right? And it's just like just bad luck. In fact, I think a lot of tech companies have this policy or at least used to have it until recently. Maybe they'll do that. You can reapply after six months exactly for this reason. Yep. And I knew a bunch of people who reapply to Google multiple times. One guy who got in on his fifth attempt and then went on to get promoted really fast and rise up the range.

and everything. You were very obviously a false negative, but it just took a bunch of tries to get in. So a super critical criticism that a lot of people who read that article have is like, well, oh, if this is what it takes in to get Google or meta or whatever, which is, you know, it's my skill,

not my matter as much as the interviewers. I don't want to do that. Like, I really appreciate that you just, like, you didn't hold back and you just kept it real. But what is your take on on people who are like, well, that's not fair? It's not meritocracy, that kind of stuff. stuff. You know, interviewing is not really a very good signal. I empathize with their viewpoint. In fact,

at several points in my career, I've sort of kind of given up on interviewing and just said, like, you guys do it. There's a lot of people who think they're really good at it and they think that they know how to do it well and so on, even though the statistics at Google, they ran many, many statistical analyses and found that there isn't really a lot of correlation between, you know, how you score and whether you get an offer and whether you get an offer and whether you do well and so on. And so I kind of lost faith in the process a little bit. I noticed that I was a referral, I was a reference, I should say, for a buddy of mine who was applying at Anthropic. Recently, right.

And I got a call, right? Just a regular reference call. And the person was the hiring manager, not a recruiter. And the hiring manager talked to me for probably at least 40 minutes digging into all the things that you don't pick up in an interview. Right? Because he recognized, just like we do. that interviewing is a really flawed process, and it's a trade-off that the company has to make

between sort of like effort that they expend, trying to find good candidates, and being really accurate in their assessments. That's a trade-off. Yeah, and then interesting enough, you know, there is some people are saying, you know, I guess a lot of people are saying, this is unfair.

You know, there's also a criticism of coding interviews, elite code, et cetera, and they're like, why can't these companies just ask me to the work? And then plot twist, some companies are doing that these days, like, linear and some of the formal companies who have a strong and a brand, they're like, we will pay you your like day rate, week rate. And for a week, you will work with us remotely. Now, of course. And it's, and, you know, I'm actually talking with the engineer manager as was on my team. Their first engineering manager is like, you can use AI tools.

They're immune to everything because you're actually doing the work. Now, the downside is it's a week of your life, right? And people are like, well, I can't interview at five different places. And I feel, you know, there's all these trades. I thought, well, yeah, but now it is real world, right? So there's this spectrum of interviews. And as you said, like, in the end, just, I guess, pick your poison, right? That's right. That's right.

And I know, look, man, I've been in the industry for 30, 35 years. I've seen people try all sorts of different variations on trying to improve this. Like, the first company I worked for required you to do a six-month co-op before you could get a full-time offer there. Was that? GeoWorks. GeoWorks. And they had probably the highest hiring bar I've ever seen. And they got acquired by Amazon.

And Amazon was just blown away. by their hiring bar. In fact, we should probably mention, I mean, I think you and me have both seen this, but there's this like open secret in the industry where if you go to the website for like Google, meta, a bunch of big tech, even Microsoft, you're not going to see software development engineer one advertised because they fill all those up with interns. So the internship is actually a recruitment operation. It is.

It is. It's a really cutthroat. College hiring is super cutthroat in the industry. And the big companies like Microsoft, you know, in Google, they sort of dominate it. They have the resources to build all the relationships with the schools. And it's, yeah, so they get the cream of the crop, you know. Yeah, and then they fill up an entry level. I'm really proud of any intern that goes off to a startup, really.

I actually just talk with someone. She'll be on the podcast. She had returned off from Microsoft and Google. And she talked with her mentor at Microsoft. It's a good mentor. And the mentor was saying, like, look, you can do big type. But, like, with startups, you have a very different skill set. and she thought about it for a long time.

And in the end, she took a risk and she went to Cota. She's now at Open AI, actually, but I think that experienced helped her. And she talked through her mentality. And I was like, wow, like she sounded like a wise experience person. And yeah, I did not expect it because, you know, it was like it was paved. I see a lot of this too. I mean, college kids are savvy these days. They know that stuff's like really in flex.

And in fact, all the stuff we talked about, even many of the things that we talked about in the blog post that seemed timeless about getting a job at Google. Getting a job is just hard as a software engineer right now. The other thing that really resonated with this article is, as you wrote, I'm going to quote it, when you get an offer from a tech company, you just happen to squeak by. And at the time, when I read it, I didn't really believe it from outside. But now that I've also, you know, I've gotten jobs. I've been a hiring manager and made so many offers.

You know, people who are coming in and they're like, oh, I smashed the interview. actually, like, out of maybe 100 interviews, roughly, that I've been the hiring manager at Uber, there was, like, two. That was, like, we had more than one person do a double thumbs up. We had thumbs up, double thumbs up. The rest were a mix of, like, thumbs up, thumbs down, and then we came to a decision, and it was like,

it could have gone either way. Like, one went to the debrief. So, like, I now really appreciate it. I feel this is one of the things, which is hard to believe from the outside. The best story is, when I was at good, I was on their hiring committee, which is a blind, you know, double blind. They don't see the candidates or the – they don't know the interviewers who's doing it.

They're just reading feedback packets. And the interviewers don't bias each other. And one day they didn't experiment with us, okay? Because we were the ones that ultimately made that decision that you just talked about, right? The thumbs up, thumbs down type thing. Not the interviewers. Google has a separate committee that actually looks at all the feedback, right? And the recruiters did an exercise with us where they presented a bunch of packets.

hypothetical packets, say, of candidates who had been rejected or accepted, actually, they didn't even tell us. They just said these were just a bunch of candidates. We're going to go and do the process on them. We had feedback on them, though. Okay. We went through and we evaluated them all and decided we were going to not hire 60% of them, right? Have you figured this one out yet? No. No, no, I knew. We were reviewing our own packets. Yeah. So we voted not to hire 60% of ourselves. Yeah. Okay?

And it was a very sobering realization. And the next week or two was like the best time to apply to Google. So we were just like, come on through. Right? I mean, it was nuts. Well, because 60% is almost a coin toss. A coin toss is 50%. Yeah.

You're a little bit better. Right. And so, I mean, the whole, I don't know, the whole process is also so heavily biased towards whether you like the person or not, you know, a lot of the decisions made in the first 10 seconds, they say. Yeah. But, but, you know, my takeaway, and I think different people take different things, but the reason that really helped me, not just at that time when I got this first job in the UK,

but actually I read read it up later when, for example, later applied to Facebook. I narrowly didn't, but I didn't get it. And actually that rejection helped me get that position at Uber, which all of these are just cut through. And what I took away from it is, this is how the process is. You might not like it, but you can either just, you know, complain or think it's unjust, or you can know it's unjust and you know that you just need to try hard. and when you do get it, you know, don't take it for granted. So how to getting rejected by Facebook

help you get a job at Uber? Because if it's helpful, I'll go get rejected at Facebook. What was helpful is I did a bunch of time preparing for Facebook. Like it was very clear at the time that they actually, you know, send me materials. And the preparation did not go to waste. So, you know, I learned how to do the algorithmical coding, Bigo. Like I knew some of that before, but I really refreshed it on the spot on Facebook, for the system design, I thought I nailed it

because I heard the question before, and I just like drew up like it was like design Instagram and like, I got this, you know, no conversation with the person. And later I kind of got some feedback on like, you know, what I didn't do and so by the time I got to Uber, I actually heard that like again, not many people got double thumbs up, but in hindsight, I kind of got

the, I did get like two or three double thumbs up because I have practiced and also I think the other thing is that Uber at the time, this was Amsterdam. So in London, a lot of people knew how it was an interview Amsterdam, Uber struggled to have people who understood these interviews. So I guess I stood out because I prepared a year earlier. So the preparation does not go to waste. Yeah, preparation is so important, so important.

But boy, what do you prepare for now? Like I've got a buddy who's out interviewing right now. He's just a very senior engineer. And he says that the teams are all asking, they want somebody to come teach them AI. That's what everyone's doing. So they want someone who knows AI because they don't. That's the theme, right? Yeah.

So what do you prepare for? Well, I just talked with someone, again, she'll be on the podcast, Jambi, who interviewed a 46 AI companies. She's the engineer who went to Koda, became an AI engineer there. So she interviewed 46, and she said it's a mess. And, you know, this is like for mid-level,

so like we're not talking to staff level, but a lot of them are still doing the usual lead code style interviews. And then they might ask you a few things about AI. And she said that there is one, type of project that she actually really likes is a project, especially for AI, you know, build something based on AI. And she says she loves it because she can actually show off what she's capable of doing. It seems it's a mess. I don't think people know what to do. And,

you know, I don't think even a lot of companies know what AI engineers will get into this. But before we go, so you wrote the Get That Job at Google in 2008. And 10 years later, you wrote another one called Get That Job at Grab. You were at Grab. Now, you would think that these two are kind of connected, but Get That Job, job at grab, was more of an article about the job market at the time in 2018. You wrote, I'll quote, because something very strange is going on in industry. It started maybe a couple years ago, and it escalated a lot around the year ago, and then what completely was crazy about six months ago, what happened is this global demand for software in years, completely

outsides supply, and I think it might be happening because we missed the market correction sometimes the past five years. The article was basically a bit of a heads of saying, the market is really hot. And now that I read it back, I was a bit of amazed because you wrote this one or two years before anyone mentioned it. It was happening. It was heating up to be the hottest job market. And we saw it in 2021. It was the peak. You saw this.

And you were pretty much advertising it to anyone who was actually listening to whatever you were preaching. Yeah. Well, I mean, they're the early warning system that recruiters are that will tell you what's going on with the market, right? because they're directly in touch with hiring managers, who are the ones who are, you know, in touch with the people with the budgets who are deciding what the company is going to focus on. And so the recruiters, if you're in touch

with your recruiter network, right, you know kind of what the trends are and all that stuff. And so I started noticing that the world was running out of engineers. Yeah. That's fundamentally what was happening back then. Yeah. And I mean, you know, like you also, I think some people were externally,

it looked a bit surprising because you were doing great at Google and you went to this scale up grab. I mean, they're growing fast, But I think some people are thinking, well, why is TV, I get going after Google to grab? Why were you going, by the way? Well, you know, I mean, GeoWorks, Amazon, Google, all really similar in a lot of ways. You know, GeoWorks was more like device software, but still, right? Yeah.

You know, grab, I had a buddy from Google who was CTO there, right, Theo and Vosalakis, and he was like, man, this is an adventure, you've got to come. So I started chatting with them and realized they were on just, I mean, that Southeast Asia in general is just this incredible productivity explosion. And it just seemed fun, right? Yeah. And it turned out to be actually really fun. It was.

And then COVID killed it. So, you know. Back then, like this get that job, job at grab, you did describe how the market was, was really heating up and, you know, some things happened in COVID. But what you wrote here is so now there's a gut of an investor money as creating a lot of startups, a lot of startups, including some very big ones. And they're gobbling up all the energy left on the planet. And now it's a fight.

Yeah, it got worse after that. Yeah, I was out and asked, like, how did you see it play out and how did it continue all this today? Because I feel today we might see something similar in a different area, right? Yeah, I mean, there's a lot of investment coming in, for sure. It's coming in hot. Right, we went through a huge spike right after I posted that because shortly afterwards was COVID, right? Two years later, we had the stimulus package. And that gave everybody a lot of money, and that was like tons of startups appeared because of that.

Yeah. So, so many, right, great time. So many founders. And so great time to be a remote engineer, basically, right? Then the stimulus package, the stimulus money went away, and things started a kind of crash, and then AI came out, and everybody got really uncertain. And so it kind of dipped a little. It has dipped, I think.

If you just look at Indeed's report, you can see jobs have dipped pretty heavily since their peak in 2021 or 2022. Yeah, possibly. But we also see a productivity explosion. on its way, like a boom of jobs coming. So it goes up and down. But yeah, I think at the time, at that time in 2018, the market was showing signs that it was going to,

and that's what, look, that's what everybody wants. They want to predict what's going to happen. Not just as though they know what stocks to buy, right? But also, you know, how to make the right decisions for their companies or their careers. And right now, I think you and I both agree that things are kind of headed back up right now. Yeah, yeah.

And we'll get into that. But I want to go back to this. second time that. So the first time I came across your blog, I didn't really even connect the name with the face back then was get a job at Google. The second time was, was a few years later, which was this Google platform rant, which was published on Google Plus, right? Yeah. So it was an internal facing document. Apparently you wrote a lot of these or just like rants or like meant for Google internal only. And somehow it was set to anyone. could read it on the intro and Hacker News jumped on it.

And as soon as it went out, you know, people archived it as well. First of all, how did this rant came along? Because this rant has been so referenced. It's now, I think, on GitHub as well as TV's platform rant because it was a really good criticism of Google. And not just that, but it was kind of a really realistic, like, picturing of Amazon, including Jeff Bezos, not giving a shit about your day.

Which I think, you know, people were like... He still doesn't, you know. Yeah, but it just felt very real and raw. And clearly it was... I understand it wasn't meant for public consumption. But, you know, like, hey, did you write these kind of things all the time? Like, because we only saw this one thing. And I've heard that you had a history of just internally just keeping it really real.

I had other ones internally. Sure. None of them were quite that, I guess. accusatory or whatever. I mean, like, I was really taken Google to task because I was fed up. I'd been there six years and I still couldn't get a platform at anybody, right?

Yeah. Like Google to ship a proper platform? Even internally. Like, the code search team didn't want to give me an API. It's inconceivable today. You'd give somebody a rest API to your stuff, right? That's the way we think today.

Yeah. Well, outside of Google, inside of Google, who knows? They're just not really big on internal services. They're just, like, use our product. Yeah. I drove me nuts. Completely enough. I went nuts.

And then a bottle of wine later, I, yeah, told him how it was. Yeah, so let's recall some of that part because I'm going to link it, obviously, so people can read it. But first, you started summarizing on what Amazon did right and what you observed throughout your time. You were early Amazon, right? Yeah. Earlyish, yeah. I got there in late 1998. It was pretty small back then.

We were in one building in downtown Seattle. just a three-story building. Wow, that's it. A four-story building of which we occupied three floors, I guess, is not yet. And, yeah, there was just one data center at the time, and it was just a very small. It already had a cult-like sort of feel to it, right? An electric feel. Yeah.

I mean, a sense that there was something really magical going on. So was this still the bookstore part, or was it already expanding beyond books? When I joined, we already had a... music and I think we were just launching video. Yeah. So I think we had just brought our tab. It was really early on. I have to go back on the McAtanastrian.

Yeah. Yeah. And then like, you know, as you said, that basically Jeff Bezos mandated platform, APIs? What did you do there? You know, it's interesting because everybody thinks that there was a real memo. The memo was, I don't know, there was, Jeff wouldn't write an actual memo, right? What the fuck would he do that?

He just tells people stuff and it happens. But the customer service organization in particular was, I was in customer service tools at the time. I may have been running customer service tools at the time. Bezos would sit with us every week in a meeting and we would look at the top 10 reasons that customers were contacting us, right? Yeah. And he'd want to know why are these customers still contacting us saying they're getting triple charge for their books? That kind of thing, right? Number one was always, where's my stuff, right?

Yeah. customer service had a really interesting need. I may have been, you know, I've never thought about this before, but it may have been Jeff's sort of affinity for customer service, wanting to be the Earth's most customer-centered company that led him down this path of forcing people to open up their APIs because the customer service team kept saying, we can't make any changes to Obidos, you know, our web server, because that's their code. We can't get into the supply chain code. We can't get into the fulfillment center code. The customer, we can't help the customer. And Basel was like, all right, tell you what. Right? I'm going to blast anybody standing in the way of that.

And what that turned into was, well, you need to provide something to the customer service technical team that's not them going and linking against your code and trying to get it to run locally in some different environment, right? Yeah. Which is what they were doing with this awful C++ code. So, yeah, so that's kind of the origin story. Yeah, and then this was like around early 2000s, right? Like before, you know, we even had things like services or microservices. Yeah, well, back then, the services were things like they were,

proprietary protocols like Corba, like Cipco and Tularean, the PubSub things, and they were all really nasty binary formats. And there was this possibility to do rest, and some right, it had been invented at the time, but everybody was kind of poo-pooing

and saying, no, no, nobody really kind of understood it from years. No type of safety, no protocol. Yeah, it took years. But it turned out, yeah, that's what you need. You need an API. And that was the origin of my rant, too, right? Which was, I talked about Amazon does stuff mostly wrong.

This is how he started your memo. So that was actually fascinating to read. I think it was clear that you were on Google's side, right? Like, even though you're trashing Google, it very clearly came through that you actually wanted to like shake things up. Like, hello. Like the memo when I read it, it felt like, hey, like, we should be better than Amazon. Here's all the reasons.

And here's the things that they're doing better. And it's not that hard. We just need to do that well. And then we will be better, right? I mean, it made sense, right? Yeah. And I just felt like we were good at everything else. We were good at a lot of stuff.

Google was extraordinarily good at a lot of things that Amazon had no clue how to do. Really? And it took Amazon years to catch up to Google in a lot of things. So let's talk about that. What were the things that Google was just really good at? Like Google had one service called Stubby. I think I even mentioned it in the post called Stubby.

Or sorry, Chubby. Chubby was the locking service. Chevy and Stevy, they went together. The locking service? Yeah, the locking. A distributed locking service. Those are not easy to implement. Okay, we're talking, you know, Paxos times 10, you know, make sure that things

stands up all the time. It had seven nines of availability, which is like, yeah, yeah. It was like basically 30 seconds of downtime every 10 years. Oh. Okay. It was a very reliable service. Oh, wow. Okay.

Now, one example. Five nine is hard to get to. Amazon, seven, yeah, five is almost insane. Seven is just like, what? So that was just one example. Bigtable, early on, they had like free, basically, like, unlimited, no-sequel storage with some pretty good query facilities for everybody in the map-produce infrastructure, Google invented it, you know, and on and on, right? So, like, really good, really good hardcore engineering problems solved in a, in a, like, way that is, like, just tough, tough to do. I was very impressed. I slapped myself, like, my forehead sometimes when I was, like, I'd see some of the stuff they did.

I got there, and I'm like, why did I think of this? Like, I had this game that I had a custom-arper. When I looked at Google's, which is now GRPC, it was called protocol buffers and stubby back then. You look at it and you're like, oh, wow, it's a forward compatible protocol. I can add stuff to it without breaking it, but it's binary and high performance. And yes, it was beautiful. It is beautiful. Surprise people more people don't use it, to be honest. So yeah, they did a lot of things really well, but they didn't do platforms well at all.

It wasn't part of their DNA. They just didn't get it. And it was, they didn't do internal or external or neither. Neither. Neither. Neither. And then so you rolled this rant, which again, like, I think, If you're listening to this, you need to read that, rent.

It is like one of the best things I've read. It's also very entertaining, by the way. What was the impact? Because obviously you send it internally. It now leaked externally. So clearly, you know, people were making fun of Google. Did it achieve that shakeup effect? And, you know, how high did this thing get?

I'm pretty sure it must have gotten pretty high. Well, I mean, Google had a very open culture. So it got brought up at the next TGIF, right? Thank God it's Friday, right? it's Google's iconic Friday meeting. It's like all hands-ish. I remember Ben, the guy who was in charge of our fulfillment centers, not fulfillment centers, sorry, our data centers at the time.

He stood at there and said, well, you know, we all read the rant. So, you know, they got a kick out of it, right? But, you know, Vic and Dutcher was pissed. I mean, he was really, really mad, right? Yeah. Because I had, like, told him he had an ugly baby and very, very loudly in public. Yeah. Yeah.

You know, and I'd used his ugly baby to do it. This was the developer saw Google.com, baby or something else. Google Plus. Oh, Google Plus. I called Google Plus Ugly, right? Yeah. And, you know, and he was like, he was really gunning for the head spot at the time. And he had planted the seat of fear in Larry Page.

He was like, Facebook's going to kill us. Facebook's going to kill us, right? We had to have a Facebook, which was stupid for many reasons. Yeah. Some of what, oh, so I'll tell this again. I'll say this again. That blog rant, that famous rant, was actually part two of an 11-part series that I had meticulously planned out. And I never finished because I accidentally published the second one externally.

And the implications were actually so big that I was kind of like in hiding for a while. But yeah, no, I was actually picking apart Google Plus dimension by dimension. And platforms was just one of the dimensions where it was failing. But you were actually right in hindsight. I was right about all of it. But they never said, sorry. I was also right about not getting into publication ads. I was right about a lot of things at Google,

but I'm not very good at convincing people that I'm... So tell me that story, because you've told me this story once in the news that around. We mentioned it super briefly. You killed publication ads. And this was, like, as I remember, like, what happened is you joined Google, and then what did you do the first time? I went around to all the projects.

I was allowed to pick whatever I wanted, and I picked print ads because I thought it sounded like a cool challenge. I became a domain expert over the next six months. months, learned everything there was to know about magazines and new paper publication ads in the United States, and concluded that we were never going to make a dime, that all of them hated us and blamed us for the declining revenues, and they wouldn't want to talk to us, and we were evil. And I wrote it up as a big decision tree. I said, we could try this, we tried this, it didn't work, tried this, the whole thing.

I mapped out the entire decision tree of everything you could do. And they said, well, what about illegal stuff? And I was like, I'm not going to entertain any of that stupid stuff, all right? It was like, they didn't put that in writing, but, you know, it's like, what if we just, what if we just sucked up the phone book type stuff? Yeah. So, like, you know, I declined. And then they got mad and they sent it to other teams and the other teams failed and came back to me for my postmortem. So they tried to make it work?

They tried again in Mountain View and then they tried in England. And they couldn't do it because I was right. I never got so much as a I'm sorry or a thank you or anything like that. No. Yeah. But, like, you concluded this is not worth it. So you, well, first of all, you said. said, like, if you were you, you wouldn't do it, and then you moved on to the next thing,

and then they failed to her tweet, well, like, sounds like twice. I did make a proposal in the post-mortem, which was very similar to what ultimately turned into Groupon. Yeah. Yeah. So, you know, I mean, it wasn't like complete shooting a day. Yeah, yeah. You could do one thing, but I said, you will need a sneaker network of, like, 8,000 people

somehow, right? Yeah. Which was what Groupon ultimately did. It's fun to be right. It sounds like, you know, you just, like, you know, you did the best that you could. you gave the best. And then you also like, sounds like you were like,

look, if you want to try it, like do it, but like I don't believe, like I believe this will not work. I believe we could try this and then just leave it at that. Right. Like,

you know, you did what you believe then? Yeah. What do you think happened to Google Plus? Like I, I remember, you know, Google launched Wave,

which kind of like died down pretty quickly. It was supposed to be the next email. That was the first time I was like, I remember like this early 2010's Google could not do anything wrong. And every time they launched something, I was like, wow, this is the next big thing. They launched Google App Engine. I was like, it's the coolest thing. And I onboard it, and it was so cheap.

It was ridiculously cheap. Later, I figured out why, because they were subsidizing it. But Google Wave was the first one where I remember all the online portals, tech crunch, et cetera, was like, Google has replaced email. And we're like, oh, wow, Google has replaced email. And you tried it out and didn't work. And then Google Plus came along. And I think we understood from the outside, not as Googlers as like that Google was, like, that Google was, trying to really take on Facebook and if they didn't succeed, you know, Facebook would win.

And I don't think we, from the outside, it seemed like it was going going. Yeah, it was, it was, it was pretty ugly. But then it just kind of stopped. You were in the inside. Like how did this play out? Because I think we've heard there's like books about like Facebooks went all in wartime. They were working, you know, hard and they actually saw this as a major threat and it would energize them. What do you think might have won't draw on there? Or like how much advantage point? did you then have on this? I mean, I was there. You know, I'd talk to people who were in the heat of it, you know.

Like, Wave was targeting a space that ultimately got solved by Slack. Slack was the right form factor, and Wave wasn't. And when I saw Wave, I was totally unimpressed, but it was like they had cast a spell over everybody. And I didn't see what, I didn't get it, right? But I got Slack instantly, right? And we all did. So it was very similar, I think. It was Google had trouble, struggle to find the right form.

factor. This was why I wrote that 11-part series. It's because I knew that if they basically acted right then and got Reddit, just took them, just bought Reddit, okay? And took over that sort of that social network, they would have had something. They would have had something. This was long before Reddit was in the top 10 in the U.S., right? This was right. Reddit was hot that only were like tech geeks, right? Yeah. Dig was also big back then. Dig, yeah, as before pre-pregs, you know, blow up or whatever. Oh, yeah. So I wanted them to, I wanted Google to start to either build a Reddit that was done kind of like slightly better because, you know, Reddit evolved and even they want to change it or something, fix a lot of things.

Because it had to be different from Facebook or people wouldn't be able to migrate because either the network effect fundamentally, right? And Google just, I mean, it's so weird, man. Companies are like people. They're like human beings. They make decisions, and the decisions can be just absolutely terrible. And everyone around them knows it and they're all embarrassed. And they try to tell the company and the company's like, don't tell me what to do. Yeah. That was his old. It feels like it.

So now, looking back so many years later, you know, you've left Amazon, like, I don't know, like 10 plus years. Even more, it's the same with Google. How do you think Amazon? 20 years. 20 years. Yeah. How do you think both Amazon and Google, have changed, but also in what sense have they not changed?

I think Amazon's changed way more than Google. You're the first person ever to ask me this, so thank you. Amazon has improved dramatically in almost every possible way that you could improve. Really? Yeah. Amazon has always executed better than anybody on Earth, but they found a way to do it without, you know, having all of the flaws that I mentioned at the beginning of my post. Yeah. Yeah.

They've, it's really, it's quite nice now. and people that I know who work there are pretty, pretty satisfied. And they're doing well and they still execute well. They're a company that makes good decisions by and large, just like Apple. Of course, they fall in their face once in a while, what company doesn't. Yeah. Google has not changed since the fucking day I joined. End of story.

So recently someone at Google was asking me about, like, what do I think about Google's developer story? And I said, like, do you want me to be honest? I said, developer what? And my example that I showed that this person is Flutter versus React Native. Now, React Native is about 10 full-time people at Facebook and a few other, in the core team and maybe a few other people from some other companies, maybe like 15 person. But Facebook invests like 10 full-time people. And if you go to the showcase page of React Native, which is, you know, where you show, you. you immediately see logos. Meta, Microsoft, Amazon.

I think they have someone big, just like flagship apps. And then you have, oh, and then you have Shopify. You have like all these big companies. And, you know, you will find the blog post. Shopify says why went all in on React Native? Why we have thousands of developers working on React Native? And you have all these case studies. React Native is inside of Meta's Facebook app.

It's inside Instagram. It doesn't run the whole thing, but it's in there. Obviously, their ad stuff. And then you go to Flutter page. Now, Flutter has at least 50 full-time people, so five times as many. And you see some small Google apps on the top. It looks nice. But then you scroll down, and it looks like an intern made that page.

Like you have some random Chinese app that you never heard about. And then BMW, which is a brand that you know, it's somewhere in the very bottom. And like, there's no apps. There's no big apps. There's no big logos outside of – and even for the Google logos, their Flutter is not used in any of their flagship apps. So I'm like, startups who are deciding which ones use, just based on this, they will go for React Native. It actually has the street cred.

And I asked someone at Meta, like, how did you guys pull this off? Like with a smaller team, you executed clearly what I think is better in terms of like you got the big customers, you're building for Google. He said like at Meta, everything is about impact. And the React Native team, the first thing they did is drive impact. They got React Native inside, you know, the biggest apps into Instagram, Facebook. etc. And then the rest came because Shopify is like, well, if it's used inside of Facebook with,

I don't know how many thousands of developers, we can use it as well. Yeah, I mean, look, Google can't afford to be disintermediated in the mobile space. They can't afford to just become the plumbing that people can swap out. And that's always been an existential threat for them. The Facebook application is a platform itself,

and you can write applications inside of it. And so, like, if you're writing for the Facebook platform I mean, you're the New York Times or whatever, like, who cares if you're running on Android or iOS? And that's Google's worst nightmare, right? Yeah. And that's why Facebook and the age of AI hasn't laid off the React Native team, because that's there basically, hey, you don't own Android, we do, right? Yeah. That's their play.

And so Google, they'll never give up on it. What happened was, unfortunately, Flutter's not from the Android team, and that pissed the Android team off because Android is... Politics. Android was an acquisition. Yeah, a good idea. The guy that ran it was... very particular about them being sort of in charge of their own destinies and not beholden to anyone else. And he kept Android sort of running the way that they ran it inside.

And they made all the decisions and the buck stopped there. Flutter came along and sort of threatened their dominance as the platform. And it pissed him off. And Google has been sort of unable to reconcile those things, even since 2018, when I was looking at this problem, 2017. Yeah. And one of my biggest question marks about Google and why they have not changed this is around their cloud platform. So when I worked at Microsoft, well, I like I said Microsoft, it was Skype. They just bought Skype and they left us alone.

So it was Skype. And then when I turned Microsoft, I kind of, I was like, all right, this is, I don't like that much. But they gave us a mandate. They said, you need to use Azure. And we were one of the first, like, we were the new purchase. So they just dumped it on us. Azure was not ready. And I was sitting next to the data team, the Skype data team, who had all our data centers

and they're moving over and they're saying it's just a huge pain. it's like we don't want to do this, but it was actually, Balmer was forcing it on them. And it was this blood, sweat, and tears, and eventually they moved. But what I've seen is, like, over time, you know, now when I talk with teams at Microsoft, like, what are you guys using? Obviously, they're using Azure. Or Bing might not be using it, but it's fun.

AWS is using AWS. And I talk with teams at Google. What are you guys using? Org. Like, hold on, why are you not using GCP? Well, it doesn't scale. It doesn't have the things we need. And, like, how can you be gunning to be number two,

or one day maybe number one cloud platform if your own company comes up with excuses. And I never understood, I try to ask this on back channels from people working at GCPN, they always come with excuses. But I don't understand how is it that it's the only cloud company that does not use its own cloud service for their flagship service, for the flagship products?

I think it's all just who's been the most successful at marketing and convincing people that they're using their own clouds. But they are all currently huffing their own fart. Amazon doesn't use AWS. No, I heard so. Sable ain't AWS. Okay.

I mean, like, right, for the retail side, for the ad side. I mean, like, of course, they want you to use AWS, but all the core, the core, core stuff, and they haven't migrated, man. So, like, it's all free-frew in far as I'm concerned, right? It's all like... I think it might have changed because it is less, they had a name for the old stuff, and I think more and more things are moving over.

That's fair. Never bet against Amazon. Yeah. AWS may have actually graduated at the point where they can't. actually use it internally. Yeah. The hurdles for Google were insurmountable. Mm-hmm.

Insurmountable. So maybe this is fair, by the way. So maybe this criticism is not entirely fair, because what I understand is their infrastructure is way bigger and more complex than anything else. It's sort of fair to say that Google's cloud runs on top of Google's infrastructure, which actually does scale the biggest in the world. That's pretty than Amazon. Well, one thing that I am wondering, because I'm still waiting for what will the tool or

platform B that Google releases that their internal tool teams use it, and they're like, oh, we have, you know, 100,000 or like 50,000 or 100,000 software developer. It's like Google using it. You should use it. You know, Microsoft did this with like visual non-gooder. No, no, no. It's not some Google tool. And I'm thinking, could we see this maybe with some AI tools, you know, like AI coding tools, et cetera? Like, could they finally do this? Or maybe this is not a Google way to do it. They'll be like, right, we have our superior internal tools and we will build an external thing. You know, we have Borg, we'll, we'll build Kubernetes for everyone else.

I don't, I just, I don't, I don't, I don't think Google understands developers. I don't think they ever did. Ironic. It's, it's, it's, it's, it's really closely related to their, their blind spot around platforms, right? If you don't get platforms, it's because you don't understand developers. It's just ironic because Google, like, no company or few companies treat developers as good as Google does, right, in terms of. Yeah, and few companies, few companies have built a platform as incredible, internally as Google's is, you know, you know, at the sort of foundation level.

Yeah. You unretired. You retire for some time. And then you unretired because of, well, initially source graph, but then also AI. Yeah. What made you kind of come back into the game? It's not a binary thing. I've been gradually unretiring.

If it means any sense. And it's because at first I was like, you know what? I'm really climbing the walls. I really want to just go work with some people. And so that's, you know, that's where I wanted to be source graph. like that was familiar ground, right? That was Google code search for everyone else. Yeah, yeah.

And then shortly afterwards, the AI showed up. And I was like, that was like the next step up is, oh, man, maybe I better get back into coding again for a while because this looks really different. So fun fact is last time we talked about three years ago, you were head of engineering a source graph. And actually people told me at source gap you came in. You made some changes, which were actually like pretty well received. But like you shook up, you introduced where people could job there, that kind of stuff. And then next thing I know is like, oh, you wrote this, like, you write about everything, which, you know, we'll link some more and more things, but I love writing it. But you wrote about like, oh, I'm stepping down as heavy engineering because I'm going back to coding, which was not what I would have expected again from just.

And I view that as another step in me sort of coming out of retirement, right, because I had given up on coding. I just, it wasn't worth it anymore. Kent Beck had given up on coding. A lot of my old buddies and colleagues, right? You know, there's just like environment setup is just over the top these days, right? And, you know, just building a simple web app, you probably have to use, you know, 25 different frameworks, many of which I have incompatible competing, you know, whatever.

Yeah, and as soon as you update to the latest react to the thing, all the router is bracing, you have to relearn it. Who wants that? And so at some point you get tired of it, and you're just like, I'm done, man, I can't. This isn't, it's not worth it, right? And AI completely turned that on his head. And I saw it coming as soon as chat, GPD came out. I was like, oh, wow, look, you can write an actual function that's reasonably good, right?

And then when 4-0 came out, then I was able to project forward with exponential growth and say, uh-oh, uh-oh, it's coming. So now I'm getting sort of like more and more fired up with each passing month. This episode is brought to you by Sonar, the creators of Sonar Cube, the industry standard for integrated code quality and code security that is trusted by over 7 million developers at 400,000 organizations around the world. Human written or AI generated, SonarCube reviews all code and provides actionable code intelligence that developers can use to improve quality and security early in the development process. Sonar recently introduced Sonar Cube advanced security, enhancing Sonar's core security capabilities with software composition analysis and advanced static application security testing. With advanced security, development teams can identify vulnerabilities in third-party dependencies,

ensure license compliance, and generate software bills of materials. It's no wonder that SonarCube has been rated the best static cone analysis tool for five years running. So join millions of developers from organizations like Microsoft, Nvidia, Mercedes-Benz, Johnson & Johnson, and eBay, and supercharge your developers to build better, faster with Sonar. Visit sonar source.com slash pragmatic security to learn more. One thing that has, we've talked a lot in the industry and everyone's talking about it is how AI will first and foremost, simple. I think, like, experienced developers, we can get there, but how will impact junior developers? And you wrote this, again, controversial title, the death of the junior developer.

But interesting enough, when you read closer, a lot of your articles are Lucas, by the way. Like, there's a title which you think, like, oh, it's the end. But a lot of them are wake-up calls. To me, when I read it properly, it wasn't like, oh, there's no more junior developers. It was a wake-up call saying, hey, if you're a junior developer, you need to get your stuff together quickly and change like like whatever the junior dolepers before you were it's not going to work for you so like what what what is it what is it that you've seen and like that something inspire you did you like see some some some some young titans who are actually just doing great with with these tools man you've hit on a question that is just so fundamental and foundational to our industry right now it's shaking the industry that question

you know and the answer is i mean you know the shortest way you know that i would think about it is AI is not easy to use. And the more senior you are, the more likely it is you're going to notice when it's being bad, when the AI is being naughty, right? It's just common sense. And the AI is very naughty

and in very subtle and insidious ways. And even as they get smarter, and they are getting exponentially smarter, and they will be frighteningly smart within a year, they will still, I mean, software is always bigger than they are, right? And they will still make silly, do silly things. And it's just going to bias

towards more senior people But it's not really seniority we learned. It's nothing to do with junior and senior. It's really more about who is demonstrating the ability to work well with AI and get good outcomes in software. And that could be anyone, a product manager. So I think there's a big shakeup coming where the roles change and everybody becomes more focused on what they're building

instead of like who's building it. And have you heard about the collapsing, the stack stuff from Scott Belski? Can you refresh the know? Basically, like there's a line of thinking that we've oversaw. specialized and everybody's like incredibly domain expertise specialized. And you got these senior engineers at Google who know exactly how the fuse file system drivers work for every version of a Linux kernel. Right?

Like, we don't have that anymore. We don't need that. That's stupid. That's going away. But all the specialization is going away because AI is democratizing all of it. You can't hide that knowledge. This is interesting because I just talked with someone, I think, a week or two ago, about how what has changed software engineering, even before AI and what has changed back in early

2000s. When you looked at software developers, you had the Java developer, you had the Doughton developer, you had the Python, and these were different people. It was the Java developer would not do dot net, even though they're pretty similar. So on the back end, languages were specialized. Fast forward to even before AI, like 2015 or 2018, when we had a big hiring for it. Like when I worked at Uber, we no longer, like, Uber was seen as like, oh, this completely change. We didn't care if you did Java or dotnet or whatever. you come, you know, one of those languages, you'll pick up whatever we're doing.

And at some point, my team was doing Go, Python, Node.js, and what else? We're still doing something else, but we're doing all of it. So, like, we started to have less specializations. So I wonder if this thing started earlier, and maybe AI actually just makes it more viable, that now, until now we've had, you know, a front-in engineer would not touch back. And they might understand the concept of APIs, but now they actually can. In fact, when the product manager can actually create pull requests. Yeah, we see that now, right?

Like at Sourcegraph, one of our UI designers is now sending pull requests for the UI instead of asking engineers to do it. And are they any good? They're actually decent or good? Look, I mean, it's all over the map. It's just like, I believe this is the new role for junior developers. Is they're going to be mentoring the next layer down of non-technical or technical adjacent people who are now starting to contribute PRs, right? And they'll be the ones who are like helping them fix the security issues or whatever else they have with their. Basically teaching junior Velf is because they're still trained engineers.

Yeah. Right. So they can teach like a UX designer or product manager. What are the right questions to ask the AI about your thing to know whether you're done or not yet, right? You know, you know those kinds of skills. I like this because I think we all know things will change. I think we're all struggling to like put the finger exactly. I mean, you clearly have a bunch of conviction, which I think is great.

because I think you need conviction in this areas of going around them. And I have been, so you know, you work at source graph. You guys are heavily using your AI. In fact, you have your own AI tool, but you've been using the existing tools from the beginning. And most of the stories I'm hearing so far about a non-technical person doing technical stuff is at AI companies where they're surrounded by these people. Winster, co-founder CEO Varun, he told me that they have a, I think it was a, who had a sales tool, and they just kind of vibe-coded it with Winsterv. It had no state.

It was a super simple thing. You know, it's not complicated. But that person did it. And I wonder if, you know, we might be seeing these type of like kind of AI or just very sharpy environments, like lead the path of what the kind of your legacy or larger companies will be in 10 years. Yeah. Absolutely, man.

We're seeing it everywhere. I mean, we're seeing companies where marketing teams are writing their own, you know, outbound campaign software. You know, we're seeing product teams, you know, bypass vendors. They don't have to re-up with their renewal or contracts with some crummy vendor software because they wrote their own and had somebody from engineering just vet it and be like, okay, yeah, you can make these two changes. So I want to ask you a little bit about that because I'm a bit skeptical about that.

Have you seen like specific examples of what they replace? Because, for example, with work date, you're not going to replace that, which has all the compliance, a lot of state, a lot of regulation, and a lot of ongoing maintenance. That is not what you're going to. But what are the things that have you've seen? Well, this was a, so imagine a company with a lot of really bad actors coming in

and trying to crawl over the site and find fan bad ways to basically siphon money out. So they have many, many different kinds of teams that are looking at different kinds of fraud and different kinds of attacks. And there are lots of kind of bespoke tools. And so you get into this long tail of little vendors that offer these crummy tools that are really expensive.

Very vertical, domain-specific. And so the product team at this one company was like, screw it, we're going to ask AI to build it. We'll give it the specs. We know what it wanted to do. And they built it, you know, in Python, you know. And so it wasn't production software. It was software that they use as their investigation trying to find bad actors. Nevertheless, it saved them from a re-up with a contract that was rather expensive.

And it gave them, they were happy, right? You know, they had full control over the software. They could make it do whatever they wanted at that point. So they were starting, and this is just one of probably a dozen examples I could give me. But we're seeing it. But let's carry on that thought, because you know what we built software. We've seen the internal tool that the team has built. In fact, Google is famous for building all the internal tools.

What is the next episode? Like, can we just move? Because we know what's going to happen, right, as experienced people who are working software. So what was happening next year when there's like more functional to be added? How far might be able to take it on? What's going to be the breaking point? Because this happened before, before AI, right? Like one internal developer wrote it.

And at some point, it becomes like, just, the pain, right? Yeah, look, I predict, I'm going to go around on the record and I'm going to predict that there is a new role, a new category of roles that's going to emerge that are the Winston Wolf that are going to come in and fix shit that you broke with AI. They're going to be fixers, and they're going to come in and they're going to be small and large. I actually call them. Let's give us role name.

Call it. Let's call it fixers. Cool name. I don't know. Fixers sounds pretty good. But whatever, right? I do think of those fixtures in the sense that, like, you've made a horrible mess. You've realized that that this comes.

company that promised the world to you because like something like 60% of all the world's programmers are systems integrators. They go to big companies that are desperate and they say, we can make your systems talk to each other and it'll be really expensive. And 70% of the projects fail, but companies go for it anyway. That whole, that whole economy of rich country setting work to poor countries, the architects and all that, that's all getting potentially turned on its head because we don't know who's going to be doing the work now, the actual implementation, right? Is it the rich companies that are going to do it for themselves now? A lot of economists are looking at this problem right now, right?

Yeah, but we've seen this without sourcing. Don't forget. Like the whole idea without sourcing from the 90s, I kept hearing like, oh, all the highly paid developer jobs will go to India or Asia because it's cheaper. And then it happened but also didn't happen. Yeah. That's how, I mean, look, I think, look, it's going to ultimately be cheaper. If a human being needs to babysit 10 AIs to get a project done, it's going to be cheaper to have that human being in Vietnam than in the UK. But what the reason we have developers sit next to the business, because we're, we're going to be able to, because we're.

where are sitting next to you can actually talk to them. And that communication, I've seen this, you must have seen this a lot. So when I was at Uber, we do this round-robin, and Uber still does it to this day. It's like, HQ is there in San Francisco, and it's very expensive to hire. Amsterdam is half the price, and India is one-third of the price. So there's this round-robin of like, okay, let's hire people in the U.S. And like, oh, it's expensive. Let's hire in India.

Okay, we hire for a while. The world turns out you can get less experienced people. There's communication issues. it's kind of breaking down. Let's now hire an Amsterdam because it's closer. It's kind of midway. And then it comes back at something, let's hire it. And it just like every few years, it goes to the next one.

And it's just a repeat. Like they're cutting Amsterdam and now they're actually hiring it. I'm like, right? Yeah. It's been like four years. Outsourcing is one of those classic expansion contraction cycles that a lot of companies just go through periodically, along with centralizing and decentralizing QA

or centralizing, you know, TPMs. or whatever. Like, they just, like, they'll try both, and the grass is always greener. They can never make up their lines, you know. So your new book is, the title is vibe coding, and it's a heated debate if you should even call it vibe coding

because the definition. So let's start with what do you define as vibe coding? Vibe coding is when the AI writes the code. All right. There's a reason that that definition is going to win. You can't put an if clause in a slogan. Use vibe coding, as long as you're doing a fine print. which is what they're trying to do

is they're trying to put a condition on it. I agree by the way. You can't do that. It's the caps out of the back. That's how I've heard people use it as well. It's like, you know, like some people use the pro procytide.

The point is like, yeah, you're kind of like, I'm in this vibe, I'm telling, I'm letting it go. It often is an Asian mode, you know, where it kind of goes and does stuff, but it might also be, I might kind of rain it in, but it's just, like, you know, like, vibing. Like, so I, I, I think,

this stuff, I think because a lot of people are pointing to like Andre Carparty's tweet or however he defined it and yeah, I think it'll just come into like whatever it makes sense. The question is, is it giving you a buzz? Like for real? Because programming can give you a buzz. When you get into flow, right, you can get an actual buzz going.

And you know what? It is insanely addictive. Cloud code and friends, Sourcegraph AMP, you know, try them out because wow, they're like a dopamine hit. It's like a slot machine. They're literally addictive. I mean, Ken Beck told me, the same thing, and I've experienced the same thing.

Like, I have this site project, which I just don't like to touch. So I try to build my APIs on the site and not pay vendors when I can, but it's just a hassle. It's somewhere on AWS, and it's a hassle to, like, remember how I deploy. But with Winsturf, like, I had one of, I just built a small API on how people can claim perplexity and Kagi codes, if they're paid subscribers to the newsletter. And I connected with an MCP server. I connected my database. I can just talk to my database.

I said, like, oh, how many people have, you know, requested codes? And they're like, oh, today there's like, like, the last 10 days. Like, oh, nine days ago, there were like 20, 30, a thousand, 2,000, 3,000. I'm like, hold on, like, what is going on? Like, that doesn't look normal. And I asked, like, can you analyze the patterns, unusual patterns? And then it told me how, you know, like, there's the same email with different cases. And I needed to code a fix for this.

But I was about to have dinner. And usually, like, if I don't have, like, 30 minutes to code or an hour, it doesn't make sense. I had like 10 minutes. And in that 10 minutes, I got like a fix done. I went and had dinner. I actually was, you know, present on the dinner. And I came back and I got back into it. And in a total of 30 minutes, I did stuff that would have taken me like even if I had the hands on like two hours easily.

And I felt like, hold on. I'm no longer worried about like falling out of the flow. So like there is a lot of new stuff that it doesn't make you more productive. And as an experienced developer, like it's amazing. And now I understand why Kent Beck is saying in 52 years, he's never felt this good about or this excited about writing code. A lot of your listeners, listening to us right now, have no idea what you're talking about because they haven't actually tried the terminal app versions of these things. Like Sourcegraph Amp and Cloud Code and Codex from OpenAI or Klein, right? Yeah.

And by the way, Klein is going to start taking on real, real importance being able to run local models. as soon as local models reach where CloudSonit is today, because CloudSonid is very viable if you keep it on the rails. Because look, let's face it, the reason people are screwing this up and saying, this doesn't work, and I don't understand why AI works, and all these stories are BS. It's because it's very difficult to wrap your head around the fact that you can't get an answer out of the AI.

All you can do is converge on an answer together with it, okay? Even if it's an agent running off and doing things, you're still doing it together, and you're going to eventually converge on the right answer, hopefully, most of the time. Sometimes you have to go try a different model, right? And you will very quickly learn the limits of their sort of cognitive ability, and that will be the constraints that you have to work within. And it's not easy, man. It's not easy. People expect it to be easy. They want it to be handed to them.

Well, and also people, I think there is this strange. I'm trying to put a finger on it. But like the first time I use chat GPT, it was magic. It was mind blown. I think I think most of listeners have had this experience. The first time I connected my MCB server, my database, in my case, it was wind surf. It could have been. Curseur could have been anything else, and I solved something with, you know, the agent. I kind of guided it, but I was just a bit lazy, and I knew what I wanted to do, and I kind of stopped it and got it done, and it got it done so much faster. There was magic. But what, I have a feeling that would Chadge, be the magic faded after a while? Like, it was magic initially, but then it's work. And I think somehow we, a lot of people, like, either get disappointed after the magic doesn't continue.

And my most surprising conversation was Simon Williston, who has been, you know, the creative Django. He is a super productive developer. He writes so much code written for AI. And he told me that this thing is hard. And in two and a half years of nonstop using it, he keeps learning. And to me, like there's this contradiction. Like it feels so easy, but it needs so much work. What is going on?

Yeah, that is a really weird contradiction, isn't it? It feels like it's making your life incredibly easier. and yet it's very, very non-trivial to keep the thing on the rails. It's like a toddler with a chainsaw, right? Like, seriously, okay, let me tell you why. I'll tell you one reason. This is from Jason Clinton. He's the C-Sode Anthropic, and he was kind enough to share with us.

After I whined at Gene Kim's Engineering Leadership Conference a few weeks back, I whined that Claude had deleted all my tests and said your tests are all passing now, which is true, they had passed away, like they were gone, dead. It deleted it? It deleted them. And it's like, all tests passed now. And it's like, well, goddamn it, right? I mean, you know, and so Jason told us, well, what happens is, what happened was Claude was trained on a reward function, and it wasn't trained not to hack that reward function, okay?

And so it will cheerfully hack it. And so that's the state of the art today is it will tell you it's done. And what you have to do is say, no, you're not. And send it back to the drawing board. Ken Buck was literally saying the same thing. He calls it a genie, which is it grants your wish, but sometimes in unexpected ways. Exactly. It's a monkey's paw sometimes, right?

Yeah, you've got to be really careful how you phrase things. You know how you know the moment you know your modern programmer, when you come down and sit down in front of your computer one day and realize you don't have any instances of any IDEs open and you're writing more code than you ever have in your life. So everybody listening in, if you've got an IDE open and you're looking at source code, you're doing it wrong. Isn't that funny?

Man, people are going to be freaked out about this. So until AI really took off AI coding tools, one of the hottest topics that I discuss and I think of everyone's mind is developer productivity and specifically the question of whether should we measure PRs per developer or not? Because at Uber, they were doing it, and it was helpful in some ways. But I recently talked with a startup

who is doing a developer productivity tool. They're launching a new startup. And I told them, I'm like, they're like, oh, we're thinking of measuring PRs or not measuring it. And like, hold on. Like, I think you're doing this wrong. Like, if we're looking ahead, like,

the question is not like if developers are doing how many in PRs, like you will be able to do however many you want. But we need to think about, like, what will productivity it looked like, because now, looking at the output of, like, how much code doesn't tell me anything. What would tell me something is if I sat next to someone, for example, are they actually reviewing the code before it goes into the code base? Are they challenging the AI instead of just

blinding the LGTM, you know, looks good to me, and sending it back? And I'm not sure how, like, you know, this is going a little bit to end during leadership, but there is going to be this big question of, like, what does, actually, I'm going to ask you this, like, fast forward to two years, let's assume these tools evolve or, you know, they will not be worse, but they will be better. What do you think a really productive software engineer will look like in terms of what they do, not what they measure, just what they do? Yeah. First of all, I got to share Kent Beck's toboggan analogy. He's like, he's like, using these agents is like being on a sled going down, like a ski slope.

You're going really fast. You're not really in control. You can, right, you can steer it. And unfortunately, that is the state of the art right now. That's what software engineers who are embracing. this, and they're spending thousands of dollars a week, right? Yeah. Which is why Klein's going to become so important, why local inferencing is going so important.

The only way for vibe coding to become truly sustainable is for it to be local influence. I'm going to stop you there. You're saying they're spending $1,000 a month. A week. Or a week. Who's spending it? Because now, like, what I'm reading is like, oh, we're not really going too much over

with, like, the $100 quad pro subscription. I personally get a bill from Anthropic for $220 about every day and a half or two days. It's absolutely insane. So I'm desperate for local inference. As a professional developer. Yeah. And you're seeing this with like teams that you're working with. Like you have some insight into a lot of other engineering teams, right?

Well, yeah. We have people use an amp. We know how many tokens they're spending. They're token pigs, man. These agents, they solve problems. All the problems you've ever heard about with AI, they solve by just brute forcing it. Oh, I hallucinated something. Let me fix it.

Oh, that was a hallucination too. I'll fix it again. And they keep going until they get it right at your expense. but it's still way faster than you could have done. So you can't not program this way. But this thousand dollars, are our vendors swallowing it? Or companies are actually being built for this? Publicly, we haven't, I haven't heard too much chatter about this.

Maybe it's because it's mostly indie devs, you know, sharing on social media and, like, corporate devs, they might not just care. No corporate devs. Look, you know who's using these coding agents right now in corporations? The CTOs. For some reason, we've noticed a pattern where the CTOs are all the ones who kind of get it, right? the global network of CTOs. They get it. They understand what's happening

and they understand the terrible, terrible economic tradeoff they're going to face, which is how many engineers do you fire in order to pay for the rest of them to have AI? Because it's very,

very, very expensive right now. This is why I keep bringing a client in local inferencing because you're going to find real fast that as soon as you start running four agents, you will feel like Poseidon, like navigating the seas, right? You'll feel like a deity,

right, how productive you are. 20,000 lines of code a day I've written, okay, like for an entire week, sustainably, okay? But it will cost you, you'll have to do a bank heist. Yeah, but where does all these lines of code go? Because, so, you know, one example that stuck with me recently, it was on Twitter, I'll have to credit whoever it was. But they told their agent, like, look, I want you to solve this, this problem, which is like, let's not do two things

at once. Right. It's basically locking. And the agent spun up a new Redis server, added a new service that implemented like optimistic or pessimistic locking it was like you know like 4,000 lines of code and it was a Rails project the person was like hold on

like maybe maybe don't do all that and then it kind of went on and then did something in Redis and in the end like because this person knew Redis it just needed to use the like a keyword that does the locking and then it kind of you know

just do this but the point is you know these Asian can write a lot of code and I'm wondering about two things one, like, how sustainable is it? Because we've seen junior developers even before AI, just like, you know, like spitting out code. And then, like, what's going to happen with maintainability?

And it is a good code? Is it the code that you actually want? Because I've also hearing that people are using agents or writing the first thing, but they're going back and they're kind of changing it to keep their coding style or like to tidy it up and that kind of stuff. Yeah, look, I mean, the answer is you can do all of this as a professional engineer today and you can get a gazillion PRs through. if your organization is willing to speed up the bottlenecks that emerge when you start generating

code at that rate. And some organizations are, and some organizations aren't willing to let that speed up, and you're going to start seeing them separate very quickly. And of the ones who decide to do it, you'll see some of them turn into train wrecks that become very public, potentially, and then you'll see some of them to succeed. You really want to be in the I tried it and I succeeded category, I think, and that means you're going to have to take some risks. The only advice I would give people, I would say, look, because our book is 300 pages. How do you write 300 pages about vibe coding? Can it really be that hard?

And the answer is, Gene and I spent, you know, five months. We wrote the book in a month after spending five months, doing deep, deep, deep dive researching on how do you push the LM and vibe coding in different ways and found a bunch of patterns and found a bunch of patterns and found that it's extremely hard. It's non-intuitive. Nobody's born knowing how to do it. It's completely new to humanity.

They have these sort of human-like but not. non-human distinctly different helpers. And the best advice that I can possibly give you is give them the tiniest task, the most molecularly tiny segmented task you can give them. And if you can find a way to make the smaller, do that, okay? At a time, keep real careful track with them on what they're working on at all times, and then own every line of code that you ultimately commit. And if you follow those rules, then you'll be astoundingly productive without causing them.

But, man, dude, I've already personally caused so many nightmares because Claude hacking its reward function and saying, hey, your tests are all done, right? So, I mean, like, this is not easy. And it's not going to get any easier. That's the painful part, man. And that's what people are struggling with. The AIs will get smarter and they won't hack the reward function anymore, but they'll have some other problem. Okay? And there's always going to be another problem.

And it'll never be ready enough for somebody to come in and just like, it just works. That's what everybody is asking for and what they want. And you hear on Hacker News, anytime. Everybody says, I've been successful with AI. Everyone says, well, I tried it and I wasn't successful. They're not realizing that you can today, but it's not a freebie. It's a tool that you have to learn how to use. So in the book, you use an example of when you kind of turned a page of like actually

believing this stuff, which was around your game that you have been building for. I remember actually when you were tired, you announced that you're working on this game and you were making some progress and releasing it. What happened there in terms of using AI to? Let's get back to the game. And what was the outcome? Where are you with that game right now? And what is the game for those who don't know?

Oh, the game's called Wyvern. It was a hobby game. I started in 1995. It's a massively multiplayer, like, you know, RPG online, you know, but it's 2D, all 2D, sort of pixie sprite graphics. Super high-speed animation, though, with like spells flying around and stuff.

It's a lot of fun, man. People love it. They have a soft spot for it. People continue to play the game for literally decades. Oh, wow. And I'd have volunteer contributors, working on it right now who've been working on it for years and years and years. So, labor of love for sure.

During that time when I said I was working on it during COVID, I got it on Steam and I got a bunch of cloud overhauls done and modernized it. And it was all really fun. But the player base got so excited about it. And they asked for so much features, right? They asked for so much work from me that I got, I buried, I get suffocated me as the owner of the game, right? And so I gave up.

And that's when I was like really done coding. And then AI has come back and put it all back on the table for me. I realized, oh, my God. Like, this thing can churn through my bug backlog that the players had asked me to go fix, right? And I have time to spare, right? And this is why, I mean, like, this is why people are coming out of retirement right now. And then, so on that game, you went back and you started to implement, like, certain features with AI. Yeah.

So, like, that was, so the thing is, I can work, I've been working on Sourcegraph Cody, you know, coding on Cody for quite some time. And then the agents came out, and I was like, you know what, I'm going to try it on a, because all we had was a brand new code base. I want to try it on a crummy old legacy code base. 30 years old is pretty crummy and pretty legacy. It really is, man. It was bad. So that's what I've been doing is I've been doing different things. I've been doing cleanups.

I've been doing adding tests. I've been doing migrations. All the things that a larger company would need to do, yeah? Because I have lots of experience with those at Amazon and Google and so. Yeah. And so you can scale it up. You can say, okay, I'm doing it for Wyvern. And this is what the experience you're going to get as a developer in a year and

half two years, working on a giant enterprise code base, right? And the answer is it's going to be real different. It's going to be a lot of fun. It's going to be really hard still. And it's just a completely different role. You don't write code anymore. You build software. So on this game, but just going back, like, you're describing, you know, the AI what to do. It turns out the code. You look at it. You test it and then you push it, push it out. It is a very complicated process. That's way too long to talk about here. It is built inherently on a foundation of distrust. You cannot trust anything the LLN gives you.

Anything. And that means multiple safeguards and guardrails and sentries and security and practices and you have to train yourself to say the right things and do the right things and look for the right things. And it is not easy. And it has reinforced my belief that people who have really good developers are going to thrive in this new world. Because it takes all of your skill to keep these things on the rail. Do I hear it correctly that what we're kind of saying, because at first I might have misunderstood you. First, it's like, all right, you know, like companies, you should invest in it, you should do it because otherwise you'll be left behind.

But it might be a little bit like what we've seen with, let's say, early Google. You know, like Google was building out all their platforms and they're not really making a secret. Or let's say Amazon's a better example. They were like building all these internal APIs that talked to each other, which no one did. It seemed like a lot of work to do. And it didn't seem why you shouldn't just stick with what you have. But, you know, 20 years later, Amazon actually built AWs. They have an organization that actually everyone talks with APIs,

and some companies are still have not figured out, you know, like we can look at, for example, Google. So what we might be saying is like, look, this future is coming, but it's going to be a lot of work. Like, start now because you will need to figure out so many things, and it's not just going to be a, okay. That's right. The call to action is absolutely not give agents to all of your developers.

That would be an apocalyptic event for your company in more ways than one. But what you should do is you should start getting some of your developers together to understand what is going to have to change in your company. And I don't just mean the technology and the IT stuff and employments and I'm monitoring. I mean like the business processes. What's going to have to change if suddenly code generation is no longer the bottleneck? Because it's historically always been the bottleneck. And so we've allowed everything else to just kind of like coast.

And this is why I really wanted to talk about your game because I think this was really helpful for me. what I'm trying to understand is what does it look like when we use these. And I'm glad that you said that it wasn't that, I don't know, all your bugs are now suddenly fixed magically now. No, it's going years and years of work, but I'll be going 100 times faster, so it's fun. Yeah, but by the time you finish. Yeah. Yeah.

And in the book, like, a thing that I liked, again, I like, you made a prediction about how jobs will be impacted. And I kind of thought, you know, we exchanged emails earlier and I kind of thought you're going to be, you would be saying there will be fewer jobs. In the book, you actually say the opposite. You said that you think there will actually be a lot more developer jobs. Why do you see this in? But what will change?

They're not going to be the same things yesterday, right? It's so hard for people to get their heads around because what's happening is we're commoditizing the creation of software, just like digital cameras commoditized photography. Right? Everybody can take nice professional pictures now. And that was inconceivable back in the 80s, inconceivable. Yeah, I mean, how much.

would have these things cost, like, you know, just 20 years ago. And by the way, everybody crapped all over digital photography for years. Oh, yeah. And they were like, it'll never, it'll never. There was a lot of it'll nevers being thrown around. Well, in Kodok went bankrupt, not believing. And they actually buried their own digital camera. Yeah, yeah, yeah, yeah.

So, like, we're in that situation again. Everybody's like, AI will never, they are wrong. AI will ever. It will get to where all the places you think you're, you don't think that it's going right now. And what's going to happen is your mom will be able to create software. Okay, your boss will be able to create software. Somebody at McDonald's will be able to create software. Like literally, we're going to find all the ramanujans, you know,

the undiscovered real geniuses in the world, right? Because my friend Brendan Hopper, he's the head of technology, CTO for technology at Commonwealth Bank of Australia. He's got some amazing hypotheses about how AI is going to bring out a meritocracy, okay? Because AI is a spotlight. It shines on all the work that people are doing, and you can't hide shoddy work anymore.

the AI will detect it. If you're hoarding knowledge, like you're an engineer who hoards knowledge to keep your job security, that's gone now. The AI will know. The AI knows everything you know now. To be honest, there are always these stories about doing so. I never really believe that. It happens, but it's a rare edge case. But there's other common edge cases where people manipulate the system to try to like benefit, you know, whatever they want instead of what's best for the system. The AI is eventually going to highlight that. And so all the people with merit, meaning the people who are good at using AI to get important things. done, I guess, are going to bubble to the top. And they're going to be an astounding number of jobs because creating software is so much more empowering than creating pictures. If anybody can create a video, so what, but if everybody can create software, that's mind-blowing. So, you know what I think's going to happen is I think big companies are going to shed a lot of jobs. I think a lot of people are not going to work for big companies. They're going to be a big zillion startups. See, one thing that I'm not 100% on this is big companies are highly profitable. And I could see

them shedding certain jobs but then replacing it, but they will want to keep their edge. Like, you know, they will, of course, want to try to increase profitability, but they're happy keeping it at level and making and having enough reserve to like fight off the startups, right? Absolutely. I mean, there's that balance will always be there, that tension. So, but I mean, I just, I feel like right now the calculus is not looking in favor of big companies bulking up any further. Like, I don't see big companies getting bigger. Well, in fact, I just, we were, during a Google deep dive, I saw that Google peaked as headcount in 2022.

It's been kind of like going slowly a little bit down. It was like $188,000 or something. So actually, like it, and this is Google we're talking about, which is profitability and revenue keeps going up. Yeah, right now companies are discovering the easy solution is you can do the same that you've been doing for cheaper by, you know,

losing some headcount and doing some stuff with AI, right? And I think that more ambitious ones are going to do, they're going to be more ambitious. So you've done your game. I want to ask you about a metaphor that I've been thinking about and I asked you to poke some holes in it the ones

you see. Game development. In game development for, if you think back of what the biggest barrier of entry used to be to build a nice, like, cool game, it was initially building the 3D engine. You know, this is why Doom was massive. Walthenstein. They built the engine and then they kind of

built the game around it. But you know, like that was like 90s. That guy's my next door neighbor, by the way. Michael Abrash, the one that made Doom fast. And quake. Wow. And over time, you know, now we actually have software, Unity and Unreal Engine, which take care of the engine. So you can now focus on the games.

And what this has resulted, and I've now interviewed a few people, very small teams can also make really, really cool games. If you actually want to build a game, I actually did a Unity's tutorial, I could build a game. I mean, I would need to put in the work. But it's no longer, like, it can look professional and all these things. If I look at how the game industry has evolved, I'm following a little bit of the news. AAA studios are mostly struggling. Not all of them.

You know, GTA6 is still doing great, and some of them on the EA sports, but some traditionally massive studios are struggling because it doesn't work that we throw a bunch of money and we get a bestseller. There's a lot more indie games, way more than ever. They're having trouble consistently doing so. I'm wondering if we might see something similar,

because, again, like there, the game engine was central to all of this, And now everything that is not the game engine is really important, marketing, story, all those things. In software engineering, coding, like, being able to code was the bottle. And now, you know, that will, to some extent, be removed. But software engineering is still, everything around is still remains. That for sure. That is absolutely true.

So, yeah, we're going to see a lot more software get created, period, which is like a lot more small software. And we're going to see more indie games, and we're going to see more step above left that's high quality. somebody's going to find a way to organize it all, like the App Store organized Q&Fs. Maybe we'll see a new startup for this. Man, dude, I'm telling you, man, almost every time I talk to anybody about this, we come up with a couple of new billion-dollar ideas, right? I mean, it's like this is another reason I think there's going to be so many jobs,

is that this will create legitimate, real actual GDP productivity. Nothing fake about it, nothing artificial. It will create real value. It's going to be an explosion of value, right? It's going to take a couple of tipping points for the AI to reach this sort of mass market ability for people to be able to use it to create reliable software. But we're no more than two years away from that, man. And it's going to be like this incredible proliferation of just cool shit for you to try. There's going to be too much, actually.

You're going to have to have AI to help you find your way through it. So in those two years, whether a listener is a less experienced engineer, especially if they're an experienced engineer, what would your advice be to? to prepare best to, you know, like make the most of either being an AI engineer, working with these tools, figuring them out. Like, what is the tactic? What is the advice that you give, you know, the engineers working, let's say, a source graph, you know, where you're at, who you're around you. Yeah.

So, you know, what's the guy that wrote the movie The Room, Tommy Wiseau, I think this is his name? Somebody asked him on Twitter, they were like, hey, man, I want to start writing a screenplay. What should I do? And he said, start, right? Yeah. I mean, like, for starters, if you're saying, you're saying, you're saying, saying, oh, I don't know, buddy. I am not ready. Blah, blah, blah. Shut up. Okay, that's done. You're done whining. Okay. Go learn it right now. I had the privilege of speaking with Dario Amadei

privately for 30 minutes about three weeks ago, four weeks ago. He invited me to come to chat with him. And I got to hear his sort of unvarnished view of the very, very new future from somebody who could arguably be considered one of the best informed people in the world. And Dario, you know, his vision of the future is a little bit more oblique than he lets on publicly. And he and Jason Clinton, his CISO, are both seeing statements that are quite dire. Like there will be badged AI employees by the middle of 2026 competing with you, right? Basically is the implication there. And other implications, like the Moore's Law of AI, how it gets four times smarter every 18 months.

So if you do the math, three years from now, if their IQ 10 today, day, they'll be IEQ 160 if you want to choose some sort of rough measure of what, you know, 16 times smarter means. And it'll be, it'll be too much for people. Dario told me, he said, look, he said, society is like an immovable force, right? An immobile object and tech, and AI are an unstoppable force. They just won't stop. And they're going to collide and it's going to be ugly because it's going to push society harder than society wants to be pushed, harder than society is willing to be pushed. And we're already seeing signs of it. We're seeing people revolting against AI, putting a, I'm sick of it, right? He posted, I'm sick,

and he never mentioned AI in the post. It was really brilliant. I love the post, by the way, the guy that I wrote the I's not sick bit because he's speaking for a generation of people who are tired of hearing about this shit. But unfortunately, you are never going to stop hearing about it. It is that, that is the way things are going to be done and in the very, very, very short order. And so my advice to you is get off your ass and learn it now, now, now, okay? Start vibe coding, figure it out. There's a lot to learn. There's a lot of weird instincts you're going to have to like learn. A lot of stuff is not going to work the way you expect it to. Okay. But you start now and you'll be ready because Dario calls 2026 the end game. And he says it without a hint of drama.

He says it casually. Oh yeah, 2026 is the end game. You understand that's how big this is going to be. And the first ones to fall, the first jobs are software engineers, right? So you need to be on top of it to take advantage of the new jobs that arise, which are software engineer V2, which use AI and get amazing things done. You have to be one of them or you're going to get kids. kicked out of knowledge work altogether. Yeah, well, this is going to be part of, like, I think it's clear that it's going to be, it reminds you a bit of the cloud where, you know, these days like, yeah, every, every company uses a cloud, either private or public.

And about 15 years ago, it was like AWS. And I talked with banks, banks, we will never use it. We will never on board. We will always have our data centers. Oh, and, you know, there was a time where I think it was very valuable to get AWS certifications that you get hired and get a salary bump. So I feel there are levels where, like, I think it's clear to me that AI as infrastructure will be in every single tech company. And of course, it will be in every single now tech company and government and all it.

It will happen. I don't see this time frame. So I think we might disagree a little bit on how that is. But it will happen. And I think your advice is absolutely solid. Like, gets started now. In fact, you know, what I'm seeing now, and again, this was just this conversation with Jambi. Jambi said that she she saw Chad GPD coming.

out. She was at Koda. Koda spun up in a few months, an AI team, and she said, I'd like to be on that team. And they said, thank you, but no, thank you. You don't have the experience. And then she thought for a while, like, I'm too late. You know, there's people been doing it for five years since Transformers. What can I do? And then she just went to hackathon. She just hacked on the side. Five months later, she was one of the best at the company, and she got on the team early on. And I think there's this thing of, like, I was just the listeners, maybe, you know, like put away the doomsay thing. But the point is this thing is happening. And as you said, now is the best time.

Like, learn it. And also do get motivation. Like, I do think the industry will change a lot. Like, we'll probably look back at this time at something big happen and we're in the middle of it. We are in the middle of it. And you know what? The funny thing is, I mean, the grass really is greener on the other side here. Like, it is so fun.

Right? It's so, it's so, I'm having so much fun. Not coding, but fixing my bugs and adding features. I love it. But I also feel sometimes you are co-ed. You know what you expect and you correct us, so there's a lot of metacoding happening. Oh, yeah, I read 100,000 lines of code a day. Yeah.

It ain't easy, right? I mean, it's exhausting because if you're not reading it, then stuff slipping by you. You'll eventually figure it out that, you know, you want to try to catch things early. Yeah, but man, it's like, it's a different ballgame, and I love it. I'm having so much fun. And Gene Kim, my amazing co-author, who's, you know, he's an author and researcher who I think probably knows everybody in the entire world who's everybody. And he and I are both just unbelievably excited about vibe coding because despite the doom and gloom sound of what's happening, the only reason it's doom and gloom is people don't like change. They don't want to change the way they're working.

I think so. And I've been guilty of this earlier. Like when I saw this big change come at first, I was like, oh, this is not great. And, you know, when people were saying it'll eliminate jobs, I didn't like the message. It just felt like very threatening. I think as software engineers, we're kind of used to us. us automating a bunch of job like customer support and you know like oh here's a cost savings of like we need for your customer and we never fired custom agents we just didn't hire as much and I think this is the first time in history where our work is it is kind of threatening us but what I came to realize is talking to you talking to Ken back seeing my experiences if you are a good software engineer and you are open to learning and using these things and adding into your toolbox you will be a better and more in demand one that's what I'm seeing from people who who started to use this, they're now being hired as AI engineers.

AI engineer is actually a software engineer who is able to use, but understand the non-deterministic part. They're going deeper into ML. So I think it's like, in some ways it's ironic. We might have had some stagnation for like 10 or 15 years where you could do the same thing and be more successful. And, you know, staff engineers just, it was more about managing people. And I think for the first time in 15 years, we're shaken up.

And to be a great software engineer, you need to learn. You need to let your ego go, which, That's right. You know, I think that's something you've always done really well. Yeah. I mean, why, yeah, why get your identity tied up in something that's actually kind of fragile, as it turns out? Look, the way I think about it, man, software is always so big. Remember when they're building the second Death Star?

I think it was an Empire Strikes Back and it was half done. How big was that freaking thing, right? That's how, that's a typical enterprise software project right there. It's a good visualization of it, right? So what if you have these robots that are 20 times as productive as a human? Yeah. You're still going to take freaking use. years and years and years to build it.

And there will be our architects overseeing it. Right? You're going to be very, yeah, exactly. You're going to be very grateful that you have the help of these robots that are 20 times faster than human data coding or 100 times faster. You're still building Death Stars and it still takes years. So there's still jobs. They're just different. Traumatic events can increase your neuroplasticity.

And you said we've been stagnating. Many of us have been stagnating. The reason I retired was I felt like I was stagnated. Yeah, I was thinking, I'll be honest. Like now, like, my publication department engineer covers, you know, like the trends happening. And I was just talking with my brother, like, he's also in tech. He's the founder of a crap docs. And I was talking about how, looking back, like, if AI did not happen, what would we be talking about?

Is it how to more efficiently move monoliths, microservices? We've been talking about it for a few years, how to measure developer productivity even a little bit better. How to scale teams better so that how can you manage 10 teams? Can we switch to memory-safe languages like rest? Yes. And I'm like, it was getting a little bit boring, so, you know, like, I think this is a good, good takeaway. Yeah, we were incremental improvement mode. Yes.

And this is a step change. Yeah. Absolute step change. So close off with some rapid questions, if you're okay with that. Sure. With all this AI stuff here, what is your favorite programming language? Or do you even have one? Wow, my favorite programming language?

Oh, my gosh. I don't even care anymore. I'm so happy. What used to be? My favorite probably before all this AI stuff made it like kind of unnecessary. I really like TypeScript. Maybe I shouldn't, but there's something about it. I mean, it's just so flexible and expressive.

And I think probably I'd have to get with the TypeScript. And what is an AI tool related to coding that you like and an AI tool that has nothing to do with coding? Okay. An AI tool for coding, you should try Sourcegraphamp, but just came out yesterday. I mean, come on, man. That's what I've been using. I actually turn all the permissions off and just let it run, but don't do that. But it's so good.

It feels so good. Yes. And then... Until there's an RRM-RF. I've gotten pretty good at sandboxing. But I think I probably going to switch to Docker containers. Anyway, as a.I. tool that's not related to coding. Yeah, boy, I tried operator.

I really want something like operator that works, if that makes any sense. So hopefully some very soon upcoming version of it. But it couldn't do something simple like edit my Google Doc for me. Like it would look at it for literally 20 minutes and then like just delete a paragraph. I mean, you know, I think that's a good example of like we'll have software explosion there. Someone will have to build it who's going to build it. Yeah. We know who's going to build it.

And what's a book recommendation that you had outside of your own book? Read Sapiens, man. It's such an awesome book. Well, Steve, this is great. I'm glad I feel we went on a roller coaster. We went like high, then low, and then we ended up high again. Yeah, well, you know, change can be scary, right? But this is a very positive change in my opinion.

And I think it's good to just, like, I like that we, let's just, you know, name what it is. It is change, and it is a big change. And I think for, I think what makes it scary for a lot of people, including, you know, my generation, I have not seen this change. Like people who have been around the dot-com bust. might have seen it. When I talk with Grady Booch, he actually told me like,

oh, actually, Ken Beck was saying, we've seen this change, like when we moved to microprocessors, for example, like, apparently it was a huge thing and everyone's world trip because they were so much faster now

they were going to, you know, change everything. And then it came back said, like, yeah, everything changed. And then, like, in some ways nothing changed. Yeah.

So. That's a good point. Everybody suddenly had a computer one day. I was there for that. And before that, nobody had a computer, and it was inconceivable. Right?

So everybody being able to create software is a really interesting step in that direction. Well, because back then, right, as I understand, as a programmer, you had to go to work to these companies which had these massive computers and whatever. So it was only very privileged and then suddenly anyone could do it. Yeah, that's right. Or who had the money who had, like, you know, rich parents or whatever savings. And PCs were at the beginning of the big boom.

So we are at the beginning of a big boom. There's a lot of money to be made. And PCs turned out to be pretty great for us software engineers. Yeah. All right, Steve. This was great. This was awesome, man. Thanks. I hope you enjoyed this interesting and entertaining conversation with Steve.

Steve remains a prolific writer, and you can read more of his rants linked in the show notes below. For more in-depth reading about developer tools, the engineering culture as Sourcegraph, or the impact of AI of software engineering, check out the pragmatic engineer deep dives also linked below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast, and a special thanks if you leave your rating. Thanks and see you in the next one.