AI Can Make Careless Developers Look Productive [Raw Session]

00:00 — The people using AI

Hey, welcome back to Slow Builds.

I've talked before about how I'm not really scared of AI anymore. I'm more scared of the people—people around AI, people making decisions and not understanding, or people looking at it from a different point of view. Basically, just people not understanding what AI can do, and they're the ones making the decisions for how it's going to be used. And that really scares me, and that still scares me quite a bit.

But specifically lately, I've been thinking about almost the complete opposite problem: people who do understand AI, or at least understand it enough to know how to use it.

And because I come at almost everything from the perspective of a software developer, an architect, just a developer in general, the group I keep thinking about is developers.

00:57 — Capable developers who don't care

And maybe the easiest way to say it is, I'm starting to get scared of bad developers using AI.

I wanted to use the word lazy, but I do have videos and I have other ideas where I want to show how I'm lazy, how I cheat with AI, how I use AI to be lazy. Just to help me get more done and remove a lot of the friction and low-level work to allow me to focus and be more clear-minded on what I want to get done. So lazy isn't the right word.

But bad developers—that kind of fits the mould I'm thinking about.

And I don't necessarily mean someone who can't write code. They might be a perfectly capable developer, probably an expert developer, who worked their way up, who have a great career.

I'm talking about someone who doesn't really care about what they're putting out. They care about closing the ticket, getting the PR merged and getting through a sprint, and just looking productive. Keeping their job, basically, and getting promoted. Whatever their motivation happens to be, the actual software is almost just secondary. They don't care about it.

And AI is becoming incredibly good at helping someone do something like that.

02:15 — AI used to require more involvement

I didn't really notice this problem before because, first, AI wasn't good enough yet. And honestly, it still isn't completely there.

Although with new models—I said I moved away from code. One of my videos was about how I'm not coding as much with it anymore, and it was burnout and fatigue and things like that. But with the new models, especially with OpenAI's new model, I feel completely comfortable allowing it to take the reins. I'm still guiding it. I'm still using it. But that's another video altogether.

But even a year ago, if I wanted AI to build something, I had to be involved. Really involved. I had to explain what I wanted, correct it, redirect it, look through the code, tell it something was missing, run it, and just find another problem and just recycle, repeat.

And there was this constant interaction between me and AI. And because of that, I was still very much the developer. AI was helping me, sometimes helping me a lot, but I was still driving it. I still needed to understand what we were building. And if I wanted something I was comfortable putting out, putting my name on, I couldn't really disengage.

The technology almost forced me to stay involved. And I think that protected us from some of these problems.

03:43 — When AI starts feeling like another developer

But these newer models, like I just said, they're getting extremely, extremely great. They're starting to feel different to me. And this is actually what made me start thinking about this and what I'm scared about, because I'm impressed so much by these new models and what they're putting out.

I'm very positive about where AI is going. I'm always optimistic and excited because I use it constantly. But we're getting to this point where I can give AI real development work, and what comes back feels more and more like another developer on my team. Not a little coding assistant, not autocomplete—a developer.

I explain what I need, give it access to the codebase, let it work through the problem. And increasingly, I get something back that actually works. And that blows my mind.

But there's also something a little uncomfortable about it, because I'm getting closer to being able to sit back. I can almost do nothing. We're not completely there, but I can see it from here. And weirdly, that's when I started getting more concerned.

Because I still look at the code. I still find things. Maybe it missed a test. Maybe there's a security consideration that wasn't handled. Maybe the happy path works, but there's failure conditions that nobody thought about. Maybe we need another guardrail. Maybe the code works today, but I don't like what it's going to mean six months from now.

And those are things I know to look for. And more importantly, I want to look for them, because I care about what I'm putting out.

05:14 — Working code can still hide problems

But here's the part that started bothering me: a lot of those problems don't stop the feature from working.

The ticket can be completed. The demo can work. The PR looks impressive. The code can still get merged. It's good enough to pass.

And that's a very different problem than AI producing obviously bad code. When the code breaks immediately, at least I know there's a problem. And that doesn't mean it's easy to fix, but I know it needs attention.

What worries me more is code that's convincing enough to get through, to get past. The feature appears to work. The ticket gets closed, and nobody bothers looking. They don't look deeply at it. They don't go beyond that. The code review passed because AI is doing the code review. AI wrote the code, so it knows what it's looking for.

06:03 — Taking ownership of what I build

And maybe part of this is just how I look at software. When I build something, I feel like it's mine. Even when I'm building for someone else, it's something I made.

I treat it like I built something physical. If I built a table, I would want the table to actually be solid. I wouldn't want someone to put something on it and have the thing collapse. If I worked on a car, I'd want to know the thing was safe and it'd run. If I built a house, I wouldn't want to hide a bunch of problems behind the drywall because nobody could see them.

Software feels the same way to me. There are users on the other side of this. There's data. There's security. There are people depending on these things working. And I want to be proud of what I put out.

I'm lucky with the people I work with. Honestly, I believe the developers around me care. They care about the product. They care about the company. They care about what they're putting out.

So maybe that sheltered me from thinking about this aspect of it until now.

07:03 — What companies reward

Because that's obviously not every development environment. There are developers who don't care about their product. Maybe they hate the job. Maybe they're burnt out. Maybe they don't believe in the company anymore. Maybe they're just there for a paycheque.

Or maybe the company itself has created that environment. They're measured on output. How many tickets? How many bugs are fixed? How much code was pushed? How much did they ship?

And I don't necessarily even blame the developer in every situation.

If you're sitting inside a massive organization and you're constantly being told you need to produce more, you're going to find ways to produce more. I've been there. I've been a consultant. You know how to push code. Show up. Punch your ticket. There's ways around it. And if you're just in it for the paycheque, you're going to find ways to make yourself look productive.

And now we have this tool that can dramatically increase how much you produce.

07:56 — Three careful changes versus fifteen quick ones

And this is where I think it gets very interesting. Imagine two developers.

One of them uses AI, but they're still going through everything carefully. They're thinking about the architecture, the testing, the security. They're thinking about weird edge cases. They're questioning what the AI is giving them back. And maybe they finish three significant things.

Then another developer using AI completely differently. They generate it, run it, looks good, push it, ticket's done. Generate it, run it, push it, next ticket. And they finish fifteen things.

Now go a couple levels above those developers. Now go above and higher. Go to the next level of developers in that scenario. Someone is looking at the numbers. Their manager's looking at three compared to fifteen.

Who looks productive? Who looks like they embraced AI? Who looks like they're performing? Who gets recognized? Maybe even who gets promoted?

08:54 — When careful developers start looking slow

And that's where this stops being about one developer, because everyone else is watching too.

If fifteen becomes possible, three starts looking slow, even if those three things were actually engineered better. And then another developer starts doing the same thing. Then another. And eventually AI-assisted output becomes the baseline.

Management sees how much faster things are moving, so expectations increase. Now everyone needs to move faster.

And the careful developer can actually start looking like the bad developer, which is a sad thing. You could be the smartest person in the room, but still feel like the dumbest.

And that's the cycle that worries me, because now we're creating an incentive to understand less. Not intentionally. Nobody sat in a meeting and said, "Let's make our developers care less about software." But that's potentially what the incentive produces.

09:45 — The software people depend on

And then you go to the thing about where the software lives. I'm not talking about some little side project no one uses. Think about banking, healthcare, insurance, transportation, any government system, massive corporations and infrastructure. The boring software that quietly runs huge parts of our lives and our environment and our communities and the world, in a way.

Those systems can have hundreds of thousands of people touching them.

People come and go. Teams change. Companies reorganize. Layoffs, hires. And the code stays.

Now imagine we're generating more and more of that code at a speed where fewer and fewer people really understand the whole thing, or even care. That's where I think the bigger problems come into this. It's bigger than just whether AI writes good code.

10:35 — I'm still using AI more

And I don't want the takeaway from this video to be that we should stop using AI to write software, because I'm doing the exact opposite. I'm using it more. And based on what I'm seeing, I'm probably going to use it a lot more. I already am. I know I am.

It's making me better. It's giving me more. It's making me be more productive. It's allowing me to look at things differently and expand what I can do. It's letting me build things I couldn't build as quickly before.

And it's taking away a lot of that tedious work. It's incredible, and that makes this complicated. I don't want AI to become less capable. I want it to become more. And everyone is, and it's going to happen no matter what.

The easier it becomes for me to remove myself from the process. And I don't know that removing myself is always the thing we should be trying to achieve.

11:25 — Responsibility doesn't disappear

Maybe that's actually where my thinking is landing at the moment. As AI becomes capable of doing more of my job, my responsibility doesn't necessarily decrease. Maybe technically it has to increase.

Because eventually writing code might be the easy part. Generating another thousand lines might not even be that much. Understanding why those thousand lines exist, what we're doing, what happens when they fail, what they're exposing, and whether they should exist in the first place—maybe that's where the actual job moves to.

And that's where I talked about AI fatigue, because my job's changing. But I think as we get deeper into this, as we move forward right now and these models change and how this is happening, that fatigue is going away. And then I talk about burnout, but we're all falling into place, I think. We're learning our new roles.

And so I think I'm scared of AI writing code. I'm definitely not scared of AI replacing the act of typing code.

12:31 — I still want to know what I'm putting out

So let me back that up. I'm not scared of AI writing code. I'm definitely not scared of AI replacing the act of typing code.

I'm starting to think the thing that scares me is AI getting good enough that somebody can produce convincing, working software without really caring about what they produced. And worse, we might reward them for it, because from the outside they look incredibly productive.

And maybe AI isn't going to create bad developers. Maybe it's just going to make it a lot easier to be a bad developer.

And I don't really know where that leaves us yet, because I'm still going to use it tomorrow. I'm going to use it tonight. I'm still going to give it more responsibility. I'm still excited to see how good it gets.

But I think I'm going to keep looking at the code. Because at least for now, if my name is attached to it, I still want to know what I'm putting out.

All right. Thanks for watching. Bye.