Its Finally Over For Devs (again, fr fr ong)

Summary

Highlights

• Developers are not going extinct; instead, technologies lead to role transformations. 🔄
• Every few years, new tech promises to replace developers but rather transforms the field. 🔄
• AI tools assist in coding but still need human architects to ensure harmony and efficiency. 🤖
• Skills like communication, system architecture, and orchestration are becoming more crucial. 🗣️
• The pattern is predictable: New tech brings hype, leads to specialization, and raises salaries. 📈

Key Takeaways

• The feared extinction of developers is a recurring hype cycle: New technologies don't replace developers but transform their roles. 🔄
• AI tools need architects: They generate code but lack the judgment and architectural insight needed for cohesive systems. 🤔
• Architectural skills remain vital: As AI tools evolve, the need for strong architectural thinking and orchestration grows. 🏛️
• Transformation rather than elimination: Technologies like AI create new roles and specializations, often at higher salaries. 💼
• AI highlights software's true value: The ability to architect systems, not just write code, is the most valuable skill. 📐

Overview

Chapters

• 00:00 - 00:30: Introduction In the chapter titled "Introduction," the author humorously critiques the recurring rhetoric around new technological advancements that claim to replace developers. They mention launching a blog post titled "The Reoccurring Cycle of Developer Replacement Hype," which discusses the cycle of new technologies from being hyped as revolutionary to eventually being integrated into the standard toolset, much like No Code or AI-assisted technologies. The author emphasizes the predictability of this cycle and the temporary notion of developers becoming obsolete due to technological advances.
• 00:30 - 01:00: Predictable Headlines and Disappointment In this chapter, the author discusses the media's recurrent theme of predicting the obsolescence of software developers. They express skepticism towards sensational headlines proclaiming the 'end of coding' and suggest these narratives often promise unrealistic outcomes, such as children programming at an extremely young age. The author shares their disappointment upon encountering actual articles promoting early coding education and comments on the business world's eager embrace of such trends, with consultants opportunistically joining the frenzy.
• 01:00 - 01:30: Transformation Over Replacement The chapter titled 'Transformation Over Replacement' explores the idea that technological advances, which are initially seen as replacements for technical expertise, often lead to transformation instead. Technologies designed to simplify tasks don't eliminate the need for skilled personnel; instead, they create new specialized roles. For example, the no-code movement didn't make developers obsolete but led to the emergence of no-code specialists and backend integrators. Similarly, cloud platforms like SAP and Salesforce have evolved into specialized systems that require dedicated expertise. Rather than eliminating jobs, these technological shifts transform them into more complex and often higher-paying positions.
• 01:30 - 02:00: DevOps and The Evolution of IT Roles The chapter discusses how the advent of cloud computing has revolutionized the traditional role of system administrators, transforming them into DevOps engineers. This transformation often comes with a significant increase in salary. The chapter reflects on nostalgic memories of early web startups, where one specialist, often referred to as the "build master," was crucial. This individual had extensive knowledge of both Windows IIS and Linux, though typically not favoring Windows.
• 02:00 - 02:30: The Rise of AI-Assisted Development The chapter explores the evolution and impact of AI-assisted development on various roles within tech environments. It mentions specific roles like 'build master,' 'web master,' and 'CIS admin,' highlighting their enthusiasm towards adopting new technologies and environments such as virtual environments and Vagrant. The discussion reflects on the historical excitement and the sometimes humorous nicknames like 'Build Cosby' attributed to these tech enthusiasts.
• 02:30 - 03:00: AI Tools Impact on Development Practices This chapter discusses the significant changes in development practices with the advent of AI tools and cloud computing. Initially, there were specialized individuals managing all cloud computing tasks until the adoption of platforms like Amazon Web Services (AWS). The emergence of DevOps roles marked a shift in how development and operations teams work together. The conversation reminisces about early adopters of technologies like Docker, with individuals such as 'Paul' leading the way in explaining and implementing containerization concepts even when others did not fully grasp the implications of these innovations. The early mention of containers in 2011-2012 highlights the fast-paced evolution of technology and its impact on traditional development roles and knowledge.
• 03:00 - 03:30: Orchestration in Software Development The chapter discusses the evolving role of engineers in the era of AI-assisted software development. Initially, AI was expected to write all code autonomously. However, the reality shifts towards a need for engineers to effectively orchestrate AI systems, which requires new skills and results in higher salary expectations. There's a contemplation on whether managing AI coding assistants might actually position engineers at a lower compensation bracket.
• 03:30 - 04:00: Misconceptions About AI Efficiency This chapter discusses the common misconceptions about the efficiency of AI tools. It emphasizes that while AI coding assistance is considered lucrative and those who develop successful tools can gain substantial financial reward, it is often forgotten that a significant part of AI development is still heavily reliant on human skill and effort. The narrative highlights the imbalance between the perceived instant success and the underlying continuous hard work in AI innovation.
• 04:00 - 04:30: Challenges of AI Assisted Software The chapter titled 'Challenges of AI Assisted Software' delves into the impact of AI tools on non-technical sectors, particularly contractors and designers. It highlights how AI accelerates the creation of applications, especially CRUD (Create, Read, Update, Delete) apps, enabling these professionals to become more efficient. The discussion suggests that these tools allow users to sidestep concerns typical in software development, like technical debt, thereby facilitating rapid content generation and project execution.
• 04:30 - 05:00: Cultural and Collaborative Issues in Development This chapter discusses the cultural and collaborative issues found in development teams. It highlights the lack of concern for technical debt due to the short-term vision of producing immediate results. The focus is on rapidly creating and deploying products without considering long-term implications. This often leads to miscommunications as different groups prioritize quick setups over sustainable development practices.
• 05:00 - 05:30: Music and Software Development Analogy The chapter discusses the analogy between music and software development, focusing on the transformative impact of AI on engineering. It emphasizes that AI is not just a tool for automating tasks but a means to illuminate essential aspects of software engineering. The key takeaway is that the most critical skill in software isn't just coding but the ability to design and architect complex systems. This reflects a shift in focus from micro-level coding to macro-level architectural strategy, which AI developments are increasingly highlighting.
• 05:30 - 06:00: Role of Conductors in Software Teams The chapter discusses various perceptions and approaches to software architecture within teams. It highlights the complexity beyond the typical box-and-arrow diagrams that depict architectural design. Specifically, it mentions the use of tools such as AWS Lambda by team members to integrate and manage various functionalities seamlessly. The conversation seems to critique oversimplified approaches to conducting architecture and emphasizes a nuanced understanding of orchestrating these components effectively.
• 06:00 - 06:30: Critical Reflection on AI Limitations The chapter discusses the balance needed in software development to create APIs that are neither too general nor too specific, referred to as the 'Goldilocks territory.' This sweet spot allows code to be reusable yet tailored enough to be effective over a long period. The content emphasizes the significance of achieving this balance for a microspecific architecture, which is a common consideration among developers.
• 06:30 - 07:00: AI's Limitations in Architecture The chapter explores the ethical and practical limitations of using AI in architecture. The author argues that while AI promotes rewriting and reusing code because of its low cost, this approach is often unsuitable for large projects with significant risks. The process is indeed cheaper for small projects with minimal risks. However, the potential for bugs and complications makes this method less viable for more complex architectural endeavors.
• 07:00 - 07:30: The Endless Lists in Discourse The chapter titled 'The Endless Lists in Discourse' discusses the concept of 'wave refactoring' in programming and the role of AI in it. It explains that wave refactoring involves making incremental changes through several stages of refactoring to manage consequences effectively throughout a program. The chapter expresses a concern that as programs grow larger and AI takes on more responsibility for these refactors, it could lead to what the author terms as 'great inshitification.' This term likely refers to the potential degradation or excessive complication of systems due to continuous refactoring.
• 07:30 - 08:00: Conclusion on Software Development Trends This chapter discusses the current state and emerging trends in software development, focusing particularly on the prevalence of small, annoying bugs across many websites. The author notes that while these issues are not significant enough to be deal breakers, they are pervasive and irritating, affecting user experience. An example given is the recurring problem of Twitter not functioning properly every third refresh. The chapter conveys a sense of frustration with the current quality of websites and highlights a growing trend in the industry where such issues are becoming increasingly commonplace.

Its Finally Over For Devs (again, fr fr ong) Transcription

• 00:00 - 00:30 All right, here we go. Devs are definitely being for real this time. Let's see this one. Here we go. I decided to launch my blog with a hopeful message. Developers are finally going extinct for this time. Pack it up. Learn to prompt and surrender your terminal to the glorious AI overlords. The post is called the reoccurring cycle developer replacement hype. I'm willing to look at this technological trigger, trial of disillusionment, slope of enlightenment, productivity plateau. Yes. Okay. This all looks this all looks really, really real. All right. From no code to AI assisted, every few years, a shiny new technology emerges that promises to make
• 00:30 - 01:00 software developers obsolete. The headlines follow a predictable pattern. The end of coding. Anyone can build apps now. Or my personal favorite, why your 5-year-old will be a programmer before learning to read. No one actually wrote that, right? Coding for 5-year-olds. Best ways to start. What? Okay. Well, actually, that search made me more disappointed. I was hoping just to see that article and be like, "Ah, people are insane." But instead, I saw just real articles being like, "Now to do it." Okay, that just makes me upset. Executives get excited. The consultant circled like sharks.
• 01:00 - 01:30 PowerPoint decks multiply. Budget shift. And then a reality sets in. What actually happens isn't replacement. Its transformation. Technologies that promise to eliminate the need for technical expertise end up creating entirely new specializations, often at higher salary points than before. The no code movement didn't eliminate developers. It created no code specialists and back-end integrators. The cloud, I mean, that's literally uh SAP, right? Isn't that like Salesforce? Like Salesforce is its own world that exists outside of everybody else. The no code thing is so true it hurts. All
• 01:30 - 02:00 right. The cloud didn't eliminate system administrators. It transformed them into DevOps engineers at double the salary. It's actually true. It's there's kind of a funny part to this cuz I remember when I was when I was young when I was a young man working at uh some of these earlier web startups, there was always the one guy, right? His name was always like the build master or something along those lines. And it was always this guy who deeply knew Windows IIIS and Linux for whatever reason. Knew them both. Always hated Windows III.
• 02:00 - 02:30 Can't blame the guy. And he would go off and no, not the codemaster, the build master. His build master, web master, uh sometimes the CIS admin is what you'd see them in flavors of. And they'd always be convincing you of the craziest things. always very early very early into virtual environments, very early into uh what was it? Vagrant, you know, super excited about stuff. I know is I'm sorry I'm saying I'm sorry I'm even saying this. Build Cosby. Yeah, they'd be normally known as Build Cosby. And I
• 02:30 - 03:00 remember like we always had one of those guys and they would just run all of our basic cloud compute and then at some point it all went to the uh went to the Amazon and then somehow we now have DevOps engineers instead. Oh, you knew Paul too? Yeah, we all knew Paul. They knew about Docker first. Oh yeah, he was telling me about Docker really early on. I was hearing all about containers in like 2012, 2011 and I have no idea what they were and I was just like I don't even know what's happening here. I didn't even understand Linux at all at
• 03:00 - 03:30 that point. Now, now we terraform bros. Now you just terform bros, which is totally cool. Uh, now we're witnessing the same pattern with AI assisted development. The promise AI will write all your code is evolving into the reality that we need engineers who can effectively orchestrate AI systems, which essentially the same engineers but now with new skills and higher salary expectations. Is that true? I wonder if that's true because in my in my brain if you orchestrate a bunch of AI coding assistants you fundamentally will be at a lower bracket just because of what you
• 03:30 - 04:00 produce. Whereas people producing the AI coding assistance seem to be at higher brackets, right? Like if you can produce a better AI tool today, you will have YC just updating you so hard and they will they will just try to hand you millions of dollars right now. like today, just today, like you do that, you got a million dollars. And it's something that I forget and it's something that I'm extremely a victim of just not remembering. There's a huge portion of development that is just
• 04:00 - 04:30 churning out content for shops that are not technical, right? They're just simply contractors. They have an entire set of tools developed around creating a project, getting things out, designers that pipe in stuff, and they just make CRUD apps as fast as possible. You can imagine, right? Like you can imagine that there's an entire set of people that AI these AI tools like genuinely make them go so much faster because they don't care about technical debt, right?
• 04:30 - 05:00 They they don't you don't have to care about technical debt because all you have to do is prod you just have to produce X. There's no longer term vision. It's just produce X, that's it. Move on to the next like single function setup website and that's that. And so it's just like boom boom boom. So the faster that process goes, the better, right? That means more business that the you know the the marketing site can get. I think this is where a lot of the miscommunication around these tools happens is that there's entire groups of people that stand up these little solo
• 05:00 - 05:30 projects that have no need to be maintained longer than, you know, whatever. uh whatever some short period of time and so then AI is this like just giant multiplier but there's something deeper happening with this particular transformation unlike previous technological shifts that primarily changed how we implement solutions AI assisted development is highlighting a fundamental truth about software engineering that has always existed but is now impossible to ignore the most valuable skill in software isn't writing code it's architecting systems I think it's kind of more of a macro game I
• 05:30 - 06:00 think there's more to that statement than uh they're obviously making which I'm going to hopefully I don't know maybe maybe I'll say because the problem with this whole like okay it's it's about just architecting there's several ways in which people think about architecture right there's the there's the very up top boxes and arrows that's like hey I need to be able to use these services to chain together these functionalities just imagine every last person using lambdas to control their entire architecture right they have this flowing into that flowing into this
• 06:00 - 06:30 flowing into that right you've seen this a thousand times okay fantastic this is one version of it but there's also the version where when you write code, you can produce code fast enough that it actually has a nice enough API that it can stick around for a while. It's not too general. It's not it's not too specific. It's just that, right? It's like that Goldilocks territory where you're like, this is really really nice and now I can use this and run with this for quite some time. And this is like more like a microspecific architecture thing, which I think a lot of people
• 06:30 - 07:00 don't value enough. And I think this is where the AI gets kind of interesting because AI's whole approach is that you can just throw this away, right? You can throw it away and you can just rewrite it into a new form because now writing code is cheap. I would argue that this isn't cheap, right? I think this is cheap in small projects because in small projects you don't have what's it called? you just don't have a lot of risk in rewriting a like some portion of your code because all the bugs that
• 07:00 - 07:30 could happen you know you'll be able to hopefully stamp out the end or the consequential the refactor wave that happens that kind of waves throughout your program is smaller but as it gets larger and as we get AI's more responsibility just to do these large set refactors that go and go okay refactor where's all the breaking things refactor on top of that refactor on top of that refactor on top of that and kind of does that wave refactoring to just do these really cheap changes is I think what we're going to see is just the great inshitification. I'm like so positive the nshitification is coming
• 07:30 - 08:00 and it's going to be larger than it ever has been because right now it has been pretty awful with a lot of websites. I have noticed that I am running more and more into just websites that just have these really annoying bugs constantly like everywhere and they're small. They're not like deal breakers, but they're just annoying enough that they're just everywhere all the time. Like I hate the fact that every like third refresh on Twitter, it just doesn't work. That's annoying. And you
• 08:00 - 08:30 see this quite frequently where it's just like, "Hey, does this work?" No, this doesn't work because for whatever reason, it's just not going to work and we're going to just have to deal with the fallout, right? It's just getting annoying at this point. And so I do think that the most valuable skill is somewhere in the middle of all this. There's some there's some world that exists where it's going to be where it's putting together systems, being able to talk with other people, and being able to make code that isn't shitty in the smallest category that that's like this is the vis. You need to be practical. You need
• 08:30 - 09:00 to be able to be theoretical, and you need to be able to communicate with people as we'll see. That's uh the one skill AI isn't close to uh replacing. The endless carousel of replacement promises. How many times have we been Let's see. Ridden this merry-go round. Let's count the rotations. No code, low code. Yep. Remember when the drag and drop interfaces were going to let business users build their own applications? The promise was clear. We Why hire expensive developers when anyone can build an app? This was a disaster. What actually happened? These tools created a new class of problems. Someone still needed to design the data models, underpin those shiny interfaces,
• 09:00 - 09:30 integrate the existing system databases, handle the edge cases. The visual tools couldn't address, maintain, and upgrade their requirements evolved. The result wasn't fewer developers. It was the birth of no code specialists who understood both the business domain and the technical limitations of these platforms. And guess what? They're they commanded higher salaries than the developers they supposedly replaced. He should have started with Cobalt. Cobalt actually is a great example of Cobalt. That's actually such a good call out. Cobalt was this idea that programming should be near English. I mean, that's
• 09:30 - 10:00 like literally why programming ended with a period in Cobalt is because you should be able to write out what appeared to be English. Like that's unironically a requirement which is kind of hard to I think it's really hard to think about that. Think that's real. I don't see I don't feel like Python was that. I don't feel like Python or JavaScript or Lua was like that. I feel like they they they understood their place whereas Cobalt actually tried to be something different. Cloud revolution move to the cloud and you can fire your ops team. This one gets me every time as
• 10:00 - 10:30 as if infrastructure could would somehow manage itself once some uh it was someone else's server. The cloud didn't eliminate the need for systems expertise. It just changed what that expertise looked like. And you could actually probably add on top of this, if they did this, you could probably add on top, I don't know if he addresses this, but uh the whole serverless revolution. Not just that somebody else manages your server, which is, by the way, really nice. Amazon just always keeps things up and running, but on top of that, that the whole serverless one, you don't even need to think about servers.
• 10:30 - 11:00 How many times do you see per week someone tweeting, "I didn't know what I was doing. I didn't cash whatever and now I have a $100,000 bill. It's like it's the same learning every single time. Like I didn't know what I was doing and now I'm absolutely screwed. Yeah, I know. Oh, for whatever reason your site has like one and a half second startups constantly. Huh. Crazy. It's crazy that that keeps happening. It's almost like you should learn some things about how this works. Serverless is actually server more. Serverless just
• 11:00 - 11:30 means you have to think about servers also. That's it. The system admins weren't eliminated. They were born as DevOps engineers with fancy new job titles and substantially higher compensation packages. They were the work didn't disappear. It evolved into infrastructure as codes, automated deployment pipelines, and distributed system management. And the worst part is that most people's projects never see more than like a thousand users a month. Do we have all of this intensity over virtually almost nothing? As uh as I noted in my LinkedIn post about microservices, I've watched teams spend
• 11:30 - 12:00 months decomposing perfectly functional systems into microservices only to discover they traded one set of problems for a more expensive set. Dude, that is so true. But I I still remember there's this very important interaction I had with a friend who finally admitted to me that they like this was unironic that they had more microservices than users. And he finally was just like, I hate this. What have I done to my life? I've actually created so many different things I have to launch just to accomplish something I could have just
• 12:00 - 12:30 done, right? Like I could have just built one thing. Instead, I have like 900 things all tied together through implicit contracts instead of just like a library. All praise to modular monolith. Honestly, it doesn't even have to be a wellthought through monolith. You know how easy it is just to have a library and then you just use that library to do your data storage and then sometime later you can come back and change it if it ever needs it. I had a project I was competing with at Meta where they had less users than people working on the project. That means the people who built
• 12:30 - 13:00 it didn't even click on it. Feels good, dude. So good. Google+. Yeah, it's plus the offshore development wave. Why pay local developers when you can get the same work done for a fraction of the cost overseas? The promise of dramatic cost savings quickly collided with the reality of communication challenges, quality issues, and discovery that effective software development requires deep contextual knowledge and continuous collaboration. I don't know how this one wasn't seen. I love my
• 13:00 - 13:30 wife, but we fight from time to time and I am completely motivated to communicate the best I can possibly communicate with her. and I am motiv motivated outside of everything else. So imagine now that you're communicating with people that you're not going that you're not going to be able to have like all sorts of cultural idioms you don't understand versus they don't understand yours. There's all sorts of different ideas that you have in your head that are just going to be when you say the same words mean or
• 13:30 - 14:00 create different pictures. Like there's just so much there's just so much craziness when it comes to actual communication. nuts to think that this was going to be a pure trade-off, right? What emerges instead was a more nuanced approach. Distributed teams with clear ownership boundaries, stronger architecture practices, and surprised higher total cost than initiated than the initial projected. Yep. AI coding assistant revolution. Now we have the pro AI promising to write code for us. Just describe what you want and AI will generate it. Huh. Huh. Does
• 14:00 - 14:30 anybody can anybody describe what they want? Can anybody describe what they want accurately? Even like even when you even when you can describe what you want accurately, you still aren't describing what you want accurately because there's so many underlying assumptions you're making. Code is the most accurate. Code has always been the most accurate. Code is the code is the reflected intentions of the person. AI generates a plausible looking code that often fails in subtle ways. Senior engineers spend significant time verifying uh the correct AI output.
• 14:30 - 15:00 The vibe coding phenomenon means experienced developers exact more value uh than noviceses. I don't know what the vi I don't know if that's true about vibe coding extract. I I honestly have no idea if that's true or not. I think it's true in the sense that part of vibe coding is you need to be able to vibe tell them what to do and to be able to use the right words in the right place probably means you get a different type of separation of code, right? Cuz like if you have no idea then yeah. Okay. Systems built entirely with AI assistance often lack a coherent architecture. Often I love I love the
• 15:00 - 15:30 word often included here. Like that's a is that really a thing is often do you no this is a filler word there is no often it is the pattern is clear in each case the technology didn't replace the skill it elevated it to a higher level of abstraction the pattern is almost formulaic at this point new technology promises to replace technical expertise early adopter uh adopters discover the hidden complexities the role transforms rather than disappear salaries increase as the skill becomes more specialized
• 15:30 - 16:00 rinse and repeat with the X-revolutionary technology. But there's something different about this current wave of AI tools. Something that highlights a truth that has been operating in the background all along. Or let's see the orchestra analogy. Why we need conductors not just musicians. To understand what's happening with AI in software development. I want to induce analogy. Building software is like creating music not a solo performer but as an orchestra. In this analogy, individual developers are like skilled musicians who can play their instruments beautifully. Technologies and frameworks are like the instruments themselves. Programming languages are the musical
• 16:00 - 16:30 notation. Okay, stretching a little bit with this analogy. AI coding assistants are like the extraordinarily talented session musicians who can play any part perfectly, but only once they know what to play. But you just said that they often lack architecture and all that. Little too high praise here. Little too high praise there. What AI assistants can do is they can make a melody that sounds like it should be there, but you have to still adjust it no matter what, right? Uh but here's the critical question. Who
• 16:30 - 17:00 decides what music should be played? Who uh ensures all these talented musicians create harmony rather than the cacophony? Obviously product managers, right? Product managers. Can we all agree like that's why we have product managers? They're they're there to make your life happy because you, the stupid developer, doesn't know what you want to build. So you have people who know what they want to build. Okay? They're called product managers. That's the conductor commonly called product manager. the architect who understands not just how individual parts sound, but how they must work together to create something greater
• 17:00 - 17:30 than the sum of its parts. I always call that also the CEO, the drive by CEOing. Who didn't love drive by CEOing? And really, this can be drive by bossing of any kind where they just just boss man walks by and goes, "Hey, we should do this differently." And then the worst part is is that you do it differently and then the actual designer/product manager is like, "What the hell's going on here? Why are you doing this?" And you're just like, That's what I do every time. An orchestra without a conductor. Imagine a
• 17:30 - 18:00 world-class orchestra, a virtuoso performance of every instrument but with no conductor. What happens? They might play this same piece with different tempos. The brass section might overpower the strings at crucial moments. The musicians might interrupt dynamics differently. The overall performance lack cohesion even though each individual musician is playing their part perfectly. Actually, I don't know what would happen. I don't know what would happen, but it could be pretty magic, right? Yoyo ma. Yoyo ma. Yoyo ma. There you go. Yoyo ma. It could be pretty magic. Like actually I have no idea what would happen. Uh that precisely what happens
• 18:00 - 18:30 in software projects without strong architectural leadership. AI can generate perfect functions, components, and even entire services. But without architecture to guide how they work together, you don't get a symphony. You get noise. So again, so this is what Okay. So this is what I people miss this constantly. This is not true. They don't produce perfect functions or components or any of those things. And this is not me even trying to like I'm really not trying to be like Mr. Anti-AI here. Uh it's just that you got to understand like if you don't understand where they fail at, you literally are doomed to
• 18:30 - 19:00 repeat stupid stuff. And so a really great example of this is just going to be whenever you see uh X uh where is it? Uh squirt. Do we have squirt in here? Okay, it must be a different look at what do you see in here? Okay, this is written by an AI. I had an AI dude. Docs equals source. Yeah, I had an AI write this entire project. Okay, what do you see in this highlighted region? What you see is a distance function being calculated multiple times, right? A lot of squirting, correct? But notice that
• 19:00 - 19:30 even the even the generation of the distance function is actually done differently. You have dxdy, but then you also have it this way. Notice that there was no even vector created with vector operations. It just simply was, okay, sometimes we're going to do it this way. Sometimes we'll use math.pow and math.squirt. Sometimes we'll do it this way. Sometimes we'll use distance squared. Right? Sometimes that's just what happens. Oh, look at this. Another squirt. Ah, crazy, right?
• 19:30 - 20:00 It's crazy that in a single file there could be four inlined ways to calculate the distance with no vec. And so that's what I'm saying is that it's not it's not meant I'm not trying to dunk on AI. I'm just saying that if you think that it produces this stuff, you just produce worse stuff. You're literally hurting yourself more. It's you have to be hypervigilant about everything. Also, the squirt's not necessary. Yes, you could also do you could also do a distance squared uh like comparison, right? Everything can just
• 20:00 - 20:30 be distance squared. You just got to learn how to prompt row. I know everyone says this. And so that's that's like my big worry that people don't understand is that they don't realize why it's bad. It's not bad because it is doing the correct thing here. I mean, technically, this also wasn't the correct thing. It did this weird sort function and it actually didn't have to do a sort function. This whole sorting that's going on right here actually did not need to exist cuz it actually doesn't even use the uh sorting state as an important part of what it's doing. Like that's the best part is that
• 20:30 - 21:00 it's updating enemies, but because in every game you need to sort things that you render by zindex before you render them. It did that, but it did it in an update function which then just ran regular updates. Like that is just so good. It's so good. Like this code doesn't even need to exist at all. What conductor actually does. People mistakenly think a conductor just keeps time human metronome. Uh but the let's see, but any orchestra orchestral musician will tell you that the conductor does far more right. Interprets the composer's intent. Translate the abstract notes on the page
• 21:00 - 21:30 into specific vision. Controls balance. Ensures no section drowns out another. Shapes dynamics. decides where to build intensity and where to create space. Unifies interpretation. Ensures consistent style and approach across all musicians. Adjust in real time. Responds to what actually is happening, not just what's on the page. Now, replace the composer's intent with business requirements, balance, and resource allocation and dynamics with performance characteristics, and you'll see exactly what the software architect does. So, I think this is a it's just too h this is just too hyperfocused on one aspect of
• 21:30 - 22:00 writing code, which is just architecture. Right? Again, it's like the it's, you know, there's the people that say everything about software is just actually really communications, all you really need to know. It's like, no, that's not it either. People that say, "No, it's just about architecture." No, it's not just about that either. People that say it's just about coding. No, it's not just that either. It's actually going to be it's it is really truly the intersection of all those things. The conductor's ear, the most valuable skill a conductor possesses isn't the ability to wave a baton. Uh it's having the orchestral ear that can detect subtle disharmony in complex uh sound. Identify
• 22:00 - 22:30 exactly which section or instrument is out of tune. Understand how small adjustments will impact overall performance in software. What this is called is architectural thinking. Uh detecting subtle design inconsistencies in complex systems. Have you ever worked in a big project? Like that's just that's literally what that's that that's just called the big project is design inconsistencies. Not a successful one. Yes, a successful one. What are you talking about? That's just called two. Like that is every project above a few
• 22:30 - 23:00 lines of code just becomes more and more out of place with each other. Right? Identify exactly which component is causing performance issues. This is not a simple thing to do. Often there's spread there's spread costs because of how you write code that are just not easy to understand. And sometimes a complete burndown and rewrites the only way you can save true performance from these things. It's not, these things are not simple. Understanding how small design decisions will impact overall system behavior. This is, by the way, this is called like hotspot performance, which hotspots performance issues can
• 23:00 - 23:30 and do happen. And you can obviously take away those ones. Like sometimes there's just things that perform really bad. Totally. Totally reasonable, but at the exact same time, this is not an always thing. You can't train an AI on this kind of ear because it requires something AI fundamentally lacks. Holistic judgment based on experience and intuition. An a an AI can tell you if a code compiles or if it follows a pattern but it can't well first off an AI cannot tell you if code compiles like fundamentally that's not true or if it follows a pattern but it can tell you if architecture feels right uh for specific
• 23:30 - 24:00 business context. Why musicians still need conductors? Even the world's best orchestras filled with the musicians who have played at the same pieces hundreds of times still require conductors. Why? Because someone needs to Okay, this has to be AI written. There's too many lists here. Every list has a list on it. How is there this many up votes on this guys? I trust you. I trust you on my site to make good judgments. Okay, I trust you, but you can't keep telling me that we need this much exact
• 24:00 - 24:30 descriptions into how conductors work. Okay, like look, do we need that? Look, look at this. It starts It starts here and just keeps on going. Dude, just just really is going. Okay. Like, guys, what are you doing to me? All right, let's just go down to um let's try to find some sort of thing. Dude,
• 24:30 - 25:00 it's still Dude, it's still on this thing. It's still Dude, it is still creating lists. Like you got to understand that if you're think if you I'm not upset that an article saying that we should just have AIS write more of the stuff and you should just you should just be the architecture architect to this. I would have to say that uh you obviously didn't follow much of your own dry principles in this architecture here. Okay. Because you repeat yourself consistently. I think the first few line I honestly think that
• 25:00 - 25:30 the first few little bits are actually really really good uh things to point out. Cloud Revolution didn't actually save us from not needing CIS admins. Low code, no code did not prevent people from having to program and program quite a bit to make this happen. Offshore development did not somehow take away all the jobs. In fact, it just more emphasized the need for being uh local right now. And so I think the same thing is going to happen with AI coding. I think the the real takeaway from this article is the following that anytime something becomes more accessible and
• 25:30 - 26:00 what it produces is a liability costs go up. People just have this weird notion that code is a strategic moat. Code is in fact not a strategic moat. Code almost universally is a liability. So if you can produce that liability faster with less even o even even if it's inconsistent in someone's head and it's not beautiful code it's still the same code. It's still someone writing the same code and they're familiar with
• 26:00 - 26:30 it. Right? At least if one person writes the code and writes it's a completely horrible one 8,000line function. At least that person knows the code. When something breaks they know where the code broke at. Do you know what I mean? At least it's in their head. But this one is like it's not in your head. You don't know where it breaks at and it's still a liability. It's a liability. The end. And now we have many more people producing the liability. There will be more