Is AI coding making technical debt worse, or could it help us finally clean it up? In this edition of the Web News, Matt and Mike debate how tighter deadlines, unchecked code, and AI’s context limits affect maintainability - and whether clean code still matters when AI can navigate the mess.
Inspired by this r/webdev discussion: https://www.reddit.com/r/webdev/comments/1wi3mi5/is_vibe_coding_creating_a_hidden_technical_debt/
This edition of the Web News was inspired by a recent (as of recording) Reddit post on /rwebdev.
From the Reddit Post:
Is vibe coding creating a hidden technical debt crisis?
I love building tools and side projects, but lately I have been thinking about how heavy reliance on AI coding assistants is going to impact long-term code quality. Building fast with AI tools is great for getting a prototype out the door, but letting AI generate massive chunks of unvetted code is quickly piling up technical debt.
When you push out code without thoroughly checking how it fits into your overall architecture, you end up with messy, unmaintainable codebases. If you ever plan to sell a project or hand it off to another developer, that unvetted code can completely ruin a deal during due diligence.
I still use AI to speed up my workflow, but I treat it strictly as an assistant rather than letting it write unchecked logic. Auditing generated code, keeping modules clean, and maintaining test coverage seem like the only ways to use these tools strategically without destroying the project. Are you noticing a drop in maintainability on projects heavy on AI code?
Reddit Link: Is vibe coding creating a hidden technical debt crisis? : r/webdev
This transcript is machine generated, there may be errors.
[00:00:00]
Matt: All righty, everybody. This is yet another edition of the Web News, and this Web News is inspired by a Reddit post titled, "Is Vibe Coding Creating a Hidden Technical Debt Crisis?" I will link to the Reddit post so you can go check out the comments and, uh, all the rest of the, the good stuff you can do on Reddit.
Give some up votes and, and what have you. Uh, go and check that out. Uh, it's on r/webdev. I'm just gonna read the post to you. It's, uh, three very brief paragraphs. So it says, "I love building tools and side projects, but lately I've been thinking about how heavy reliance on AI coding assistance is going to impact long-term code quality. Building fast with AI tools is great for getting a prototype out the door, but letting AI generate massive chunks of unvetted code is quickly piling up technical debt. When you push code out, uh, without thoroughly checking how it fits into your overall architecture, you end up with messy, unmaintainable code bases.
If you ever plan to sell a project or hand it off to another developer, that unvetted code [00:01:00] can completely ruin a deal during due diligence. I still use AI to speed up my workflow, but I treat it strictly as an assistant rather than letting it write unchecked logic. Auditing, uh, generated code, keeping modules clean, and maintaining test coverage seem like the only ways to use these tools strategically without destroying the project.
Are you noticing a drop in maintainability on projects heavy on AI code?" Uh, so there's a bunch of different, uh, opinions in the comments. The top ones that I saw were generally like, yeah, like obviously, you know, tech debt is kind of going up and things like that. But I have a couple of topics that I'd like to kind of roughly discuss just to kind of kick things off here, and it is, is AI coding adding technical debt?
Just kind of tackling that project, that, uh, that question 'cause I think it's a little... It sounds like it's something that we could just say yes or no, but it's a bit... There's a bit of nuance there, what type of projects and things. And also AI is, quote unquote, "coding fast," and when humans code fast, technical debt is an [00:02:00] inevitability.
Is this the same situation for AI? So Mike, I've been yapping for quite a while. Why don't you kind of this off?
Mikhail: So Those are two, there's two things that I wanna say. One thing is, it's, yes, it is adding technical debt for most projects because of how managers are twisting AI. Like, A- how, how AI is to a product manager is it's an accelerator. So we'll, you know, what used to take us three months, we'll do in three weeks.
That's kind of how they're seeing it. So because of that mentality, yes, most projects are gonna launch with a bunch of technical debt, a bunch of refactors that need to happen and stuff like that. Having said that, if treated properly, if used properly, it's like l- let's say that, hey, instead of saying that it increases your throughput by 10X, it increases your throughput by 1.5X, that's a more reasonable take.
In that scenario, if you still have the same team and you still have the same tools as you have today, I think it should be decreasing technical debt a- in the places that it matters. And the places that don't matter, like a bunch of syntax, a bunch of tests, it does-- it might not matter. Like, who cares if it is increasing technical debt, as long as the AI is able to assist with it?
I'll explain a little bit. What we, we used to have is a massive backlog of features, right? That, like, you, you, you, that we need to build. That is no longer the technical debt that should be present for you, because AI should be able to build those features. The technical debt that happens now is, hey, this feature was implemented in a different way than this feature, this feature was implemented in a different way than this feature, so it's like code technical debt because AI is not doing a good job of maybe implementing the features in the exact right way.
That's the ty- technical debt that we're seeing with AI a lot, especially like AI three or four months ago. Now AI
is getting a little bit better at figuring that stuff out, so it's getting better and better. But [00:03:00] features are not the technical debt. The technical debt is becoming, again, more and more like the bad code smells, too much code, like especially in, in a- in the thing, like refactors needed. If you have the time, you can have good cycles of technical debt that happen also accelerated by AI.
So lead out, like build, build, build, build, build, have technical debt windows where you-- similar to how we used to have it in traditional development, where we would have weeks of te- battling technical debt. Well now, you can send AI to actually hit your technical debt. "Hey, refactor this to be more like this.
Do this to be more like this." As long as product is aligned, and this is a big if, because right now we're, we're not seeing that. But if product is aligned, and they're willing to not increase your speed by 10X, go down to 1.5X, you can actually create pretty robust code bases with less technical debt than before [00:04:00] I've done that before.
I've also had it very much where a lot of code bases have increased technical debt by considerable amount because of the deadlines that are being proposed nowadays
Matt: I, I wanna pick apart one thing, and that is technical debt was the feature list that you had? I always kind of associated
Mikhail: I
Matt: debt with like, uh, you know how companies will sometimes like push, push, push new features, new features, new features, and they'd actually code them and put them in the platform. But then the platform or whatever app it is gets really, really buggy, and then they kinda come back and they go, "All right, we gotta refactor, we gotta clean this up." And what they're cleaning up at the end of the day is technical debt
Mikhail: I think you're right. I think, I think I mixed that up. Um, I think I was th- thinking technical debt is like backlog,
Matt: Right
Mikhail: debt isn't backlog. Technical debt is a separate column. You're right. So technical debt would be the f- the, the stuff that after adding a feature, um, it would have, like, some sort of a, a s- code smell.
Like, [00:05:00] you added a feature, but you left in the environments from dev and staging in the wrong places and stuff like that, and you need to go and clean that up. Yeah,
Matt: like adding
Mikhail: exactly.
Matt: the code base
Mikhail: Exactly. So it's actually, like, something that would happen during a feature creation depending on the scope that you have and depending on how it goes.
So
Matt: Right
Mikhail: y- you, you're right about that. I was conflicting it with a, with a backlog, which is something that should be much le- much more doable nowadays in terms of speed. But technical debt, yeah, it's, it's more along the lines of fixing code smells, refactors, uh, you know, adding, adding more security around things, stuff like that
Matt: Yeah, and, and I think, I think like with the code smells and that, I mean, you're naturally gonna have code smells and issues and, and, and things that just, like even as you put them in, you're like, "Man, this is band-aided in here," due to speed. And like there was that one part that I wanted to talk about where it's like AI is coding fast.
It's all about, you know, speeding the [00:06:00] human up. then if, back in the day, if humans were to code fast and technical debt is, is basically an inevitability unless you have, you know, some amazing perfectly running, you know, 10X engineers all on your team type of thing. Uh, I think that even with AI, like especially with those deadlines that you mentioned, you will naturally have more technical debt because once again, the, the human brain is the bottleneck.
There's still a human there that's prompting this thing, that's checking the code hopefully, or maybe not, due to the, due to the, deadline, which is probably gonna add to more technical debt as well. And you're prompting it and just taping things together and trying to get things working, uh, so fast that you're not, you know, doing all the checks and balances and things.
I mean, we can see this with products. Like we could see this with things like a normal way to answer an email form is you pull up the email form on the contact page, you fill it in, and then that's it. But if I backspace my name, I should be able to retype in my name. A piece of technical debt might be that they never check [00:07:00] that, and once I backspace my name, I can never reenter my name again into that field. that's an, that's a very, very rudimentary example, but that is an example of like technical debt potentially, you know, getting in the way there where it's like, "Oh, we didn't have the time. We like, we're going as fast as we could, and we only checked the most basic use case," which is pull up the page, fill in the form, and then press submit type of thing. Um, so
Mikhail: Mm-hmm.
Matt: that, that's like a, you know, a b- a basic example of that, and that's, and that's absolutely something that you can imagine with an AI or without an AI you would skip. You wouldn't, you wouldn't check going into each field to filling it in, then backspacing it and, and doing all these things.
You would just be like, "Oh, well, you know, it, I filled it in, I submitted it, you know, onto the next thing, like naturally.
Mikhail: I, I think the thing that I'll push back on in terms of, like, the, the original statement is the idea that unmaintainable code bases are super, um, important now. [00:08:00] Whereas, like, it, it, it could, it could, you know, hurt you if you're trying to sell a project, or it could make it difficult for another developer to onboard.
I think that stuff has become less and less important. As long as the code base is robust in the s- in the sense of, like, not leaking data and h- is being secure enough, right? Like, as long as it's feasible, like it's, it, it works the way it's intended to, even if it's not maintainable, like if there's, you know, interfaces all over the place and there's comments, no comments, and variables named stupidly, the advantage of AI is it's the thing that's gonna have to spin up in it, and it's very good at interpreting code based on code.
Yes, it helps to have comments, but r- recently it's gotten better and better at just understanding what code is doing. And so when you're spinning up, the thing that has probably become the best, the easiest, is spinning up in a code base. Now, a code base of a massive size still takes time, but [00:09:00] a lot less time than it did before because you can ask AI very direct questions about, "Hey, what does this do?"
Or, "How does this work in this? How does the deployment infrastructure work? How does," you know, "How does changing this impact that?" All of that can be kinda handled, or at least you can skill up in it with AI, and then once you have that knowledge, you can start to implement fixes and implement changes and implement features with that knowledge a lot faster than before, even if the code base is somewhat unmaintainable.
So maintainable code is becoming, in my opinion, less and less important. Now, this might be a controversial opinion, but over time, it's going to become to the point where, again, comments are not going to be necessary, and stuff like, you know, r- human-readable languages, we talked about that before, isn't going to be a thing because it's gonna be e- ex-- um, it's going to be abstracted away because the machines are gonna know how to write this machine code a lot more efficiently [00:10:00] than we can,
Matt: Right
Mikhail: more efficiently.
So the more compilers we have that make it more human-readable and more maintainable, the less efficient the code is at the end of the day. And we'll, we're gonna start removing those compilers as we, as we start to trust AI more and more
Matt: Well, if you start co-- Like, I mean, I th- I think that's almost two things though. Like, you're starting to c-code closer to the metal. There's gonna be, there's gonna be examples, for example, within the web development space where React and these other frameworks and libraries and tools that we've made, Svelte, the rest of them, these tools are made as more or less human interfaces a lot of the time to help people create maintainable, readable code across
Mikhail: Mm-hmm.
Matt: But at the end of the day, the browser really only understands CSS, JavaScript, the three pillars that we've talked about, you know, repeatedly in the past. And so, uh, a code, a, an AI that is doing some coding for you could realistically just code in those, in, in the pillars and forget about the maintainability [00:11:00] f- in terms of a team perspective. Like, I, I suppose, like,
Mikhail: Yeah.
Matt: like, that, that part's true.
Mikhail: Mm-hmm
Matt: I will have some pushback on the maintainabil- like, the maintainable code base 'cause the... What I-- If your code is g- is, like, a mess, it is not maintainable, it is the equivalent to me as having a messy workshop. Yeah, if you're in there all the time and you, like, know how to step around the saw and know how to, like, avoid stepping on the rakes and know how to not slip on the hammer that's laying on the floor, fantastic. But... And I, and I understand that if another human showed up, they'd, you know, they'd slip on the hammer, they'd bump into the saw. It'd be a mess 'cause they don't know your, your area. An AI comes in and it analyzes things, and it, it has a better chance of avoiding that thing on the floor, uh, not bumping into this thing, not knocking over the rake or stepping on the rake, right?
It has a better chance of it not Not making mistakes like that. However, I would still say that those things are still hazards, and they're still th- they're still out of [00:12:00] place, in my opinion, for no reason. No good reason. The reason in the technical debt world is oftentimes due to inexperience, a mistake, or due to a project deadline, or due to complexity. Some code bases are so legacy, so old, so crazy that, yeah, I get it. I do agree that an AI could help you navigate these, navigate these, uh, sort of hazardous work, work... I'll just call them hazardous workshops. They, y- they, the AI could help you navigate that hazardous workshop, but it's still a hazardous workshop. And I do, I, I would, I would push back and say, maybe we should just tell the AI to pick up that hammer and to realign that saw so that w- people won't bump into it, and to not have the rake laying around so we don't step on it, because some point, even in AI is... There's still hazards that the AI is, is, uh, is, is avoiding.
We talk about AI context and losing context all the time. I mean, we get, you know, we get 10, 15, 20, 50, 100 [00:13:00] prompts in to talking to this thing, and it's gonna forget the rake is there, and then wham, it's gonna step on the rake. W- w- what, what could have avoided it? The rake not being there in the first place, the rake being in the shelf or on the hook where it's supposed to be. That, like, I would, I would push back on that. But I, I, I... Like, I do concede that, yeah, in a hazardous, in this figurative hazardous, like, workshop situation that I'm equating to a code base, an AI is likely, and it's definitely based on what code base and other things, likely gonna navigate a little better than a human, especially a new human, someone that's new to the code base. It's probably gonna pick up on it quicker But it's still hazardous, and I, I think hazardous for no good reason in, in many cases. What this, what this... What you could potentially argue then is, is that you could kinda have these emergency tickets that show up. "Hey, we really need a contact form here," to go back to then the basic example.
"We really need a [00:14:00] contact form here." All right, let's fire that up. So we spin it up, whatever. We kinda tape it together. Maybe the AI vibe codes it. We look at it, it looks good. In context it looks great, but it doesn't really interface with the CRM too well. There's some missing fields. It's a little messy.
Maybe the number's actually a string or something, and it's not pulling into the CRM nicely or something. An emergency? No. The emergency was getting that form out because we needed people to be able to contact us in this particular context for some reason. That was the emergency. So okay, now there's a bit of a hazard in the work- in the code base now, in the w- in, in the workshop.
There's a bit of a hazard 'cause we've taped this thing in. Okay, so now we need... In, in my opinion, we still need someone to go in there, or AI, preferably maybe both, to go in there and I, I think to still clean it up. 'Cause I don't wanna go, "Emergency ticket, we need this, this contact form." Okay, great.
"Emergency ticket, we need this other page." Okay, great. Emergency, emergency, and then now it's like we have this like, whoa. Like this big bu- like bundle of b- of BS. Maybe I'm [00:15:00] worse at juggling it or h- holding it up and, and, and balancing it than an AI would be, but it's... The AI's still using some of its power to like juggle this nonsense. If that... I don't know if you agree or disagree with me, Mike. I know you're nodding your head a little
Mikhail: Yeah.
Matt: like
Mikhail: I, I, I, yeah, I, I think you're definitely correct. I, I think that you have to kind of make a point of where you draw that line of what is maintainable and what isn't maintainable by AI. And again, I think as we progress and as AI progresses, that line will start to become further and further out. So right now you're 100% right, honestly.
Like, a- and I'm experiencing it right now. Like currently in the code base that I'm in, it's, has a ton of technical debt, and AI is stepping on a bunch of rakes. It is actually, like, that's actually happening to me at this very moment. If, if we clean up that technical debt, it's gonna make it a lot easier for me to work with it and for AI to work with it, 100%.
So that's the... You hit the nail on the head there. What [00:16:00] is inevitably going to happen is it will become better at, A, cleaning up that technical debt as it sees it. 'Cause right now what AI doesn't do very well is it sees an error, it sees an unmaintainable aspect of code, and it's just like, "All right, that's fine," and it just works around it.
For some reason, almost every AI that I use, from the Astras to the Fables down to whatever, that's the way it interacts. But inevitably it will start to get better and probably start to make it less, l- do these things where it, it will fix the unmaintainable code as it sees it. Now, this could be part of its reasoning of like, "Hey, don't touch things that I didn't ask you to touch," which isn't a bad, which isn't a bad call.
But it seems to do that even when I ask it to touch it. Like, it, it's a context issue, like you said. If there's too much context or if the code base is too big, it just becomes way too hard for it to under- to understand what is a rake and what isn't.
Matt: Well, it,
Mikhail: So-
Matt: also, I think it's a utopian issue too, where the AI
Mikhail: Yeah
Matt: it as, well, if [00:17:00] nobody, if nobody's... Like, if, if, if you know how to do the right footwork, then the rakes are not a risk. The rakes are there, they're stored in the building, but they're not on the, the hook, they're not on the shelf. so good, man. But it's like, whoa, whoa, whoa, you know? Like, we have to come in there, and, like, that's how I use it to clear technical debt, is I'll go in there and be like, "Isn't this a risk?" I'll have it, like, tell me, not change. I'll even say, "Don't frigging change anything. I want you to tell me what this is." And it'll do all kinds of stuff, and I'll be like, "Isn't this, like, a bit of a risk and, like, a bit of a mess?" And sometimes it'll be like, "Yeah, but, like, it, you know, as long as no one steps on it, it's not a hazard at all." Cool, you're still changing it.
Mikhail: Yep
Matt: treat the AI. Hey, that's what I mean by kinda like a person with an AI is kinda what, who I'd want, I guess the duo that I'd want to go in and fix technical debt, right?
Mikhail: Yeah. And again, like I think the technical debt shouldn't be as big of an issue as it is right now with AI, but because of the time constraints that is, is put on everything due to h- AI increasing our productivity by X amount, whatever, uh, whatever [00:18:00] the, you know, CEOs and the product managers pass down to the engineering team, you're put in a situation where you're inevitably making more technical debt.
That's, at the end of the day, what's happening, but it doesn't have to be that way. Like, we could be in a place where we could have the right, l- like, you know, a sprint and then a, an A- an AI to fix the technical debt because we have that time. That's how it should be used, and in, in hopefully in good engineering teams, that's how it is, it, it is used.
But in a lot of places, that's not the case. So you need to fight for that, or you need to align and deal with the technical debt and accept it as well. Like, that's another thing that engineers might have to accept in a situation where they can't deal with it or they can't push back. Yeah, technical debt exists, so maybe you have to start prompting your AI differently to go around it, to have it step around the rakes, which is unfortunate
Matt: And I, I do wanna like quickly, just very quickly touch, 'cause like we're pretty well at the end of this web news, but j- just quickly touch on like there's a lot of surrounding supporting, [00:19:00] uh, tech that goes into, into production pipelines and code bases. Like your CICD pipeline could be, you know, a con- a factor with technical debt. Uh, your, your, uh, DevOps, like your... The way you have your, your servers set, the way you have your, your checks set, your linters set, all these things can contribute to technical debt. I mean, we're just focusing on sort of like the general idea of it. But I do, I did just think, I do think it's important to mention that because that's even more and more and more context that you have to give this AI. And AI, by the way, that all of them, as far as I know, struggle with context to some degree. the same way that a human would, and then one day accidentally step on the rake that they avoided for five years
Mikhail: Угу
Matt: But I think that's
Mikhail: Correct
Matt: That, uh, unless you had anything else to add, Mike, I think that is the web news. Working title right now, may even be the title: What Is AI Doing To Technical Debt? Again, this is inspired by a Reddit [00:20:00] thread with a ton of comments on there. There was 90 some odd comments in there when I went and checked on it. That will be in the show notes. Go check it out. You can click on that link. Uh, I'll, uh, also likely include it in the RSS description if I remember, but it will be in the show notes for sure. It's already in there, in fact, um, in the draft version. So please go and check that out, and again, give some up votes or comments or whatever you do on the Reddit. that's it. That's the web news. We're signing off
Mikhail: Goodbye