Everyone is either offended or excited about “vibe coding.” It’s all the rage and going to solve all your problems, or it’s the next great evil spewing crap code all over your systems. Those of us who love well structured clean code which is modular and concise seem to be a dying breed. For someone who’s early career was shaped by McConnell’s Code Complete, Brooks’ The Mythical Man Month, and Fowler’s Refactoring, this feels.. odd.

But when we dig into the WHY, something interesting happens:

Why do we want “well structured” code?

Well structured code is easier to understand to debug, extend, and maintain. But is there a single, shared definition of “well structured”?

Why do we want “clean” code?

Clean code is easier to understand to debug, extend, and maintain. But is there a single, shared definition of “clean”?

Why do we want “modular” code?

Modular code is easier to understand to debug, extend, and maintain. But is there a single, shared definition of “modular”? Actually, yes the Single Responsibility Principle addresses this one.

Why do we want “concise” code?

The less code there is, the easier it is to understand to debug, extend, and maintain. But too concise can make things harder to understand.

But when it gets down to it, all of these goals point at the problem.

It’s Not About You 

Previously, we needed “well structured clean code which is modular and concise” because writing code was easy but reading code is hard. Really hard. Painfully hard. Making sense of someone else’s code is harder still. All of our practices are really just to decrease that pain. Anything we can do to make it easier for the next person – or ourselves six months from now – is worth it.

But what if the next “person” isn’t a person?

If we assume that the code will only be debugged, extended, and maintained by a computer, most of our reasoning for clean code goes out the window. We don’t care what a human can do with the resulting (output) code as long as they can consistently generate code and configuration to solve the business problem, which gets at the REAL problem.

It’s Not About Code 

Somewhere along the line, we started treating the code as our goal. We worked hard to make sure it was structurally perfect on whatever framework we’re using today and didn’t realize that no one cares about our code. No one cares or even knows how “clean” our code is. They don’t even know what code is.

All our customers know is “does this solve my problem?” Enter vibe coding.

It’s About the Problem 

When a savvy user can describe their problem in detail, they can skip over all the messy coding steps and get directly to a solution. It won’t be perfect, and it won’t have “clean code” but they’ll see it in hours instead of months. More importantly, the savviest users can make mistakes, improve their understanding, experiment with ideas, and iterate on the entire process while getting better at each step along the way at a fraction of the cost.

And that’s why vibe coding is popular and only going to get more popular.

Instead of seeing vibe coding as a threat, we need to consider it another tool.

If you see it exclusively as a threat, I’m shocked you read this far. Thanks. I hope I can nudge your thinking.

If you see it as a tool, there are a few things we can do.

Improving Vibe Coding 

First, remember that any generative AI approach is only as good as the underlying model. If there’s a public model that suits your needs, use it. Though you can also give it context by adding code that fits your standards and expectations. To be clear, I don’t mean coding standards but patterns and practices which demonstrate good security and performant code.

Next, build out the rest of your tools. If you’re not writing the code directly, you need to be able to validate that the code works exactly the way you expect. At a minimum, that means testing business logic and validating interfaces, but you should include security and load or performance testing systems too.

Next, figure out how to describe your needs and capabilities effectively. We all know about requirements documents and Jiras but you’ll need to figure out how to translate that into actionable requests and steps for the generative AI. This will vary heavily on the system you’re using.

Finally, get used to throwing code away. Remember that your goal is solving the problem, and your code is merely the byproduct or the tool to get to that solution. The most important parts are the prompt and process used to generate the code, along with the understanding you gained and applied to get to that prompt. The more and faster you can learn, adapt, iterate, and ship, the better your solution will be.

But what happens After Vibe Coding?

It’s hard to predict things – especially the future – but I have a couple ideas.

First, more people are going to try more ideas faster. This is good. The people who were Excel wizards a generation ago are going to create “pretty good” things that solve their problems without involving a developer. My friends over at Dreambase are already doing that. We’ll have more automations and solutions than ever before.

Second, we may see the rise of “developer-less” companies. People will be able to imagine, describe, and ship a product with minimal developer input. Occasionally they may need an integration or similar and might contract with someone but maybe not even that. In my “Creating Better SDKs with Generative AI” course for LinkedIn, I realized that with well-defined interfaces, you don’t need much human interaction.

BUT – is this good or bad? Depends on who you are. If you job is to solve problems faster, this is a great time to be in the space. If your job is only to write beautiful code, you have a problem.