If you think vibe coding is terrible, you don’t know how apps are made

The loudest criticism of vibe coding usually rests on a fantasy about how software gets made. In this fantasy, a serious engineer begins with a complete specification, understands every dependency, types every line by hand, and arrives at the correct architecture through expertise alone. AI breaks that sacred process by letting someone describe what they want and receive code they did not personally author. Therefore, the result must be unserious.

Almost no real app has ever been made that way. Software is built by assembling abstractions, borrowing proven patterns, reading documentation, testing assumptions, throwing away first attempts, and improving the thing after people use it. Vibe coding does not invent that process. It makes one part of it radically faster — and exposes how many people had confused writing code with building a product.

Nobody builds from first principles

Modern developers stand on an absurdly tall stack of work they did not author. The language, operating system, framework, database, cloud, authentication provider, payment API, open-source packages, design system, code examples, and answers copied from a twelve-year-old forum thread all arrived from somewhere else. Good engineering has never meant understanding every transistor beneath the button. It means knowing which abstractions to trust, where they can fail, and what deserves closer inspection.

AI is another abstraction layer. It can turn intent into a rough implementation, explain an unfamiliar code path, generate the repetitive parts, and offer three approaches before a person would have finished scaffolding the first. Treating that as inherently illegitimate is like arguing that a developer who uses a framework did not really build the app because they did not write the router.

Software has never been a typing contest. The value is in deciding what should exist, making it reliable, and taking responsibility when it doesn’t work.

The first version was always supposed to be wrong

The expensive mistake in product development is not producing a bad first draft. It is spending six months producing the wrong polished product. Every capable product team works in loops: make the idea tangible, put it in front of someone, observe what fails, and revise. A written specification is still a guess. A working screen gives people something concrete to reject.

Vibe coding compresses the distance between an idea and that first useful reaction. A founder can discover that the workflow makes no sense before hiring a team. A designer can test an interaction instead of explaining it in a meeting. An engineer can compare architectures in running code instead of debating them in the abstract. Most of those versions should be discarded. That is not waste. That is the point of a cheap first version.

The criticism confuses code with product

Code is one ingredient in an app. The product is also the problem definition, the workflow, the interface, the data model, permissions, edge cases, accessibility, performance, security, analytics, deployment, support, and the hundred decisions that make the software comprehensible to someone who was not in the room when it was built. Generating a component does not settle any of those questions. It simply makes the component cheaper.

That is why an experienced builder with AI and a first-time builder with AI do not produce the same thing. Both may get an impressive screen. The experienced builder sees the missing states, the dangerous assumption, the migration that will hurt later, the unbounded query, and the moment a user will lose trust. AI increases output. It does not equalize judgment.

A prompt can produce code. It cannot accept responsibility for the result.

Yes, bad vibe coding is bad

If someone ships generated code they never inspected, stores secrets in the client, skips tests, ignores error states, and cannot explain what happens to a user’s data, that is bad development. Calling it vibe coding does not make it better. But it does not make AI the cause, either. People shipped copied forum answers, unreviewed contractor code, fragile no-code workflows, and confident junior mistakes long before a model could autocomplete a function.

Powerful tools amplify the operator. A disciplined team uses the speed to test more, simplify sooner, and spend attention on the parts that matter. An undisciplined team uses it to create a larger mess faster. The responsible conclusion is not that the tool is fraudulent. It is that speed raises the importance of review, tests, observability, security, and clear ownership.

What competent vibe coding looks like

It starts with an outcome, not a prompt. The builder defines what the software must do, what it must never do, and how anyone will know it works. AI scaffolds the first path. The builder runs it immediately, reads the diff, tests the boundaries, removes unnecessary complexity, and keeps the system small enough to understand. Before release, the work gets the same treatment any production software deserves: real data, failure handling, permission checks, automated tests, logs, monitoring, and a rollback plan.

At Revenue Arc, we use AI to reach the consequential questions sooner. We do not need to spend a week proving that a form can save to a database. We need to learn whether the workflow is right, whether the prediction is trustworthy, whether the permission model survives a real organization, and whether the system runs unattended on a Tuesday. Faster code gives us more time for that work, not permission to skip it.

The scarce skill was never syntax

As implementation gets cheaper, taste and accountability become more valuable. Someone still has to decide which problem is worth solving, what to leave out, where the risk lives, when the result is honest enough to ship, and whether the app made anyone’s day better. Those are the decisions that separated good products from bad ones before AI, and they will separate them afterward.

So yes: vibe coding can produce terrible software. So can traditional coding, outsourcing, a year of planning, and a room full of senior engineers. Dismissing the entire practice because the first draft can be careless reveals an old-fashioned idea of the job — that value is proportional to the number of keystrokes a developer personally supplied. It is not. Apps are made in loops, with judgment. AI tightens the loop. The builder still owns everything that comes out of it.