Hello Coders! 👾

Something about the way many people talk about AI and creating software has started to bother me a lot lately. I keep seeing people use the term vibecoding for all AI assisted coding and often this is meant in a negative way.

I think vibecoding and other ways of using AI for software development can be very different approaches. While all approaches involve AI writing most of the code and they can produce a working application, for me, the distinction is how to get to the result.

Not everything is vibecoding

When I think about vibecoding, I think about that turtle in Finding Nemo who just goes with the flow and sees where the current takes him. It’s about exploring and experimenting without a rigid plan, letting the process guide the outcome.

People are basically just throwing instruction at an AI until something works. It’s a way to explore an idea. To try a game mechanic or build a quick prototype, you don’t always need a detailed plan before you start and vibecoding can be quite effective for that. But software engineering is much more. Anyone can create a piece of software that works now, but that does not mean it’s good software, let alone a AAA title.

It’s not the only way to build software with AI. It’s definitely not the best way to build applications using AI. And, most often, vibecoding something results in something that shows low effort, slop.

Imagine two developers building the same feature. One starts prompting, tries the result, and asks for fixes whenever something breaks. The other defines the requirements, thinks about how the feature fits into the application, and decides how to test it. They then use AI to help with the work and review what comes back.

Both use AI. They might even end up with something that looks the same. But the process behind it is quite different.

The difference isn’t who creates the code. It’s the engineering that goes into it.

Code is only part of the work

Writing code is only one part of software development. As a software developer, I still need to understand the problem, make design decisions, test the behavior, and maintain the result later.

AI doesn’t remove any of that work. It can help with it and speed things up, but generating an implementation isn’t the same as knowing that implementation is good and correct.

For a prototype, “does it work when I try it?” might be enough for now. For something I want to keep building on, I need more answers. Does it meet the requirements? Does it fit the existing code? What happens with unexpected input? Can I change it later without breaking something else? Is it secure?

That’s where I see the difference between vibecoding and a more structured, agentic approach.

Of course, these aren’t two completely separate worlds. I can explore an idea through vibecoding and then bring more structure into the project once I know what I want to build. And a plan doesn’t magically make the software good. Bad requirements and weak tests are still bad requirements and weak tests, even when an agent follows them perfectly or when everything is written by hand.

My role as a developer

What I find most interesting is how the whole AI thing is changing the way I develop software, especially where my attention is spent. If an agent handles more of the implementation, I can spend more time defining the problem, deciding how to divide the work, and checking that the result makes sense. This felt really weird at first. Mainly on my personal project I’m used to sketch out my ideas in code. That used to be part of my thinking process. But now I writing that in text instead. And when an agent is working on something I can continue on something else in parallel.

Though, I don’t think being a developer becomes only about writing prompts. We still need to understand the software well enough to guide the work and take responsibility for the result. The old books like Domain-Driven Design are still relevant. Maybe they are becoming more relevant again now that we need to think a lot more about the overall structure and behavior of the software rather than just the implementation details.

What I mean by agentic coding

There are plenty of labels floating around: AI-assisted development, AI-driven development, agentic coding, and agentic software engineering. I’m not too concerned about finding the perfect one. When I talk about agentic coding in this context, I mean using AI agents within a deliberate development process. They can help plan, implement, test, and review, but I still define the requirements and decide whether the work is ready.

Just using an agent doesn’t guarantee that process. I can vibecode with an agent too. I think you could even vibecode without AI. If you would just copy-paste pieces of code from Stack-Overflow without knowing what they do it’s almost the same thing, just not as fast.

Vibecoding is useful for exploring ideas, and I don’t want to dismiss it. I just don’t want it to become the label for everything we do with AI in software development.

For me, the interesting shift is from asking AI to generate code to building a workflow where AI can contribute reliably, a software development tool. I might write fewer lines myself or not even any code at all, but I still need to make sure we’re building the right software.

That’s still software engineering. The tools are changing, not the need to understand what we’re building.

Happy Coding! 🚀