Wire Up the Tools the AI Needs: Git, Preview, Tests

The small setup that turns vibecoding from risky to safe: version control so every step is a checkpoint, a live preview so you can see what the AI built, and at least a few tests so changes that break things announce themselves. You do this once at the start and it protects the whole project.

Version control means a bad AI generation costs you one git revert, not hours of untangling. A preview turns 'the code looks right' into 'I can see it works'. Tests turn silent regressions into loud, immediate failures. Together they give you the safety net that makes fast, confident iteration possible — you can let the AI move quickly because you can always see and undo what it did.

At the very beginning of every project, before you build features. Set up the repo, get a preview running, and add one or two tests around anything important as you go.

For a throwaway experiment you'll delete in an hour, full setup is overkill — though even then, initialising Git costs seconds and has saved many 'throwaway' projects that turned real.

Set this project up for safe iteration: initialise Git and make an initial commit, get a local preview/dev server running and tell me the URL, and add a couple of basic tests for the core logic. After each feature we build, commit the working version so I always have a point to roll back to.

Halfway through a build, an AI change breaks the app in a confusing way. Because every prior step was committed, you run one revert command and you're back to a working version in seconds — instead of trying to manually unpick what changed across five files.

Ask the AI to commit with clear messages after each verified step, and to run the test suite automatically before reporting a change as done. Now your history is a clean, revertible timeline and every hand-off comes pre-checked, so you spend review time on judgement rather than catching obvious breaks.

• Skipping version control until 'later', then having no way back when a generation goes wrong.
• Building without a running preview and only discovering the app is broken much later.
• Never writing a single test, so regressions stay invisible until a user hits them.