Vibe coding mistakes that cost you hours

Mistake 1: typing “fix it” again and again

Something breaks. You type “fix it.” The AI says it’s fixed, but it isn’t, or now something else is broken. Twenty minutes later you’re on attempt five and the app is worse than when you started.

Why: “fix it” tells the AI almost nothing, and every failed attempt stays in the chat as part of what it reads next. Anthropic, the company behind the AI Claude, describes this in the guide to its coding tool Claude Code as a chat history “polluted with failed approaches.” AI tools also tend to patch the error they can see rather than its cause, so each fix quietly moves the problem somewhere else, as this analysis explains.

1. 1Stop after two tries. Anthropic’s advice is the same: after two failed corrections, start fresh in a new chat with a better prompt.
2. 2Go back to the last version that worked (see mistake 2).
3. 3Copy the exact error message, if there is one, and write down what you expected to happen.
4. 4Ask the AI why it happens before you let it change anything.

This is broken: [what you see]
Exact error: [paste the error message]
What I expected: [what should happen]
Must keep working: [features that must not change]

Don’t change any code yet. Explain what you think causes this and which files are involved. Then suggest one fix and wait for my OK.

Mistake 2: prompting without a save point

The app worked. You asked for one more thing, lots of files changed, the login broke, and there’s no clean way back. Every prompt edits the version you have, so without a save point, “the version that worked” only exists in your memory.

Your tools already offer save points. Claude Code creates a checkpoint, its name for a save point, with every prompt; press the Esc key twice or type /rewind to go back. Cursor creates checkpoints before significant changes. Lovable saves every change as a version you can revert, and you can bookmark the good ones.

1. 1Before a prompt: make a commit (or have the AI make one with the prompt below), or bookmark the current version.
2. 2Send one prompt.
3. 3Test what changed.
4. 4Broken? Go back to the save point and try again with a smaller step. Don’t keep patching the broken version.

Before we change anything: commit the current state with a short message that says what works right now.

Mistake 3: clicking “Accept all” without looking

The AI shows its changes, you click “Accept all,” and a week later you find it edited a file you never mentioned. It changes whatever looks related to your request. It can’t know which parts are off-limits unless you say so. And as Cursor’s own guide warns, AI-generated code “can look correct but be subtly wrong.”

You don’t have to read every line. Read the list of changed files: it takes seconds. For each one, ask: did I expect this file to change?

• A file you expected: fine. Test the feature.
• A file you didn’t expect (payments, login, settings): reject that change, or ask the AI why it touched it before you keep it.
• Far more files than the task needs: go back to your save point and ask for a smaller change.

Mistake 4: building the whole app in one prompt

“Build me a booking app with login, payments, an admin area and emails.” Something impressive appears fast. Then you find half of it doesn’t work, and nobody, the AI included, knows which half.

One giant prompt means one giant change. Every gap in your description gets filled with a guess, and when something breaks, the cause could be anywhere. It’s also where features you never asked for sneak in.

Instead: one feature per prompt. Write down what your first version must do, build the most important item, check it, set a save point, then move to the next. New ideas go on a “later” list, not into the current prompt.

New ideas go to Later · From the Faber knowledge base

Mistake 5: one chat that never ends

After dozens of messages, the AI starts ignoring rules you set early on, redoes things you decided against, or mixes up features. The chat has simply become too long.

The AI can only work with what fits into its working memory for this chat, called the context window. Anthropic writes that performance “degrades as it fills” and that the AI may start “forgetting” earlier instructions. Cursor also warns that long conversations can make the AI “lose focus.”

1. 1When a feature is done, or the AI keeps repeating the same mistake, ask for a handoff summary with the prompt below.
2. 2Save the summary, in a note for example, then open a new chat and paste it in as your first message.
3. 3Put rules that apply to every task, like “Never change the payment code without asking,” into a rules file. Many AI coding tools support a file called AGENTS.md, which agents.md describes as “a README for agents,” meaning a read-me file for the AI; Claude Code reads CLAUDE.md. You can ask the AI to create the file for you.

Summarize this chat so I can continue in a new chat. Include:
- what the app does and who it’s for
- what is finished and works
- decisions we made, including what we decided not to do
- what is still open or broken
- the next step
Keep it under 200 words. Don’t include code.

Mistake 6: trusting “Done!”

The AI reports: “Done! Everything works.” You move on. Later you find the feature only works in the one case you tried, or not at all.

When the AI says it’s done, it tells you what it changed, not necessarily what it checked. In the developer survey Stack Overflow Developer Survey 2025, 66% of developers named “AI solutions that are almost right, but not quite” as their biggest frustration with AI tools, and 45% said debugging AI-generated code takes more time. Almost right looks exactly like done until you test it.

So ask for proof. Anthropic recommends having the AI “show evidence rather than asserting success.” Then check it yourself.

Before we call this done: how did you check it? Show me what you ran or tested and what the result was. Then give me three steps I can follow myself in the app to confirm it works, including one where something goes wrong (wrong input, empty list, logged out).

Go through the three steps yourself. Only when your own check passes is the feature done.

Implemented is not verified · From the Faber knowledge base