Vibe coding grew up. Where it still breaks

Andrej Karpathy coined "vibe coding" in February last year, describing a way of building software where you tell an AI what you want, accept what it writes, and mostly stop reading the code. By November, Collins Dictionary had made it its word of the year.

Since then the tools have become much better. Claude Code, OpenAI's Codex and Cursor can work for long stretches on their own, write features across dozens of files, run the tests and fix what fails. A founder with no engineering background can describe a simple booking app and be clicking through a rough version the same day.

We build with these tools every day, and they have changed how fast we deliver. They have also made one gap more visible than ever: the gap between software that works in a demo and software that is safe to put real customers on.

What it is good for

• Prototypes for investors and early users. Something clickable and real beats a slide deck.
• Testing an idea before spending serious money. If nobody uses the rough version, the polished one will not save it.
• Internal tools for a small team, where the users are known and the data is not sensitive.
• One-off scripts and automations: cleaning a spreadsheet, moving data between two systems, generating reports.
• Giving a developer a precise brief. "Build it like this, but properly" is a far better starting point than a written spec.

Where it breaks

The problems rarely show in a demo. They show when strangers, real money and real data arrive.

Security is the big one. In January, an AI agent social network called Moltbook went viral. Within days, security researchers at Wiz found its database wide open: a key sitting in the code that every visitor's browser downloads, and no access rules on the database behind it. Anyone could read and change the data, including about 1.5 million API tokens and tens of thousands of email addresses. Wiz said it keeps seeing the same pattern, secrets in front-end code and missing database permissions, in vibe-coded apps. Moltbook fixed it within hours of being told. Nobody can say for certain who else had looked before then.

Mistakes in how software is shipped catch out experienced teams too. At the end of March, Anthropic accidentally published the source code of its own Claude Code tool in a software package, through a packaging error. No customer data was involved. It is a reminder that the steps around the code, such as what gets published, where and with which settings, need as much care as the code itself.

The other gaps are less dramatic and more common:

• Logins and permissions that work for the founder's account and fail for the second user, or let one customer see another's data.
• Payments that succeed in testing and break on refunds, failed cards or currency changes.
• No backups, no error tracking and no way to tell that something has gone wrong until a customer complains.
• Code that nobody understands, so every change takes longer than the last and fixes start breaking other things.
• App store rejections, missing privacy policies, and personal data handled in ways India's DPDP rules or UAE data protection law would not allow.

The checklist before real users

If you built something with AI and want to launch it, have someone experienced check these before the first real customer signs up:

1. No secrets or keys in anything the browser or app downloads.
2. Database access rules set so each user can only see and change their own data, and tested with two accounts.
3. Login, password reset and account deletion working properly.
4. Payments tested for the unhappy paths: declines, refunds, duplicate clicks.
5. Daily backups that someone has actually restored once.
6. Error tracking and uptime alerts going to a person.
7. Dependencies up to date and scanned for known vulnerabilities.
8. A privacy policy that matches what the app really collects, and consent where the law needs it.
9. The code in a repository you own, with a short note on how to run and deploy it.

How we use these tools

We let AI write a large share of the code and we read what matters: anything touching money, personal data, permissions or other systems. A person reviews every change before it ships.

If you have a vibe-coded prototype that people like, that is a good position to be in. You have proved the idea and you know what to build. The next step is not to throw it away. Have it reviewed, keep what is sound, and rebuild the parts that will carry customers' data and money.