Did AI Kill Programming? | EP. 50

Speaker A: Foreign.

Speaker B: Welcome to Inlayers, where we explore the people and technology behind artificial intelligence. I'm your host, Ron Green. Today we're going to discuss a topic close to my heart. Is programming dead? Over the past year, AI coding tools have crossed an important threshold. They've moved from advanced autocomplete to systems that can design, write, refactor entire chunks of software when prompted in plain English. For many engineers, the day to day experience of writing code, uh, already ah, feels fundamentally different even more than it did 12 months ago. That shift raises some uncomfortable questions. Are we watching the early stages of AI replace programmers outright? Or is this simply the next stage of tooling transition when it changes how software is built while keeping humans firmly in the loop? If programming becomes more about intent or architecture and review than syntax, what skills actually matter going forward? And how much further can these systems realistically go? In this episode we're going to take a look at all of those questions seriously and we'll talk about what has actually changed, what has not, and where the hype is justified and where it is clearly not. And we will also look at how the role of programmer is evolving and what this means for people entering the field. Today, as always, I'm joined by two of the sharpest minds in history. My co founder and distinguished machine learning engineer, Dr. Z.Z. tsai. And uh, our vice president of engineering, Michael Wharton. All right guys, I'm really excited about this conversation because we've had this on our list for a while to talk about this and um, I'm actually kind of glad that it just kept getting bumped because there have been some enormous changes in the last three or four months.

Speaker A: Absolutely.

Speaker B: Specifically I'm thinking about Opus 4.5 which came out from Anthropic. That model was released what, late November? Yeah, around that, around that timeframe. And you know, it takes, these models are um, uh, not easy to evaluate anymore. Um, it takes a bit. But I would say really by mid December, late December, we were all pretty excited about what we were seeing from uh, Opus 4.5 and its ability to take us from maybe the vibe coding error where you would say I want you to um, um, help me uh, finish this code I'm writing and it's making sophisticated autocomplete decisions to more task driven uh, completion but where you really had to check it and it was maybe 80% hit or miss to. I'm increasingly seeing I can give it high level uh, objectives and it will almost always successfully complete them in the first go. So right off the bat I Want to ask you about your experiences with 4.5 which is funny, it's what 3, 4 months old and that's already been replaced by 4.6. That's how fast things are changing. But Opus, um, let me throw this to you first zz. How has it changed your day to day? Like are you feeling the same difference that I'm feeling in the quality of its code generation?

Speaker A: Yeah, absolutely. I would say I'm um, kind of an early adopter and kind of on the end of a spectrum where you know um, where I began to use Cloud Co and it's uh still uh Opus 4 and also uh, when codecs from OpenAI just came out and I would say over time the quality has changed, has improved a lot and I would say Opus 4.5 is a uh step change in terms of the quality and also speed and the um accuracy of the code uh just came up a lot. So I've used it to automate more and more of my workflow from in the beginning of simpler code completion, completing this line to help me write this unit test um to right now. It's sometimes whole application like a simple web app or a machine learning ah pipeline that automatically kind of uh try to come up with the first solution to this Kaggle problem. Yeah, this is quite impressive.

Speaker B: And are you ah from a um success perspective? So if you give it an assignment you say add this capability or maybe try to fix some bug. How often today do you see it fail?

Speaker A: M. That's a great question. It really depends on what type of things you do. I'll give you one example. I did this um, uh around last uh October uh end of October where I try to automate uh a simple kind of Kaggle competition. Come up with this model um training pipeline that takes in uh ah text data and try to classify uh given this excerpt which of the three authors do you think wrote this text? And uh for that task I was able to just without intervention I just write a simple spec like hey here are common um machine learning uh steps that you need to do. You need to split the data ah to train validation. Here uh are some common text features, uh blah blah blah so a spec and then just have the coding agents um generate code and also train models over time. It's time consuming because of the training loop. It takes long right? And it ran for half a day to a day depending on which coding agents. And I compared the uh few solutions uh there including clock code and codecs and also the composer from cursor and the Quality, um, it blows my mind. I mean it easily exceeds the median accuracy of human participants of Kaggle. And you know, people who participate in Kaggle, they're already self selected people who work in machine learning. It didn't quite reach the top 10% or 5% yet, but I mean that's hard to reach and to kind of compare with myself. I also tackle it kind of manually and it took me kind of couple of days on and off to achieve that accuracy. Yeah.

Speaker B: Okay, Michael, so you run an entire engineering team and all you do is work, you know, building AI solutions day and night. Has this tool yet? Has the really the quantum leap in performance in AI coding assistance affected your project timelines yet, or the amount of um, work that you think can be completed in any given sprint? Or is it still, you're just still absorbing the capabilities?

Speaker C: I think it's, it's probably the latter. I mean when you think about the parts of the development workflow that are strictly related to software engineering, those are leaps and bounds faster than they would have been otherwise. Um, but in the reality, or in reality the world's just a messy place. There's a lot of stuff to happen which is like requirements, development, system architecture decisions, a lot of planning that happens before you even submit that first prompt. I'm starting to think that yeah, these tools have almost like sped out ahead of us and we haven't caught up to exactly where they are. There's a, there's a layer of abstraction between coding agents and how we interact with them that is evolving rapidly right now. There's so many different workflows, prompting techniques. There are paradigms like spec driven, uh, development that are, people are starting to play with. Which I think to your point earlier Ron, you know, that can really help close that gap between product owners and managers and developers themselves and really like tighten that iteration cycle time. But um, at the moment I feel like it's so incredibly immature. It's almost like the, the work is now on us to figure out how to interface with these tools rather than, you know, some quantum leap of model performance that's going to change the game.

Speaker B: You know, it's a great point. I completely agree. I've always, you uh, know I'm a technologist and so this hurts me a little bit to say, but I've always kind of seen that any product I've ever developed or any product company that I've started that didn't succeed. It was never the technology, it was always product market fit, right? It wasn't the technology we were always able to build what we could imagine. I wonder if we're entering a phase where product managers and being able to know what you want to build is going to become the most important part of technology. Because we've got this new leverage. We've got this ability to build anything we want. Now we have to figure out what we want to build. We're no longer.

Speaker C: Yeah, the question's the important thing now, not the methodology for building it in the first place.

Speaker B: Exactly, exactly. So, all, uh. Right. So we're kind of dancing around the question for today, which is, you know, is programming dead right? And by that I mean, are we in a world where, um. If you were giving advice to, um, young people, would you tell them, don't go into software, don't go get a computer science degree. You will not be employed? And so I want to hear what both of you think about this.

Speaker C: Michael.

Speaker B: Um, first, do you think that that's an exaggeration or that's an exaggeration? Just for now?

Speaker C: I think it's an exaggeration for now. I mean, I always feel like it's. That's a, It's. It's a tough question, you know, so that we were in a, um, in a boardroom talking to one of our clients recently, and they, they asked me, he's like, okay, my kid's going to college. Should he become a programmer? What. What should he do? What, like, what? Just give me some advice here. I was like, honestly, there's just a lot of. I don't know if there's any one correct answer. Um, but there are two answers I gave them. One is that I think domain expertise is invaluable regardless of what you're doing. So even if you have someone go in, you know, learn computer science, I think that's still important, but it needs to be paired with. Paired with some sort of domain expertise. Whether that's, you know, in my case, it's aerospace, you know, zz, I know you've got a lot of deep expertise in computer vision, specifically, and other fields. Builds brawn, genetic algorithms. And, you know, everyone has their own domain expertise, but, uh, programming alone as a skill is not sufficient. And the other thing, I think that's really important, more so now than ever. It's an idea I stole from Andrew Yang in a substack post that he, he published, I think, late last year. And the, the sense is that, um, you know, success is almost predetermined by personality traits rather than, you know, some particular set of skills. So it's almost like a conscientiousness or like a, um, you know, like your willingness to adopt new workflows and adapt really quickly is the most important skillset that you can have.

Speaker B: Yeah.

Speaker C: And it's really in short supply in industry from, from my experience.

Speaker B: Yeah, yeah. ZZ what do you think? Is, is programming, is programming dead now or will it be dead soon? Or do you think. No, um, this is just another generation of tools, it's another advancement. But there will always be a need for human developers.

Speaker A: Um, my personal belief is that it's far from being dead and on the contrary, it's going to um, maybe experience one of the best time uh, in history for getting into programming. So my reason, but of course, fast forward 10 years, looking back, um, are our predictions correct? It's always hard to say given how fast paced the development are in AI. But uh, here's why I think this way. Um, if you think of programming narrowly as writing code as to Python C, um, these are tasks and these tasks can be largely automated. But I'm quoting Jensen Huang's uh, words recently. There are tasks and there are purposes. Um, software engineering and programming is more than writing code using specific language. Um, as engineers and as you become more senior, you need to think more and more about architecture, systems, machines, your customers. It's a whole, um, whole collection of things that you need to balance about and decide against. Um, and also to our point around like deciding what features to build, deciding what product uh, shape should be, that's even more important. Um, programming is much more than um, generating or writing code. And in that sense I think um, I think it's far from dead.

Speaker B: Okay, I like that. I mean I may even believe it because it's such a nice thought. I've always believed that programming is a means to an end, meaning you're not writing the code to write the code, you're writing the code to accomplish some task, to build some capability. And we've seen throughout the history of uh, the software industry we move up in levels of abstraction, right? Originally it was machine code, then it was assembly, then it was high order languages. And for decades we've been stuck at this sort of high order language level. Um, and now we uh, have perhaps the most powerful level of abstraction period, which is we can express just in plain English, we want and build entire applications, right?

Speaker A: Yeah.

Speaker B: So I think that, I really genuinely think we could see both of these past come true. I'm not trying to dodge the question, but it seems to me that software and programming is both Dead or dying in the sense that the need to understand and write the code, I truly think will diminish just the way it did with assembly language and just the way it did with machine code. Um, but at the same time it may, it may allow us to move more quickly and there will be an increasing return. The leverage that people who know how to use these skills and know what they want and know how to drive and prompt and direct these systems, uh, will be the most valuable. And this is a perfect segue for, you know, the junior developer problem. Okay, let's say software programming is not dead. I'm seeing an increasingly lack, um, of appetite for companies to hire young out of college talent.

Speaker C: It's a big problem.

Speaker B: Yeah, it's a really big problem because, um, uh, let me ask you this. Do you, I feel like senior developers, people with a lot of experience, get the most out of these coding agents. Are you seeing the same thing or are you seeing something different?

Speaker C: A thousand percent. You know, I think that not only is, is this AI coding agent kind of, I guess, revolution, it's amplifying the abilities of these expert developers. People have been doing it for years and years, but it's also amplifying flaws at the bottom end. So you can do a whole lot of damage if you are a junior developer. And I think that to your earlier point, it is really short sighted for a lot of organizations to look at that imbalance and be like, oh, okay, you know, maybe we just only need experts and we can like really get a lot more out of them exclusively. But the problem is if you're not building that pipeline to constantly create experts in the first place, then it's a ticking time bomb. And you know, you're, I mean, I, I think that prematurely devaluing, uh, mentorship and stewardship of younger developer developers is one of the biggest mistakes we could make as an industry right now.

Speaker B: Yeah, the, the uh, dystopian scenario is we, we flash forward few decades and we don't even understand how the software works anymore.

Speaker A: Right? Yeah.

Speaker C: Yeah, okay.

Speaker A: Yeah, that's a great point.

Speaker C: Yeah.

Speaker B: You know, so. All right, um, all right, I'm going to pause one second, guys. I want to look at my notes. How are we doing on time? I know we had to stop there.

Speaker C: It's about 15 minutes.

Speaker B: Okay, so I want to go about another 10, 15 max. I want to keep these tight. So I'm going to, I'm going to, I'm going to just make a couple of comments and then I'm going to I'm going to ask you guys some questions, if that's cool.

Speaker A: Yeah, definitely.

Speaker C: Sounds great.

Speaker B: Okay. Um, I read a quote the other day that I thought was amazing. It said, uh, you know, software ate the world. And this was a quote that I think that came out about 15 years ago, that software is eating in the world. And by that it meant that there's nothing, uh, there's no part of our society or culture that's not being impacted by software and either being, uh, improved or automated. Um, and the new quote is, software ate the world and AI is using software now. Right. And so from an ego perspective, does that hurt? Like, as somebody who's spent decades, definitely, you know, mastering this skill, Zizi, how does it make you feel?

Speaker A: Oh, definitely ouch for me. But I think it's not the first time, you know, we collectively, um, uh, has an ego hit when deep blue, the deep blue moment for chess. And then, you know, I never thought, go, the game of go, um, we will lose to computers. And that happened. Right. And then the more recent example that I just mentioned, automating training, uh, the model, it did a pretty good job that I have to try hard at it, to level myself up.

Speaker B: Yeah. So definitely it's crazy to think that, uh, it's very, very possible that the first job that ever got fully automated was the programming job. We, we, we worked ourselves out of a job. I mean, it's just nuts. Okay, so I've got, I've got a couple of hard questions for you guys. Number one, um, well, I'll actually start a little bit easier. So. Zz, and this is especially for you, describe a moment, like a surprising before after moment that changed your workflow in the last six to 12 months. We talked about Opus 4.5. But, like, what's changed? Like, what, what did you stop doing? What are the types of things that you just simply don't do anymore? If there are any. And what did you start doing now with these new capabilities?

Speaker A: Um, that's a great question. I'm thinking because there are so many of them now. Um, so before, I wouldn't think of myself, like, trying to build a browser or trying to build, um, I don't know, a video editor app, which I'm now doing as a hobby projects. Now, before coding agents, I mentioned myself I have to maybe take courses, maybe read books and read other people's thousands of lines of code to understand how Electron works, how do you build, and, uh, how do video editor timeline work. But now, with coding agents being they already have A lot of knowledge that's built in. They also can read very fast, much faster than me. It's able to generate boilerplate code which um, I guess a couple months ago when I tried it, it didn't work super well. It's sort of a working app, it's a working browser but with a lot of uh, uh, messy UIs and stuff. And now it's much better now, um, and it will keep getting better but uh, I can um, interact with coding agents first. Let it ask me questions about, hey, what's important about the UI and you know, and then being able to kind of connect to MCPS and you know, let it inspect, take a screenshot and inspect what's happening. And then you know, just um, keep feeding information to the coding agents about how the app is doing, what uh, needs to be improved and that, you know, just seeing uh, the app getting better and better without me looking at the code, even 1% of the code that it generates.

Speaker B: It's astounding.

Speaker A: Yeah, it really blows my mind.

Speaker B: I had a moment, um, a couple weekends ago. I was working on a, ah, user interface for a client project. And um, as I clicked across um, some of the elements, it uh, would flash white, the screen would refresh and would kind of flash white really quickly. And I wanted to see how little guidance I could give the model. And I literally said this was cursor. Uh, I just said when I click sometimes it flashes white. Fix that. And it didn't take long. I think it thought for about a minute it identified it had had some property that wasn't being set. It was being set to null and it fixed it. And I mean I literally had to take a moment. I stood up with my coffee and just paused. Just mind blown that we're in this world with just almost no guidance, something flashing white. I didn't even say what I was doing. And it could very quickly get to the bottom of that. I mean we're just in an entirely new world. It's astounding. Um, okay, I'm going to pause there again for break. Michael, do you want to answer that question or you want me to go to a different question? The one around um, before, after.

Speaker C: I could. But if you're compress for time, you want to just go to the next one?

Speaker B: No, no. Do you want to answer it? I'd love to.

Speaker C: Uh, sure. Sure.

Speaker B: Okay. Okay. Michael, how about you? How's your, you know, last six months? The before, after? What, what are, what are the things that you stopped doing and what, what are Things that you're doing now that you weren't doing before.

Speaker C: Yeah, I think there are a lot of old and good habits, or at least that would have been good habits as you know, software engineer, pre coding agents. Um, and even there have been like multiple steps along the way. Like autocomplete was the real big boon to begin with. Uh, with, with like delegating at least some of our work to these coding agents and even that I feel like I just mentally have to get my head out of that level of development and like bite size, iteration and move up a layer.

Speaker B: You mean you need, you need to stop yourself from thinking that way and

Speaker C: I need to stop myself from like delegating such a small, trivial thing and think more at the feature level.

Speaker B: Feature level, Spec level. Yeah.

Speaker C: And I, and even like with debugging like you just mentioned, like, I built this app recently, um, where I was kind of frustrated with how much time I was spending throughout the week to try to just keep up with what was going on. And there's a clear context engineering problem of, you know, what sources do you trust, what newsletters do you think are pretty, you know, reliable at least? And I did a little bit of prompting there and built this thing out. And then just that like beautiful kind of like human machine melding of whenever there'd be a bug. Because that it was, it wasn't, it wasn't just like a locally hosted application. There's like a custom domain with DNS records that I put together for a custom email server. Um, I had some, you know, it was all CDK based and AWS deployment with a lambda that runs daily and you know, EventBridge schedule and everything. And um, you know, along the way, even the parts of the integration that were kind of buggy in like outside of my local development environment, all I would do when something bad would happen, I was just like, paste the error, put it in, say, hey, what's going on? Help me understand this. And it's just it honestly, like, dare I say it was more fun than developing a year ago.

Speaker B: Oh, uh, man.

Speaker C: Like, I actually think we're in a better spot now as developers if you can just guide it in the right way.

Speaker B: I completely agree. I mean I've been doing this for decades and I completely agree. It's just more fun. You, you are, um, it's so rare you get blocked in a way.

Speaker A: Yeah. How much more things you can do now in the same amount of time.

Speaker B: Yeah, exactly.

Speaker C: You know, something else that's crazy, um, that I feel like I've gotten over recently is, you know, I used to do a lot of planning up front to, I mean it's uh, it's common best practice now that the more upfront planning you do, you know, the better the result probably is going to be. If you can put that in just kind of like a single turn spec sheet. Um, um, but I'm noticing like even in domains I have like a hairbrained idea of something that I want to do that's new. I don't even know where to start. Instead of going to the Internet and doing this big research problem, I'll just be like, hey club, ask me what you think is important to guide the design from the get go. And even that is like a learning process and like a teaching moment to learn how to design something. And by the time we have this spec sheet put together at the end of it, it's like, it's just so fun.

Speaker B: I totally agree. And we were talking earlier about how it's going to become more and more important around knowing what you want and specifying what you want. But what I didn't say is that I'm increasingly using AI for that part of it too.

Speaker A: Right.

Speaker B: Like, I have an idea. I think I want to build this before I even go create the spec, interact with it and say what am I missing? What gaps, what questions need to be answered? Um, any recommendations on how I can improve this? This you have this whole iterative process with the agent before you even begin creating the spec. And uh, ultimate recursion. It of course can create the spec if you do that part well and you don't even have to do that part of the development. Right. It's astounding. Okay. All right, I want to wrap up. I've got a couple more things I want you both to go on the record. This is a falsifiable prediction. We can look back in time. Um, have we hit peak computer science graduates, let's say in the year 2030. So let's just go 2030. 2031, five years in the future, are there the same number of computer science graduates? More or less.

Speaker A: Wow.

Speaker B: Michael, what do you think?

Speaker C: Oh, it's tough because I think the definition of computer science is going to be changing in that timeline.

Speaker B: Question.

Speaker C: Okay, okay, I. If you want just like a really simple answer, assuming that computer science captures, you know, the person who's in the driver's seat of development, like that's the core skill set we're looking at, I think it's going to be dramatically more, dramatically more awesome.

Speaker B: Okay. I love it. It's easy.

Speaker A: I think it depends on, you know, whether, uh, computer science, uh, departments are going to open up courses for uh, developing using AI. And I, you know, assuming that's true, I think it's going to be more. And the reason is you. The paradox, uh, the Devon's paradox, I think, is that as the cost of development, uh, become lower, the total demand is going to increase. And I think this may be the moment where the level of abstraction for human programmers increase again. And I think in history, maybe it happened once or twice, but I wish I can speak to this, but I don't have any experience of coding in assembly language aside from the. In college courses. Um, but when compilers came out and people begin to program in C, in Fortran, and now in Pythons, uh, et cetera, that's increase of, uh, level of abstraction allows you to do so much more. I cannot imagine writing assembly for a model training type.

Speaker B: I know.

Speaker A: And even bytes.

Speaker B: Okay, I'm gonna go.

Speaker C: Yeah, you gotta get on the record too.

Speaker B: I'm willing to do it. So you both think it'll increase? I genuinely think it's gonna decrease. And um, they could. I'm saying what's defined as a computer science major right now, that's what I'm talking about. I could see colleges adapting and it becoming an AI engineer certificate or something like that. And that's kind of moving the goalposts. But assuming I'm just talking straight up the computer science curriculum as it stands right now, I think we're probably hitting peak. And that's just my guess. And I think it will. Those sets of skills, um, uh, will be displaced by new capabilities, um, and new academic tracks in the future. And I think we've kind of hit peak. Okay. All right, guys, any final thoughts here on. Is programming dead?

Speaker C: Don't forget to set a Calendar invite for 2030 so we can check back in.

Speaker A: Okay?

Speaker B: Deal. All right. That was awesome. All right, guys, fantastic conversation. Thanks so much.

Speaker A: Thank you.

Speaker C: Thanks a bunch.

Speaker B: Thank you for listening to Hidden Layers. This series is hosted by Kung Fu AI, a management consulting and engineering firm focused exclusively on artificial intelligence. If you have any questions or thoughts about today's episode, or if you know someone we should feature, please visit us at Kung Fu AI.