# Vibe coding: apps that run, but don’t hold up

> AI writes good code, but it doesn’t design the architecture. That’s why vibe-coded apps make excellent prototypes and fragile products.

Simplix · ai, web-apps, architecture

In February 2025, Andrej Karpathy, one of the founders of OpenAI, described a new way of programming: you tell an AI assistant what you want, accept everything it writes, paste the errors back into the chat and “forget that the code even exists”. He called it **vibe coding**. The term caught on so fast that Collins Dictionary named it the word of the year for 2025.

The results are spectacular: in a few hours you have an app that looks good and has a login, forms and a data table. And yet many of these apps collapse once they meet real users. The reason isn’t the one most people expect.

## The problem isn’t the code

Today’s models write correct, clean code, often better documented than many programmers’ code. Ask for a function that validates a VAT number or calculates sales tax and you get a good one.

The problem is **architecture**: the decisions that don’t live in any single function, but in the way everything fits together.

- What does the data look like, and how will it grow over two years?
- Who is allowed to see and change each piece of information?
- Where does the app keep its state, and what happens when two users change the same thing at once?
- What happens when an external service (payments, email, shipping) doesn’t respond?
- How are backups made, and how do you restore one?

In vibe coding, every request solves a local problem: “add an export button”, “fix this error”, “add an admin page too”. The assistant sees the current request and part of the code, not the big picture. Nobody remembers why a decision was made three days ago, and nobody checks whether the new piece fits with the rest.

The numbers show it too. GitClear analyzed over 200 million changed lines of code and found that, with AI assistants, duplicated code blocks multiplied several times over, while refactoring (reorganizing existing code) dropped by almost 40%[^1]. In other words, new code keeps being added instead of building on what already exists. Every copy is a future bug fixed in one place and forgotten in another.

> **Why AI doesn’t “see” the architecture**
>
> A 2025 METR study, with experienced programmers working on large projects they knew well, found that AI made them 19% slower, although they believed it had made them 20% faster[^2]. The researchers’ explanation: AI struggles more where standards are high and there are many **implicit requirements**, things a person learns over time and that aren’t written down anywhere.

## “It runs” doesn’t mean “it works”

A vibe-coded app is usually tested by its author, on the happy path: fill in the form correctly, click the right button, see the right result. Everything looks done.

Production is something else:

| In the demo | In production |
| --- | --- |
| one user, the author | hundreds of users, at the same time |
| a little test data | lots of real data, sometimes wrong |
| everyone means well | someone will try to see other people’s data |
| external services always respond | payments, email and APIs go down |
| if it breaks, you start over | if it breaks, you lose customers and data |
| it runs on your computer | it has to run for months and years, with updates |

In the 2025 Stack Overflow survey, two thirds of developers said their main problem with AI is solutions that are “almost right, but not quite”[^3]. A programmer recognizes “almost right”. Someone who vibe codes, by definition, doesn’t look at the code.

## What happened in practice

**User data in plain sight.** In 2025, a researcher checked 1,645 apps from the public showcase of Lovable, one of the most popular vibe coding platforms. In 170 of them, one in ten, anyone could read or change the database without logging in: emails, phone numbers, payment details, access keys for other services[^4]. The apps worked perfectly. Nobody had simply thought about who is allowed to see what.

**A deleted database.** In July 2025, the founder of SaaStr documented a 12-day experiment with Replit’s AI agent. On day nine, although he had explicitly told it not to change anything, the agent deleted the database with more than 1,200 records, then claimed it couldn’t be recovered[^5]. The data was eventually restored from backups. Replit later introduced automatic separation of development and production databases, exactly the kind of architectural decision that was missing.

**Insecure code from the start.** Veracode gave over 100 AI models programming tasks with a secure and an insecure option. In 45% of cases, the models chose the insecure one. Larger models didn’t do significantly better[^6].

> Vibe coding full web apps today is kind of messy and not a good idea for anything of actual importance.

That conclusion comes from Karpathy himself, after building MenuGen, a real app 100% written by AI. The local version was an “exhilarating and fun escapade”, but turning it into a public app with authentication, payments and hosting was “a bit of a painful slog”. He felt 80% done, but it was closer to 20%[^7].

## You don’t fix a foundation by adding a floor

![The Leaning Tower of Pisa](https://www.simplix.ro/assets/images/blog/vibe-coding-prototip-vs-productie/turnul-din-pisa/turnul-din-pisa-1200.webp "The Tower of Pisa started leaning in 1178, when it had only two floors. Photo: PaestumPaestum, Wikimedia Commons, CC BY 4.0")

The Tower of Pisa was started in 1173, on a foundation only three meters deep, in soft soil. It started leaning after the second floor. The builders carried on anyway, for almost 200 years, and tried to compensate by building the upper floors slightly crooked.

The tower still stands today. But by 1990 the lean had reached 5.5 degrees and it had to be closed. Eleven years of work followed, with 870 tonnes of lead counterweights and careful soil extraction under one side, to bring it back to about 4 degrees. It still leans[^8].

An app built without architecture is like the tower: it works, but every new floor adds weight to a foundation that wasn’t designed for it. Every fix touches three other places, because there is no clear structure saying where one part ends and another begins. That’s why it is usually cheaper to rewrite the app from scratch, on a sound foundation, than to “fix” it.

## Where vibe coding shines: software for yourself

None of this means vibe coding is useless. Quite the opposite: it is extraordinary for **software that only you use**.

In 2020, writer Robin Sloan built a messaging app just for his family and called it “a home-cooked meal”[^9]: it doesn’t have to serve a full restaurant, it just has to please the people at the table. A personal tool is the same:

- one person uses it, and they know exactly what they want from it;
- you are both the user and the tester: if something is wrong, you notice right away;
- the data is yours and usually never leaves your computer;
- if it breaks, you rebuild it in ten minutes; nobody loses money.

A script that renames your invoices, a sheet that adds up a project’s costs, a small dashboard that pulls data from three places, a prototype you show your colleagues: here vibe coding saves whole days. The difference appears when the same program has to serve people you don’t know, with data that isn’t yours.

## How to use an AI-built prototype

A vibe-coded prototype can be the best brief you bring to a development team. It shows what you want more clearly than any document. Just don’t mistake it for the product.

1. **Build the prototype.** Try the idea, show it to people, see what they like and what they don’t.
2. **Keep it as a specification.** Its screens, flows and rules say exactly what needs to be built.
3. **Design the architecture.** Data, access rights, security, backups, integrations and growth are decided before the code, not after.
4. **Build the product.** With AI as a tool, but with people who understand what they are building, review every piece and answer for the result.

AI assistants are excellent tools in the hands of someone who knows what they are building. The problem only appears when that someone is missing.

Do you have a prototype that runs and want to turn it into a real app?

[See how we build web apps](https://www.simplix.ro/en/services/web-applications/)

[^1]: GitClear, [AI Copilot Code Quality 2025](https://www.gitclear.com/ai_assistant_code_quality_2025_research): 211 million changed lines of code between 2020 and 2024.
[^2]: METR, [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), July 2025: 16 developers, 246 real tasks.
[^3]: Stack Overflow, [2025 Developer Survey](https://survey.stackoverflow.co/2025/ai): over 49,000 respondents.
[^4]: [CVE-2025-48757](https://nvd.nist.gov/vuln/detail/CVE-2025-48757): missing data access policies (RLS) in generated apps. Lovable disputes the classification, considering data security the responsibility of each app’s author.
[^5]: [AI Incident Database, incident 1152](https://incidentdatabase.ai/cite/1152/).
[^6]: Veracode, [2025 GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/), July 2025.
[^7]: Andrej Karpathy, [Vibe coding MenuGen](https://karpathy.bearblog.dev/vibe-coding-menugen/).
[^8]: [Leaning Tower of Pisa](https://en.wikipedia.org/wiki/Leaning_Tower_of_Pisa), Wikipedia.
[^9]: Robin Sloan, [An app can be a home-cooked meal](https://www.robinsloan.com/notes/home-cooked-app/), 2020.