Stop Calling It Vibe Coding. It's Agentic Software Development.

After 15 years of building software, I think we’re describing one of the biggest changes in the industry with entirely the wrong words.

I’ve been involved in application development and design for about 15 years. I’m not a traditional programmer. I don’t spend my days writing thousands of lines of code. What I do is envision software, figure out what I want it to accomplish, how I want it to look, how users should interact with it, and how all the pieces should work together.

Then I get it built.

For most of those 15 years, that meant working with programmers, often overseas. I would develop the concept, define the functionality, work through the user interface, and explain what I wanted. My programmers would write the code, update the application on our servers, and send it back for me to review.

I’d test it, find things I didn’t like, discover bugs, think of improvements, and send everything back through Jira. They’d make the changes, and we’d repeat the process. Sometimes dozens of times before a particular feature was where I wanted it.

That’s how software development has worked for me for a decade and a half.

And then along came something called vibe coding.

I have to admit, I don’t particularly like the term.

To me, “vibe coding” sounds like someone sitting in front of a computer, having a vague idea for an application, typing a few sentences into an AI, and deciding that whatever comes back must be pretty good because, well, they’re getting a good vibe from it.

I’m sure there’s some of that going on. And I’m equally sure there’s a tremendous amount of terrible software being created that way.

But that’s not what I’m doing.

What I’m doing with Claude Code is almost exactly what I’ve been doing for the last 15 years. The difference is that I’ve replaced much of the human programming work with AI.

I still have to understand what I want to build. I still have to think through the architecture, the functionality, the user experience, and the business logic. I still have to test the results, identify problems, refine the design, and make decisions about how everything should work.

The difference is that instead of describing a change to a programmer halfway around the world, creating a Jira ticket, waiting for them to get to it, reviewing their work a day or two later, and starting the process all over again, I can have that same conversation with Claude Code.

And I can have it right now.

If I don’t like the way something looks, I change it. If I discover a problem in the workflow, I explain it. If I think of a better way to accomplish something, we try it. I can go through ten or twenty iterations in the time it previously took to complete one or two.

That’s an extraordinary change in productivity.

We Need a Better Name for This

I think it’s time we started calling this something other than vibe coding.

My suggestion is Agentic Software Development.

The distinction is important.

Vibe coding suggests that the human is somehow casually participating in the process, offering a few ideas and hoping the AI figures everything else out.

Agentic Software Development describes a much more deliberate relationship. The human provides the vision, the requirements, the direction, and the judgment. The AI agent performs the implementation, proposes solutions, executes changes, and helps work through problems.

It’s not about surrendering control to artificial intelligence. It’s about directing artificial intelligence to accomplish something you understand and can evaluate.

In many ways, it’s not unlike managing a team of programmers. You don’t need to personally write every line of code to be responsible for the quality of the software.

You do, however, need to know what you’re doing.

And that brings me to something else I’ve been thinking about.

The Programmer’s Dilemma

I’ve noticed an interesting reaction among some traditional programmers who are beginning to use tools like Claude Code.

They’ll ask Claude to write a feature, and then spend hours poring over every line of code it produced, looking for mistakes, questioning its decisions, and sometimes rewriting perfectly functional sections simply because they would have done things differently.

I understand the instinct.

For someone who has spent years, perhaps decades, developing the ability to write code, that skill is an important part of their professional identity.

And suddenly here’s a machine that can produce an extraordinary amount of code in seconds.

I suspect that for some programmers, there’s an almost subconscious need to demonstrate that they’re still the expert in the room. To catch Claude making a mistake. To prove that they would have written something more elegantly. To establish that the machine still needs them.

And of course, sometimes they’re right.

Claude makes mistakes. It can introduce security vulnerabilities, misunderstand requirements, create inefficient solutions, and produce code that works today but causes problems tomorrow.

Those are legitimate reasons to review code.

But there’s a difference between reviewing code because the application requires it and reviewing code because you feel an obligation to prove you’re still better at writing it.

I wonder whether some programmers are spending so much time trying to catch the AI doing something wrong that they’re missing the much larger opportunity to use it to accomplish something right.

Think about it.

If I hire a talented programmer, I don’t sit beside them and inspect every keystroke. I explain what I need, establish expectations, review the results, and make sure the software works as intended.

That doesn’t mean I blindly trust them. It means I manage their work at the appropriate level.

Why should working with an AI coding agent be fundamentally different?

Certainly, critical systems need appropriate code review, automated testing, security analysis, and human oversight. And today, AI-generated code still deserves considerable scrutiny, particularly in applications involving sensitive data or consequential decisions.

But the goal of that scrutiny should be to establish confidence in the software, not to establish the superiority of the person reviewing it.

The measure of a good programmer may increasingly be less about how much code they personally write and more about how effectively they can direct, evaluate, and improve the code that gets written.

I suspect that’s going to be a difficult transition for some people.

And I don’t mean that as criticism. It’s simply what happens when technology changes the nature of a profession.

The skills that once defined expertise don’t necessarily disappear, but their relative importance changes.

Knowing What to Build Is Not the Same as Knowing How to Code

Here’s the part I think gets lost in all the excitement about AI-generated software.

The ability to generate code is not the same thing as the ability to develop good software.

Those are two very different skills.

A person who has never designed an application, never thought through database relationships, never dealt with user permissions, never considered security, and never had to support a real product with real customers can certainly ask AI to build something.

And the results might even look impressive.

But how do they know whether it’s any good?

How do they know whether the application will scale? Whether the underlying logic makes sense? Whether the user experience is intuitive? Whether the security is adequate? Whether the architecture they’re building today will become a nightmare six months from now?

More importantly, how do they recognize when the AI has confidently delivered something that is fundamentally wrong?

This isn’t really a new problem.

I’ve worked with plenty of human programmers over the years who could write perfectly functional code that didn’t accomplish what I actually wanted. Sometimes they misunderstood the requirements. Sometimes they made assumptions. Sometimes they solved the immediate problem without considering the larger application.

That’s why I had to manage the process.

And that’s why I still have to manage it today.

Claude Code can make mistakes just like a human programmer. It can misunderstand instructions, introduce bugs, make questionable architectural decisions, or fix one problem while inadvertently creating another.

The fact that it can do all of those things at remarkable speed doesn’t eliminate the need for experience and judgment. If anything, it makes those qualities more important.

Because now you can make mistakes at remarkable speed, too.

The Real Revolution Is the Elimination of Waiting

I think the real revolution here isn’t that everyone has suddenly become a software engineer. It’s that people who understand software development, who know how to define problems, design solutions, and recognize good results, have been given an enormously powerful new tool.

For someone like me, the bottleneck was never really coming up with ideas.

It was the time and effort required to turn those ideas into working software.

There was always a delay between imagining something and seeing it on the screen. Every iteration involved communication, scheduling, interpretation, and waiting. Even with excellent programmers, the process was necessarily slow.

Now that delay has practically disappeared.

And something interesting happens when you remove that delay.

You start experimenting more.

Ideas that might not have been worth assigning to a programmer suddenly become worth exploring. You can try a different interface, rethink a workflow, or build a small feature just to see whether it improves the experience.

Sometimes it doesn’t. So you throw it away and try something else.

That freedom to experiment is, in my opinion, one of the most underappreciated aspects of AI-assisted development.

It changes not just how quickly you build software, but how you think about building it.

The Value Is Moving

I think we’re witnessing a fundamental shift in where the value lies in software development.

For years, the ability to translate an idea into computer code was a relatively scarce and valuable skill. Now that translation is becoming increasingly automated.

That doesn’t mean experienced programmers are becoming irrelevant. Quite the opposite, actually.

The best programmers have an enormous advantage because they understand what’s happening beneath the surface. They can recognize architectural problems, anticipate failure points, evaluate tradeoffs, and build systems that are reliable and maintainable.

But to take full advantage of that expertise, they may have to become comfortable with a new role.

Less time being the person who writes the code.

More time being the person who knows what the code should accomplish, how it should be structured, and whether the result is good enough.

And for people like me, who have spent years directing software development without personally writing the code, the transition feels remarkably natural.

I’ve already been working this way for 15 years.

The only thing that’s changed is who’s sitting on the other side of the conversation.

So, Am I Vibe Coding?

I suppose, by today’s popular definition, the answer is yes.

But I don’t think of it that way.

I’m still doing application development the way I’ve always done it. I’m still designing, directing, testing, criticizing, and improving the work.

I just have a programmer who is available 24 hours a day, responds in seconds instead of days, never gets tired of my revisions, and can work through an extraordinary amount of code in a very short period of time.

I haven’t stopped managing software development.

I’ve simply removed much of the waiting from it.

And after 15 years of doing this, I can tell you that removing the waiting is a much bigger deal than it might sound.

So perhaps it’s time to retire the term vibe coding, or at least recognize that it doesn’t adequately describe what many of us are actually doing.

I’m going to call it Agentic Software Development.

Because the future of software development isn’t necessarily about who can write the most code.

It’s about who can imagine, direct, and deliver the best software.

And increasingly, those are not the same people who are typing the code.