Vibe Coding Playbook

From idea to working tool

Step-by-step guidance, examples and prompts to help you go from idea to working tool, without pretending that revenue management is simple.

Pick a starter module

The method

Six moves. Each one has a job, and skipping the fourth and fifth is how people end up trusting a tool that is confidently wrong.

Write the business question first

Not “build a dashboard”. Something like: on which dates next month is my compact fleet at risk of selling out at the wrong price? A question with a location, a period and a class in it can be answered. A vague one cannot.

Turn it into a build prompt

Name the input files and their exact columns. State the rules in full sentences. Say what must never happen: no silent defaults, no estimated values, no rows dropped without a reason. Ask for the excluded rows to be listed.

Get a working example running

Small data, one location, one class, a short date range. If you cannot check the output by hand, the data set is too big to be learning from.

Write tests with known answers

Put in one row you have already worked out on paper. Break something deliberately and confirm the tool notices. A tool that never complains is not being careful, it is being quiet.

Find the operating complication

Every useful tool has one: stale rates, class mapping, availability across the whole rental period, duration, currency, taxes and fees, cross-location returns. Name yours and handle it on screen, where a reader can see it.

Decide what connects, and what does not

Read-only and synthetic is where you start. Anything that writes to a live system is a different product with different guarantees, and it comes much later.

A prompt, before and after

The difference between a prompt that produces a demo and one that produces a tool you can defend.

Too vague

Build me a dashboard that shows how my rates compare to the market.

Nothing here says what “compare” means, so the assistant will decide for you, and you will not know what it decided.

Specific enough to be useful

Load my_rates.csv and market_rates.csv. Columns: pickup_location, dropoff_location, pickup_date, return_date, vehicle_class, currency, base_rate, taxes, fees, observed_at. Use class_map.csv to map competitor vehicle_class to mine. Only compare rows matching on both locations, both dates, mapped class and currency. Show my rate, the lowest and median comparable rate, and my gap in currency and percent. Let me switch between base rate and total including taxes and fees, and show which is active. List every row that could not be compared, with the reason. Do not estimate missing values.

Every decision is written down, so every result can be traced back to a rule you chose.

Rules worth keeping

Check one row by hand

Before you trust a thousand rows, verify one against the source. This single habit catches more problems than any amount of code review.

Make exclusions visible

A tool that shows a smaller, honest data set is worth more than one that quietly fills gaps.

Put assumptions on the screen

Freshness thresholds, comparison basis, how same-day returns are treated. If it changes the answer, it belongs next to the answer.

Start read-only

A tool that only reads can be wrong without being expensive. Keep it that way until you have a reason not to.

Use data you may use

Synthetic or authorised only. No credentials, no personal reservation data, no nonpublic pricing in a prompt.

Narrow beats ambitious

One location, one class, one question. You can widen a tool that works. You cannot narrow one that never did.

Start with a module

Each module already carries its build prompt, its tests and its operating complication. You are not starting from a blank page.

Browse modules Start Here