AI in My Developer Everyday Life: Between Routine Aid and Creative Brake

Some time ago, I wrote an article explaining why I’m not worried that AI will take my job. Back then, I was convinced: AI is my assistant – not my replacement. Today, a good while later, I still believe that. But I’d add something: AI supports me immensely in some areas – and limits me in others.

Where I use AI and see its real potential

I mainly use AI where it truly helps me think faster and structure my ideas. For research on new topics, outlining software architectures, or simply when I want to challenge myself and ask if there’s a better approach.

My physical rubber duck on the desk has been replaced – by a short chat with ChatGPT. Sometimes, that quick exchange is all it takes to untangle a mental knot. AI helps me question my assumptions, break patterns, and see new perspectives. It’s my patient sparring partner that never gets tired of reflecting my thoughts.

Where I deliberately avoid AI to stay a developer

Still, I don’t use AI everywhere. Especially in the early stages of new projects, I consciously avoid it. I take my time to understand the project, the business case, and the overall flow – without shortcuts.

I see a trend where AI is increasingly used for documentation or code generation in companies. That can be helpful, but I also notice how often it causes a disconnect. Software sometimes looks assembled, but not designed. Clean code, but without soul.

Even as AI continues to improve, I notice the same effect: code style changes. It becomes more generic, more interchangeable, less shaped by the developer’s own voice. That’s convenient – but also risky, because it strips away individuality.

And honestly, I’m also skeptical about feeding AI with company-specific source code. No one truly knows where that data ends up. And who knows what insights might be drawn from it later?

The golden middle ground

For me, the key lies in balance. I usually use AI in a very isolated way – without giving it too much context. When I need to write or optimize a function, I describe exactly what I need, without revealing the entire project.

If I can do that, it shows me that I actually understand what I’m doing. Because deep understanding of software doesn’t come from great prompts – it comes from real engagement.

Good code is one thing – but great developers understand the business case behind it. And that, in my opinion, remains the most important skill in times of AI: not just writing code, but understanding it.