Vibe Coding: Is It Good Enough for Business Software?

What is vibe coding?

It is programming by describing what you want and accepting whatever the AI writes, without reading the code.

Vibe coding is a way of building software where you describe what you want in plain language, an AI generates the code, and you judge the result by how it looks and behaves, not by how it is written. When something breaks, you paste the error into the chat and ask it to fix it. The code exists, but almost nobody reads it.

Andrej Karpathy, an OpenAI co-founder and Tesla's former head of AI, coined the term in a post on February 2, 2025. He described it as fully giving in to the vibes and forgetting the code even exists: accepting every change without reading the diffs, and asking for random tweaks until a bug goes away. He added that it was not too bad for throwaway weekend projects. In March 2025 Merriam-Webster listed it as a slang and trending expression, and Collins named it its 2025 Word of the Year.

Two things that get lumped together today are worth separating. One is vibe coding in the strict sense: accepting without reviewing. The other is programming with AI, which every serious development team does in 2026: using assistants to write faster, while reading, testing and answering for every line that reaches production. The tool can be the same; the difference is who understands the result.

What is it actually good for: prototypes and validation?

For testing an idea with real users before investing in building it properly, vibe coding is hard to beat.

Vibe coding shines when the goal is learning, not operating. A clickable prototype to show investors, a page to see whether anyone leaves their email, a demo to check with five customers whether the flow makes sense: in all of those cases, having something working in days rather than months is worth more than flawless code.

It also works well for small, low-risk internal tools: a dashboard that reads a spreadsheet, a form that sorts requests, a script that renames files. If it goes down, nobody loses money or personal data, and the person using it is the same person who built it.

For a founder, it is also an excellent way to walk into a conversation with a development team knowing much more clearly what they want. An AI-built prototype communicates better than twenty pages of requirements. What should not happen is that the prototype quietly becomes, without anyone deciding it, the system where your customers, payments and company data live.

Where does it break: security, data and maintenance?

It breaks where errors do not show on screen: permissions, other users' data, secrets and future changes.

The problem with vibe coding is not that the code does not work. It is that it works in the demo and fails where nobody is looking. Authentication seems fine because the login form appears, but the API answers anyone who knows the address. A customer's data can be read by changing a number in the URL. The payment gateway key ends up hard-coded in the browser bundle.

This is not a theoretical risk. In Veracode's 2025 GenAI Code Security Report testing, AI-generated code introduced risky security flaws in 45% of cases, and bigger models did no better. In May 2025, vulnerability CVE-2025-48757 was published: insufficient row-level security (RLS) policies in sites generated with Lovable let unauthenticated attackers read or write database tables. Lovable disputed it, arguing that each customer is responsible for protecting their own application's data, and that argument is exactly the point: the platform generates, but whoever ships is accountable.

The third front is maintenance. Code nobody understands is expensive to change. Every new feature requested from the AI can break another one, there are no automated tests to catch it, and as the project grows even the AI struggles to keep it coherent. What was fast in month one becomes slow by month six.

How do you know whether your AI-built app is ready for real customers?

If you cannot answer yes to every item on this list, the app is still a prototype, even if it already has users.

Before you open the app to customers, start charging or load personal data, go through these items. You do not need to code to ask the questions; you do need someone with technical judgment to verify the answers in the code, not just on screen:

• Authentication: login is handled by a proven provider, and every API route checks who is making the request, not just the screen.
• Permissions and RLS: one user cannot view or edit another user's data by changing an ID; in databases like Supabase, every table has row-level security policies enabled and tested.
• Secrets: no API key, password or token sits in browser code or in the repository; they live in server-side environment variables.
• Personal data: you know what data you store, where and why, and you can handle a deletion request as data protection law requires, such as Colombia's Law 1581 of 2012.
• Backups: the database is backed up automatically, and you have actually tested restoring one at least once.
• Tests: critical flows (sign-up, payment, permissions) have automated tests that run before every change.
• Payments: payment confirmation arrives through a verified webhook from the gateway, not because the browser says it was paid.
• Monitoring: you hear about a production error from an alert, not from a customer messaging you on WhatsApp.
• Dependencies: libraries are up to date, with no packages the AI made up and none that have been abandoned.

Rescue or rebuild: how do you decide?

Rescue what has sound structure and isolated flaws; rebuild when the problem lives in the data model or the permissions.

Not every AI-built prototype needs to be thrown away. Often the interface, the flows and much of the code are usable, and the work is closing gaps: moving secrets to the server, enabling access policies, adding tests and cleaning up deployment. Other times the data model is so poorly designed that every fix is a patch on top of another patch.

The decision comes after a short code audit, not before. These are the signals we look at to recommend one path or the other:

How do professional developers use AI?

We use AI every day; the difference is that a person reviews, tests and understands every line that reaches production.

At Beleaf we use AI assistants to write code, generate tests, review changes and document. They make us faster, and denying it would be as dishonest as claiming they replace technical judgment. What changes compared with vibe coding is the process around them: a person decides the architecture and data model before asking the AI for anything, every change goes through review, automated tests run before deploying, and permissions are enforced on the server.

That process matters more as the system gets more complex. In multi-tenant platforms, like the one we built for Kreatup, data separation between companies, sync with the online store and each user's role are exactly where a silent error costs you customers. None of those decisions can be left to the vibes.

If you already have an AI-built prototype and are thinking about launching it, the best investment is not a blind rewrite but a review against the checklist above. And if you are still validating the idea, keep vibe coding: it is the right tool for that stage. What matters is knowing when to switch tools.