The 60-second answer
Vibe coding — describing what you want to an AI and accepting most of the code — is the biggest shift in how web apps get built since the framework wars. In 2026 it is genuinely transformative for the first 70% of a product. It is also where a wave of stalled launches, security incidents and expensive rewrites is coming from. The short version:
- It wins at: prototypes, validation MVPs, internal tools, UI scaffolding, one-off scripts, and the boring boilerplate of any project.
- It breaks at: authorisation, multi-tenant data isolation, concurrency, error states, accessibility, performance under load, security, and regulatory handling (GDPR, CCPA, HIPAA, PCI DSS).
- The real cost: the demo is 10–20% of the work. A production-ready v1 on a vibe-coded base still lands at 60,000–180,000 EUR in US/EU terms — the AI saves discovery time, not engineering time.
- The winning pattern: AI writes the first draft and the boilerplate; senior engineers own architecture, security, data and the judgement calls. Teams who do this ship 20–40% faster. Teams who ship AI output unreviewed accumulate defects that erase the gain within a quarter.
What “vibe coding” actually means in 2026
The term was popularised by Andrej Karpathy in early 2025: building software by telling an AI what you want in plain language and steering by outcome rather than hand-writing each function. By mid-2026 it has become a mainstream way to start a project. The tools have matured fast:
- In-repo agents — Cursor and Claude Code work directly in a real codebase, reading and editing many files, running tests, and iterating against errors.
- Prompt-to-UI — v0 (Vercel), Lovable and Bolt turn a sentence into a working Next.js/React front end with components and routing.
- Full-stack scaffolders — the same agents wire up a database, an API and auth from a description in minutes.
The capability is real and it is not hype. A senior engineer with these tools is meaningfully faster. The trap is treating “it runs and looks right” as “it is ready for customers.” Those are two very different claims, and the gap between them is where this article lives.
Where vibe coding genuinely wins
Let’s be fair to the technique. There are categories where vibe coding is not just acceptable but the correct default in 2026:
- Prototypes and validation MVPs. When the goal is to learn whether anyone wants the thing, a disposable AI-built prototype answers the question in days, not weeks. Throwaway code for a throwaway hypothesis is good economics.
- Internal tools. An admin dashboard used by ten employees behind your VPN has a small blast radius. Ship it, iterate, move on.
- UI scaffolding. Generating the first version of a component library, a layout, or a form — then refining by hand — is faster than starting from a blank file.
- Boilerplate and glue. CRUD endpoints, type definitions, test fixtures, migration files, config — the repetitive 60% of any codebase that AI writes correctly and tirelessly.
- Exploration. Trying three architectural approaches in an afternoon to see which feels right, before committing a team to one.
If your project is one of these, much of this article’s caution does not apply. The risk begins the moment a vibe-coded artefact stops being disposable and starts holding real customer data.
Seven places AI-generated web apps break in production
These are the failure modes we see most often when a vibe-coded app meets real traffic, real data and real regulators. None of them show up in a demo. All of them show up in week three.
- Authorisation, not authentication. AI reliably adds a login screen. It routinely forgets that user A must not be able to read user B’s records by changing an ID in the URL. Broken object-level authorisation (IDOR) is the single most common defect we find in AI-generated apps.
- Multi-tenant data isolation. “Add organisations to my SaaS” produces a tenant column and queries that forget to filter by it somewhere. One missing
WHERE tenant_id = ?is a cross-tenant data leak and, in the EU, a reportable GDPR breach. - Concurrency and race conditions. AI writes read-modify-write code that works for one user and corrupts data under two. Double-spends, lost updates, duplicated charges — the bugs that only appear at load.
- Error and edge states. The happy path is flawless. The network timeout, the empty list, the half-submitted form, the expired token — frequently unhandled, so the app shows a blank screen or a stack trace to a paying customer.
- Performance under load. N+1 queries, missing indexes, unbounded result sets, no caching. Fast with ten rows, unusable with a million. AI optimises for “works,” not “works at scale.”
- Security hygiene. Secrets committed to the repo, SQL built by string concatenation, missing CSP and security headers, dependencies with known CVEs, overly permissive CORS. Each is a one-line fix a senior engineer catches and AI happily ships.
- Accessibility and compliance. Generated UIs miss WCAG 2.2 AA basics — keyboard traps, missing labels, poor contrast. In the EU the Accessibility Act (EAA) made this a legal baseline in 2025; in the US it is ADA exposure.
The 70% problem — the last mile that isn’t
There is a pattern so consistent it deserves a name. AI gets you to roughly 70% of a working product astonishingly fast. The trouble is that the remaining 30% is not the last 30% of the work — it is most of the work, and it is the hard part.
The first 70% is features that demo well. The final 30% is everything that makes software trustworthy: the authorisation matrix, the data model that survives contact with real usage, the test suite that lets you change code without fear, the observability that tells you what broke at 3 a.m., the performance budget, the security posture, the accessibility, the compliance paperwork. This is precisely the work that requires judgement, system-level thinking and experience — and precisely where today’s AI is weakest without a senior engineer steering every step.
Worse, the 70% is often built on assumptions that the 30% invalidates. A data model that ignored multi-tenancy, an auth approach that does not scale to roles and permissions, a front end with no error boundaries — fixing these late means partially rewriting the comfortable 70% you thought was done. This is why “we’re almost there” can last for months.
The real cost of shipping a vibe-coded app
The dangerous mental model is “the AI built it in a weekend, so finishing it is a small job.” The honest accounting is the opposite. Treat the prototype as 10–20% of the total effort.
A demo that took a weekend typically needs 8–16 weeks of senior engineering to become a launchable product: a real data model, an authorisation matrix, a test suite, observability, security hardening, accessibility, CI/CD and load testing. In US and EU budget terms, a production-ready v1 built on a vibe-coded base usually lands between 60,000 and 180,000 EUR depending on scope — the same range as a hand-built MVP. See our breakdown in how much an MVP costs in 2026.
What the AI genuinely saves is discovery time — the weeks spent deciding what to build and validating it with users. That is real value. It does not save the engineering required to make the thing safe, fast and maintainable. Founders who budget as if it does are the ones who run out of runway at 80% “done.”
| Phase | Vibe coding | Senior engineering |
|---|---|---|
| Working demo / prototype | Hours–days | Reviews scope, keeps product decisions |
| Data model & multi-tenancy | Often wrong | Designed for isolation and scale |
| Auth & authorisation | Login only | Roles, permissions, object-level checks |
| Tests & CI | Sparse or absent | Coverage on critical paths, gated CI |
| Security & compliance | Ad hoc | OWASP, headers, GDPR/CCPA by design |
| Performance & observability | Untested at load | Budgets, indexes, RUM, alerting |
Production-readiness checklist for AI-generated web apps
Before you put a vibe-coded app in front of real users, walk this list. If you cannot tick every box, you have a prototype, not a product.
- Authorisation matrix — every endpoint and every record access checks who is allowed. Test the “change the ID in the URL” attack explicitly.
- Tenant isolation — if it is multi-tenant, prove that no query can return another tenant’s data. Postgres row-level security or an enforced scoping layer, not discipline alone.
- Secrets — nothing sensitive in the repo or client bundle; secrets in a manager; history scrubbed if anything leaked.
- Input handling — parameterised queries everywhere, validation on every input, output encoding to stop XSS.
- Error states — timeouts, empty states, partial failures and expired sessions all handled with a sensible UI.
- Tests on critical paths — auth, payments, data writes covered, running in CI, blocking merges on failure.
- Performance budget — Core Web Vitals (LCP < 2.5s, INP < 200ms, CLS < 0.1), no N+1 queries, indexes in place, load tested.
- Accessibility — WCAG 2.2 AA: keyboard, screen reader, contrast, labels. EAA (EU) and ADA (US) baseline.
- Observability — structured logs, error tracking (Sentry), real-user monitoring, alerts on the paths that matter.
- Compliance — GDPR/CCPA data handling, consent where required, DPAs with vendors, a defensible data-deletion path.
How senior teams actually use AI in 2026
The takeaway is not “don’t use AI.” The opposite — the teams winning in 2026 use it aggressively, with discipline around it. The workflow that works:
- AI writes the first draft. Boilerplate, components, CRUD, tests, refactors — let the agent do the typing.
- A senior engineer owns the architecture. Data model, auth design, service boundaries, tenancy strategy — decided by a human before the AI fills in the body.
- Every line that touches auth, data or money is read. The review bar does not drop because a machine wrote it. If anything, it rises — AI writes plausible, confident, wrong code.
- Typed everything. TypeScript end to end, schema-validated boundaries. Types catch a large share of AI mistakes for free.
- Tests and CI as the safety net. Evals for AI-assisted changes, gated CI, no merge on red. The tests are how you trust code you did not write by hand.
- Security and accessibility in the definition of done — not a later ticket.
Done this way, AI is a genuine 20–40% accelerator on real codebases. The acceleration comes from removing the typing and the boilerplate, not from removing the engineering judgement. That is the part you are paying a senior team for — and the part that keeps your launch from becoming a breach notification. It is exactly how we build on web application development engagements.
When to keep the prototype and when to rewrite
A vibe-coded prototype is not waste — even if you rewrite the code. The two things worth keeping are almost always the product decisions (what screens exist, what the flows are, what users responded to) and the proof that the idea works. Treat the prototype as an executable spec.
Keep and harden the code when: the architecture is sound, the data model survives scrutiny, and the gaps are additive (tests, error handling, observability). Rewrite the foundations when: tenancy or auth were never designed in, the data model fights the product, or security review turns up systemic issues. In practice most production engagements are a hybrid — keep the front-end product layer, re-engineer the data and auth core. The decision should be made deliberately by someone who has shipped production systems, not by momentum.
FAQ
What is vibe coding?
Building software by describing what you want to an AI tool (Cursor, Claude Code, v0, Lovable, Bolt) and accepting most of the generated code without reading every line. Coined by Andrej Karpathy in early 2025. Excellent for prototypes; risky as the only discipline behind a production system.
Can you ship a vibe-coded app to production?
Yes, but rarely as-is. AI gets you ~70% of the way fast; the remaining 30% — authorisation, multi-tenancy, concurrency, errors, accessibility, performance, security, GDPR/CCPA — is where production lives and where AI is weakest without a senior engineer. Keep the product decisions, re-engineer the foundations.
Is vibe coding safe for a real business?
For internal tools and validation MVPs, yes. For anything storing customer data, taking payments or carrying regulatory exposure, unreviewed AI code is a liability — missing authorisation checks, leaked secrets, unparameterised SQL and cross-tenant leaks are the common incidents. A senior review pass and real tests are non-negotiable.
How much does it cost to take a vibe-coded prototype to production?
Plan for the prototype to be 10–20% of the total. A weekend demo usually needs 8–16 weeks of senior engineering — 60,000–180,000 EUR in US/EU terms, the same range as a hand-built MVP. The AI saves discovery time, not engineering time.
Which AI coding tools are best for web development in 2026?
Cursor and Claude Code for agentic in-repo work; v0, Lovable and Bolt for prompt-to-UI. The tool matters less than the discipline: typed code, tests, code review and evals.
Will AI replace web developers in 2026?
No — it changes what they do. AI handles the first draft and the boilerplate; seniors own architecture, security, data and judgement. Teams that adopt it well ship 20–40% faster; teams that ship it unreviewed accumulate debt that erases the gain within a quarter.
Ship the prototype for real
We take AI-generated web apps from impressive demo to production-grade product — auth, multi-tenancy, performance, security and GDPR/CCPA — for US and EU teams. Senior engineers only, honest scoping, no juniors hidden behind invoices.
Last updated 7 June 2026.
