Over the past two years, I’ve been using various AI-assisted tools for programming like Codeium, GitHub Copilot, ChatGPT, and others. These tools have become part of my daily workflow. Mostly, I use them for code completion and to help me finish thoughts, suggest alternatives, or fill in repetitive boilerplate. I’m not doing anything too wild with autonomous agents or fully automated codebases. Just practical, incremental help.
That said, even in this limited use, I’m starting to feel the friction.
Not because the tools are bad but actually, they’re improving fast. Individual lines and even complete methods are cleaner than they used to be. The suggestions are smarter. The models are more context-aware. But one thing still nags at me: even with better completions, a lot of the output still isn’t good code in the long-term sense.
Maintainability Still Matters
The issue, to me, isn’t whether AI can help me write code faster. It can. The issue is whether that code is going to survive over time. Is it going to be easy to understand, extend, or refactor? Does it follow a style or pattern that another human could step into and build on?
This matters especially when you’re not the only one touching the code or when you come back to it after a few months and wonder, “Why did I do it this way?”
And here’s the contradiction I keep running into: AI helps you write code faster, but it often creates more problems to maintain. That’s especially true when I’ve tested more advanced setups where you let an agent plan and generate entire components, classes, or services. It sounds great in theory, but in practice it causes a lot of changes, inconsistencies, and small bugs that end up being more trouble to fix than if I had just written it myself from the start.
So for now, I stay close to completions. Code at the scale of a line or a method. It’s easier to understand, easier to control. I can be the architect, and the AI can be the assistant.
The Self-Fulfilling Trap
There’s a strange loop forming in AI development. Since the generated code is harder to reason about or maintain, people often treat it as throwaway. And because it’s throwaway, nobody bothers to make it better. So it stays bad.
Self-fulfilling prophecy.
The more AI you use to generate logic, the more you’re tempted to not go back and polish or structure it. You get into a loop of “just generate something that works,” and soon you’re sitting on a pile of glue code and hacks that’s impossible to build on.
But maybe that’s okay? Maybe we need to accept that some code isn’t meant to last.
Disposable Software Might Be the Point
This is where I’m starting to shift my thinking a little. I’ve always approached code as something you build on something that lives and evolves. But not all code needs that.
A lot of software today already is disposable, even if we don’t admit it. One-off internal dashboards, ETL jobs, scripts for events, MVPs for marketing campaigns, integrations that won’t live beyond a quarter. We often pretend we’re building maintainable systems, but we’re not. We just don’t call them disposable.
With AI in the mix, maybe it’s time to embrace disposability for what it is. Write the code, run the code, get the result, throw it away. Next time, generate it again maybe with better context or updated specs.
This mindset removes a lot of the pressure around maintainability. And it fits the strengths of today’s AI tools.
When Not to Use Agentic Systems (Yet)
I’ve played with more autonomous agent systems what people call “agentic AI” or multi-agent code platforms. Honestly? I’m not sold on them yet. They generate too much. They make decisions I wouldn’t make. They refactor things that didn’t need to be touched.
And then I spend more time reading diff views and undoing changes than I saved by delegating in the first place.
Maybe in the future I’ll be comfortable letting an AI agent draft a service or plan out an architectural pattern. But today, I’m not there. I use these tools more like smart autocomplete than autonomous developers. It’s still very much my code and they’re just helping speed up the flow.
Final Thoughts
There’s a real risk of overhyping what AI can do for codebases today. But there’s also an opportunity to rethink how we treat different classes of software. We don’t need to hold everything to the same standards of longevity. Not every project needs to be built for 10 years of feature creep.
Some software can (and should) be treated like scaffolding and built quickly, used once, and removed without guilt.
And that’s where AI shines right now. Helping us build the things we don’t need to keep.
I’ll keep experimenting. I’ll keep writing most of my own code, and using AI where it makes sense. But I’m also watching carefully because the balance between what’s worth maintaining and what’s better thrown away is shifting.
And we should all be ready for what that means.