Vibe coding is everywhere and it is being blamed for a lot. I follow a number of subreddits, both technical and non-technical, and there is a theme emerging. People are hearing “vibe coded” and instantly dismissing AI generated code as slop, unreadable, broken, insecure, architecturally bankrupt garbage that is not maintainable. There is a field of memes that have been generated, leaning into this.

It is hard to argue. On the whole I agree. But they are misidentifying the problem. The tool isn’t the issue; the lack of intent is.

We need to stop pretending this is a new way of working and call what it is: it’s a new way of being lazy.

The Machine Gun and the Toddler

Blaming AI for producing bad code is like blaming a pencil for not the right spelling. Or worse, it is like blaming a machine gun for the chaos caused by a toddler. The tool is not the problem, the lack of discipline in the person commanding the pencil is the problem.

When you use an LLM to generate a block of logic without understanding the underlying constraints, you aren’t engineering. You are gambling and hoping that the statistical probability of the next token being correct outweighs the architectural requirements of your system.

That isn’t “vibe coding” it is just high-speed guessing.

Hello World

Every developer starts out writing the classic “hello world” test program. The goal is to create something mind numbingly simple, with zero complexity to produce an instant reward to prove everything works.

Engineers know though, if you give 100 developers this problem, you will get at least 80 different versions of this. Here I produced at least 10 different ways to do it in Java (I got bored after 10). Everyone is legal and works.

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}
public class HelloWorld {
    public static void main(String[] args) {
        System.out.print("Hello, World!\n");
    }
}
public class HelloWorld {
    public static void main(String[] args) {
        System.out.printf("%s%n", "Hello, World!");
    }
}
public class HelloWorld {
    static {
        System.out.println("Hello, World!");
    }
    public static void main(String[] args) {}
}
public class HelloWorld {
    public static void main(String[] args) {
        String msg = String.format("Hello, %s!", "World");
        System.out.println(msg);
    }
}
public class HelloWorld {
    public static void main(String[] args) {
        StringBuilder sb = new StringBuilder();
        sb.append("Hello, ").append("World!");
        System.out.println(sb);
    }
}
public class HelloWorld {
    public static void main(String[] args) {
        java.util.List.of("Hello, World!").forEach(System.out::println);
    }
}
public class HelloWorld {
    public static void main(String[] args) {
        Runnable greet = () -> System.out.println("Hello, World!");
        greet.run();
    }
}
public class HelloWorld {
    public static void main(String[] args) {
        java.io.PrintWriter pw = new PrintWriter(System.out);
        pw.println("Hello, World!");
        pw.flush();
    }
}

The point being, that even with this simple program, there are many ways to print “Hello, World!”. Some have little differences, some have major performance implications.

An AI, being at its heart, a random number generator, will not produce the same output each time. A developer however, will have their own style/rhythm and most likely will be consistent each time they need to do the same thing. They also know better which ones is better in the overall problem being solved.

Vibe Coding vs. Directed Coding

“Vibe coding” has become a catch-all term for low-intent prompting, describing the process of throwing a vague requirement at a model, such as “Create me a CRM,” or “Make this button look modern” and accepting whatever comes out as if it were a finished product. This is where the slop lives. It is shallow, it is unverified, and it is dangerous.

The word itself is telling. A “vibe” is an intuition, a feeling, an atmospheric mood. It is something you sense rather than something you measure. While that might be fine for choosing a restaurant or picking a playlist, it is a catastrophic way to build software. You cannot debug a feeling. You cannot unit test an atmosphere.

In the cold light of day, relying on “vibes” provides no stability, no predictability, and no professional rigor.

We need better language to describe AI output that is intentional, orchestrated and architected.

I call asking AI under these conditions as Directed Coding.

In Directed Coding, the human remains the architect. You are not asking the machine to “figure it out”. You are providing the specifications, the constraints, the patterns, and the logic. You use the AI as a high-velocity implementation engine, but you remain the one defining the boundaries of the box it operates in.

The difference is intent.

• In Vibe Coding, the model leads and the human follows.
• In Directed Coding, the human leads and the model executes.

It’s the Contractor Problem

The real danger for CTOs and engineering leaders isn’t that their teams will use AI. It is that they will use it without the ability to audit it.

It reminds me of that classic Fawlty Towers episode, “The Builders.” Basil gets a group of cowboys in to do a knock-through because he thinks he is being clever by getting it done cheap and fast. He is all pleased with himself until Sybil comes home and demands a real builder look at it.

The horror on his face when the professional arrives is exactly how an engineering leader should feel when they realize their “vibe coded” codebase is actually a structural disaster. This is the future result of most due diligences, as private equity firms contend with AI generated platforms more.

If you know how to read blueprints, you can walk through the site and see if the foundation is poured correctly or if they are using cheap materials behind the drywall. You can spot the shortcuts before they become structural failures.

But if you don’t know anything about construction, you are at the mercy of the contractor. They can tell you the work is done, it looks great, and everything is “fine.” And for a while, it will be. But eventually, the cracks will appear. The pipes will leak. The roof will sag.

This is not a new problem. We’ve run into this when we bring in 3rd party developers, off/onshore doesn’t matter. The quality of their output needs to be poured over to ensure they are producing to your coding standards. AI should be treated as that external development house.

AI is a little slicker than most outside developers though. AI creates an illusion of completeness, producing code that looks finished. It uses the right syntax and follows common patterns and fills in the gaps with such confidence that it masks the technical debt it is creating.

If you don’t have the fundamental knowledge to see those gaps, you are just building a house on sand.

The Fundamentals are the Guardrail

There is a growing argument that we don’t need to teach the basics anymore because the AI can do it for us.

This is the most dangerous lie in the industry.

The more we rely on automated generation, the more critical fundamental knowledge becomes. You cannot audit what you do not understand. You cannot direct what you cannot define.

If your engineers only know how to prompt, they are not engineers. They are operators of a black box. And when that box fails, and it will, they will be powerless to fix it. Anyone with “Prompt Engineer” as their title – get out.

We must double down on the basics. We need to teach the “why” alongside the “how”. We need to ensure that the next generation of developers understands memory management, concurrency, architectural patterns, and complexity analysis not as academic exercises, but as the essential tools required to supervise the machines.

The goal is not to fight the AI. The goal is to be better than it.

Stop Guessing

If you are using AI to bypass the hard work of thinking, you are not increasing your velocity. You are just increasing your future technical debt.

Stop vibe coding. Start directed coding instead. Slop is on the user, not the AI.

AI Disclaimer: Written by a human with Gemini 3.8 Flash generating the photo from the 1998 “The Big Lebowski“ movie.