What is vibe coding?
Vibe coding is building software by describing what you want to an AI tool and accepting the code it writes, mostly without reading or reviewing it. You judge the result by clicking through the app to see whether it seems to work. When something breaks, you describe the problem and let the AI try again.
The term spread in early 2025, as chat assistants, AI code editors and browser-based app builders became able to produce a working app from a few prompts.
This article is for founders, product leads and operations managers who have seen a vibe-coded app work, or built one, and wonder whether it can carry part of the business, or whether a supplier's promise of AI-built software is safe. We use coding agents every day ourselves, so the question here is what happens around the AI: who reads the code, what checks it and who owns it.
Where it is a sensible choice
Vibe coding makes sense when the software is small, the stakes are low and the only person who depends on it is the person who built it. If it breaks, you lose an afternoon, and no customer data or money is involved. That covers a fair amount of useful work:
- Personal tools, such as a tracker for your own tasks or a calculator for a quote you prepare every week.
- Internal experiments that a few colleagues try for a week, on made-up or public data.
- An idea you want to try before investing in it. A first working version for yourself shows what the idea needs, which makes it easier to explain to a developer or supplier later.
- Throwaway scripts: a one-off data clean-up, a conversion between two file formats, a check you run once and delete.
- Learning how software fits together, by asking the AI to explain what it wrote.
Things change once other people depend on the tool: colleagues who use it every day, customers who log in, or personal data that belongs to someone other than you. Tools often reach that point gradually, without anyone deciding they should.
What breaks once real users and data arrive
Vibe-coded apps tend to break in the parts you cannot see by clicking through them: missing tests, security gaps, careless handling of personal data, and code nobody understands when something goes wrong. An app can look finished and still have all of these problems, because none of them shows up on the screen.
No tests
Nobody wrote down what the app is supposed to do, so nothing checks that it still does it. Each change gets tested by clicking around, and the paths nobody clicks, such as a cancelled order, a date at the end of the month or a form submitted twice, stay unchecked until a user hits them.
Security gaps
Three problems are common in code nobody has reviewed, and each one can be checked:
- Exposed keys: API keys or database passwords written into code that runs in the browser, where anyone can read them, or committed to a code repository.
- Missing access checks: the screen hides another customer's records, but the server returns them to anyone who changes an ID in the request. A hosted database whose access rules were never switched on has the same problem.
- Injection: text a user types goes straight into a database query or a prompt, so a crafted input can read or change data it should never reach.
Personal data and GDPR
Once the app stores names, email addresses or customer records, GDPR applies. You need to know what personal data it holds, where that data is processed, which suppliers handle it under what agreement, and how to delete a person's data when they ask. In a vibe-coded app, personal data can end up in logs, in prompts sent to an AI provider or in a hosting region nobody chose. This is general information and is not legal advice, so check your situation with your privacy officer or legal adviser.
Code nobody understands
When something breaks on a Monday morning, someone has to find the cause. If nobody has read the code, the only way in is to ask the AI again, and it may fix the symptom while changing something else. The person who built the app may have moved on, or never knew how it works inside.
Dependencies nobody tracks
AI tools add packages freely. Each one is someone else's code that needs updating when a security problem is found, and some are no longer maintained. AI tools can also suggest package names that do not exist, which an attacker can register and fill with malicious code. Without a list of dependencies, nobody knows when an update matters.
Running costs
Code that works for a hundred records can be slow and expensive with a hundred thousand. Typical causes are a query that loads a whole table to show one row, a database call for every item in a list, and a model call on every page load where one a day would do. The bills grow with use, often with no spending limit set.
Changes that break other features
Ask the AI to change the invoice layout and it may also rewrite the date handling the monthly report depends on. Without tests, a user reports the break days later. Every fix carries the same risk, so the app gets harder to change the longer it runs.
How agentic engineering differs
Agentic engineering is experienced developers building software with coding agents. The developer breaks the work into scoped tasks, writes a spec and tests, lets the agent write the code and reviews every change before it is merged. The developer owns the architecture and answers for what ships.
Both approaches use AI to write code, and both can be quick on the first day. We work this way on our own builds and client projects, and our article on how we ship SaaS with coding agents covers scoping, tests first and review in detail.
If a supplier tells you their software is built with AI, that says little about its quality either way. Ask who reviews each change before it is merged, which tests run automatically, and whether the code repository and hosting accounts are in your name.
How the two approaches compare
The main difference is who takes responsibility for the code. With vibe coding, you accept the AI's output when the app appears to work. With agentic engineering, a developer reviews it, tests check it and the team keeps a design it understands. That costs some speed at the start and keeps the software safe to change later.
| Aspect | Vibe coding | Agentic engineering |
|---|---|---|
| Who reviews the code | Usually nobody; the app is judged by clicking through it | An experienced developer reviews every change before it is merged |
| Tests | Rarely written, so problems surface when users hit them | Written for the flows that matter, often before the code, and run on every change |
| Security | Depends on what the AI happened to write | Access checks, secrets and dependencies checked in review and by automated scans |
| Who understands the system | Often nobody, including the person who wrote the prompts | The developers who designed the architecture, with notes and documentation in the repository |
| Speed on day one | Very quick to a first working version | Quick, with time spent up front on scope, specs and tests |
| Speed after six months | Slows down, because each change risks breaking something else | Holds up, because tests catch breaks and the code stays readable |
| A good fit | Personal tools, quick experiments, throwaway scripts and learning | Software that customers, colleagues or auditors rely on for years |
The two can follow each other. A founder can vibe code an idea to see whether it holds up, then have it rebuilt with review and tests once people depend on it. The first version still shows the screens, data and rules the real system needs.
What to do if your business runs on a vibe-coded app
If your business already runs on a vibe-coded app, you rarely need to throw it away. Find out what it does and what it touches, secure the data and keys, put tests around the flows that matter, and then decide part by part what to keep, refactor or rebuild. Work through the steps in this order:
- 01List what it does and who uses it. Write down each feature, who relies on it and what happens if it stops for a day. That shows where to start.
- 02Check where data and keys are stored. Find every API key, password and database connection, move them out of the code into a secrets store and replace any key that has been exposed. Note which personal data the app holds, where it is hosted and which providers receive it.
- 03Add tests around the flows that matter. Start with the paths that handle money, orders or customer data. Tests that record how the app behaves today let you change it without silently breaking those flows.
- 04Run a security review. Check that the server enforces access rules on every screen and API route, look for injection in forms and prompts, update or remove vulnerable packages, and confirm the logs hold no personal data they do not need.
- 05Decide per part whether to keep, refactor or rebuild. Parts that pass their tests and the review can stay. Parts that work but nobody can follow get refactored. Parts with a broken data model or no access control are often quicker to rebuild than to patch safely. Some may be better replaced by standard software, and our build or buy guide helps with that call.
- 06Put it in a repository you own, with deployment and monitoring. Move the code to a repository under your organisation's account, with automated deployment, backups, error alerts and more than one person with access, so the app no longer depends on one laptop or one person's AI account.
If the app is a tool only you use, most of this is more effort than it is worth. If customers or colleagues rely on it, an in-house developer can work through these steps, or you can hand them to an agency for custom software development. For a product you sell, our page on SaaS development describes the foundations to check first: tenant isolation, roles and permissions, and billing.
Questions about AI-written code
Is vibe coding safe?
Vibe coding is safe enough for tools only you use, with no personal data, money or customer access involved. Once other people or their data depend on the app, treat it as unreviewed software: have someone read the code, add tests and check for exposed keys, missing access checks and injection before you rely on it.
Can a vibe-coded app go into production?
Sometimes, after review, tests and a security check. Some vibe-coded apps do the right things and need work only on what the screen does not show: secrets, access rules, data handling, dependencies and monitoring. Others have a data model or structure that makes a rebuild the faster route.
Going live also means someone is responsible for updates, backups and fixes afterwards. Decide who that is before customers start using it.
Do professional developers use AI to write code?
Yes. Many professional developers use AI tools every day, from suggestions in the code editor to coding agents that take a whole task and return a change for review. What separates this from vibe coding is that the developer reads and tests what the AI produces and stays responsible for it.
Is agentic engineering just vibe coding with extra steps?
The AI part looks similar: someone describes a task and an agent writes the code. The extra steps are a spec, tests, review of every change and ownership of the architecture. They decide whether the software can still be changed safely a year from now.