Vibe coding: building an app in a weekend is real — and so are the five problems that come with it

The owner of a nail salon in Da Nang wants her own booking page instead of taking messages scattered across three chat apps. She cannot program, so she describes it to an AI tool in plain words: customers pick a service and a time, leave their name and phone number, and she sees the day's bookings. By the end of a Sunday afternoon the site works. Real customers start booking the following week.

Three weeks later a regular customer who works as a programmer sends a message: open the developer tools built into any browser, and you can see the name and phone number of every customer who has ever booked.

That story is a composite, but every part of it has happened for real — and both halves are true. Building a working app in an afternoon is a genuine achievement. The vulnerability is genuine too. This piece is about both, and about the line between them.

What vibe coding is

The term was coined by Andrej Karpathy — an AI researcher formerly at OpenAI and Tesla — in a post on 2 February 2025. He described a new way of making software: tell the AI what you want, accept the code it writes without reading it closely, paste any error back for the AI to fix, and more or less forget the code exists. By the end of that year, Collins Dictionary had named "vibe coding" its Word of the Year for 2025.

One detail from the original post is rarely repeated: Karpathy himself said the approach was not too bad for throwaway weekend projects. The person who named it drew its boundary from the start.

Two things that often get lumped together should be kept apart:

• Vibe coding — the AI writes, you do not read, and you judge by whether it runs.
• AI-assisted programming — the AI writes, but someone reads, understands, tests and takes responsibility for each change.

Most of the problems in this piece belong to the first. Not because AI writes bad code, but because nobody reading it is the defining condition of vibe coding — and the most dangerous bugs are the ones that do not stop an app from running.

The benefits are real

Start with what is valuable, because it is.

Testing an idea before spending money. Finding out whether customers would use a feature used to mean paying someone for a few weeks. Now a working version can be built in an afternoon, handed to ten customers to try, and the answer known before spending anything on real development. Killing a wrong idea early is the biggest saving vibe coding offers.

People who know the business can build their own tools. An accountant builds a page pulling figures from three Excel files. A warehouse manager makes a quick lookup screen. Small internal tools with one or two users, which were never big enough to make it onto the technical team's schedule.

Clickable prototypes instead of drawings. Handing a customer an interface they can click through works far better than a static design. Real feedback arrives earlier, before the design is locked.

One-off jobs. A script that renames thousands of image files, cleans a table exported from old software, merges two customer lists. Run it once, check the result by eye, throw it away.

These four cases share one thing: the cost of being wrong is low. A wrong prototype gets rebuilt. A broken internal tool means going back to Excel. A one-off script that produces something odd is noticed immediately. This is exactly the territory Karpathy marked out at the start.

Problem 1: running is not the same as secure

Veracode, a software security testing company, had more than 100 language models write code for 80 purpose-designed programming tasks, then tested the results. Its 2025 report found:

• 45% of code samples contained vulnerabilities from the OWASP Top 10, the list of the most common and dangerous classes.
• For cross-site scripting — an attacker planting a script that runs in the viewer's browser — the AI failed to defend in 86% of relevant cases.
• Java had the highest failure rate, at 72%.
• And most notably: newer and larger models were not more secure. The ability to write code that runs correctly kept rising over time; the ability to write secure code stayed flat.

The reason is easy to see. You ask for "a booking page where customers enter their name and phone number" — the AI does exactly that. You do not ask for "and this customer must not see other customers' bookings", because to you that is too obvious to say. But the model optimises for what was said. Security is the part of the requirement nobody puts into words.

Problem 2: the public key and the unlocked door

The vulnerability in the salon story has a name, a number, and has happened at scale.

Many vibe-coding tools build apps on Supabase, a popular database service. Its architecture works like this: the web page holds a public key and talks to the database directly from the browser. That key is designed to be visible to anyone. What protects the data is not the key but row level security rules set on the database: only the owner of a row can read it.

When those rules are missing, the public key opens everything. The vulnerability tracked as CVE-2025-48757 describes exactly this situation in apps built with Lovable: of 1,645 apps scanned, 170 — about 10% — exposed their databases, including user lists, phone numbers and in some cases payment information.

In fairness to the vendor: Supabase has since turned these rules on by default for tables created in its dashboard, and the flaw is a matter of configuration rather than a bug in Supabase. But the lesson stands: someone vibe coding does not know this layer of rules exists, so cannot notice when it is absent. The app keeps working perfectly — for everyone.

Problem 3: libraries that do not exist

Modern code leans heavily on other people's libraries. When AI writes code it chooses libraries too — and sometimes chooses ones that do not exist.

A study presented at USENIX Security 2025 had 16 models write 576,000 Python and JavaScript code samples, then checked the libraries they called against the real package registries:

• 19.7% of suggested libraries did not exist.
• 205,474 distinct invented library names in total.
• Open-source models invented far more than commercial ones: 21.7% against 5.2%.
• And the detail that makes this dangerous: running the same prompt ten times, 43% of invented names came back on all ten runs.

That repeatability turns a harmless error into an attack route. An attacker only has to ask AI common questions, note the invented library names, then register exactly those names with malware inside. Next time the AI suggests that name to someone else, the install command succeeds — and installs the malware. The attack already has a name of its own: *slopsquatting*.

Someone who does not read the code does not read the list of libraries either. An install command that finishes without an error is enough to carry on.

Problem 4: agents with access to real data

Newer tools do not just write code; they run commands themselves — creating tables, changing data, deploying. In July 2025, SaaStr founder Jason Lemkin described how Replit's AI agent deleted the production database of a project he was working on — despite his instruction to freeze all changes. The database held records on more than a thousand companies.

The data was eventually recovered through the platform's rollback feature. Replit's CEO called the incident unacceptable, and the company went on to separate development environments from production. That is the most telling detail: before the incident, testing and production shared a single database.

The lesson is not "AI is dangerous". It is three old principles that apply to any agent — human or machine — allowed to run commands: keep test environments apart from real data; grant only the access the current task needs; and keep a backup you have actually restored from. Vibe coding does not break these principles. It just means the user does not know they exist.

Problem 5: feeling fast is not being fast

In July 2025, METR — an independent research organisation studying AI capabilities — published a controlled trial: 16 experienced developers worked 246 real tasks on open-source projects they knew well, with each task randomly assigned to allow or forbid AI tools.

• Beforehand, they predicted AI would make them 24% faster.
• With AI allowed, they actually took 19% longer.
• Afterwards, they still believed AI had made them 20% faster.

This result needs reading within its scope. These were experienced developers on projects they knew intimately, using tools from early 2025 — METR itself later noted the result does not necessarily reflect current tools. For someone who cannot program building a new app, the comparison is between "can do it" and "cannot do it", and AI wins clearly.

What keeps its value is the gap between perception and measurement: nearly 40 percentage points, in the optimistic direction. When deciding whether to move a whole team to this way of working, measure the time from taking on a task to finishing it with checks done — do not ask people how it feels.

The line: three questions

So when is vibe coding the right choice? A simple test of three questions:

• Does the app touch money — taking payments, recording debts, calculating pay?
• Does it store other people's personal information — names, phone numbers, addresses, purchase history? Since 1 January 2026 this is also a legal obligation under Vietnam's Personal Data Protection Law.
• Will anyone besides you depend on it for longer than a few weeks?

If all three are no, vibe coding is a reasonable approach: fast and cheap. The salon at the top of this piece answered yes to the second question from day one.

If any is yes, the app is no longer a weekend project. AI can still write most of it — but at least one person who can read and understand the login, permissions and data-access code needs to do so before it goes live. That is the line between vibe coding and AI-assisted programming.

Before going live: six self-checks

If you already have an AI-built app about to be used by other people, here are six checks you can run now. The first four need a few commands — if those are unfamiliar, hand this list to whoever provides your technical support.

One — search for secret keys in the code sent to the browser. Everything in the build folder can be downloaded to a user's machine. After building, run:

• grep -rEn "sk_live_|service_role|AKIA[0-9A-Z]{16}|-----BEGIN" dist build .next/static out 2>/dev/null

Any result means a secret key is public. Revoke it immediately, issue a new one, and move the work that uses it to the server side. Also check whether a secrets config file was ever committed to source history: git log --all --oneline -- .env.

Two — try to read someone else's data. Create two test accounts. Log in as A, open one of A's records, then change the ID in the address to one of B's. If the app uses Supabase, call the table directly with the public key taken from the web page:

• curl "https://<project-id>.supabase.co/rest/v1/<table>?select=*&limit=5" -H "apikey: <public-key>"

If it returns other people's data, access rules are missing. This is the bug to fix before any other.

Three — verify every library. For each package the AI added, check it exists and when it was created:

• npm view <package-name> time.created

A package created a few weeks ago, with few downloads, matching exactly the name the AI just suggested, is a warning sign. Then run npm audit — or pip-audit for Python — to find known vulnerabilities in the real packages.

Four — test login and admin. Try opening admin pages without logging in. Try twenty wrong passwords in a row and see whether you get blocked. Try resetting the password for an email that is not yours.

Five — separate real data. Test data and customer data live in two separate databases. The AI tool only gets access to the test one. Never paste production database credentials into a chat with an AI.

Six — back up and restore once. Turn on automatic backups, then restore one to a separate place to be sure it works. A backup that has never been restored is only an assumption.

Closing

Vibe coding is neither a passing fad nor a threat. It is a tool with a very clear area of use — the area its namer marked out on day one: work where being wrong does not matter.

Inside that area, it lets ideas be tested faster and more cheaply than anything before. Outside it, its defining condition — nobody reads the code — becomes the main risk, because the most dangerous bugs are the ones that do not stop an app from running. The five problems in this piece share that trait: the app runs fine until someone looks closely.

The question worth asking is not whether to use AI to write code. It is: who will read the code that matters, before other people depend on it?

If you have built an app with AI and would like someone to review its security, permissions and data handling before it goes out — or to turn a prototype that has proved its worth into software built to last — get in touch or see KonexForge's Development capability.