Host 1 (2:37)

Right.

Philip Hsu (2:37)

Dirty fuel would be something like, you know, my parents never complimented me and so now I'm going to drive and prove them wrong. Right. Clean fuel would be something like, oh, I've always Loved, you know, computer science. And I'm here to. Right. So I think when I looked back at my past, it really is a transition from dirty to clean. And I'll give you specific examples. Like I feel like I moved from sort of ambition to a bit of stasis and then to fear. At Microsoft, what drove me to Amazon was depression and then. Exciting, right? Yeah. And so let's talk about that. So at Microsoft, when I started in my 20s, I was just very ambitious for myself. All I wanted to do was to get promoted to eventually become a dev manager. And that actually happened relatively quickly in my career. So I became a dev manager before I was 30. And you know, what happens when the dog catches the car, you know, before halfway through his life, is you need to figure out what else to do. Right. I was very comfortable working at Microsoft because I knew how to be effective within that organization. But what caused me to change eventually is 12 years into my time at Microsoft, I interviewed for three other local companies, you know, Google, Amazon and Meta at that point. And for all three of them, they gave me offers that were three levels below where I was at Microsoft. And that's when fear kicked in is I realized, look, I have differential value to one company in the industry and the rest of the industry values me much lower than that. And so that's when I knew I had to change. You know, and picking Facebook was easy, not because it was successful. People Forget back in 2010 when I joined Facebook, it had 500 employees. People were saying that Friendster would come back. You know, Google was yet to be released. Right. And so Facebook was not at all a safe bet. Facebook was in fact, a very dangerous bet. But the reason I considered switching to Facebook was because I realized if I wanted to change my life, I wanted to make the change radical and noticeable. You know, going from one 70,000 person company to another like Amazon or Google was not, in my opinion, a big enough change to justify the move. So I moved to Facebook and that was a great experience. But I would say after I quit Facebook for a while, I had started a nonprofit, and then I stepped down from the nonprofit about three years in because I was really struggling with depression. And, you know, I was at home without work for about nine months, at which point I sort of idly clicked onto Amazon, you know, slash careers, because I had always read that, you know, robots were taking over there. And I had a real interest in automation and where that would take us. And I also felt a little bit like, you know, I would preferred in my Depression to have a job that just required me to show up every day at 6:00am and just, you know, and the shifts were 11 and a half hours each. And so it was like serious work. And I also felt a little bit like there were all these breathless essays about how, you know, people at Amazon were peeing in bottles and stuff like this. And I, I just found that, frankly, a little hard to believe. So I wanted to try it for myself.

Host 1 (5:40)

And you did. Right. Like you were in the warehouse working 11 hour shifts, processing 15k packages a day. How did that feel?

Philip Hsu (5:50)

Yeah, you know what's crazy is the number of packages I move per day is about 6 tons of packages with my arms. Right. And to give you a conception of that, that is trailer of an 18 wheeler Amazon truck, you know, the prime trucks that are out there, that basically is moving all the boxes from one truck to another in a day. That's how heavy it was.

Host 1 (6:11)

So what did you learn like that? That is a very, let's call it physical experience. Right. You got what you bargained for, right? Like a work that just needed you to show up and you did. Yeah, but I'm sure there's a lot of learnings you took from that experience.

Philip Hsu (6:26)

Yeah, first, like, personally, I did get what I wanted out of it, which is one, working next to robots, which was very TR2 is the scheduled work. And the exercise was honestly very helpful for me. But I'll tell you the big learnings that I got out of it. One is that incentives matter. You know, like in, in Amazon's corporate division, if you worked as a software developer in Amazon, for instance, right. You would get promoted based on doing a good work. You would get bonuses based on doing better work. Things like this, Right. That's not how it works in the Amazon warehouse. So same company, different job. Right? Amazon warehouse, you get a raise based on tenure. So six months in, you get 25 cents more one year and you get 50 cents more an hour. And that same raise goes to the worst performer on the floor, as well as the best performer. That incentivizes you to be the absolute worst you can without being fired, basically is what the incentive is. Right. And workplaces work as you know, completely differently when that's the incentive. I'd say one other thing that you learn from software, but you learn in an Amazon warehouse much more clean, mainly is that changing machines that are already operating is extremely hard. So an Amazon warehouse might have 3 to 5,000 employees working on the floor at the same time. You never stop the lines because Packages are shipping direct from China to American porches every day. Right? So the thing with that machine operating is there were so many suboptimal things like how people flow worked, how you might route packages, but they just can't change it because they can't bear to have the downtime. And so changing that machine when it's already flying is extremely difficult. So you end up with these legacy systems that stay around forever because you can't ever shut them off. And you're hoping for the new warehouse being built to be where all your great ideas go. Right. And so that's the second thing about it. And I would say one last thing that I learned from it, similar to our topic today about software and how it's impacted by AI, right, is there was a lot of misplaced pride. There were people on the lines that very proudly told me, well, they tried a robot here once and it failed horribly. And they thought it was hilarious, like, oh, these robots can't do what humans do. Right. And my takeaway from that was completely different. I felt like, well, do you think the corporate robot designers, they just gave up and went home? Or do you think V2 is coming and V3 is coming until finally it takes over your job? It to me was not something to laugh at at all. But there is this sort of pride that I hear from software developers now as well, who laugh at AI because they get such joy out of like, oh, look at this dumb machine, right? They have no idea. They sound exactly like the Amazon floor worker who laughed at machines and told me how bad the machines are, who no doubt by this point has lost his job.

Host 1 (9:11)

You can't ask a fish about water. And I guess we all go through those same anti patterns, if you will, sooner or later. So let's dive into the AI topic, which is the topic we want to explore in depth with you today. You wrote a post on Substack which I really, really loved. It's called no more Code Reviews. Lights out Code bases ahead. Before we dive into the conclusions and the aspects we should take away from it, give us the main argument.

Philip Hsu (9:42)

Yeah, so I think there's a pragmatic one and then there's a real one. And first, like lights out code bases, why is it that it's like lights out data centers, which is ones that operate without humans. Right. And so I think code bases are going to go lights out where humans no longer look at the code first. Like all the, all the debates, I'll settle them now by saying, I am not saying that you should move your production level code base to lights out right now. I am not at all saying that. Let me lay out the pragmatic argument, which is simple. And then the real argument, the pragmatic argument is when I worked at Meta, and That was starting 16 years ago, right? I would spend up to an hour every morning reviewing other people's code. Because that's just part of your developer day, right? Now most developers say they are developing 5x to 20x more code per day. So just pragmatically, first of all, there's like, where is all this magic time coming from for you to review code? Okay? Now when I say that, people always laugh and they say, well, you're basically making the argument that we should ship more crap faster because we can't review it. That's not at all the argument I'm making. When people say that, however, they feel so satisfied that they have laughed at the argument. But not a single person who says that has proposed to me what their proposed alternative is. You know, when their coworkers are producing 10x the amount of code they used to produce, like, what is their argument for, like, continuing review? Is it literally our 9 to 5 job now is simply reviewing other people's AI generated code? Like, that doesn't seem to be like a good argument. But let me give you the real argument, right? I grew up in the 80s and 90s, right? And back then there was a big question, whether Deep Blue would beat chess masters, blah, blah, blah. Today, even stockfish, free on your phone, can beat the world's best chess masters, okay? There's no doubt about this. A free software that runs on your phone can beat any human alive. Okay? What if I propose to you today that you should take that free software and when you're playing some other player, have a human chess master review every move just to make sure the AI hasn't made a mistake, you know, and once in a while that human will quote, unquote, correct the AI's move. Okay? I would think that was patently ridiculous. Now, can you imagine a day when you would be freaked out, just absolutely freaked out, if you found out your cloud provider allowed humans to actually review the work of AI, to quote, unquote, make changes and to quote, unquote, make it better, right? I don't think this is outlandish at all. And I feel like people who laugh at this, they haven't laid out an argument why we aren't going the same exact direction as stockfish, right? And I think most of of the arguments come down to pride. Yeah.

Host 1 (12:23)

Okay, so pride is definitely an hypothesis here. There are others, so I'm going to propose a couple of others. So the pride, right, like the machine will never be as good as me. I think that's there and it's very natural. It's almost like a self defense mechanism. Like the, the, the workers on the, on the warehouse line laughing at the robots who couldn't stand up or whatever. But there's another argument. The argument is we're still looking at software the same way we did way back in the 80s and 90s when we grew up, both of us, right? Like we're thinking, okay, software is a piece of code written that somehow works well together and is understood by the people who need to maintain it. I think that one of the aspects that your blog post or the substack post makes very clear is that even if that were true, which I don't think it is anymore, but even if that were true, just the massive amounts of software that is going to get produced will require drastically different ways to interact with the source code, right? Like, because we're talking about source code, right? So even though everything is still called software development, you know, from idea to a released product, the source code item will grow so far and will be so big that there's not going to be a possibility for us to work with it. And people are thinking in the old methods, meaning we know exactly what is written, how it's written and who wrote it. But I don't know how you use AI. We're going to dive into that in a second. But the way I use AI when I do my own coding projects, it's not just one AI, it's. It might be four or five different AI solving different problems in the same or even in different code bases that somehow interact, right? Like through scripts or APIs or whatever. And for me, it starts to become impossible to even spend enough time understanding the code that is written because I'm spending my time solving much harder problems. I'm not spending my time solving source code problems. I'm spending my time solving interactions, systems problems, right? Is that also something that maybe people aren't yet realizing? And that's why they still feel tempted to say, oh, ridiculous, it will never be as good as humans.

Philip Hsu (14:46)

Yeah, absolutely. I think you're spot on. And I think that we are simply uncomfortable moving up the abstraction layer that you articulated. So, for instance, today most people are quite comfortable never looking at the assembly that their compiler generates, right? Not only because we've used it forever but also, what's a human going to do with the output? You know what I mean? Going to do correct the compiler and make like a more optimal, you know, optimization, right? Most likely not. But I'll tell you a concrete example. When I worked in Windows 26 years ago, even 26 years ago, the Windows code base was 50 million lines, okay? So even if you were a distinguished engineer in Windows, nobody would say, well, you never look at all the code. You don't even understand how the whole thing works. Like, how are you supposed to make a contribution here, right? Well, the thing is, the distinguished engineer in Windows looks at boxes and lines all day, basically. Like, what is the principle? They do the DLL dependency stack, which back then had internal cycles and all this stuff, and they say, well, of course a DLL dependency stack should not have internal cycles. That sounds like a very bad idea. And so even without looking at the code, you can make that statement. Now someone else would say, yeah, but some human somewhere understands the code, right? Which is true at some level. But I think you're right that we cannot aspire to build bigger things if the fundament, fundamental requirement to building them is that one human, or at least a handful of humans, have understood every last line of code in a code base. And all of this presupposes that the human understanding is like, this is like presupposing the chess master is better than the AI, right? Like it all presupposes that having a human understand it is actually a good thing.

Host 1 (16:27)

What I'm thinking is that there's so many examples of this, like we all drive cars that we don't understand. We all go to, we use Amazon, which we don't understand how it works. A very specific example that happens to me every day. I use an incredible amount of services, hardware and so on, in my data center provider that I have no idea what's going on there. I don't know how they maintain it, I don't know how they measure it, but I still comfortably use it and take advantage of the services they offer to build other things on top. So the other thing that I'm thinking is the second layer of abstraction is this idea that actually if the Internet is built on very small components like the tcp, IP stack and so on, but then on top of it, you have a huge economy. Now imagine what a large amount of AIs could produce as components that we can compose into a much larger set of valuable services, right? So I think that the other aspect we are also missing is this idea that that we're just starting to build the small components with AI that eventually will be composed by AI and humans later on to deliver different services and different applications. So I guess that aspect is also missing, right? Like the historical context, which we can't have until we've gone through it. Of course.

Philip Hsu (17:54)

Yes, absolutely. I think you're right that if we decouple things and we develop them in units and we test and verify them and whatnot, those things are ultimately working. Software is ultimately the work product we want. People keep behaving like human reviewed code is the work product. You know what I mean? Like the actual work product you care about ultimately is code that actually works and serves a customer's interests well enough that they will pay you money. Like that is what you care about. And I think the premise that human understanding of, let's say the compiled code is required for that is a flawed premise. Now, once again, today, of course it's necessary. You know, I'm not at all arguing about today. I'm arguing about the direction we're going. And I'm saying that not because it's just an intellectual argument, but because to your point, and a lot of the things that you talk about and mention about is people aren't restructuring the way they do their work in anticipation that this is going to happen. And I think that is the change that we need to encourage people to begin considering.

Host 1 (18:59)

Yeah, absolutely. I was working with a client and they have an AI transformation project going on, like everybody does. Of course, course. And they were proudly talking about how they want to be 10x more productive. I'm like, but 10x, that's what you should get without any effort. Right. Like, we're not really understanding the impact of something like this. And you actually have a first person story to share about 10x or 100x. You're a solo founder, you're developing Superphonic. Now tell us a little bit about what Superphonic is and also how is your day to day as a one person AI assisted product team?

Philip Hsu (19:38)

Yeah, great question. So Superphonic is a podcast player for iOS. I worked on it because I listened to a lot of podcasts and so I felt like even very basic things in podcast players don't work the way you want. Let me give you a concrete example. Superphonic is the world's only podcast player that allows you to subscribe to a topic instead of a feedback. This is very weird to me, like why you can't subscribe to a topic. Right. So there's a bunch of things like that developing on it has radically changed. I started using GitHub Copilot about three years ago. Okay. And back then it was tab completion mostly. And for about two and a half of those years it was mostly me, like doing a little bit of AI augmented work. But in the last six months I've transitioned to me barely touching the code. I still review all the code on Superphonic, but I no longer touch it pragmatically. And I think that change has made it so that my day now is a lot more like a manager's day and a lot less like an individual contributor's day. So this is things like figuring out direction, right? Figuring out what approaches are right to do. It's things I'm sure you've noticed and talked about before too. Like, if intelligence was cheaper and faster, what things would you build to make your system even more stable than you would otherwise? For me it is comprehensive unit testing. You know, I used to have only a few tests. Now that they're free to spin off and do like I have thousands of tests. Okay, so like some people may laugh and say, well, those test code, it must be worse than human written. And I'd say, yeah, probably is, honestly worse than human written. Right. But the alternative is not. I had 18 people write tests for me, you know, the alternative was I had no tests. Right. So the quality of the code has actually gone way up because of that. That. Can I ask you a simple planning question that you are the master of?

Host 2 (21:29)

Right.

Philip Hsu (21:30)

You have devs claiming that they are producing 5 to 20x the amount of code they used to produce, and that is borne out by the PR commit numbers that you are seeing now on the code base. I have joined many teams that worked on Agile with daily standups and stuff like this. A person producing 5x the code, that's like saying let's have a daily standup becomes the equivalent, the moral equivalent of a weekly 15 minute standup. Right? 20x the code means a daily standup becomes the equivalent of one standup a month is literally how the math works. So like, where are we going? Even with the planning and organization and coordination of work?

Host 1 (22:06)

Yeah, you've touched it. That's exactly what I would like to explore with you. Like you're working now as a solo founder, so obviously you don't have that problem yet. Hopefully you will soon. But when we work with teams, my question is no longer will we be more productive? My question is, what will break when the developers are more productive? And I'm sure you have some ideas. I have some Ideas as well. The very basic thing is that, okay, the bottleneck will no longer be writing code. But then if you think about wasn't before either, right, like you can think about it this way. We wrote a lot of code that never got used. So obviously the writing of the code wasn't the problem. It was finding the code that would be useful and valued by the customer. So that would be a product question. So this is just one example. So I'm thinking that we need to start thinking what will break in the way we develop software today that is nothing to do with the code because as you said, we can write a lot more tests, we can run them more often. The documentation will be perfect, spotless, and we can easily replace it if we think it's not good enough. But what will break? And I think that's a question worth exploring. What do you think will break when developers are 20x or as I expect, 1000x more productive?

Philip Hsu (23:24)

Yeah, let's just take 20x to start. I think this problem is easier than people frame it to be, which is imagine your team today. Let's say you have a team of five engineers, 1pm, right? And one designer. Let's suppose that's your team. If they produce 20x, it is morally equivalent to saying suddenly you have 100 software developers, 1pm and one designer. That is the team you are proposing running with. Okay. And I think the breaks are very clear when you think about it that way. One is the onus of planning and coordination becomes much more important. The second, as every engineer knows, is if you take my team from 5 into 100 today, everybody's going to have a merge nightmare. And why is that? It's because it's hard to have everybody running forward in a smooth way if your code base is what it is. And now you've 20x the amount of staff on the code base. Right. So I do think that the types of things that need to change one is far more talent needs to be hired or retained or amplified. That is about deciding, to your point, what the customer wants. What would be the strategic thing to do next? How do we prioritize and cut things that we should not be doing? Right. Another thing that I would certainly do with a hundred developers at 1pm is I would create a lot more things, tasks for the developers that can be independently done that would improve the code base even without PM like decisions being made. But unit testing is one such example, right? Like clearly getting CICD much more smooth. Like making the API documentation like there's a ton of stuff that you can improve in a code base. Like take anybody's like list of backlog things to do, right? There's always a set of those backlog items that would be great for the customer that no one thinks is high priority to do and don't need APM much thought time to actually get done. Those things should actually get done. But I think that the balance, balance of hiring people with more PM and design skills is going to go way up.

Host 1 (25:28)

So I have a thought about that. I totally agree with you, by the way. Everything that you said and the way I look at it is if, because it's all about economics, right? Like if writing code becomes 20x cheaper, right, then we might want to think about, okay, what could we do with part of that that would give us the input, the information you need to make the decisions for what the customer wants. So like a very simple example would Instead of writing one feature, you write 10 features, you try them all out and then you select the winner, right? And it becomes, if you think about it just from the workload perspective, you can now afford to do that kind of experiments. But then when I think about the companies that I work with, they are so focused on the productivity angle that they forget that productivity isn't a working or a work effort metric. It's a systemic metric, right? Like input, that means investment versus output, that means return. So there's no productivity at the team level or at the individual level in a business. It's the business productivity that matters. And as you, as you said, if the bottleneck becomes the product decisions, you know, deciding what to work on, what to prioritize, what to give the customer, then productivity is now a factor of the impact of those decisions, right? And if you would be able to magically, let's say maybe AI would show up and make you 20x more productive. Maybe we're already there. Why not spend some of that advanced or not advanced, but increased output from the teams to experiment, to collect information, to gather the data you need to then make better decisions going forward.

Philip Hsu (27:13)

Great idea. And that's one massive change I saw when I moved from Microsoft to early Facebook is Microsoft in all my 12 years there was very much a plan based execution company. Meaning like they would spend all this time and back then it was the waterfall model. So it was all this planning, all this planning and then they would release a new version of Office every two to three years, right. When I moved to Facebook, most people were quite skeptical about you trying to convince them about some feature that you think Is great a response. Very common back then. Sixteen years ago at Facebook was very much like, well, why don't you build it at the next hackathon and. And then we'll just all use it, you know, and many features ship like that. A concrete example is a coworker of mine on chat. So chat way back when was about three to four engineers. A coworker of mine said to me, I think chats you should get to send a thumbs up back to someone. And I said to him, that's so dumb. Like, why would you send a thumbs up? Like that's just dumb. And then at the next hackathon, he literally built this himself. And then you, as you know, like every app supports that concept now. Right. But like he just couldn't convince me. Right. But once he wrote, it was very clear that he was right and my intuition was wrong. So A, you're absolutely right. People should be looking at what additional ways they can do work differently to get more customer value. Right. But part B that I find very funny is almost every CEO mostly is looking at how do they earn more money now by reaping efficiencies by cutting developers. I don't know why people aren't thinking, why don't I tackle the next three things I wanted to tackle in my business, you know, now faster? I suspect part of that is because of the classic mythical man month problem. Would I rather tackle 5x more stuff at Microsoft right now, or would I rather reduce Microsoft's staff by 5x and have far fewer human coordination collisions and problems, human coordination, human politics. It's a massive efficiency slowdown in an organization. If I could accomplish the Same work with 5x3 less people or 5x more work with the same number of people, I actually produce far more per employee, far more customer value per employee by reducing. Right. Than I do by increasing. And I think that's another part of the intuition that people are having is this is our big opportunity to go to far more smaller companies.

Host 1 (29:38)

Yeah. And that's fine. And maybe that is the future. I am famous for being very bad about predicting the future. But one thing that really puzzles me is that when we look back at the Internet, you were growing up, I was growing up. When the Internet came up around 93, 98, we were all like, oh, this is amazing. But nobody had any idea of what the Internet would become. The Internet today has nothing to do with the Internet back then. Still the same tcp, IP stack though. So when we think about it, I'm thinking AI and maybe this is a little bit of an extreme argument, but that's the way I'm thinking about it now. AI is just like TCP IP be. It's what we're going to build on top of it that will make a difference. And we don't even know what we will be building on top of it because we're so busy trying to get, as you said, a little bit more efficiency out of the existing companies.

Philip Hsu (30:29)

And to your point of being bad at predicting the future, I do think mapping it to the dot com boom and bust is instructive. In the dot com era, right, There were two things that we got wrong. We were directionally right. People back then felt the Internet would change everything. We were directionally right. There were two things that we got wrong. One is we thought it would happen sooner than it did. And so people laughed@pets.com when they went under. And there were whole articles written about how could you possibly think you could ship 50 pounds of dog food profitably, right? It turns out if you are willing to take 20 years to replace the entire UPS system, the entire shipping system in America with your private truck drivers and everything, it turns out you can ship 50 pounds of dog food quite profitably, right? So we were wrong about the timeline. And then the second thing we were wrong about is 100% of every winner you would have bet in 98, you would have been wrong about. That's the other thing we were wrong about, right? Directionally wrong about all the winners that you would have bet. I think AI, we have an equivalent right now, except we're wrong about time the other direction, which is most people are saying, oh yeah, but it'll be years before this happens, right? I think we're wrong about time the other direction because the AI is improving itself at this point. I had one work week in OpenAI and at this point this won't sound exceptional, but you got to remember this was about three years ago, right? I had one work week at OpenAI where I was asked to develop in a technology I had never used before, databricks, right? I didn't know what I was doing. And that week I literally sneaker netted between copy and pasting from ChatGPT into Databricks, running it and pasting the error back to ChatGPT. So technically, for that one week, ChatGPT improved itself is technically what happened, right? And so we have that making the timeline shorter. I think the other thing though, that to keep aware of is every winner, no. 1 came out of 98 out to 2000, three, three remaining, the winner, meaning not a single person that was the winner in 98 came out the other end. So today when people are saying, is it going to be anthropic? Is it going to be OpenAI? But what if Google comes back? Part of me feels like history might suggest that someone who's way behind right now is the person who ends up winning seven years hence. Yeah.

Host 1 (32:34)

And it's good for us to then also start asking, okay, but how can we take advantage of this? And you have a very, I would say, provocative but insightful post on Substack. AI killed the individual contributor. You know, throwback to the. What was it?

Philip Hsu (32:53)

Video kills the radio star.

Host 1 (32:55)

There you go. Video kill the radio star. I love that song. All right, so. But we need to explore what that means for us because at the end of the day, we're responsible for our careers, so we need to start thinking about this. So when you look at your own profession, the work that you're doing, and how you're developing your own company, Superfox, what does this AI killed individual contributor mean and what might it mean for companies that want to both give value to their customers so not just increase efficiency, that's not the point. But also adapt to this new, let's call it infrastructure layer of AI that is being built at the moment?

Philip Hsu (33:34)

At the ground level, my premise is that if I look at my workday on Superphonic, right now I am mostly spending my time doing what classic engineering managers do. I am setting priorities for the quote unquote team of agents. I have. I am reviewing the code of the agents. I am sort of deciding between agents who conflict in recommendations. Like when I try Codex, it recommends this. When I try Claude, it recommends that I'm the one making the decision which argument is more compelling. Right. So I'm resolving conflict like I'm doing all the classic manager things. I think if you extend it just one level. If I were instead on a team and now you have a scrum that's made up of five engineering managers, you know, how would you run that differently?

Host 1 (34:19)

Right.

Philip Hsu (34:19)

You would certainly ask a different set of questions if every day five engineering managers gathered for a standup. So I do think when I think about the work I do now, it's easier, honestly for me as a single person company, because now I can focus on a lot of the other customer facing things because I have the time. Like I am looking up App Store Connect like stats on my app and I'm building in new features like Sentry and whatnot. That I didn't have before. But I think for anybody with even a modest size company, this requires completely rethinking how you organize people within the company. Because now you have a company that's entirely composed of engineering managers, plus PMs and designers.

Host 1 (34:59)

Yeah, absolutely. That's a great way to frame it. And also for us to think and start developing that idea. What would a company look like where you only have engineering manager designers and PMs and some companies are already working on also making the designers designing managers

Host 2 (35:17)

rather than designers themselves?

Philip Hsu (35:20)

And it has all the difficulties of. If I today told you, you might remember in the early 2000s, there was a big offshoring scare. You know, lots of work was moving to India back then and then eventually to Eastern Europe. Imagine if your company worked on the premise that all your engineering managers just manage remote workers in these other countries. Countries. Now, back then, the quality of product being produced out of those countries was objectively lower than in the US. That certainly won't stay the case forever because the skill sets in those countries have gone way, way up. Right. But back then, it was commonly understood that you would kind of get worse code, but it was cheaper. Okay, this is exactly what AI is today, which is you kind of get worse code, but it's cheaper. So if you ran a company that way, you will have all the difficulties of a company that ran with offshoring as its primary premise back then. And you have to structure the company and how you coordinate the people accordingly. Yeah, absolutely.

Host 1 (36:12)

That's a great point.

Host 2 (36:13)

Right. Like, it's just, you're.

Host 1 (36:15)

You're kicking the can down the road. Yeah, we get a little bit more efficiency, but what does that mean? Well, we won't know until we actually try it. All right, Filip, thank you very much for sharing all of those insights and stories with us. We're about to end. But before we go, what's one resource? Could be a book, a blog post. Of course, your own substack will be in the show Notes. How do you pronounce your substack, by the way? Way.

Philip Hsu (36:38)

You know, Mala Nations. It comes from Moloch. It comes from a post by the guy who does Scott Alexander that does Slate Star Codex. And it comes from a post from him called Meditations on Moloch. And that post has really fundamentally changed the way I think about the world. It's supposed to encourage us to think about the world as systems, not as individual people. And think about what incentives the system will naturally lead to.

Host 1 (37:03)

Absolutely. We'll put the link to that, to that post also there so Malachi nations by Philip Su Substack. But what is one resource that you think would be a great starting point for people who want to really go deeper, understand better this AI adoption wave

Host 2 (37:20)

that we are part of right now?

Philip Hsu (37:22)

I think the mistake I see most of my friends making right now is everybody is so excited about AI that they are reading about it all the time, watching YouTubes about it all the time. I think this is the mistake. The one resource that I would recommend people do do is trust no one. Do the work yourself. You know, every person that just brags they vibe coded Tetris or whatever or every person that says I changed my Claude MD to do this right, all of this is wild West. Your best resource is to hands on, build real products with the AI and build it in the leading edge way. So if Claude announces that they're going to support teams, you know, go ahead and pay for the tokens and use the teams for a while while. Right? See what happens. By doing, you will much more concretely know for yourself which things are hype and which things are actually true. Absolutely.

Host 2 (38:13)

Do it yourself.

Host 1 (38:14)

That's what we advocate here on the podcast and we love to share these stories from the people who are doing it themselves. Like you, Philip. All right, and where can people find out more about you superphonic and the work that you're doing?

Philip Hsu (38:26)

Yeah, I think Malacca nations is the best way to go if people are amused by podcasts. My miniseries Peak Salvation talks a lot more about the experience of working at Amazon, what it means for technical unemployment, what it means when robots take over our jobs. So that one is just a miniseries they can find anywhere.

Host 1 (38:44)

Absolutely. And we'll put the link to those in the show notes. And we thank you very much, Philippe, for your generosity with your time and your knowledge.

Philip Hsu (38:53)

Great chatting today. Thank you.

Host 1 (38:58)

Hi there friends.

Host 2 (39:00)

Thanks for sticking around till the end of the episode.

Host 1 (39:03)

So let me tell you what's coming on May 4th.

Host 2 (39:05)

We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in Organization, where practitioners show what actually works.

Host 1 (39:33)

No hype, just AI.

Host 2 (39:36)

That makes your Monday better.

Host 1 (39:38)

Happy Monday, everybody.

Host 2 (39:40)

And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is agile in construction.

Host 1 (39:54)

And yes, I really mean brick and mortar.

Host 2 (39:56)

Construction Lean and Agile Actual job sites Field leaders Removing waste Teams transforming how buildings get built Stay tuned for what I think will be a super track on Agile in construction and the fourth track is Agile in Gaming. How Game Studios Ship Without Burning out Agile Inside the Creative Pressure Cooker over

Host 1 (40:27)

the years We've had more than 12,000

Host 2 (40:29)

participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th.

Host 1 (40:50)

Or you can grab the Practitioner Pass

Host 2 (40:52)

and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adzic and Mirete Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to bitly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly globalagile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.

Philip Hsu (41:41)

Sam.