Is Vibe Coding Bad? And Is It Going to Replace Programmers?

Vibe coding has become one of those topics where everyone seems to have a strong opinion.

Some developers think it's the future of software development. Others treat "vibe coding" almost like a dirty word. And behind all of that is the much bigger question:

The answer, at least today, is that nobody really knows.

There is a huge amount of uncertainty around where this technology is going. Anyone confidently telling you exactly what software development will look like in five or ten years is probably guessing.

Today, I don't think AI can replace software engineers.

There is still a significant gap between generating working code and designing, deploying, securing and operating reliable production software.

But five years from now?

I wouldn't pretend to know.

Technology is moving far too quickly for that kind of confidence.

What I am much more confident about is that AI is going to change software development significantly.

It already has.

Artificial intelligence has been around for decades. Machine learning and neural networks aren't new either.

What has changed dramatically is capability, scale and accessibility.

Massive investment in AI infrastructure and models has given ordinary people access to capabilities that would have been unimaginable not that long ago.

Software development tools have evolved incredibly quickly as a result.

We went from basic autocomplete, to smarter suggestions, to AI chat inside our IDEs. Now we have increasingly agentic tools that can inspect an entire codebase, create files, run commands, write tests, debug failures, refactor applications and implement complete features.

Tools such as Claude Code, Codex and Cursor are genuinely impressive.

And they are improving ridiculously fast.

So naturally we ask:

I think we make the AI conversation too much about ourselves.

"Will AI replace programmers?"

That's an interesting question if you're a programmer, but the transformation is potentially much bigger than the tech industry.

Look at customer support.

We already have businesses where AI handles a large portion of customer enquiries before a conversation ever reaches a human.

Transport is another obvious example.

Autonomous vehicles are already operating commercially in parts of the world. As the technology becomes safer, cheaper and more widely accepted, it could eventually affect taxi drivers, rideshare drivers, delivery drivers and many other transport jobs.

But I wouldn't pretend this means millions of drivers are disappearing next year.

Technology doesn't spread as neatly as a demo suggests.

There are regulations, insurance, liability, infrastructure, geography, economics and public acceptance to consider. Something that works commercially in a carefully mapped part of one US city isn't automatically ready for every road.

The direction of travel is still difficult to ignore.

And when industries change, people move.

Some jobs disappear. Some change. Some new jobs appear. Workers move between industries, which changes the supply and demand for labour elsewhere.

We've seen versions of this before.

Computers changed the workforce. The internet did it again. Entire categories of jobs became smaller or disappeared while completely new industries emerged.

AI will probably follow a similar pattern, although possibly much faster.

If you forced me to guess, I'd say the next five years will bring much bigger changes than the previous five.

But that's exactly what it is: a guess.

Predictions about technology have a terrible habit of ageing badly.

The more important question might be whether our governments, businesses and societies are prepared for the transition.

But back to programming.

Despite all the criticism around it, vibe coding has personally given me something extremely valuable:

I'm primarily a backend developer.

There are plenty of technologies I've wanted to explore over the years, but there are only so many hours in the day.

This blog is a good example.

I've built parts of it using Three.js.

Traditionally, doing that properly would mean spending a considerable amount of time learning Three.js and the world around 3D development: scenes, cameras, lighting, geometry, materials, animation and all the little problems that come with rendering things in 3D.

With AI, I could start building immediately and learn the pieces I needed along the way.

I've done the same with Laravel Livewire for the administration side of the blog.

And the effect has been even bigger across my personal projects.

I have applications for my notes, home lab and various dashboards. Things that previously existed as a database, a few scripts and CLI commands now have proper interfaces, charts, dashboards and features that I probably wouldn't have considered worth spending the time to build manually.

AI even suggests useful improvements I hadn't thought about.

My Home Assistant setup is another example.

With hundreds of entities, keeping everything organised was always cumbersome. Now I can give AI some context, a few prompts and exported JSON and organise or audit large parts of it in minutes.

That's a genuine productivity improvement.

And I think this reveals something important about the "AI will replace developers" argument.

AI didn't replace the Three.js developer I would have hired to build my personal blog.

I simply wouldn't have built it that way.

AI made software economical to build that previously wasn't worth my time.

Scale that idea beyond personal projects and it becomes very interesting.

There are millions of small problems inside homes and businesses that aren't worth spending $20,000 to solve with custom software.

What happens when the cost of creating that software drops dramatically?

We might not simply get the same amount of software built by fewer developers.

We might get far more software.

Twice.

Yes. Twice. :)

I had an AI coding agent working directly on the server for this blog.

It ran migrations against the production database, destroyed data and effectively came back with the AI equivalent of:

It's funny because the consequences weren't serious.

But it's also an important lesson.

And blaming AI entirely would be unfair.

At that stage the blog was still being developed. The data wasn't particularly important, and I had consciously accepted the risk because working directly there was convenient.

The blast radius was small.

But imagine exactly the same situation with someone who doesn't understand databases, backups, environments or infrastructure.

They give an AI agent SSH access to a production server because that's what the AI suggested.

The agent proposes a command.

It looks technical.

They approve it.

What tells that person that the command is dangerous?

This is where I think we reach one of the fundamental characteristics of AI-assisted development:

That's incredibly powerful when your intention is correct.

And incredibly dangerous when it isn't.

On another project, I accidentally configured the wrong repository URL as part of a deployment workflow.

The GitHub self-hosted runner decided that the existing project wasn't the repository it expected and cleaned it up.

Including the .env file.

Again, AI wasn't solely responsible.

The configuration was wrong, and the deployment workflow behaved according to that configuration.

But if you don't understand where your database credentials are stored, how secrets are managed, how deployments work or how to recover the application, congratulations:

You've just accidentally scheduled yourself a disaster recovery exercise. :D

These experiences haven't convinced me that AI coding is bad.

They've convinced me that understanding the system still matters enormously.

Security is probably one of the strongest arguments against blindly vibe coding production applications.

AI can absolutely help with security.

It can review code, identify vulnerabilities, recommend safer patterns, inspect dependencies and even have another agent review what the first agent produced.

But it can also miss something incredibly obvious.

I experienced a simple example with my personal notes application.

The application's secrets and code had been checked. Authentication worked. Nothing immediately looked wrong.

But AI had happily implemented public registration.

There wasn't necessarily anything technically broken about the registration code.

There was just one fairly important requirement missing:

Had I explicitly told the AI:

it almost certainly would have implemented that correctly.

But that's exactly the problem.

Someone has to know that requirement exists.

"Make it secure" isn't a security model.

This is where I think the discussion about AI replacing programmers gets much more interesting.

Writing code is only one part of building software.

Understanding what should be built is often much harder.

After years of discussing requirements with stakeholders, one thing I've learned is that people often struggle to describe exactly what they need.

That's not criticism.

It's normal.

Someone describes a feature.

You ask questions.

They clarify it.

You build or show something.

They realise that's not quite what they meant.

You watch how they actually perform the task and discover an exception nobody mentioned.

Then someone from another department explains that their workflow is completely different.

Eventually you start understanding the real requirement.

AI doesn't magically eliminate that process.

In some ways, it could amplify the problem.

If you describe the wrong thing extremely efficiently, AI can build the wrong thing extremely quickly.

The bottleneck starts moving from:

to:

That's a very different skill.

Interestingly, this isn't just my experience.

Google's DORA research describes AI in software development as an amplifier: it magnifies the strengths of organisations that already have good engineering practices, but can also magnify weaknesses in organisations that don't. Their research found higher AI adoption associated with greater software delivery throughput, while delivery stability can suffer when the underlying engineering system isn't strong enough.

That description makes a lot of sense to me.

Give a good engineering team AI and they can move faster.

Give a bad engineering process AI and it can make bad decisions happen faster too.

The same applies at an individual level.

AI doesn't just increase your ability to produce code.

It increases your ability to act.

That's a much bigger deal.

There is another interesting side to this.

AI feels fast.

I certainly feel much faster using it for many tasks.

But that doesn't mean AI makes every developer faster at every type of work.

METR ran a controlled study with experienced open-source developers working on mature projects they already knew extremely well. The developers expected AI to make them faster and, after completing the work, still believed it had.

The measured result was surprising.

With the early-2025 AI tools used in the study, they actually took 19% longer when AI was available.

That doesn't mean AI makes developers slower.

The study involved only 16 experienced developers working on repositories they already knew deeply, so it certainly shouldn't be generalised to every type of software development.

But it demonstrates something important:

An expert working inside a mature codebase they have understood for five years is very different from me using AI to cross into Three.js, where I would otherwise need to learn an unfamiliar ecosystem before becoming productive.

That's where AI has been transformational for me.

It dramatically reduces the cost of crossing knowledge boundaries.

There's another issue that I think experienced developers increasingly recognise.

AI is often incredibly good at producing something that is almost right.

And almost right can be surprisingly expensive.

Stack Overflow's 2025 Developer Survey found that 84% of respondents were using or planning to use AI tools, yet more developers distrusted the accuracy of AI output than trusted it. The most common frustration was AI producing solutions that were almost correct, but not quite.

I recognise that feeling very well.

An obviously broken solution is easy.

You run it.

It fails.

You fix it.

A solution that's 95% correct can be much more dangerous.

It looks good.

The tests you thought of pass.

Everything works normally.

Then six months later someone discovers the missing 5%.

In production.

One way I've found to improve AI development is to chain agents together and give them different responsibilities.

One agent implements the feature.

Another reviews the architecture.

Another reviews security.

Another writes or reviews tests.

Another tries to find edge cases or break the implementation.

You can effectively create a small AI development team where agents challenge and verify each other's work.

That can reduce the risk considerably.

But at this point I think we should make an important distinction.

If you're defining the architecture, reviewing the changes, controlling permissions, validating tests, making deployment decisions and using AI agents to implement large portions of the work...

Are you really vibe coding anymore?

Or are you doing AI-assisted software engineering?

The original spirit of vibe coding was much closer to giving yourself over to the AI, repeatedly prompting until things worked and not worrying too much about the underlying code.

That's very different from deliberately directing agents while understanding and reviewing the system they're modifying.

Personally, the more important an application becomes, the less willing I am to just vibe.

Even multiple agents don't completely solve the problem.

Every agent ultimately works from some combination of your instructions, available context and its interpretation of the problem.

Garbage in, garbage out still applies.

Maybe now it's just:

Current AI assistants can challenge assumptions, but they still generally operate within the framing they're given.

And then there is hallucination.

AI can be confidently wrong.

It can misunderstand documentation, invent configuration options, misunderstand an API or give you a technical explanation that sounds completely reasonable but isn't true.

For an experienced developer, something may feel suspicious enough to investigate.

For someone with no experience, exactly the same answer can sound authoritative.

That's where false confidence becomes more dangerous than a simple coding mistake.

Someone who knows they don't know something is usually careful.

Someone who doesn't know something but has AI confidently telling them everything is correct may not realise there is anything to check.

This is another area where the "anyone can build software now" narrative becomes a little too simple.

Fine.

You built the application.

Where does it run?

Which cloud provider should you use?

Which database?

Where are the secrets stored?

How are deployments performed?

How do you roll back?

What happens when the server dies?

Do you have backups?

Have you ever actually restored one?

How do you monitor the application?

How do you know when something is broken?

How do you patch it?

What happens when your traffic increases by 100 times?

Can you scale vertically by giving the server more resources?

Can you scale horizontally across multiple instances?

Was your application designed to support that?

What happens when a deployment fails halfway through a database migration?

This is operability.

This is scalability.

This is resilience.

And this is software engineering too.

AI can help with every one of these things.

But it needs the right context and, more importantly, someone needs to know whether its recommendations make sense.

If you explain the full picture from day one, AI can probably recommend a sensible architecture for many applications.

If instead you build an application through dozens of disconnected prompts, you may discover six months later that decisions made at the beginning have backed you into a corner.

Maybe you chose the wrong framework.

Maybe the wrong database.

Maybe your architecture doesn't scale.

Maybe your deployment model can't provide the resilience you now need.

Developers have been making bad architectural decisions forever.

AI just gives us the ability to make them much faster.

No.

I think it's fantastic.

It has allowed me to build things I wouldn't otherwise have had time to build.

It lets me experiment with technologies outside my normal area of expertise.

It turns small ideas into useful personal tools.

It removes huge amounts of repetitive work.

And for prototypes and MVPs, it can be ridiculously productive.

The mistake is assuming that because AI generated a working application, that application is automatically ready for production.

Those are completely different standards.

A prototype needs to work.

It needs security, monitoring, backups, recovery, maintainability, appropriate architecture, testing, deployment processes, observability and people who understand what happens when something inevitably goes wrong.

And developers themselves seem to recognise that distinction. Stack Overflow's survey found strong resistance to handing high-responsibility tasks such as deployment and monitoring entirely to AI, even while adoption of AI development tools continues to grow.

So I wouldn't say AI coding isn't production-ready.

AI-generated code is already being used in production.

I'd say something slightly different:

Maybe we're asking the wrong question.

Perhaps the better question is:

Software development has always moved towards higher levels of abstraction.

We don't write our own operating system before building a web application.

We don't implement TCP/IP ourselves.

We don't normally write our own database engine.

Frameworks mean we don't rebuild routing, authentication and database abstractions for every application.

Cloud computing means we don't necessarily manage physical servers.

AI may simply become the next enormous abstraction layer.

Future developers may write dramatically less code themselves.

Their value may increasingly come from understanding requirements, designing systems, making architectural decisions, directing agents, reviewing implementations, managing security, validating assumptions and operating production systems.

In other words, the job changes.

And yes, it's entirely possible that fewer developers will eventually be required to produce the same amount of software.

Pretending that's impossible doesn't help anyone.

But there's another possibility we shouldn't ignore.

If building software becomes dramatically cheaper, we may simply build dramatically more software.

My own projects are a tiny example of that.

AI didn't take development work away from another programmer.

It caused software to exist that otherwise wouldn't have existed at all.

That makes predicting the eventual effect on programming jobs much harder.

Right now, AI helps us ship incredibly quickly.

For personal projects, experiments, prototypes and MVPs, vibe coding can be almost ridiculously effective.

For production systems, AI-assisted engineering is already useful too, but the surrounding engineering discipline matters enormously.

There is still a meaningful difference between:

and:

AI is closing that gap.

Fast.

I don't think developers should be scared of these tools.

And I don't think dismissing vibe coding makes much sense either.

Use them.

Learn them.

Push them.

Understand what they're good at.

And, probably more importantly, understand where they fail.

Because I think the dangerous part of vibe coding isn't that AI writes code.

But strangely enough, that's also its superpower.

It lets a backend developer build a 3D experience.

It lets someone automate a problem that was never worth paying a development team to solve.

It lets people turn ideas into working software at a speed that would have sounded ridiculous only a few years ago.

That's genuinely exciting.

The challenge is knowing where exploration ends and engineering responsibility begins.

Whether AI eventually replaces programmers, reduces their numbers, creates more demand for them or simply changes what the word "programmer" means, I don't think anyone can confidently answer yet.

But the industry is clearly changing.

And perhaps the most valuable skill for developers in the next few years won't be competing with AI to see who can type code faster.

It will be knowing what to build, how to direct AI to build it, and whether what came back is actually good enough to trust.