Education · AI Development Series
The term for building software by describing what you want to an AI tool and accepting the output. It demos brilliantly. It fails in ways that are invisible until they are very visible.
The term was coined to describe the practice of building software by describing what you want to an AI coding tool and accepting what it produces, without a developer understanding, reviewing, or owning the output. You are going on the vibe of whether it looks correct, rather than on a verified understanding of what it does.
This is distinct from using AI as an assistant within a development process. A developer who uses AI to suggest an implementation, reviews it, understands it, modifies it to fit the actual requirements, and takes ownership of the result is not vibe coding. That is AI-assisted development done properly.
Vibe coding is when the AI is the developer. When the human's job is to describe the feature and accept the output. When the code is produced without anyone understanding what it does or why.
"The tools are genuinely good at one thing: writing code once a human has decided what to build. They are catastrophic at the first mile, which is deciding what to build, how it should be structured, what could go wrong, and what it needs to do two years from now."
A demo tests one thing: does this feature work for one person right now? AI tools are extremely good at producing code that passes that test. The problem is everything the demo does not test.
The AI generates code to retrieve data. It does not add the check that confirms the requesting user is allowed to see that data. The demo works because there is only one user. In production with multiple accounts, the missing check means user A can see user B's records.
This is the most common and most serious failure. It is not subtle. It is the fundamental access control mechanism, absent.
AI tools generate schemas that work for a single test scenario. They do not add indexes, because indexes are chosen based on query patterns that are only clear once you understand the application at scale. They do not enforce relationships at the database level, because enforcing relationships requires understanding what the data means.
The result is a database that works fast with small data and grinds at real volumes. Queries that take two seconds with ten records take thirty seconds with ten thousand.
Operations that modify shared state (assigning invoice numbers, updating stock levels, booking time slots) need to be atomic. If two users run the same operation simultaneously, without transaction locking, they can produce duplicate outputs or corrupt shared state.
This is invisible in testing because you cannot discover it by using the application yourself. It appears as intermittent, hard-to-reproduce bugs under real concurrent use.
No human wrote the code, so no human fully understands it. Business logic is scattered without consistent structure. There is no design philosophy because the tool that generated it cannot have one. Every change is a guess at what might break.
This is the longest-term failure mode. The code is not wrong exactly. It is just impossible to maintain, which means every future feature is slower, riskier, and more expensive than it should be.
No. For a prototype, a proof of concept, or a personal tool you are the only user of, vibe coding is fine. The problems emerge when the software handles other people's data, scales to concurrent users, or needs to be maintained and extended over time. If none of those apply, the risks do not apply either. If any of them apply, the risks are real.
No. Using AI to suggest implementations, generate boilerplate, or speed up well-understood tasks is not vibe coding. Vibe coding specifically means the AI is making the structural and architectural decisions, and no human is reviewing, understanding, or taking ownership of what is produced. The distinction is whether a human is thinking about the system, or whether the AI is.
Usually yes. The problems follow consistent patterns and they are fixable. The starting point is an audit, which tells you what you actually have before you commit to a remediation approach. Most vibe-coded applications do not need to be rebuilt from scratch. They need the engineering underneath them that was not provided by the tool that generated them.
Honest advice on whether AI belongs in your specific project, where it helps, and where it will cost you. No pitch.
We reply within one working day.
Tell us about your project and we will be in touch within one working day.