Vibe Coding With Claude: How It Actually Goes, and When to Stop

Describing what you want and getting working software is real, and it works. But the skill that decides how far you get is not technical: it is describing the symptom precisely rather than guessing at the fix, and recognising the moment to stop.

What the loop actually looks like

The common image is "say what you want and get software". In practice it is a loop, and nearly all the value is in the second round onwards.

1. Describe something small.
2. Run it and look.
3. Describe what is wrong.
4. Repeat.

Step 3 is the whole thing. And it is exactly where non-developers get stuck - not because they cannot read code, but because they try to guess the fix instead of describing what happened.

The rule: what you did, what you expected, what happened. Those three components produce a correct fix; one of them alone does not.

Two rules that save projects

1. Start from something that runs

The common mistake is describing the whole system in the first request. You get something large that does not work, and there is no way to tell which part is broken.

What works: the smallest thing that runs, then add. If something breaks, you know exactly what you added.

2. Save a working copy before every change

If you take only one rule from this, take this one.

Developers use version control. You do not - and there is no undo button. The most common point at which people give up: everything worked, they asked for one more change, and now nothing works and there is no way back.

The simple equivalent: before each change, save a copy of what worked. A folder with a date. It is ugly and it is enough.

What is genuinely worth building this way

The criterion is not complexity but cost of being wrong:

• A personal tool. Something only you run. If it breaks, you fix it.
• A prototype. Showing an idea before investing. This is the strongest use - finding out cheaply whether building is worth it.
• A one-off conversion. Turning a file from one format into another, once.
• Something where nothing happens if it breaks.

And for the genuinely small things - a calculator, a checklist, an internal form - you usually do not need a code project at all.

The four stopping lines

These are not recommendations. They are lines.

1. Real customer data

The moment the system holds names, phone numbers, addresses or customer details, it stops being only your problem. A leak is a problem for the people on the list.

2. Money

Payments, charges, amounts entering the books. An error here costs real money and surfaces late.

3. Logins and permissions

This is the line most easily crossed without noticing. "Add a login screen" sounds like another feature - and it is precisely the feature where a quiet error opens everything. The specific risks are documented separately, and what they share is this: you cannot see the problem by looking.

4. Someone else depends on it

Once an employee or a customer uses the tool, it stopped being an experiment. They do not know what not to trust.

And the follow-on question - whether something built this way can go live - is answered separately and honestly.

Three things that will surprise you

1. One fix breaks something else

This is the most important signal, and worth recognising early.

You fix A, B breaks. You fix B, A comes back. What it means: the project outgrew what can be held in one conversation.

That is not a failure of the tool - it is a boundary. What works: stop adding, go back to the version that worked, and decide whether what you have is enough. What does not work: continuing to ask for fixes.

2. "Looks like it works" is not "works"

You test what you built the way you use it - in the right order, with sensible data. A real user hits back halfway, leaves a field blank, enters a date from last year.

Three checks worth running every time: an empty field, a very large value, and pressing the same button twice.

3. Confidence is not correctness

A wrong answer arrives in the same tone as a right one. You cannot tell the difference from the phrasing - only from the result.

So: check, do not believe. Enter a case whose answer you already know and confirm the number matches.

Hebrew

If the tool is in Hebrew, three things break quietly:

• Directionality - ask for Hebrew explicitly, then open it and look.
• Dates - day/month rather than month/day. This is an error that looks valid on any day from the 1st to the 12th, which is why it is found too late.
• Text arriving from elsewhere - names with double spaces or invisible characters break comparisons.

The decision at the end

Once you have something that works, there are three paths:

1. Leave it as is. If it is a personal tool that serves you, that is the end. Nothing further is needed.
2. Throw it away and build properly. If the idea proved worthwhile, the prototype did its job. It is a living specification, and that is worth more than a document.
3. Have someone review it. Before it touches money or customers.

The only failure is not choosing - continuing to stretch a personal tool into a role it was not built for, without deciding that is what is happening. If it became a business process, it is now an automation question with a known cost.