I’ve seen a growing number of posts lately about how terrible AI-generated code will supposedly be to maintain. The argument usually goes something like this: “Sure, it’s fast now, but in a year or two no one will understand it.” And while that might sound reasonable on the surface, it misses an important point—maintaining code has always been difficult. Anyone who has joined a new project knows the pain of trying to decipher another developer’s “clever” logic from three years ago.

AI doesn’t change that reality. What it changes is the speed and accessibility of getting to a working solution. Whether that code is maintainable or not still comes down to the same thing it always has: the habits and discipline of the person writing it. If you’re sloppy, AI will happily amplify your sloppiness. But if you care about structure, clarity, and testing, you can guide AI to produce the same level of quality you would yourself—and then improve it further.

That’s the key mindset shift. Using AI doesn’t absolve you of responsibility; it amplifies it. You become the reviewer, the architect, and the quality gate. You’re no longer just typing code—you’re designing how that code should exist and evolve.

The irony is that AI is also excellent at refactoring. It can take legacy code and clean it up faster than most developers can finish their morning coffee. The trick is knowing how to use it: guiding it with context, giving it examples, and holding it to the same standards you’d expect from any human teammate.

When used properly, AI isn’t lowering the quality bar—it’s raising it. It gives us the opportunity to focus on architecture, testing, and maintainability instead of boilerplate. And yes, it’s faster. Much faster. But speed isn’t the problem—lack of care is.

One of the unexpected benefits of coding with AI generation is how it naturally pushes you toward writing modular software. When you describe what you want clearly enough for an AI to generate it, you start breaking your ideas into smaller, more independent parts. Each piece has a clear purpose and boundary — just enough context to stand on its own.

As a result, my GitHub repos have become cleaner and leaner. There’s no half-finished idea in a corner, no unneeded scaffolding, no “maybe I’ll use this later” utilities. Each repository does one thing, and it does it well. The code reads more like a set of purposeful tools than a workshop full of scraps.

AI generation forces clarity — if you can’t describe a function or module precisely, it won’t generate what you want. That discipline carries over to the code itself. The outcome is concise, readable, and free of clutter. Clean code, in the truest sense, is not about clever tricks or perfect architecture — it’s about removing everything that doesn’t need to be there.

I think the hardest part of joining a new company as a Senior Software Engineer, is taking that first step to confidently approve Pull requests.

You have to feel confident in your knowledge of the code base, the architecture used, the libraries used in the project, and the team’s coding standard. You also know that one Approval means the code makes it’s way into the main code base and will go to production…. Being confident enough to do this is scary!

And then of course you know the Lead will check the code anyway, and if you approved something that was blatantly incorrect, you really feel you let the team down.

But once you have the confidence to start approving, your contributions to the team are increased significantly as you make the code flow faster, and you take some of the load off the Lead.

Last night I built a small website to show different webpage styles. So if you have wondered what Glassmorphism vs Neomorphism vs Minimalist web page styles look like, you can find them all on this page.

https://styleguide.cairns.co.za/

The amazing thing is they are all done using Tailwindcss with no custom classes being defined. All 29 style pages are all done without any custom CSS.

(Yes I used AI to generate most of this)