This week, we’ve seen more than one coding YouTuber release a rant video criticising vibe coding. On Hacker News, Godwin’s Law has been replaced by one stipulating that all conversations degenerate into vibe coding vs boomer coding (i.e. coding strictly without using AI assistance).

I hear stories every day of senior developers in this or that company who a) have never even heard of Claude Code and/or b) are still poring over API documentation before slowly beginning to lay down code that interacts with it.

You won’t need to read the rest of this to understand that vibe coding is going to win. No amount of online influencers who’ve seen the looming end of their media revenue can hold back this tide.

Not even the most seasoned dev can out-deliver a context engineer.

Let’s look at the jist of the argument.

LLMs sometimes get it wrong frequently. You still need to read, understand, and test what comes out.

But guess what? Humans write broken code all the time, too. Almost all human-written code is buggy and clumsily implemented. That’s the reality of coding for money: good enough is usually the best we can shoot for.

The question isn’t

can I trust it?

The question is:

can I verify it quickly, correct it easily, and move faster than before?

And with proper context engineering, the answer is almost always: yes.

This is a real risk of vibe coding. This is what leads to production apps with glaring security holes, stolen data and incorrect functionality.

But learning how to engineer context, design good inputs, and review outputs is a skill. It’s not something that a beginner can do, nor is is something somebody with no coding skills can excel at.

Just as the best boomer coding devs are those that learn at a phenomenal rate, the best vibe coders are those that stay close to the code that’s being written and learn as they go. They treat the AI as part slave, part mentor.

If we can forsee a future where those who don’t vibe code are eventually cast out of the industry, we can also anticipate that vibe coders who don’t learn along are next on the list.

Most levelling this criticism have yet to get beyond copy-pasting prompt responses into their IDE (see our previous issue on the progression of a context engineer).

This leads to the criticism that bad prompting is just copy-paste with plausible syntax.

But real vibe coding is:

If you think it’s just copy-paste, you’ve stopped at “chatbot” and never made it to “toolchain.”

Serious vibecoders add dozens of .md files to their repo and use CLI or IDE-based agents (with access to MCP tools) that work directly on the code. They follow along as changes are made and reject those they don’t like.

Let’s name it:

Some devs feel threatened by vibe coding because it breaks the craft.

If anyone can prompt their way to working code, what’s left of our identity?

But here’s the thing: this has happened before. C compilers. Rails generators. React component libraries. In any developer thread, the person shouting “LLMs are a crutch” is also the person with 27 custom Vim macros and a 400-line .bashrc.

That said, we can’t in all honestly characterise the rise of AI coding as just another development in coding practice. It’s a new paradigm that will lead imminently to many thousands of devs losing their jobs forever.

And if you think because your shop doesn’t use LLMs, you’re safe? There is an AI-native competitor with 10% of your company’s headcount sneaking up on you, intent on eating the firm’s lunch.

In the early 1900s, people defended horses over cars using perfectly valid arguments:

And still cars won. Not because they were instantly better, but because they scaled faster. LLMs today are horses vs. cars all over again.

Sure, the roads aren’t paved, and the cars don’t go faster than 20mph as yet, but they will. Be sure of that. You can insist on riding the horse. It’s even a little romantic. Pretty soon, though, you’ll find cars buzzing past you on the track.

Critics are right about one thing: you need standards.

LLM generated code isn’t magically correct, it’s just fast. If you don’t structure your inputs, you’ll get messy, inconsistent, hard-to-review output.

That’s why you need:

Professionalised vibe coding isn’t chaotic. It’s structured, reproducible, and often better than junior dev output. This is where actual coding experience becomes an absolute asset that puts senior developers and above in the driving seat for LLM use.

There are a lot of lies about vibe coding online. A lot.

As a general heuristic, anything combining the terms MRR or ARR and vibe-coding is absolute bullshit. Anything where the entrepreneur in question is under 20 has very questionable provenance. Almost anything that talks about an AI SaaS company getting investment is suspect.

The real gainz are being made on the quiet, in offices, labs and bedrooms around the world. Builders are building and using these relatively newly-found powers (Claude Code has been out for a few months) to lay down 5000 lines of code a day.

“I could write this faster myself”

No, you can’t. Not in this physical universe.

Next question.

You don’t have to throw away your craft. You don’t have to stop thinking. You just have to stop typing so much.

Vibe coding isn’t the end of software engineering. It’s the beginning of something faster, clearer, and more modular.

Only those that embrace it and develop the skillset required to really leverage AI tools will survive.