You described the app to an AI model on a Thursday. By Friday, it worked on your machine. A month later, 12 people use it. It reads the live customer table with an admin key, and nobody else knows how it is put together.
That is vibe coding, and the first two days of it were the right call. This piece covers what it is, where it fits, and what has to happen before the second month.
What vibe coding is
Vibe coding is building software by describing it to an AI model in plain language and prompting again until the result looks right. Andrej Karpathy gave it the name in February 2025.
The output is real code, written by the model rather than assembled from drag-and-drop components. Nobody writes a specification, and often nobody reads the code. Vibe coding judges software by what appears on screen. What the code does underneath goes unexamined.
How it works in practice
The loop has four steps: prompt, generate, run, refine. You describe the outcome, the model writes code aimed at it, you try the result, and you describe what is still wrong. The description and the app tighten together with each pass.
Its strength is speed from a blank page. A working screen, a script that reshapes a CSV export, or a small app can appear in an afternoon. The model writes the boilerplate that usually slows a first version down. The trade is control. You accept code you did not write and may not fully understand.
Where vibe coding fits
It fits wherever being wrong is cheap, and the work is meant to be temporary:
A prototype that shows an idea to the people who will use it.
A one-off script that reshapes a dataset and is then deleted.
An experiment to learn whether an approach works at all, before anyone commits engineering time.
In all three, nothing downstream depends on the result. No live data passes through it, nobody has to maintain it, and throwing it away costs an afternoon.
A vibe-coded prototype also does something a requirements document rarely does. It shows, in working screens, what the person who runs the process needs. That makes it a better brief than most written specs, because people can react to it.
Where it stops being enough
The trouble starts when the prototype becomes the tool. It happens quietly: one colleague asks for access, then the team, then the month-end close depends on it. At that point, the app needs four things vibe coding rarely produces, because nobody asked the model for them.
Auth
Who can sign in, and what can each person do? A vibe-coded app often has a shared password, or no login at all behind an unlisted URL. A production app signs people in through the company's identity provider (Okta, Microsoft Entra ID, Google Workspace). Roles come from the directory, so leaving the company removes access.
Data
The quick version usually reads and writes the database with one all-powerful key. Nothing checks a value before it lands, and nothing records who changed what. A production app gets its own credentials with the narrowest access that works. It validates input at the point of entry and logs every write with actor, timestamp, and before and after state.
Deployment
It runs from a laptop, a personal cloud account, or an AI builder's free tier. There is no source control, no staging copy to test changes on, and no way to roll back a bad prompt. A production app lives in the company's repository and infrastructure, with a test environment and a release path someone other than its author can run.
Monitoring
Today, the first sign of a failure is a colleague's message. A production app reports its own errors to a named owner, and a failed nightly job raises an alert before anyone reads stale numbers.
Behind all four sits one more gap: the owner. The person who prompted the app is often the only one who can change it. They may not be able to explain the code either. That is a key-person risk with a deadline nobody has set. Cool demo. Now what? covers the full list in more depth, and the security and compliance checklist is the version your IT team will ask for.
Is vibe coding the same as low-code?
No, though the two now meet. Low-code started as drag-and-drop: apps assembled from prebuilt components. Retool's new app builder works with code instead. Its apps are React. You write them in the builder's own chat and code views, or in a coding agent such as Claude Code, and deploy them to Retool.
What Retool adds around that code is what a vibe-coded app is missing. It hosts the app, keeps version history, and connects to source control. Permissions are set on each data connection, so one rule applies to every app that uses it. Sign-in goes through the company's identity provider, actions are logged, and writes to live data can wait for approval.
That governance layer is the real value at company scale. The code can come from a person, a model, or both, and the same controls sit underneath every app. Vibe coding brings the speed. The platform brings the controls your security team has already approved.
What it takes to run the result
Before anyone opens the code, someone has to ask what the app is for. Who relies on it, and for which decision? What data does it touch, and who else depends on that data? What happens to the team if it is down on the last day of the month?
Those questions usually move the brief. A team that asks us to make the app production-ready often needs something one level down. It might be a reliable approval step, one place the numbers come from, or a handover that does not depend on one person. The answer shapes the build more than the generated code does.
Then we audit what was generated, together with the person who built it. They know the process better than anyone, and they stay the product owner: they set direction and make the final call. We bring the architecture, the production engineering, and the running of it, and we recommend a path with the reasoning behind it.
Our view
Use vibe coding for the first version, and do not let it run the business. We recommend it for prototypes because nothing turns a vague need into something people can react to faster. We recommend against leaving the result in place, because it becomes a production system nobody is accountable for. It has live data and real users, and no auth, audit trail, deployment path, or monitoring.
Keep the prototype. Rebuild the plumbing.
