Vibe coding, explained with a small application

You describe a need, AI writes code and you try the result. A customer-tracking example explains what this approach offers and what you need to check.

Imagine this request: “Make a page where I can record my customers, their phone numbers and their next appointment.” You send that request to an AI tool. A page appears; you try it, then ask for a button to find this week’s appointments. That is one way to practise vibe coding.

Describe instead of writing code

With this approach, you make requests in everyday language. AI writes the code, and you guide what happens next by looking at and using the result.

It lets you make an idea visible without first learning a programming language. An initial page can help you discuss it with a colleague and discover what your request was missing.

A successful page does not answer everything

Your customer list looks useful. But is the information still there after you close the page? Can a colleague change it? Can an outsider access it? Appearance does not answer these questions.

Use invented names and numbers for an initial trial. You can explore the idea without entrusting real customer records to it straight away. These checks help distinguish a demonstration from an application used every day.

Keep your decisions outside the conversation

Record important rules in a document you can find easily. For example: “Each customer has one record. Only team members can view it. Deleting an appointment does not delete the customer.”

A simple requirements document keeps those decisions together. It helps identify omissions, but you still need to check that the application follows them.

Ask for a specific change

Instead of “improve tracking”, ask: “Add a filter to show this week’s appointments. Keep the existing customer records and appointments.” Try the filter before adding another request.

If something breaks, describe the action, the actual result and what you expected. Requesting several fixes at once makes it harder to identify the cause.

Choose what you want to try

This approach is useful for exploring an idea and gradually building a tool. The time needed afterwards depends on the data, users and consequences of a mistake; an attractive first version cannot tell you how long that will take.

Comparing the different approaches helps you choose. Maestro organises work around documents, stages and approvals. Whatever tool you use, start with a limited task whose correct result you can recognise.