Vibe coding without breaking production

What is vibe coding, and where does it go wrong?

Vibe coding means describing what you want in plain language and letting an AI model write the code. Wikipedia’s entry on the term says it was coined in February 2025 by computer scientist Andrej Karpathy, and that it may involve accepting AI-generated code without thorough review. It also records the criticism: a lack of accountability and maintainability, and a greater risk of security vulnerabilities.

The prompt is rarely the problem. The failure happens at the other end: unreviewed changes go straight to production, and there is no way back. Everything below fixes those two things, and none of it needs to slow the fun part down.

Rule 1: how do you keep the agent off your main branch?

Do all agent work on a branch. git switch -c agent/signup-form costs nothing, and if the result is bad you delete the branch and production never knew.

Then let GitHub back you up, even if you are the only developer. A branch protection rule can stop force pushes and deletion of your main branch and require passing status checks before a merge. By default these rules do not apply to people with admin permissions, so if you are the admin, turn on the option that applies them to administrators too.

Rule 2: what safety net do you build first?

One command that runs every check. For a JavaScript project that might be an npm run check script that runs the linter, the type checker, the tests and the build. Have your CI run it on every pull request, and tell the agent the command in its instructions file.

Anthropic’s advice for Claude Code applies to every agent: give it a check it can run, because that is what lets it finish a task correctly without you watching.

No tests yet? Start with three smoke tests for the path that makes you money: sign up, log in, and the one core action. Ask the agent to write them, then read them yourself. Three tests that fail when the app is broken beat three hundred that nobody trusts.

Rule 3: how do you keep secrets and production data out of reach?

Keep configuration in the environment, not in the code. The Twelve-Factor App’s config rule gives a litmus test: could the codebase be made open source at any moment without compromising any credentials? If the answer is no, a key is hiding in your repository.

Use separate values for development and production, and give the agent only the development ones. It should never see a production database URL, a live payment key or a deploy token. If it needs to touch an external service, create a token scoped to that one resource, and revoke it afterwards.

Anything you pasted into a prompt, committed or logged should be treated as exposed, and rotated. Our pre-launch security checklist goes through the rest.

Rule 4: how do you ship small and keep a way back?

Small changes are easier to review and easier to undo. Google’s engineering practices list both reasons: small changes are reviewed more thoroughly and are simpler to roll back. Ask the agent for one thing at a time, and merge each thing before the next.

Put a preview step between the branch and production. Many hosting platforms can deploy a pull request to its own preview URL, so check whether yours does. Click through your critical path there, not on your main site.

Decide your rollback before you need it. For code, that is git revert <commit> followed by a redeploy, and you should know how long that takes. For the database, it is harder. Take a backup before any change to the schema, and prefer additions, such as a new column, over drops and renames, which cannot be undone by redeploying old code.

Rule 5: where do you actually read the diff?

You will not review everything with equal care, and that is fine. Read slowest where damage is expensive: anything touching money, authentication and permissions, deleting or migrating data, new dependencies, and configuration. Look over the rest at least once, and let the tests catch what you miss.

If a change touches those areas and you cannot explain what it does, that is a reason to ask the agent to explain it, or to send it back.

What does the whole workflow look like?

Nine steps you can copy:

Create a branch. Write down the finish line as a command that passes or fails. Let the agent work in small steps and commit after each green one. Run the checks yourself. Read the diff of the risky parts. Open a pull request and let CI run. Click through the preview. Merge. Watch the logs for the first few minutes, with the rollback ready.

It sounds like a lot until you have done it twice. After that it is habit.

Rewind a bad step in SwarmPane

SwarmPane’s Undo for agents takes a checkpoint before every agent step that can edit your files, and rewinds a step byte for byte. A rewind refuses to overwrite edits you made since, and says which. Agent Race can also give two agents the same task in separate copies of the project, so your tests choose between them.

SwarmPane runs the agent CLIs and accounts you already have. Start with a 7-day trial for $1 and keep the speed with a safety net.