Vibe Coding vs Engineering: Where the Line Is

What vibe coding actually is

In practice it means describing what you want, accepting what the model produces, running it, describing what is wrong, and repeating until the thing appears to work. The code itself is never really read — it is treated as an implementation detail, the way you treat the machine code your compiler emits. When the model is good and the task is well-trodden, this works startlingly often.

That is not an insult. It is a real capability shift, and dismissing it is as wrong as trusting it blindly. The mistake is treating the absence of visible problems as the absence of problems. A vibe-coded app has whatever security, error handling and data integrity the model happened to include — and nobody has checked which of those it did. Checking is the unglamorous core of bespoke software development, and it is the whole difference this post is about.

Where vibe coding genuinely shines

Used in the right places, vibe coding is the cheapest idea-validation tool ever created. We actively encourage clients to arrive with a vibe-coded prototype — it communicates a product idea better than any document. The common thread in every good use is the same: the cost of the software being wrong is close to zero.

• Prototypes and proofs of concept — testing whether an idea is worth building properly.
• Personal tools — a script that renames your files or summarises your inbox answers to nobody.
• Internal one-offs — a throwaway data-cleanup job or a quick calculator for one meeting.
• Demos for investors or stakeholders — where the point is the concept, not the plumbing.
• Learning — exploring an unfamiliar framework by watching a model use it.

The five signals you have crossed the line

The line is not about project size or how professional the app looks. It is about consequences. Any one of these signals means the software now needs engineering, whoever or whatever wrote the first draft.

• Money moves through it — payments, payouts, invoices, anything Stripe touches.
• It holds other people's data — customer records, health details, anything you would have to report if it leaked.
• Strangers can reach it — a public URL changes your threat model from "my mistakes" to "everyone's malice".
• Someone depends on it being up — staff who cannot work or customers who cannot buy while it is down.
• You could not afford to rebuild it — the moment it becomes an asset, its bus factor and maintainability start to matter.

What engineering adds that prompting cannot

Engineering is not slower typing or fussier style. It is a set of practices aimed at the failures a demo cannot reveal. Code review reads the generated code an attacker will eventually read. Tests pin behaviour down so next month's change cannot silently break this month's feature. Authorisation checks are verified per endpoint, not assumed. Secrets live server-side, database migrations are reversible, webhooks handle retries, and monitoring notices failures before customers do.

The failure modes these practices catch are boringly consistent in generated code: API keys embedded where any browser can read them, endpoints that check who you are but not what you are allowed to touch, queries with no limits that a growing table will eventually turn into an outage, and success-path-only integrations that fall apart on the first timeout. Every one is invisible in the demo. Every one is routine to catch in review.

The security data: how often generated code is quietly wrong

This is measurable now, and the numbers are uncomfortable. Veracode's GenAI code security research, which has tested more than 100 models on standardised code-generation tasks, found that roughly 45% of completions introduced a known security flaw — a pass rate stalled around 55–56% across successive snapshots, even as syntax correctness climbed past 95%. The code compiles more reliably than ever. It is not getting safer.

The breakdown by flaw type maps exactly onto what a demo can and cannot show. In Veracode's testing, models handled SQL injection and weak cryptography reasonably well, with pass rates of 83% and 87% — but collapsed to 15% on cross-site scripting and 12% on log injection. The categories where generated code fails hardest are precisely the ones no happy-path demo ever exercises. That is the vibe coding trap in a single statistic.

Maintainability is drifting the same way. GitClear's analysis of 211 million changed lines of code found duplicated blocks rose roughly eightfold during 2024, the first year on record in which copy-pasted code exceeded refactored code. And the practitioners closest to the output are the most sceptical of it: Stack Overflow's 2025 Developer Survey found 46% of developers actively distrust the accuracy of AI output against 33% who trust it, with around 3% reporting high trust. When the heaviest users trust it least, take the hint.

A worked example: what an invisible bug costs

Put numbers on the risk. A small store takes 40 orders a day at a $35 average — $1,400 a day of revenue through the checkout. A vibe-coded payment flow that mishandles webhook retries and silently drops one order in ten costs $140 a day, roughly $4,200 a month, and nothing on any screen says so; the orders simply never exist. A hardening pass on that flow, at our fixed prices, sits in the $500 to $1,500 range — the $500 end pays for itself in under four days of prevented losses, and even the $1,500 end pays back within eleven.

The data-leak version of the same arithmetic is worse, because the downside is unbounded: regulatory exposure, mandatory disclosure, and customer trust that does not return at any price. That is why the decision rule in this post is consequence-based rather than size-based. A tiny app that moves money or holds personal data is over the line; a large one that does neither is not.

The same feature, two ways

Here is the difference made concrete for one unremarkable feature — a customer places an order and pays. Both versions demo identically on a good day.

From prototype to production: what the crossing costs

The move across the line is cheaper than most founders fear, which is the most useful thing our delivery data has to say. Across PINCLER's 79 documented projects — every one fixed-price between $500 and $2,500 — the median build is $1,450 and ships in 13 days, and hardening or integration-focused work sits below that median: our integrations category runs to a median of $1,200 and 10 days. The full dataset is public at pincler.com/research/what-you-can-build.

For a working prototype, the engineering pass is usually the small end of bespoke software development, not a rebuild: review and fix authorisation on every endpoint, move secrets server-side, add error handling on the money paths, pin core behaviour with tests, stand up monitoring. A $1,000 budget reaches the starting price of 55 of those 79 documented projects — which is another way of saying that production readiness is no longer the expensive part of shipping software.

A five-question test before your next deploy

If you are unsure which side of the line an app sits on, score it honestly against five questions, one point each. Zero or one point: keep vibing — the software is cheap to lose and engineering it would be premature. Two points: get a lightweight review of authorisation, secrets and backups. Three or more: it needs proper engineering before the next real user touches it, whatever it looked like in the demo.

• Does money move through it now — or will it within three months?
• Does it store any data you would have to report if it leaked?
• Can anyone outside your own team reach it on a public URL?
• Would somebody's workday stop if it went down for 24 hours?
• Would rebuilding it from scratch take more than a weekend?

Use both: the workflow that actually works

The two approaches are not rivals; they are stages. Vibe-code the prototype in a weekend and put it in front of real users — that is the cheapest truth about demand you will ever buy. The moment the answer looks like yes, engineer it before scale arrives: review, tests, access control, monitoring, and a codebase someone can own.

That staging is roughly how we work internally, too — AI writes fast first drafts, senior engineers turn them into production systems. A hardening pass on an existing prototype typically lands between $500 and $2,500 fixed price depending on scope. If you have a vibe-coded app doing real work and a quiet worry about what is underneath it, a free 30-minute call is a sensible next step.