Vibe coding means creating software by describing what you want in everyday language and letting AI write the code. You try the result and request changes, often without understanding every edit underneath. Within our guide to AI automation, this concerns how software is built; our explanation of no-code versus custom development covers the choice between existing building blocks and developing your own solution.
What exactly is vibe coding?
People use the term for different ways of working. In its strict sense, you mainly watch whether the software behaves as expected while the code stays largely out of sight. In reviewed AI-assisted development, someone reads and tests the changes and understands what’s being delivered. Google Cloud draws this distinction in its explanation too.
That’s why “built with AI” tells you little about quality. A developer may use AI while carefully reviewing every change. Someone else may accept everything in the same tool as soon as the on-screen button works. Their responsibility differs even if the software they use has the same name.
You don’t have to ban the term to use the approach sensibly. Agree what you’re making: a demonstration to discuss an idea, a bounded trial or software that colleagues need to rely on every day.
How do you turn a description into a prototype?
Consider a hypothetical app for borrowing tools. You want to see which equipment is available and who has reserved it. Start with fictional records and a limited request, such as:
Create a prototype where an employee can browse tools and submit a reservation request. An administrator accepts or declines the request. Use only fictional data and don’t send real messages.
That’s a better starting point than “build a complete business platform”. You can now judge whether the screens make sense and whether the sequence fits the work. Perhaps a reservation is useful only if it shows the collection location. You discover that by asking a colleague to complete the task without explaining every field as they go.
Then make a focused change and try the same task again. A new button may affect an existing path. Save a usable version before larger changes and record which rules must continue to hold.
The prototype can be incomplete. Provided you’re clear about what it demonstrates, that doesn’t make the work wasted. Screens and conversations can help you define a smaller, more specific first release later. Our guide to building an MVP discusses that scope decision.
Where do Lovable, Bolt and Cursor fit?
These names often appear together in lists of vibe coding tools, but their working environments differ. Lovable and Bolt can build an application from a description. Cursor provides an environment for working with code and asking an AI assistant to make changes. None of those descriptions certifies the quality of the finished app.
| Tool | Documented starting point | A question to ask when choosing |
|---|---|---|
| Lovable | Build web apps using natural language, with editable code and Git synchronisation | How will you review code, data and connected services outside the building environment? |
| Bolt | Generate apps from prompts, supporting JavaScript web technologies | Does the technology suit whoever will maintain the app? |
| Cursor | An AI assistant that searches code, edits files and runs commands | Who will review changes and investigate a fault? |
Sources: Lovable documentation, Bolt documentation and Cursor Agent. Functions checked in September 2026; consult the current documentation before choosing.
A business owner may value an immediate app preview. A technical team might care more about making focused changes to existing code. Don’t choose solely on the best first demo. Try an amendment, a failed step and a handover to someone who wasn’t part of the initial conversation with the AI.
Why isn’t a successful demo a production test?
Our tool-borrowing app looks ready when you can submit and approve a reservation. But what happens when two colleagues request the same equipment at almost the same time? Or when someone tries to change another person’s reservation?
Those questions concern your application’s behaviour. A test should define what ought to happen in that situation. “The AI says it’s fixed” isn’t a test result. Perform the action and check its effect on stored records, including after signing in again.
What needs checking before you add real data?
Start with access rights. Signing in establishes who a person is; it doesn’t automatically determine which reservations they may view or change. OWASP recommends checking permissions on every request rather than relying on restrictions in the interface. A hidden button isn’t an access rule.
For the borrowing app, this means an employee shouldn’t be able to perform an administrator’s action through another route. Have that separation checked where the software reads and writes data. Test different roles, rather than using only the account that built the app.
Building platforms can help. Lovable documents security checks covering areas such as database policies and application code, with different scopes for its scans. Use their findings as evidence for your review. An empty warning list doesn’t demonstrate that your particular reservation rules are correct.
Also agree which data is actually needed, who can delete it and where errors are reported. Don’t copy a customer database into a trial if fictional records can answer the same question. Decide who will stop the trial if data becomes visible unintentionally or an action has the wrong effect.
Does exporting the code give you the whole application?
No. Code, stored data and external services are separate parts. Lovable’s Git synchronisation guidance explicitly says that cloning code doesn’t bring the services it calls. The database contents aren’t included in that code copy, and running locally can still connect to the published app’s backend.
There’s a practical consequence: a test version on a different URL isn’t automatically a separate test environment. Establish which database and services it connects to before someone changes or deletes trial records.
Ask for more than a download during handover. You need to know how to start the app, which settings it requires, where data lives and which subscriptions remain active. Someone else should be able to follow the agreed process without guessing what the original prompt conversations meant.
Code ownership and technical independence are different questions too. Our explanation of code ownership and vendor dependencies covers why access to source code doesn’t resolve every other dependency.
Can you develop the prototype further or must you rebuild it?
That depends on an assessment of what exists. The tool used to create it isn’t, by itself, a reason to discard everything. Clear code organisation and functions that demonstrably work may provide a useful foundation. Conversely, substantial repair may be needed if changes have accumulated without anyone understanding how they fit together.
Ask the reviewer to explain what can be retained and why. Ask what remains unknown too. An offer to “just make it production-ready” says little if nobody has examined the data structure, roles and main user journeys.
A useful handover might describe:
- The task users can complete and which situations are deliberately outside scope.
- What has been tested, including problems found and what was done about them.
- Who reviews changes and who is available when the app fails.
- How to restore a code version and recover data, treating those as separate operations.
If we take a prototype further, we start with that assessment. A custom software development brief should describe what will be delivered and maintained. The code is and remains yours. Existing licences and services belong in the decision, so a handover involves more than moving files.
What does using vibe coding tools actually cost?
Costs start with the building tool, but don’t end there. Hosting, storage, external APIs and maintenance also belong to a running application. A free starting plan or trial account may suit exploring an idea; check its limits before making a team dependent on that offer.
Prompt count isn’t a good measure of the cost of a finished product. Sometimes another amendment is straightforward. Sometimes it changes the data structure and existing records need to change with it. Alongside the subscription, have the remaining work assessed: what still needs doing for the use you have in mind?
Keep learning and delivery budgets separate. A prototype showing that an idea doesn’t help serves a different purpose from an application that must be available every working day. Mix the two together and every quick demo looks cheap, while every necessary check afterwards looks expensive.
How do you actually get started?
Choose a question that a prototype can answer, such as whether employees can request a reservation without an explanation. Describe the intended behaviour, use fictional records and ask someone to complete the task. Capture what remains unclear, as well as what looks good.
Then decide whether to continue. Before everyday use, establish who understands the code, how rights and data are managed and who carries out maintenance. That gives the experiment a clear next step.
Want to know what it would take to move your prototype forward? Book a call and show us the task it can already handle.
