Do you care about code quality anymore?

For the past six to twelve months, I've been struggling internally with the idea of clean code.

In my perspective, clean code matters less and less. The more AI produces and reviews code, the less useful clean code becomes. Clean code was incredibly useful when humans built software and read code firsthand. It might be different for you, but I find myself, most of the time at work and on personal projects, asking the AI why bugs arise, what a certain part of the code does, and so on.

This is a natural byproduct of using AI to develop systems: the farther you get from actually programming with your own two hands, the less knowledgeable you are of the system you're building, the weaker your rational connection to it, and the harder it is to reason about it.

I think that clean code and proper programming patterns take a back seat the more AI takes the wheel.

Depending on your philosophy regarding programming with AI and following clean code patterns, changes you would request in a pull request or code base—whether they are nitpicks or not—could be useful if humans handle all reviewing and debugging.

AI has an incredible talent for writing nonsensical comments, creating variable names that make little sense, and using weird logic gates that a normal human wouldn't write. When encountering these oddities, you will either ignore them or request changes: remove or clarify comments, make logic gates more sensible, and give variable names clearer intent, along with clearer function names.

So you might not suggest these changes. If you think that clean code doesn't matter, and if AI is going to be taking the wheel from here on in, why does it matter what a variable name is, why does it matter if it has a lot of comments? Why does it matter if your code is understandable to humans at all, if AI will be the one running the show?

I had a great conversation with my team today during our stand‑up. I posed a question because I was doing a lot of pull‑request reviews and watching the AI over and over again add comments to the code—comments that we didn't remove or verify as accurate.

I brought up this topic because I was struggling with it, wanting to suggest changes that seemed like nits in this new programming world but would be reasonable to any other human. I found myself at a crossroads and asked the team what they thought about writing code that they maintain for humans, even if it is AI‑generated, and even if you end up using AI to look through it and remind you of certain aspects.

To make a long story short, we had a great discussion and concluded that even if AI writes, reads, and maintains the code under your purview, we should still write it to be maintainable for humans.

Take AI out of the picture; we should still conduct pull‑request reviews as if we’re doing them for ourselves. What really stood out to me, and why this conversation was so beneficial, is that we all agreed taking pride in the code you approve and write is incredibly important. What does any of this matter if you don’t take pride in what you’re doing?

With more AI‑generated code being added to software codebases, you start losing touch with reality. You can’t have pride in something you have little control over.

It may be a desire for control, a wish to have a say in how software is built and looks, because it’s easy to let the AI decide as long as it works. Otherwise, you end up with a nonsensical codebase where you don’t need any READMEs or documentation because the AI has littered paragraphs of comments in every function.

But I digress.

It felt good that we all agreed we should still care about code quality, treat our code bases as something to be proud of, and have pride in what we create. The AI should be an extension of us, and we should use it to check for edges and help us create and maintain, but we should do it with pride. A craftsman wouldn't take less pride in his work if he's using a Dremel or a drill instead of a hammer or other machinery that makes his job easier.

He would have the same amount of pride and would use those tools with that pride, caring about the quality of the wood even if it ends up underneath paint or in a wall. If you care about your craft, which we ultimately should, you should still care about the outcome of the tool.

Hand-sewing t‑shirts versus using a machine to make the t‑shirts, you would still care about the outcome of that t‑shirt. You wouldn't allow the machine to skip corners, make one arm just a bit shorter than the other, because it would really notice missing threads and all that kind of stuff.

So, having this conversation and getting on the same page about how we feel about code quality and design was really uplifting. It felt like we’re reclaiming some of the stuff we had so easily given up to AI, and it’s no one’s fault because it’s a very new paradigm.

But it felt good to be on the same page about caring about what we build, even though we are not the ones physically building it.

We should still be intentional about the quality of the software from both a product and technical standpoint. I think this conversation ultimately made our team better, and I look forward to sharing it with those who weren’t there.

Instead of deliberating about whether my suggestion to clarify comments, remove comments, clarify variable names, or undo the over‑engineering that AI sometimes does, it feels good to know those will be welcome changes. We should ultimately care about what gets built, even though we’re using AI to do it.

How do you feel about code quality? Do you let the AI, shotgun, its patterns into your code? Do you let it name things as you want on your team? Or do you reign it in? Do you have pride in what you build using AI? Or have you given up to our AI overlords and whatever they say goes.