How to vibe-code without having to rewrite it all later

Building an app with an AI assistant is a perfectly good way to get to something working fast. The trouble starts not on day one but in week three: the codebase has grown, the assistant fixes one thing and breaks another, and you’re afraid to touch a file because you no longer know what’s in it. Rewriting from scratch at that point is expensive. It’s cheaper to work from the start in a way that never gets you there.

None of what follows slows you down noticeably. All of it pays off within a week.

Small steps

The most common mistake is asking for a big chunk at once: “add payments, a user dashboard and notifications.” The assistant will do it. Somewhere in those forty changed files is a decision you wouldn’t have made, and good luck finding it.

Work in tasks you can check in a couple of minutes:

• one function, one screen, one fix at a time;
• before a big task, ask for a plan first, agree on it, then go item by item;
• if you can’t hold the assistant’s change in your head all at once, the step was too big.

Commit after every working state

An assistant can confidently break what worked five minutes ago. The defense is a commit every time the app is in a working state. Not once a day, but after every step that worked.

Then any failed experiment rolls back with one command instead of trying to explain to the assistant “how it was before.” Write in the commit message what changed and why. A month from now it’s the only record of why the code looks the way it does.

Use a branch for experiments. If it doesn’t pan out, throw the whole branch away, no archaeology needed.

Read the diff

Before committing, look at what actually changed. You don’t need to understand every line, but you should notice:

• changes to files that have nothing to do with the task;
• removed checks, error handling or tests (assistants sometimes “fix” a failing test by deleting it);
• new dependencies you didn’t ask for;
• keys, passwords and URLs written straight into the code.

If something is unclear, ask the assistant why it made that change. “Not needed, I’ll remove it” comes back more often than you’d like.

Tests as insurance against the assistant

Here tests aren’t about coverage. They’re about keeping the assistant from breaking what already works. Start small: a few tests for what matters most, like signup, payment and the main user flow. Ask for a test with every new feature and run the suite before each commit.

A good sign is the assistant running the tests after a change and noticing a failure on its own. A bad sign is having no tests and hearing about the breakage from a user.

A project rules file

Nearly every AI coding tool can read a rules file in the project root. It’s the cheapest way to stop the assistant from reinventing decisions you’ve already made. Keep it short and specific:

- Stack: React + TypeScript, Node API, Postgres.
- Ask before adding any new dependency.
- Database access only through the db/ module, never from components.
- Secrets only from environment variables.
- Before committing: npm test and npm run lint must pass.
- Never delete or disable tests to make them pass.

Every time the assistant makes the same mistake twice, add a line to this file.

Tidy up regularly

Every couple of weeks, spend time on cleanup instead of features: delete dead code, merge duplicated pieces, split the file that grew too big. With an assistant this goes quickly, as long as you do it in small steps with tests. Skip it, and the codebase slowly becomes the place nobody wants to touch.

The upshot

You keep the speed of building with AI if you add ordinary engineering discipline: small steps, commits, reading changes, tests and written rules. That’s the difference between a prototype you’ll throw away and one you can grow into a product.

If your project has already reached the “afraid to touch it” stage, SUBXCAT can clean it up and set up a workflow that keeps it from happening again.