AI Is Pouring Gasoline on the Problem 62.4% of Devs Hate

Indexado: 2026-05-22

[00:00:00]Two years ago, Stack Overflow published their 2024 developer survey, and they asked professional developers what frustrates them the most. The number one frustration selected by 62.4% of developers was technical depth. And second place was not even close, which really puts it into perspective. Now, if you're someone with a technical background, you know that not only how frustrating technical depth is, but also how dangerous it can be for a project.

[00:00:29]And if you're a nontechnical person, you don't have to worry about this because you are too busy shipping production code at Coinbase.

[00:00:39]I mean, come on. You don't need to have a daddy working at Blizzard to realize there's something wrong here and that we are at a point where AI is basically pouring gasoline on the technical depth dumpster fire at scale. So, today we got to talk about how AI is speedrunning this. We're going to take a look at some empirical data. I'm going to give you some of my predictions and where I think a lot of these companies are heading. As always, links to all my sources are in the description. Okay, so first you need to take a look at this diagram. I don't know the official name for this, but let's call it software quality diagram.

[00:01:17]It's this simple square. On this side, we have good and bad. And on this side, we have visible and invisible. So the first box is good and visible. That is a feature. It works. Everyone can see it and it provides some kind of value in some expected way. Then we have bad and visible. This is a bug. The application crashes, does something nobody wants or behaves in a way nobody expects. Bugs are frustrating and painful, but they are visible and you are aware of them.

[00:01:47]The other two boxes are the invisible software qualities. So the invisible good is architecture, maintainability, clean boundaries and so on. Good architecture matters because it makes future work easier. Martin Fowler has this thing called the design stamina hypothesis and the idea is basically that skipping design can make you faster at the beginning but later the code becomes harder and harder to evolve.

[00:02:16]Good design is what lets you keep moving instead of turning every new feature into a hostage negotiation with the code base. The invisible bad is technical depth. The app works today with the current feature scope, but adding or changing anything is like trying to pull up piece from a Jenga tower while standing on one of those half ball balance things from the gym. I don't know what the name for this is. Now, since technical depth is invisible, you can have a completely fine-l lookinging demo, but underneath it can be a bigger mess than my dating history. And this is the problem. While a bug screams, technical depth is like a silent disease that eats your code base without giving any signals. It's basically a negative aura buff on your code base, like minus 36% on all stats. Okay, now AI enters the chat. And according to some well we don't need studies for this but according to some studies it makes you code faster and that's also my perception but for example there was a control study on GitHub copilot where developers had to implement an HTTP server in JavaScript and the group with co-pilot finished 55.8% faster and this is everyone's perception that you can generate code faster than typing it all by yourself. So AI is very good at creating this visible thing fast. And I'm not talking about the code quality underneath it. Okay? So calm down. You're going to break a nail. Take a deep breath. So you can give it a specification. You press enter and then something happens and you get kind of what you asked for. But AI is also good at creating the invisible bad thing very fast. And if you don't know how to recognize the invisible bat thing or don't know that it even exists, you might look at the output and think, "Nice, let's fire all the people and get a fifth private jet." While the code base quietly becomes a dumpster fire, but with dark mode. So yes, AI makes coding faster. That is not the controversial part. The controversial part is what happens after the code exists. I have said this many times.

[00:04:28]Writing code is the easy part. The real work is making sure the code is engineered correctly, secure, testable, understandable, and maintainable. But now, just to play devil's advocate, you could say yes, Tariq. But you're acting as if all humans write this perfectly crafted code all the time. People write dog code, too. And that's true. Of course, humans also write bad code. I've seen projects where the only documentation is a comment from 2014 saying temporary fix. Temporary fix of what? But there are two very important differences when it comes to comparing bad AI code and bad human code. The first one is awareness and the second one is volume. When I write a bad piece of code, I usually know what I did usually. I mean, I know which piece of code I need to tell my colleagues about.

[00:05:25]Like, listen, the deadline was tied, but I finished somehow everything in time.

[00:05:31]This part is not beautiful, but we can clean it up later, which most of the time never happens, but that's not the topic today. And that is not ideal by any means. But at least you are aware of it. There is some ownership. You know where the body is buried. But with AI generated code, that awareness disappears like like it never happened.

[00:05:55]You don't have this moment where you say to yourself, "Okay, this is ugly, but it will do the trick for now." This sounds like a night out with the boys. Anyway, now the problem is the code compiles, it's formatted nicely, and it has the confidence of someone who absolutely knows what they're doing, even when it doesn't. So my point is even if AI creates the same amount of technical depth as a human would, the depth is more dangerous because you may not know where it is. And then comes the second part, volume. If I have a bad day, which is like every day when I'm at the office, I can only write so much terrible code. So there are physical limits to my mediocrity. And AI does not have this problem. As long as it has electricity, it can generate more dog than a animal rescue shelter where somehow every pitbull is a mix. A mix of what? Like a pitbull in a pitbull. You get my point. AI fixes bad code with more bad code until it kind of works. So the problem is not the technical depth will happen. The problem is creating it without any awareness on a scale never seen before while at the same time it still compiles and is formatted nicely.

[00:07:18]And that's how you get technical depth on steroids. And now you might say, "Okay, Tariq, but if AI creates the problem, can we not just use AI to fix the problem?" Well, a study called refining chat GP3 generated code looked at 4,66 generated Java and Python programs and found wrong outputs and maintainability issues and showed that this self-repair improved code quality by more than 20%.

[00:07:48]But the important part is that it only partially addressed the problems. It helped obviously, but it did not magically clean everything up. So yes, AI can help fix some AI generated issues, but that does not mean that the problem magically disappears. That is like saying, "I'm going to put below a BMW a mop." So when the engine starts leaking oil, the mop is going to clean it up. Bro, get out of my house. Jokes on you. I'm an kid and we don't own houses or anything. Anyway, now many people will say the real issue isn't just AI. It's who's using it and how.

[00:08:29]And I agree with that. And that's the point where we enter what I call the non-technical depth trap. The problem when you don't know what you don't know.

[00:08:39]This is where the whole non-technical team shipping production code thing becomes much more interesting because the problem is not just AI. The problem is who's using it, right? How much they understand and whether they even know what they should be looking for. If an experienced engineer uses AI, they can still be skeptical. They can look at the output and say this part is weird, this is unnecessary, we don't need this dependency and so on. But if someone is non-technical or just very inexperienced, they may not have that filter. They see code that compiles an explanation that kind of makes sense and then the first thing that comes into their mind is let's fire everyone. And that is the trap because in software I mean not just in software but generally speaking in life the same knowledge you need to solve a problem is often the same knowledge you need to judge whether the solution is good or not. And there's also a nice paper called unskilled and unaware of it which describes how people with limited skill in a domain can also lack the ability to recognize the quality of their own performance and this is what we all know as the Dunning Krueger effect. So if you use AI as a teacher, that's good. Ask it questions, ask why, and ask for tradeoffs. But if you use AI as a shortcut around understanding, you're not removing the work. You are moving the work into the future. Okay? So now we have all the ingredients. We have something that can generate a lot of technical depth very fast. And we have overly confident and overly incompetent people using this tool. Now we just need to let it cook for long enough for the real disaster.

[00:10:21]So the question is where does this lead if we keep letting this cycle run?

[00:10:26]First, there will be a horde of middle managers bragging to upper management about how they can now fire half the developers and still create more code for less money. All in the hope that one day they will get a seat on the private jet. People are mistaking code output for actual progress. And after a while, the code base starts getting heavier than my student app. Review takes longer and everything is getting bloated because you were not removing the real issues. It's like your car is broken, but you've now put a spoiler on it. And that is not engineering. That is like gambling, but with a better font and emojis, like rocket emojis. That, my friend, is the technical depth cycle on fast forward. Generate faster, then you review slower. You ship more, then you debug more. You create more code, then the system becomes harder to change. And eventually someone says the cursed mythical sentence, maybe we should rewrite the whole thing, which is like the worst thing that can happen in any software project. But sometimes it's the only solution that you have. Now to zoom out a bit. When you read this survey and see what the Coinbase guy said, you quickly realize a lot of people have this very optimistic definition of production ready code. If it compiles, that means it works and that qualifies it as production level code. Well, no.

[00:11:53]Compilation only means the code is shaped like code. That is not the same thing as production level code. And this is why anyone who's serious about software engineering or software development, whatever you call it, should not just let AI run wild without any oversight. Okay. Now, to be honest, I don't think this gets much better before it gets much worse. I think we will see a lot of bloated software like never before. We will see companies overestimating themselves, overestimating AI, and definitely overestimating what non-technical teams can safely ship without real engineering support. Whenever I worked with interns or junior developers, I usually spend the least amount of time teaching them how to literally like write code. Of course, I mean sometimes you tell them practical details like think about the memory layout or you should not use dynamic memory allocation on small tiny embedded devices. But the most important stuff was what is good architecture, communication, documentation, learning to say early, hey, this part is messy and learning not to hide problems because you think you're going to embarrass yourself. This is not Stack Overflow, okay? I tried to teach them how to think like a software engineer and also other stuff that many people unfortunately never learn like how to keep your ego out of the engineery thinking method equation. And now if companies stop hiring junior engineers because AI can generate code, where is the next generation of the senior software engineers going to come from?

[00:13:38]You could say, "Yeah, AI is going to get better. It's an infinite possibilities.

[00:13:44]But if you ask me, I don't think we can fully replace like this senior engineer guy. I mean, you become good at this or good at anything by learning, listening, creating, failing, and slowly developing good judgment. In the past, people used to complain about code monkeys, but rather we now have like uh prompt gorillas. I mean, if AI helps me write a better algorithm, great. If it helps me search faster than Google, even better, because Google became basically an ad engine where the search engine is a side quest. But now back to the topic that is coding is like not the main reason I would hire a junior developer or an intern. I never wanted juniors to produce as much code as possible in the least amount of time. I wanted them to grow into someone who can challenge my ideas, who can ask good questions, who can point out risks, and eventually tell me where I'm wrong. And that is valuable. I'm not saying AI will automatically destroy your whole code base, but it will absolutely help you destroy it faster if you already don't know what you're doing. And that is the silver lining. AI is giving developers a bigger shovel. Some teams are going to use that shovel to build some amazing things and other teams are going to use it to dig their own grave and probably a grave with dark mode. Okay, enough rambling. Now, I want to say a big thank you to my patreons and YouTube members.

[00:15:21]If you want to support me and get your name on this wall of fame, there are links in the description. That's it for today. Let me know what you think about this topic. If you like the content, hit like and subscribe and see you in the next one. Taran X.