The Great Vibe Coding Illusion

With the rise of AI, Generative AI and now Agentic AI, vibe coding has become one of the most exciting developments in software development.

Every other week, there seems to be another story about someone who built an entire SaaS platform over a weekend, launched an application without knowing how to code, or turned a few prompts into a business generating thousands of dollars in monthly recurring revenue.

And, importantly, many of these stories are true.

Vibe coding is a software development approach where a person uses AI tools to generate, modify and debug code primarily through natural-language instructions rather than writing every line manually. The user describes what they want, tests what the AI produces, and continues prompting until the application appears to work.

It dramatically lowers the barrier to software development.

And I am not against it.

I vibe code myself on many projects. The pace at which I can develop software has increased significantly because of AI tools. Things that used to take hours can sometimes take minutes. Prototypes that might previously have taken weeks can now be produced in days.

Vibe coding represents a significant leap forward for the software industry.

The illusion is not that vibe coding works.

The illusion is believing that because we have made it dramatically easier to generate code, we have somehow made software engineering easy.

Those are two very different things.

We Have Seen This Movie Before

Since I became a software developer, there has always been a conversation about the technology that will eventually replace developers.

Before vibe coding, there was low-code and no-code.

Platforms such as Bubble, Google AppSheet and Softr promised to allow ordinary users, entrepreneurs and business teams to build applications without traditional programming.

Many of these platforms are still around today and remain excellent tools.

But they did not replace software engineers.

Instead, they found their place in the software ecosystem. They became useful for prototypes, internal applications, simple business systems, MVPs and situations where speed was more important than building a highly customised software platform.

Extraordinary founder stories also fueled the hype around no-code.

1. Joshua Tiernan built Ernestly using Bubble as part of a 24-hour startup experiment. The product subsequently reached #1 Product of the Day on Product Hunt.
2. Then there was Articly.ai. Its founders built the initial AI SaaS product entirely on Bubble over a single weekend, improved it over the following weeks, and reportedly reached $12,000 in monthly recurring revenue within two months.

These are fantastic stories.

They are also where we need to be careful.

The Exception and the Rule

My sister likes to say:

It is important to differentiate between the exception and the rule.

There is a similar idea in Greg Behrendt and Liz Tuccillo's book He's Just Not That Into You. One of the recurring lessons is that people often hear an extraordinary relationship story and then use that exceptional outcome to justify treating it as the normal rule. The book even contains a chapter titled Don't Listen to These Stories, centred around exactly this problem.

Technology suffers from the same problem.

Someone builds an application over a weekend and makes $12,000 MRR.

The story becomes:

You can build a successful SaaS over a weekend.

But that is not what the evidence actually says.

The evidence says:

Someone built a successful SaaS over a weekend.

Those are very different statements.

I would be fascinated to know what percentage of people who built a Bubble application over a weekend subsequently reached $12,000 MRR.

Probably not many.

Yet we naturally hear about the winner.

Nobody writes a viral LinkedIn post titled:

I spent my entire weekend building an app, and six people visited it.

Success stories get amplified precisely because they are unusual.

The New Exceptions to the Rule

Vibe coding has now produced a new generation of these stories.

And some of them are remarkable.

Fly.Pieter.com

In February 2025, entrepreneur and developer Pieter Levels decided to experiment with building a browser-based flight simulator.

He had never developed a game before.

Using Cursor and AI, he reportedly produced the initial working game in approximately three hours. The project went viral, attracted advertisers and became one of the most frequently cited examples of what one person can now build with AI. Later profiles reported that the project reached approximately $1 million in annualised revenue within 17 days.

That is extraordinary.

But there is another part of the story that matters.

Pieter Levels was not someone who discovered the internet on Friday afternoon and became a software entrepreneur by Sunday.

He had already spent years building, launching and monetising internet products. He understood product development, distribution, payment systems, launching, marketing and how to build an audience.

AI gave an already experienced builder extraordinary leverage.

That is different from AI replacing experience.

Stanley

Another recent example is Stanley, an AI content product created by Vitalii Dodonov and his team at Stan.

Dodonov says he vibe-coded the fully functional product with Cursor in a 14-day development sprint, without manually writing a line of code. Stanley launched with 250 paying customers on its first day and reached approximately $50,000 MRR within six weeks.

Again, an extraordinary demonstration of what AI-assisted development can achieve.

But again, context matters.

Dodonov had taught himself programming years earlier, worked as a data scientist at Deloitte, became a senior software engineer at eBay and had already helped build Stan before creating Stanley.

The headline is:

Founder vibe codes $50,000 MRR product in 14 days.

The fuller story is:

Experienced technology entrepreneur uses years of accumulated software and product knowledge, an existing business, an existing customer base and extremely powerful AI tools to build a new product remarkably quickly.

The second version is less sensational.

It is also considerably more useful.

These stories do not prove that engineering knowledge has become irrelevant.

In many ways, they demonstrate the opposite.

AI dramatically multiplies the capabilities of someone who already knows what they are doing.

The Great Engineers and How They Differ From Coders

There is a fundamental piece of knowledge that great engineers have that most people outside software development do not.

Developers do not just write code. They engineer.

The words coder, developer and engineer are often used interchangeably, and job titles differ between organisations, but there is a useful distinction.

A coder writes code. They translate instructions into syntax and functionality.

A developer goes further. They combine code, creativity, product thinking and problem-solving to build useful solutions.

An engineer thinks about the entire system.

They ask what should be built, why it should be built, how the pieces should interact, what compromises should be made, how the system will operate at scale and what happens when something goes wrong.

A coder may create an API endpoint.

An engineer asks:

• What happens when 10,000 users call it at the same time?
• What happens when the database goes down?
• What happens if a deployment breaks production?
• How do we secure the data?
• How do we restore the system from backups?
• What happens when usage grows by 100 times?
• How do we know the system is failing before customers tell us?

These are not primarily coding questions.

They are engineering questions.

Building the App Is Only the Beginning

This is where much of the vibe coding conversation gets confused.

We have dramatically reduced the time required to get from:

Idea → Working Software

That is revolutionary.

But a working application on your laptop is not necessarily a production software platform.

Production introduces another world of concerns: authentication, permissions, databases, concurrency, security, infrastructure, backups, monitoring, observability, deployment, testing, caching, queues, latency, disaster recovery, third-party integrations, data retention, data lifecycle, migrations and cost management.

AI can generate an authentication system.

• An engineer needs to know whether that authentication system is secure.

AI can create a database.

• An engineer needs to understand what happens when that database contains 300 million records.

AI can deploy an application.

• An engineer needs to know what happens when that deployment fails at 02:00 while thousands of customers are using the system.

AI can generate a solution that works.

• Engineering asks whether it will continue working.

That is a very different standard.

The Real Danger Is Not Bad Code

One of the biggest risks with vibe coding is not necessarily that AI writes bad code.

Developers write bad code too.

The bigger problem is when the person operating the AI does not have enough technical knowledge to recognise when something is wrong.

If I use AI to generate Python code and the solution is poor, there is a reasonable chance I will recognise the problem because I understand Python and software architecture.

If I do not understand the system at all, I am completely dependent on the AI evaluating its own work.

I can tell it:

The login doesn't work.

It makes a change.

The login works.

Great.

But:

• Did it fix the underlying problem?
• Did it remove an important security check?
• Did it create another bug somewhere else?
• Did it duplicate logic?
• Did it introduce a dependency that will become a problem six months from now?

The application working is not necessarily proof that the application was engineered correctly.

That distinction becomes increasingly important as AI makes it possible for people to build systems far more complex than they personally understand.

Where Vibe Coding Is Incredibly Powerful

This does not mean businesses should avoid vibe coding.

They should embrace it.

For prototyping, experimentation, proofs-of-concept, internal tools, automation, MVP development and testing new business ideas, these tools are extraordinary.

An entrepreneur who previously needed R200,000 to test an idea may now be able to prove whether customers want it for a fraction of that cost.

• That changes entrepreneurship.

A developer can experiment with five different implementations in the time it previously took to build one.

• That changes software development.

A small company can automate a process that would never previously have justified the cost of custom software.

• That changes business.

The mistake is not using vibe coding.

The mistake is confusing rapid creation with production engineering.

The Great Illusion

The Great Vibe Coding Illusion is not that vibe coding is fake.

It isn't.

It may be one of the most significant changes to software development in decades.

The illusion is believing that because writing software has become easier, engineering software has become easy.

It hasn't.

We have changed the interface between humans and computers.

Instead of spending hours explaining our intentions through programming syntax, we can increasingly explain them in English and allow an AI to translate them into code.

That is enormously powerful.

• But architecture still matters.
• Security still matters.
• Reliability still matters.
• Scale still matters.
• Data still matters.
• Judgement still matters.
• And understanding how all those things fit together still matters.