Ruben Bijker
Get in touch

Vibe coding: the good way, the bad way and why experience matters

By Ruben Bijker · Published · 6 min read

Vibe coding means building software by prompting an AI tool and accepting what it writes. You describe a feature, the tool produces code, you run it, and if it seems to work you move on. For a prototype that can be great. For software a business depends on, the difference between the good way and the bad way is experience.

I use AI every day. It makes me faster. But speed only helps when you know where you are going.

The bad way: it works until it doesn't

The bad version looks productive at first. Features appear quickly and the demo works. The problems arrive later, usually all at once.

  • Code nobody understands. If you accept a change you cannot explain, you cannot debug it, extend it or tell whether it is safe.
  • No architecture. Each prompt solves the problem in front of it. Nobody decides where logic lives, so it ends up everywhere.
  • Duplicate logic. The tool happily writes a second version of something that already exists. Now a bug fix has to happen in three places, and someone will miss one.
  • A weak data model. Tables and fields get added prompt by prompt. Migrations become painful and the data stops making sense.
  • Security holes. Missing authorisation checks, unvalidated input, secrets in the code, an admin route anyone can reach. The app works fine, right up until someone looks for these.
  • No tests. Every new change might break an old feature, and the only way to find out is a user reporting it.
  • Unmaintainable growth. Each change takes longer than the last, because the AI now has to work around its own earlier decisions. Eventually the honest estimate for a small feature is a rewrite.

None of this shows up in a demo. It shows up when real users, real data and real money are involved.

The good way: an engineer steering the AI

The good version uses the same tools. The difference is who makes the decisions.

  1. Decide the architecture first. The stack, the data model, the boundaries between modules and where business logic lives. These choices are cheap to make early and expensive to change later, so I make them, not the tool.
  2. Give the AI a clear frame. Conventions, the relevant files, types and schemas. The tighter the frame, the better the output fits the codebase.
  3. Work in small steps. One focused change at a time is easy to review and easy to revert.
  4. Review every diff. I read what the AI wrote the way I would review a colleague's pull request. If I cannot explain a line, it does not go in.
  5. Test what matters. Unit tests for logic, end-to-end tests for the critical flows, and a type check and linter on every change.
  6. Treat security as a design task. Authentication, authorisation, input validation and secrets get deliberate attention, not whatever the tool suggested first.
  7. Ship it properly. Automated deployments, preview environments, error tracking and monitoring from the first day, so problems are found by me and not by users.

Done this way, AI takes over the typing and the routine work. The thinking stays with someone who knows what good software looks like.

Why experience is the real requirement

AI tools write code that looks convincing. That is exactly why experience matters. Spotting the problem in plausible code takes knowing what tends to go wrong: the query that gets slow with real data, the race condition, the shortcut that turns into a data leak, the abstraction that will not survive the next feature.

You only learn that by building, shipping and maintaining software for years, including the parts that went wrong. Without that background you cannot tell good output from bad, and the AI will not tell you either.

Keep an eye on the architecture

Architecture is what keeps a codebase workable as it grows. With AI in the loop that matters more, not less, because code now gets written faster than anyone can casually keep track of.

  • Keep a clear structure, so every new piece of code has an obvious place to go.
  • Refactor when duplication appears, before it spreads.
  • Delete code that is not needed. More code is more to maintain, whoever wrote it.
  • Revisit decisions when the product changes, instead of letting the AI patch around them.

How I work

I have been building software for more than 15 years, from design and frontend to backend, infrastructure and hosting. I use AI to move faster, and I use that experience to decide what gets built, how it fits together and what goes live. That way you get the speed without paying for it later.

Related: AI-assisted development and choosing a stack.

Frequently asked questions

What is vibe coding?
Building software by describing what you want to an AI tool and accepting the code it writes, often without reading it closely. It is fast for prototypes and risky for anything that has to last.
Can someone without coding experience build a product with AI?
They can build a demo. A product needs a sound data model, security, tests, deployment and monitoring. Without coding experience you cannot judge whether the AI got those right.
Is vibe coding bad?
Not by definition. The tool is not the problem. The problem is accepting code nobody understands. With an experienced engineer steering, reviewing and owning the architecture, AI makes good work faster.

Related service: Software engineer for custom web applications

Have a project in mind?

Tell me briefly what you need. You get an answer from me, not from a sales team.

Get in touch

Keep reading