A new pattern has emerged in the last 18 months: non-technical founders and product people building full working applications almost entirely with AI assistance — cursor, Claude, Copilot, v0. The apps look great, they function in demos, and they ship in days.
Then reality arrives.
What "Vibe Coding" Actually Produces
The term "vibe coding" — prompting AI to build what you need without deeply understanding the output — describes a real workflow that produces a specific class of artefact: software that works under the conditions it was tested in.
The problems emerge when those conditions change, which happens with every non-trivial application in production.
It works until it needs to change
AI-generated code is optimised to be correct for the prompt. It is not optimised for future maintainability, extension, or modification. The patterns chosen are often whatever the model's training data suggested most frequently for that context — not what's best for your specific system.
Adding a feature to a vibe-coded codebase often requires regenerating large sections, because the structure wasn't designed with extension in mind. Each regeneration has a chance of breaking something that was previously working.
It works until load increases
AI-generated database queries often contain N+1 patterns — a query for every item in a list rather than a single join. In development with 20 rows, this is invisible. In production with 20,000 users, it brings the database to its knees.
Rate limiting, connection pooling, caching, and query optimisation are rarely prompted for and rarely volunteered. They appear in the codebase only if the human building it knows to ask for them.
It works until security matters
Authentication flows are a common vulnerability. AI models produce technically functional auth code, but subtle vulnerabilities — improper token validation, missing rate limits on login endpoints, insecure password reset flows, unprotected API routes — are common.
In a demo, nobody tries to exploit these. In production, the first malicious user will find them within weeks.
It works until something fails
Error handling in AI-generated code is often optimistic — happy path only. What happens when a third-party API is unavailable? When a database transaction fails halfway through? When a file upload times out? Often: an uncaught exception, an inconsistent state, or a user-facing error with a stack trace.
The Asymmetry
This is not an argument against AI-assisted development. It's one of the most powerful productivity tools available. I use it constantly.
The argument is about the role of engineering judgement in the process.
Experienced engineers use AI to accelerate work they understand. They review the output against a mental model of what correct, maintainable, secure code looks like. They accept what's right, reject what's wrong, and direct the AI toward better solutions.
Vibe coding uses AI as a replacement for that judgement. The output is accepted if it runs, not if it's correct. The human doesn't have the model of the system needed to evaluate what they're accepting.
The asymmetry: the AI does not get worse at producing code you don't understand. It produces the same code regardless. The difference is entirely in whether there's a competent engineer in the loop to catch the problems.
When Vibe Coding Is Fine
There are real use cases where this approach is entirely appropriate:
- Prototypes and demos: functionality over quality, lifespan of weeks
- Personal tools: low stakes, single user, maintainer is also the user
- Exploration: trying something to see if it's worth building properly
- Templates and boilerplate: well-understood patterns where AI output is predictably good
If you're building for revenue, users, or longevity — the cost of the engineering review is smaller than the cost of the production incidents, security breaches, and rewrites you're deferring.
The Practical Model
The highest-leverage use of AI in software development is not replacing engineers — it's dramatically multiplying what engineers can produce.
A good engineer with strong AI tooling:
- Produces 2–4× more code per day
- Spends less time on boilerplate and more time on design
- Has more capacity for the hard problems: architecture, security, performance
A non-engineer with strong AI tooling:
- Builds things that work in demos
- Creates a technical foundation that becomes increasingly expensive to maintain
The second scenario has a place in the ecosystem. But if your product is your business, get an engineer to review what's been built — or better, to drive the build with AI as the accelerator. That's what I do for early-stage products and teams.