Have you ever faced the situation of working on a project and seeing some code that you think “smells”? Obviously you didn’t write it, someone else did. And you begin to refactor it, thinking that the code you write is better than the original.

I believe this is something that all engineers do and think. The code you will write will surely be better. And it’s probably because you didn’t face the original implementation with the original deadlines that the person had at that point, doing their best effort to have something ready.

But when you pick that code again, you currently know how the feature works, the perspective is clear, and you know how to make it better. Or maybe, the other person didn’t have the seniority that you have, and they are learning along the way.

And the funny thing is, you might think the same about your code in a few days in the future (happens a lot!).

AI has entered the picture

Nowadays I’d say a lot of the code is AI generated. Which at the end of the day, is code from “someone else” that the AI has learned over it and we settle for less. As AI has been gaining popularity, there is some kind of believe that code is not needed to be understandable anymore for humans, as AI will do all the major understanding and coding.

And don’t get me wrong, having AI as an assistant is great. Developing things is much quicker, and when used right, it boosts productivity sky high. But also, I have the feeling that making really good code (which for me, is a type of “art”) has become second place. Now everyone wants speed. Everything should be done fast, and we’ll make fixes later.

That’s something that I don’t want to give up. That’s why I’ve been skeptical about the vibe coding situation that happened over the last months. I did try it on some personal projects, but felt that I was over and over losing knowledge of how the application was supposed to work.

I really enjoy thinking about how to do the implementation before coding. Maybe I can learn something along the way while making the thing, implement a new design pattern, check for trade-offs, ask a friend or coworker what they think and if they agree that it’s a good implementation (if it isn’t, also learn from them!).

Not only that, I want to know how code is being placed. That the code matches my style and the project, that I know what it does, and that I can catch any bug along the way. While using AI tools makes you faster, there is a fine line you need to be careful about between what you can omit because the task is repetitive or boilerplate, and when you start losing touch with what you have developed so far.

For instance, I’ve been using Claude Code over the past months, and I’ve enjoyed using it. But one thing that I always have on is the plan mode, so I’m 100% sure what to expect from the conversation within the chat. And in my opinion, that’s how AI is supposed to be used. Having a conversation with the agent, instead of blindly accepting everything that it says.

Finding the right balance

I’m a believer that AI is here to stay and to help us in the long run. But we should know how to use it properly in order to get the most out of it.

For instance, having good rules and documentation about your project and what you want to achieve is primordial. We have to do a lot of research and planning in advance so we can work better with any AI tool. One example would be: if you use Cursor, write as many cursor rules as you need (and remember to use them responsibly so you don’t end up filling the context with unneeded rules for files that shouldn’t use some particular rule).

And it seems that now more than ever, TDD is the most effective method for using AI. Having a comprehensive testing suite plus good documentation gives the AI the resources it needs to develop features with the constraints you want to have.