Does AI Make Tech Debt Worse OR... Does AI Make Tech Debt Go Away?

Transcript is auto-generated and may contain errors.

Hey folks, we are going to the experience devs subreddit. This topic is about tech and of course everyone else's favorite topic, AI. And so uh you know we can't have a video in 2026 without AI. So, uh, the author was, I guess, posing a couple of different views and then asking folks like for their opinion. Um, I kind of feel like this one could be pretty polarizing depending on how people talk about it. And so, my goal is to kind of share maybe some different thoughts to try and see if we can balance out some perspectives. Uh, I'll let you know like kind of what way I'm leaning and why, but be kind of interesting. Obviously, I don't have the answer definitively to this and how how and why and whatever it looks like for Tecta and AI in the future. But a lot of it was coming down to like are we going down this path where tech debt becomes a uh a thing of the past is one of the options.

Okay. So the idea being that if uh if you can have AI write all this code, can't you just have AI do all this refactoring? right? Like can't you just solve this problem of tech debt with AI itself and then effectively move away from them? Right? That's kind of like one general framing of this. The other is like that uh the tech debt becomes um significantly worse. And the framing there being that if it's a thing of the past or sorry if it's a thing that we're already experiencing and it's you know in software engineering it's it's it's always been a thing um like doesn't that suggest that it will just continue to be a thing and if not more because uh with AI if we're able to get code output faster and uh at least for now in the foreseeable future, we're in this position where we're talking about AI.

Yeah, it writes a lot of code. It can it can write really good code, but the fact that it writes tons and is not always uh, you know, perfectly aligned with you, uh, means that you're kind of moving at a higher velocity in a direction that's not perfectly the direction you want to go. So, these are kind of two polar opposites on this. And I usually think that you know truth is somewhere between opposites. And I also think it's going to depend on uh how things are executed, the type of software you're building um and uh this obvious unknown which is like how do how do the tools and the models and stuff evolve over time. Um, at a at a high level, like I think I probably lean towards. I mean, there's literally parts to both sides that I that I agree with. So, maybe I'll start that way.

And the parts that kind of stick out for me when I'm thinking about this kind of stuff, um, I'll start with, uh, making more tech debt, right? So, uh, based on the last thing I was saying, I I do really think that, um, with things unchecked because agents are able to write lots and lots of code. Um, I do think that we're heading down a path where again with with things unchecked, there's my caveat that uh, you know, we we go down a path of more and more tech debt being introduced into code bases. Okay. And so like maybe it's it's worth pausing like so what what is tech debt? And I think that also shifts the conversation a little bit and it's I don't know depending on people's uh view of what tech debt is. You might have differing opinions. So some people have like a more strict view on specifically what tech debt is.

Uh, and I think that mine is uh, encompasses a little bit more. And so I think some people will say tech debt is when you make a conscious decision, right? Like you're going, okay, uh, we need to ship this feature faster, but we don't have time to go do it the good way, so we'll compromise and do it not the good way. Um, and we'll we'll come back. we'll pay down this debt later, right? We'll refactor it later to uh accommodate for uh this this crappy solution we're doing now. So, this is like a conscious tech debt decision and um some people stick to mostly something like that and I don't like I think that's part of it and the other part is that um I I have this perspective that even if you have an architecture for the software you're trying to build and trying to adhere to it.

That the over time, the longer the software is around, the more complexity that's added, the more features that are added that you didn't perfectly plan for on, you know, day zero that uh there's going to be drift, right? And like this tech debt thing can come up because of uh just over time enough unknowns coming up that you're accommodating for where you see this drift and you go okay like uh you know I've been trying to as as you know as much as possible accommodate these things with as little as possible hacks and if I step back and look at the code base like we've just drifted from um you know this architecture that we set out and maybe it's because it's the wrong architecture. Maybe it's because we picked a technology or a a library early on or at some point along the way that's making things challenging.

And so you consciously tried to make good decisions along the way, even regarding your architecture, even focusing and prioritizing on your codebase, and it still ends up not being quite the thing. And it could be for various reasons. So this is uh like a like unintentional tech debt. And so I think both of these things exist personally and I factor them both into into my tech debt conversation. And so when I tell you that I think that sure we're going to, you know, parts of me think that AI is going to create more and more tech debt, it's for both of these reasons, I guess. Um you know I I think the unintentional part for me the unintentional tech that is going to be the bigger one in terms of you as let me let me clarify to you in terms of you as a human or uh the group of you as a team of humans then imagine that you want code to be structured a certain way.

Uh by the way I am talking about code specifically but when we talk about code being structured a certain way uh at some point that also has other technical implications outside of just the code structure. for example, um maybe you have dependencies pulled in where they shouldn't be pulled in and that's causing size bloat and now you have some like I don't know like deployment issue because you have extra tons and tons of uh uh data being you know stuck along your your executable or something. So it can have other side effects outside of the code but I am primarily focused on code when I'm talking about this. So you can have AI creating code that is drifting further and further away from like what you might imagine is the ideal world. Okay? And so I'm not saying that there's no solution for that or nothing that helps keep that in check.

I'm just saying that I used a special word earlier. I said when left unchecked, I do think that uh you can really go down this path and I think that we will see more and more of it. And uh you know one of the sort of implicit helpers here will be smarter models and better tooling right I think I think we're going to get those things right things will keep improving over time so I'm not uh you know freaking out about that or anything. So, the stuff that people use without putting even more effort in will do a better job, which is great cuz that helps level up everyone that's using it. So, that's goodness. Um, but I I do think that like uh the the one of the big risks is people uh doing things unchecked with AI is how I would frame it.

And you might say, "Well, Nick, maybe people should stop sucking at programming or they should, you know, get good at using AI." And sure, yeah, like I'm not saying that people should stop there and that everyone stops at the bare minimum of like um you know, just vibe coding in their terminal. I'm not saying that that's what will happen or what should happen. But I am saying that um if there is more and more of that or it doesn't improve then I see uh the opportunity for tech that just going up and that's just because AI produces more volume of code per unit time. Okay. So want to come back to like some some mitigations and stuff maybe in a little bit. But the other side to this is the opposite which is like um the reduction of tech debt. And so how can both of these things be true?

Well, I think this goes back to uh some of the things I said near the beginning of like how how you use implement focus on AI in your your domain. So, there's a few projects that I've been playing with where um on purpose I've not been paying much attention to the code. And I say on purpose like I if you aren't familiar with me in my other videos and stuff like I've been programming for over 20 years. I'm not like I didn't just pick up Cloud Code yesterday and decided I'm going to be uh making software development videos. Um so I am uh I'm not saying I'm the best programmer in the world, but I've been doing it for a little bit. Uh so I know at least a couple of things I would say. Um I feel like I can say that confidently. I have programmed once or twice over the past 20 years.

And so, um, I think when it comes to some of these apps I've been playing with and not paying much attention to the code, I have noticed that I've been able to make like significant progress in terms of like adding functionality, getting something useful done. I will also acknowledge that for some of these things I am not shipping them to customers right like I'm moving extremely fast with them I am not shipping that stuff to customers because I think that my confidence level would not be there okay so this is like what I am building right that's a factor how I'm building it is I'm sitting there hyperfocused on just features and functionality So, what's interesting I'm finding is that when I'm like like vibe coding these things with an LLM, I'm I'm just focus on like how do I like I have specific functionality. I want it I want more of it and I want it better.

And because I'm sitting there vibe coding with the agent and then using what it's doing, I'm it's like a really tight feedback loop focused on a thing I'm trying to do. So it's uh in terms of like tech debt um this is where it's interesting is like the effect of the tech debt might be getting uh minimized which maybe is a funny way to put it. I already told you in the last few minutes. I'm not looking at that code. So, you might say, "Nick, how do you know there isn't tech?" Great question. Uh, I don't. Right. Um, or I have less exposure to it. Right. There could be 10 times as much tech debt as normal. And in fact, I genuinely think that at given points in my workflow, there is probably significantly more tech debt than I'm comfortable with if I were to be looking at it.

But I'm not. And the reason I don't have to in these circumstances is that I'm not the one writing the code. I have strong opinions about how to structure code. I've said this in other videos and stuff like I love building everything with a plug-in architecture even when it's not the right tool. I just like to do that, you know, self- acknowledging that I I realize it's not always the right tool. I like building software that way. It's just my brain works that way and I like to do it. So, I do. Um, so you know, if I were to look at the code that's being produced in these cases, I would assume that a lot of it is probably not, you know, up to how I would like to do it or it's just different ways. But I'm not the one coding exclusively for these projects, right?

It's literally entirely LLM driven. So the the perspective of the tech debt becomes minimized. And then you might say, well, Nick, how do you how do you know that it's actually minimized? What happens when you hit a problem? And again, like good question. I have been doing this and hitting problems at some points. One, the most very most recent one I was uh back to file sizes. That's why it was relevant for me. I was uh giving someone an MCP server um yesterday and uh zipped it up for them, sent it over to Teams, and I was like, why is Teams like hanging? And you might say, Nick, it's a Microsoft product. Yeah. Like, okay, I get it. No one likes Teams. Fine. Um but I'm like, Teams is like, what's going on here? Like, it's not taking the not taking my upload. And then I I looked and the zip file was 200 megabytes.

And I said, "What what the hell is going on here? It's a it's an MCP server, man. Like, it's what are you what are you talking about? What what is this?" And then I realized that the way some of the code was structured is that it was pulling in dependencies from uh sort of like a charting application that had nothing to do with the MCP server. It also had multi-platform stuff because it was uh using some native libraries. So it added like you know a couple hundred megabytes before being zipped. So okay like co-pilot how do we you know get around that and it moved some things around and it did it in like a couple of minutes. Okay. And then it was still pretty big and I said co-pilot where's the rest of the the size coming from?

like you just moved out like something that obviously was consuming a lot and it's like well you have another entry point with a similar problem where it is uh it's actually integrating with a co-pilot CLI a very different integration and it was packaging a co-pilot executable which is another 100 megabytes. So I said, "Okay, like how do we what are we doing for that?" And it's like, "Well, this is going to be more of a significant refactor." Gave me a couple options. I picked one that sounded good to me in terms of uh how I would structure things architecturally. It did it in a couple minutes and my problem was gone. And it it restructured, like I said, architecturally something that I I feel way better about now. So it's not that there was no tech debt. It's that that tech that was accumulating reached a point where I was hitting an issue and then I was able to work through it very fast and I didn't have to be the one suffering.

It was just yeah, let me pick a design and you go do it. Now I realize I'm and I I know that I'm I'm oversimplifying the things I'm saying, right? like that refactor that it did. How do I know that didn't add more problems? Right? I I don't I don't know that it solved it perfectly. I know that it addressed the problem we were talking about. And my last couple minutes here, this is where I would bring up guard rails, right? So, um I have confidence that it didn't break everything, which is a a genuine concern with a refactor. And I have confidence that it didn't break everything because there's, you know, in even in this app, there's like 1500 tests. And how do I know those tests do anything useful? Well, that goes back to some guard rails, right? Like when it was writing the code, it was uh I was steering it to mostly use TDD uh to use like a red green approach.

I would have it uh manually do some mutations, right? So that it would say like okay like this test is over this scenario if I change one of these things around if I mutate what's happening in the code. Yeah, like the test breaks. Cool, right? Different types of tests. So, there's unit tests, there's uh integration tests. I have some stuff that uh wouldn't run in continuous integration, continuous deployment, more of like a run it live, so to speak, kind of thing. I have some uh some tests that are just prompts where I can say, "Hey, let me go, you know, talk to this MCP server with a list of prompts and see if it does the right things." Right? Not in CI/CD. And so just different layers of test, different types of guard rails, and those are giving me confidence that when it does a big sweeping refactor or something that seems kind of scary that maybe it's not so bad.

So I do think I'm on both sides of this, which makes it funny to talk about. Is there parking? There's no parking spots. My god. And so I do like long term. Okay, my my perspective is that uh we will be paying less attention to code being structured perfectly and more attention to code functioning the way we want is my idea. Okay, there's literally no parking spots. I have to cross the street. I'm pissed. This is so stupid. This is the the just for context, the first time in in two years that I've not had any parking. I don't even know if I can park here. So, we'll find out. find out if they tow my car. Anyway, those are my thoughts on this stuff. Um, I think it's going to be interesting times. Um, I think it's I still for all the people saying it's not a good time for software engineering, I still think it's a great time.

I understand hiring and uh stuff is really difficult right now, but um super interesting stuff going on. So, I'm I'm it's it's it's a lot of fun right now. So, if you got questions, leave them below in the comments. Otherwise, go to codec.com. You can submit stuff anonymously. And I will see you in the next video.