Give an app-building tool a plain-language description, watch a first version appear, then ask for changes. That loop is the practical idea behind vibe coding. A product manager can sketch a customer portal; a founder can test a booking flow; a developer can ask an agent to wire up a feature. In each case, the person steers while software does more of the typing.
The speed is real. So is the distance between a convincing demo and a product people can safely depend on. “Vibe coding” describes a way of working, not a guarantee about what the finished app can handle.
What people mean by vibe coding
The term became widely known after AI researcher Andrej Karpathy used it in 2025. Since then, it has been applied to everything from quick experiments to full software teams using coding agents. Google Cloud’s overview is a useful starting point; the important distinction is what happens after the first prompt.
For a throwaway prototype, a builder may be comfortable accepting most of the generated code as-is. For a business application, a more responsible version looks familiar to any engineering team: describe the requirement, generate a change, run it, inspect the result, test edge cases, and revise. The AI can do a large share of the implementation. Someone still has to decide whether the implementation is correct.
It helps to separate the products from the working method. A hosted app builder and a coding agent in an existing repository can both accept prompts. One may set up a new project for you; the other works within decisions your team has already made.
The tools don’t all do the same job
Suppose you want a supplier to submit a delivery update and an employee to approve it. Starting from nothing, you need a form, stored records, two user roles, and somewhere to run the application. Starting inside an existing procurement system, you need a change that respects its identity service, data model, and release process. Those are different assignments, even if the screen looks identical.
For the first assignment, compare how builders handle the whole application. For the second, find out how an agent works with the repository and tests you already have. Several products now cover both kinds of work, so judge the actual workflow rather than relying on a category label.
What to try in each platform
The comparisons below draw on the products’ documentation, not a timed performance test. They suggest useful evaluation tasks; they are not a ranking. Features, included services, and commercial terms change, so check the current offering before committing.
Replit: try the whole application
Replit Agent works alongside the project’s code and running environment. It can set up a project, implement changes, run tests, and help prepare it for publishing. That gives a team somewhere to inspect the implementation as well as try the result. Database and third-party integrations can be part of the same project.
For a useful trial, build the supplier form described above and publish a test version. Submit a record, leave the page, and confirm it is still there when you return. Then sign in as the other role. Check the production data setup as well as Preview: Replit distinguishes development and production databases. This exercise tells you more about the proposed application than generating another landing page.
Lovable: check the handoff as well as the interface
Lovable builds full-stack web applications from conversational instructions and provides hosting and backend services. It also supports keeping the code in a connected repository. A product team can use it to revise an application flow while engineers examine what those revisions change.
If independent hosting is a requirement, test it during the evaluation. Lovable’s ownership and deployment guide distinguishes moving the front end from moving backend services and data. Copying a repository does not, by itself, migrate the database, stored files, or external-service configuration. Ask the receiving team to run the app and list what else it needs.
Bolt: get other people to use the prototype
Bolt combines browser-based building with a code view and preview. Its hosting options let you share a running application rather than send screenshots. That is useful when the next question is whether colleagues understand a workflow, not whether they like a mock-up.
Give the published test link to someone who did not write the prompt. Have them create an account, submit a record, and reopen it on another device. Review where the project stores that record and which services the deployed version uses. Then estimate ongoing usage, including any separate services; the cost of generating the app is not its entire operating cost.
v0: evaluate how generated work enters your project
v0 supports interface generation and full-stack applications, with deployment through Vercel. Describing it only as a UI generator misses part of the current product. Its documentation also describes opening a pull request for review, which matters to teams that want generated changes to go through their existing delivery process.
A sensible test is one complete feature: an edit form, its server-side validation, and the data update behind it. Have a developer review the resulting change. Check accessibility and error handling alongside the visual design. For an existing application, find out whether the generated components follow its conventions or introduce a second way of doing the same work.
Cursor: work with the code you already maintain
Cursor is an AI coding environment for working with a repository. A developer can use its agent to investigate and change code rather than begin with a new hosted application. Existing tests, internal APIs, and project conventions become part of the assignment.
Give it a contained change in a real codebase, such as adding a filter to an existing report. Review every changed file, including configuration and dependencies, and run the relevant tests yourself. A useful result should fit the project without requiring unrelated rewrites. This kind of evaluation needs a developer who understands what the code is supposed to do.
Google AI Studio: include the model’s behavior in the trial
Google AI Studio’s Build mode supports full-stack web applications, including a server-side runtime. It is worth evaluating when a Gemini-powered feature is central to the app—for example, extracting information from a document or answering questions about approved reference material. It is not limited to experimenting with isolated prompts.
Test an unreadable upload, a question the source material cannot answer, and a failed model request. Find out what the user sees and whether anyone can inspect the failure. Also check who pays for model calls, what usage limits apply, and what information is sent to the model. Those questions matter even when the surrounding app is small.
The first demo is the easy part
A polished screen can hide unfinished decisions. Try the paths that don’t appear in a happy-path demo: What happens if a user enters the wrong information? Can one customer see another customer’s records? Does a form fail clearly when a service is unavailable? Can someone recover an account, export data, or remove it?
For an application that handles business or customer information, review authentication, access controls, data storage, secrets, logging, and backup and recovery plans. Test the application on the devices and browsers people will actually use. Ask how changes will be reviewed, monitored, and maintained after the original builder has moved on.
A review should produce evidence: a permission test, a successful restore, or a recorded failure and recovery. Asking the same agent whether its own code is secure is not an independent check. The requirement to verify the result applies to developer-written code too.
Where the risks increase for B2B applications
A team lunch planner and a customer billing portal may take roughly the same effort to demonstrate. They should not take the same route to production. For a B2B business, the useful question is not “Can AI build this?” It is “Who is affected if this is wrong, unavailable, or exposed?”
Internal use is a starting point, not a security exemption
An internal tool can be a sensible first project when the audience is small, the data is low sensitivity, and mistakes are easy to reverse. Think of a meeting-room directory, a campaign-planning board, or a dashboard reading approved, non-sensitive data. If it goes down for an afternoon, people can use the old process.
But “internal” says who uses an app, not how much risk it carries. A payroll tool, a production scheduling system, or an automation with permission to update an ERP can cause serious damage without ever being customer-facing. A useful boundary is whether the tool can spend money, change important records, reveal confidential information, or stop people doing their jobs. If it can, professional review belongs in the plan.
Customer-facing apps carry obligations beyond the screen
External B2B applications introduce customer data, contractual commitments, and a wider range of users and permissions. A supplier portal may need account provisioning, approval chains, accessible interfaces, audit records, and an agreed recovery process. A customer may also require SSO, data residency, or evidence of security controls before allowing its employees to log in.
Those requirements need to be designed and verified. Adding a login page is not the same as getting authorization right. A button hidden in the interface does not prevent a user from calling the underlying API. Nor does a working demo establish that the application can meet an uptime commitment or recover from a failed deployment.
Multi-tenant apps: test the download, not just the dashboard
Consider two customers using the same supplier portal. Each sees only its own orders in the dashboard. That looks correct, but it proves little about the export button. Does the download request enforce the same access rules? Can a user change a record ID in a request and retrieve the other customer’s invoice?
Tenant isolation means keeping each customer’s data and operations separate wherever the application handles them. An engineer needs to trace the boundaries through database queries, file storage, search, caches, and background jobs. A tenant column in a table is not enough if one query ignores it.
A practical review uses two test organizations and attempts cross-tenant reads and writes. It also checks exports and job retries. Keep those tests in the release process; a later prompt that adds a convenient reporting feature must not undo the isolation model.
Mission-critical systems: decide what happens after a partial failure
Take an order that triggers a payment, reserves stock, and creates an accounting entry. The payment succeeds, but the response times out. The application retries. Without a rule that recognizes the original operation, the customer may be charged twice. Generating each integration separately does not settle how the complete transaction should behave.
This is where architectural decisions become unavoidable. Idempotency prevents a retry from repeating an action that already succeeded. Reconciliation identifies records that no longer agree. A compensating operation may reverse completed work when a later step cannot finish. Queues also need rules for duplicate events, out-of-order messages, and jobs that repeatedly fail.
The team must decide which records are authoritative, what can be retried, what needs a human intervention, and how long recovery may take. Those decisions need an engineer and a business owner who understands the consequences. They apply to a monolith as well as to distributed systems; adding microservices does not solve them.
Similar scrutiny is needed for production scheduling, financial approvals, sensitive HR records, and automations that can update an ERP. A generated workflow may complete a demonstration successfully while having no safe answer to a broken connection halfway through. Failure tests and an agreed recovery procedure belong in the delivery scope.
A balanced approach: three ways to proceed
There is no need to choose between letting an AI build everything and refusing to use it. Match the delivery approach to the consequences of failure and the requirements the business actually has.
1. Vibe coding for low-risk, non-mission-critical internal tools
Use this approach for small, bounded tasks with low-sensitivity data and a workable manual alternative. A prototype for collecting workshop ideas or organizing internal reference material is a more sensible starting point than a tool that approves supplier payments.
Keep access limited, use synthetic or approved data during development, and give the tool an owner. Check permissions and backups before real use, and agree on what happens if it stops working. Even here, “low risk” should be a decision someone has made—not an assumption based on the word “internal.”
2. Hybrid delivery: engineers set the boundaries
Return to the supplier portal. An engineer might approve generating the submission form and status screens, but require those screens to call an existing API. That API would remain responsible for permissions, tenant checks, and the approval rules. The builder can help produce the interface without being allowed to redefine who can approve an order.
Decide that boundary before connecting production systems. Give the engineer enough information to assess the data, user roles, integrations, and consequences of a mistake. The answer may be to use generated code for most of the application, or only for a small part. “Hybrid” describes that allocation of responsibility, not a fixed percentage of AI-written code.
Put the resulting controls into the workflow: changes go through review, tests run before release, and deployment requires the agreed approval. Assign someone to monitor the app and keep a rollback available. A rule written in a prompt is not a substitute for an enforced check.
3. Custom enterprise development: when the platform cannot meet the requirements
Some constraints rule a builder out. A customer may require a dedicated environment that the proposed service cannot provide. A factory application may need to run on infrastructure with restricted connectivity. An existing transaction system may have reconciliation and audit requirements that its replacement must preserve exactly.
Check whether an established enterprise product can meet those requirements first. If it cannot, and the builder cannot either, a custom implementation is necessary. Changing the requirement merely to keep the prototype would be the wrong compromise.
Custom development does not require engineers to avoid AI. They can use coding agents for implementation tasks, tests, and documentation. They still own the design, review the changes, and verify behavior against the business requirements. That is different from accepting whatever architecture emerges from a succession of prompts.
Run the same small trial before choosing
Write down one workflow and its acceptance criteria before opening a builder. For the supplier example: a supplier submits an update, an employee approves it, and neither can read another organization’s records. Use invented data, not customer information. Try the same assignment in the products on your shortlist.
Keep a short record of what happened:
- What worked without correction? Record whether the form saved data, approval persisted, and permissions held. Note the changes that needed a developer.
- What happened when something failed? Disconnect a test service or submit invalid input. Check that the user gets a clear error and that records are not left in a misleading state.
- Could someone else take over? Ask another person to run the project using its repository and setup instructions. Include database access, configuration, and external services in that handoff.
- What would the live app cost and require? List hosting, database, model calls, backups, support, and a named maintenance owner. Separate generation credits from ongoing operating costs.
Choose from those results, not from which tool made the most impressive first screen. A product that needs fewer corrections in your workflow may be the better choice even if its initial demo takes longer. If none passes a requirement you cannot relax, stop the trial and change the delivery approach.
For a business, the useful outcome is an application somebody can operate, maintain, and trust within agreed limits. Getting there may involve a builder, professional engineering, or both.
Further reading
- Google Cloud: What is vibe coding?
- Replit Agent documentation
- Lovable documentation
- Bolt
- v0 documentation
- Cursor
- Google AI Studio: Build mode