AI is writing most of our code. Not just helping, not just autocompleting a function here and there. It is a driver now. Companies have automated workflows where AI produces bug fixes for monitoring tools like Sentry alerts without a human ever touching it. Many bugs are being caught, diagnosed, and fixed by AI without a human ever spending even a second to worry about how to fix it.

People are building features with AI. Entire apps with AI. The human is becoming the reviewer, not the author.

So in this AI productivity era, does code quality still matter?

If yes, how much? If no, why not?

I think the discussion now circles back to what "clean code" even means. There was a popular saying: write code for humans, not for computers. The idea was that your future teammate, or your future self, would be the one reading it at 2am trying to figure out what went wrong.

But think about that now. Computers, agents, and systems are going to read and edit the majority of code going forward. They are the ones writing it, and they are the ones coming back to fix it. So does the old definition still hold? Does it even matter if the code is messy, as long as the machine can parse it?

That is the question worth sitting with.

Here is the honest answer: for most code being written today, quality probably does not matter as much as we used to think.

And that is not a controversial take anymore. It is just reality.

The weekend project. The internal tool nobody outside your team will ever touch. The script that runs once and gets thrown away. Vibe code it, ship it, move on. If it works, it works. AI will probably rewrite it anyway the next time someone asks it to "improve this."

But here is where it gets interesting.

Maybe the parts where quality does matter do not matter as much anymore either. And that is a strange thing to say out loud, but it might just be true.

Think about what is actually happening in production systems today. AI is autonomously patching code. It is building entire features. It is fixing its own bugs. It is writing code, maintaining it, and coming back to clean up after itself. Humans are not disappearing from the loop, they are just stepping further and further back from it.

Maybe clean code was always solving a human problem. And if humans are leaving the loop, the problem is leaving with them.

We honestly do not know yet. The codebases running on AI-generated and AI-maintained code are still young. The compounding effects, if there are any, have not fully shown up. Maybe they will. Maybe clean code will turn out to matter more than ever in those systems. Or maybe AI just gets better and the whole debate becomes irrelevant.

That is the part nobody can answer right now.

Clean code was a discipline built for a different era. Whether it survives this one or quietly becomes a relic, we are probably a few years away from knowing for sure.

And its very convenient to use them, and I am in full support of it (usually). But the problem comes when you pick a framework or tool to use to solve a particular problem. It can be anything - it can be as small as picking bootstrap to speed up your design, and it can be as complex as picking some platform libraries to support some protocol. It gives you great boost, its easy to begin with usually, it helps you solve the problem in hand, roll feature / things quicker, also maybe give you a discount for not knowing everything in depth yet achieving the result.

But it starts a rabbit hole as well; frameworks are, till some extent, generally opinionated, or I would say they have some prescribed patterns (many people call it best practices too). So if you start fighting it, that’s where things can get nasty. What does fighting it mean (it can mean overriding random things, not using the prescribed practices, trying to write one thing in another, and the list keeps going)? I would give few examples

1. I have seen people using Fastapi because it supports Async really well and offers other benefits like having a micro framework, out-of-the-box support for Python, etc. But they try to use it as a Django. They will create unnecessary abstraction just to get some convenience they have in Django to have similarities here. By no means, I mean this is wrong, but will you be able to actually leverage what Fastapi offers you if you try to mould it as Django?

2. I see people using bootstrap but after some time start to override random classes and at one point they will start fighting with bootstrap with more css code overriding everything

3. Or anything else—let’s say someone picks a library that helps them to do authorisation and it only supports CSV format to add policies. Maybe they could just use an adapter pattern or some preprocessing to convert data to CSV, and the tool should take care of the rest? But I have seen people trying to override random methods inside the library to get things working weirdly. And at what cost later they get to the unique bugs , performance issue, hard-to-understand code, etc

To summarise, I am by no means against enhancing an existing tool or moulding it to your pattern, but it should happen with careful planning and consideration and try to leverage the best offering from the tool you are using and not be shortsighted and only solve problems at hand because its so easy to think, Hey, why not?

So be careful next time you are fighting a framework :)

PS: This blog is a WIP in some sense, as I wrote this raw. Maybe someday i will edit it to add more examples, follow best blogging practices (LOL, I am fighting the framework here), and maybe make it more easy to consume. But thanks for reading anyway. Happy to chat about anything in this if you have got different perspective. Thank you!