What is vibe coding and where are its limits

Short answer: Vibe coding is a way of building software where you describe the app in plain language and artificial intelligence writes the code for you. It is great for prototypes, internal tools and validating an idea. Once the app works with real users, data or money, though, it runs into limits in security, operations, maintenance and law. At that point you need to work the way real software development works.

Where vibe coding came from

The term was first used by Andrej Karpathy, OpenAI co-founder and former head of AI at Tesla, in a post on X on 2 February 2025. He described a way of working where you fully give in to the vibes and “forget that the code even exists”. He was mostly talking about weekend projects, not production software.

Within a year, one post turned into a phenomenon. Collins Dictionary named vibe coding its Word of the Year for 2025. Karpathy himself no longer recommends pure vibe coding for professional work and talks instead about “agentic engineering”, meaning work with AI agents under the control of an experienced developer.

How vibe coding works in practice

Instead of writing code, you have a conversation with AI. You describe what the app should do, the AI builds it, you try it out and say what to change. When something breaks, you paste the error message back into the chat. Often you never read the code at all.

The most common tools differ in who they are built for:

• Lovable, Bolt, Replit: build a complete web app from a description, including the database and login. They mainly target people who don't code.
• Cursor, Claude Code: work directly with code and are used mostly by developers. They can be used for vibe coding as well as for careful development where every change is reviewed.

Vibe coding is not the same as developing with AI

This distinction is key for companies. When AI writes code and an experienced developer reads it, tests it and understands it, that is not vibe coding. It is development with an AI assistant, and most development teams work this way today.

Vibe coding starts where nobody understands the code and the result is judged only by whether it “works”. That is fine for a prototype. For an app your customers use, what matters is the scope and impact of a possible mistake. For a new app with tens or hundreds of users, it can be reasonable to prioritise speed and product validation. A financial app or a large system needs much tighter control.

What vibe coding is good for

Vibe coding opened software building to people who used to have to hire a developer just to find out whether their idea made sense. It works best for:

• Prototypes and idea validation: you get a clickable version of the product in a few days and can show it to users or investors.
• Internal tools: simple tables, forms and dashboards for a few colleagues, with no sensitive data.
• Quick experiments: try out a new process or feature before the company invests in it.
• Communicating with developers: a working prototype tells developers more than a long brief.

Have a vibe-coded app and not sure whether to keep building on it? Book 30 minutes online with us. We will go through it and tell you what we would tackle first. Book an online call

Where its limits are

The problems with vibe coding usually don't show up in the prototype. They show up when real people start using the app.

1. Security

AI can write secure code if it gets the right brief and rules. Without them, it writes code that works, but not necessarily securely. In 2025, Veracode tested more than 100 language models on 80 coding tasks. In 45% of cases, the generated code contained vulnerabilities from the OWASP Top 10, the list of the most serious security risks for web applications. AI also doesn't know which security rules your app needs unless someone tells it, and a person without a technical background often can't. A bigger risk than the code itself, though, tends to be architecture and permissions: if an AI agent gets direct access to the production database, it can run a destructive operation that no amount of code quality will prevent.

2. Production operations and data

In July 2025, SaaStr founder Jason Lemkin was testing vibe coding in Replit. On day nine, despite an explicit instruction not to make changes, the AI agent deleted a live database with records of more than 1,200 executives and companies. Replit then introduced separate development and production databases.

The lesson is not “AI is dangerous”. The lesson is that production needs the basics experienced teams set up long ago: separate environments, backups with tested restores, approval for destructive steps and a person who reviews changes.

3. Maintenance and technical debt

The first version comes together fast. The trouble starts with the tenth change. Code that nobody understands is hard to extend, fix or hand over to another developer. Every new feature can break two old ones, and the app becomes fragile exactly when the business starts to depend on it.

That doesn't mean a person has to hold the whole codebase in their head. Today AI helps with understanding someone else's codebase and with maintenance too. What is usually missing is what gives AI direction: a functional specification, a description of expected behaviour, project context and control mechanisms.

4. Law: who owns code written by AI

Companies tend to ask this question late, often only when an investor shows up or the first dispute arises. Practice is still settling, and in the EU it is not yet settled where exactly the line for copyright protection of AI output lies. It pays to know at least a few general starting points:

• Copyright protects human creation, not machine output. Legally, AI is a tool. A prompt on its own is generally not considered creative work.
• Protection of purely generated code is uncertain. If no person contributed to it creatively, defending it against copying can be difficult. You can still use it commercially: copyright protection and the right to use code are two different things.
• AI tool terms are not copyright. When a provider says the outputs belong to you, it only means the provider makes no claim to them. It doesn't protect you against third parties.
• Third-party licence risk. AI also learned from open source code under various licences. If it carries part of that code into your app, you may be infringing someone else's rights without knowing it.
• Protection rests on human input and contracts. What helps is demonstrable human input (architecture, structure, substantial changes), documentation of the development and contracts that protect the code as a trade secret.

Owning the code may not be your main protection against competitors anyway. With AI, a product's functionality can be copied without access to the original code, so a stronger position comes from know-how, data, a good specification, distribution and the ability to keep developing the product.

The legal situation around AI is changing fast. For a product your business depends on, it is worth discussing the specific setup with a lawyer.

Then there is personal data protection. Anyone who pastes customer data into a public AI tool is already dealing with GDPR.

When vibe coding is enough and when it isn't

You don't have to throw away what you have built. A prototype is valuable because it shows what the product should do. What matters most is the impact of a mistake: who it affects, how big it is and whether it can be undone.

Vibe coding is enough when:

• Only you or your team use the app. A bug slows down a few colleagues, not customers.
• You are validating an idea. You need to find out quickly whether anyone wants the product, not run it long term.
• It doesn't handle sensitive data. No personal data, payments or data whose leak would hurt you.

It is time for an experienced team when:

• People outside the company will use the app. Customers expect it to work and to be secure.
• It handles personal data or money. Now it is about security, GDPR and liability.
• You need to keep developing it. Every new feature in code nobody understands raises the risk that something breaks.
• The product is the company's main asset. For example because of investors, who will ask who owns the code and how it is built.

This is not a move from AI back to manual development. AI is used in both cases. What changes is the level of control and trust. The bigger the impact of a mistake and the harder it is to undo, the more thorough the review of architecture, permissions and results has to be. A backup can sometimes save a bad database write. Money sent to the wrong place usually can't be recovered.

If you recognise yourself in the second list and nobody in the company understands the code, it is time for a review. You will find a concrete approach in our checklist for getting an AI-built app ready for real users.

If the second list sounds like you, send us a few sentences about your app. We will get back to you with how we would approach it. Send an inquiry

How we work with vibe-coded products at MeguMethod

We see vibe coding as a good start, not a problem. At MeguMethod we have been building apps since 2014, and over the past year we have seen the first version increasingly being built by the client, not by us. That is why we added App as a Service to our custom development: we build the first version of the app including architecture, tests and deployment rules, hand over the code and tools, and you make further changes with AI yourself. Every change is checked by automated review and by our engineers before it goes live, so vibe coding stays fast and the app stays secure.

For us, AI doesn't start at writing code. We already use it for product and technical specification of requirements, for example during joint video sessions. Each project also has rules for AI: architecture, limits, guardrails and constraints. That keeps code from different AI sessions and different developers readable and consistent. The difference from unmanaged vibe coding is not whether AI is used, but the quality of the specification, context and rules.

The model has limits and we say so upfront. It works best for clearly defined apps: internal tools, customer portals, your own sales channels. A system for hundreds of thousands of users or a critical part of the business needs a dedicated development team. And someone in the company has to want to develop the product. It doesn't have to be a developer. It can be a product manager, a marketer or someone from operations. How App as a Service works

Next step

Want to know what your app is missing before production? Go through the readiness checklist for real users, see how App as a Service works, or book 30 minutes online.