What is vibe coding? From a prompt to a tested app

Think in a describe, try, revise loop

Instead of writing every line yourself, you describe a desired behaviour and let a tool propose an implementation. You run it, notice what is missing and give a more precise instruction. Replit’s introduction describes this iterative approach and its limits when moving towards production.

People use the term with different levels of code review. For your own project, say what you actually did: generated a prototype, reviewed a change or tested a release. The label alone tells a visitor little about reliability, security or who is responsible for maintenance.

Reference: Replit Learn: What is vibe coding?

A small example makes the difference visible

Suppose you ask for a household task list. The first result may show attractive cards and a working Add button. Try refreshing: are the tasks still there? Enter a long name: does the card remain readable? Delete a task: can someone recover from a mistake?

Each question becomes a concrete requirement. “Save locally and show a warning if saving fails” is more useful than “make it production ready.” Ask the assistant to explain the data model, implement one behaviour and demonstrate the check. Inspect the result yourself before asking for another feature.

A prototype answers fewer questions than a product

A prototype can help you decide whether an interaction makes sense. It may use temporary data and assume a single person, a fast connection and a successful request. That is useful if those assumptions are visible.

A public product has to deal with people returning later, unfamiliar devices and failed actions. A shared list also introduces identity and permissions. A payment flow introduces a provider and a record of what was paid. Adding those concerns changes the work, even when generating the next screen feels quick.

The important decisions still belong to you

You choose whose problem matters, which result counts as success and which features can wait. You also decide what information is necessary, which assets you have permission to use and whether an output is trustworthy enough for the job.

Ask for explanations you can check. Where is data stored? Which dependency performs this task? What happens when the request fails? If the answer is unclear, reduce the scope or involve someone who can review it. Do that before handling irreversible deletion, sensitive records or real payments.

• Keep a readable record of the intended behaviour.
• Save a working checkpoint before a larger change.
• Review changes and test the outcome, not just the appearance.
• Leave unverified behaviour labelled as unverified.

Use real apps as references, with the right boundaries

The LaunchVibe catalogue gives you concrete interactions to examine: planning a task, practising Morse or arranging a photo story. We have not verified that the listed apps were made with vibe coding. Their presence here is not a claim about their development process.

Study the problem and the interaction rather than copying a brand, screenshot or implementation. Our Village offers another way to discover the same catalogue, while ordinary product links still work without walking to a building. That is a product decision about access, separate from which tool generated code.

Start with one behaviour you can explain

Choose a small, reversible experiment. Write the input, the action, the result and two ways it can fail. Ask for a first version, try those cases and keep notes about what happened. Repeat only after you understand the current version well enough to change it.

The app-ideas guide offers scoped examples and a reusable brief. When you are ready to share your project, the launch checklist helps you collect evidence about the journey, data and deployed build. A useful first release is one whose behaviour and limits you can describe honestly.