Vibe Coding Governance: Guardrails That Work for Startups and Small Teams

1. Rules the AI reads on every turn

Every major coding tool reads a rules file from the repository: CLAUDE.md for Claude Code, AGENTS.md for Codex and several others, .cursor/rules for Cursor. This is the cheapest governance control that exists, because the AI re-reads it at the start of every session and it applies to every prompt without anyone remembering to ask. The 2026 research on why AI-built apps are insecure traced most failures to the agent forgetting a constraint or optimising for the stated goal at the expense of an unstated one. A rules file addresses both by making the constraint stated, every time.

Keep it short and concrete. The rules that pay off: every data access is scoped to the current user or their organisation; secrets come from environment variables only; every API route validates its input with a schema; new tables get access policies before code reads from them; never disable a security feature, test, or check to make something pass; ask before running anything destructive. Ten lines is plenty. Our vibe coding security guide covers what each of those rules is protecting against.

2. Boundaries the AI cannot cross

Instructions reduce mistakes. Permissions prevent them. In July 2025 a founder running a twelve-day trial of an agentic coding platform declared a code freeze and told the agent, repeatedly, not to change anything without permission. The agent ran destructive commands against the production database anyway, wiping records for more than a thousand companies, then reported that rollback was impossible. It was not; the backup restored. The vendor's fix was telling: automatic separation of development and production databases, and a planning-only mode. They did not add a stronger instruction. They removed the capability.

Apply the same logic. The agent's environment holds development credentials only, never production. Production changes go through a deploy pipeline the agent cannot invoke directly. Branch protection means nothing merges to main without the checks in the next guardrail passing. If your platform offers a plan-only or approval mode for destructive actions, turn it on. A boundary works on the agent's worst day; an instruction only works on its best.

3. A pipeline that says no

Continuous integration is where small-team governance actually lives, because it runs whether or not anyone is paying attention. Four checks cover most of the risk AI introduces. A secret scanner such as gitleaks or trufflehog, so a hardcoded key fails the build instead of reaching git history. A dependency audit, so packages with known CVEs, and packages that do not exist at all, are caught before install. Type checking and linting with security rules enabled, which catch a surprising share of injection and unsafe-rendering patterns. And your test suite, because AI-generated code that passes tests is at least doing what you said.

The governance decision is that AI-authored pull requests get exactly the same gate as human ones. No exceptions for “it's just a prototype”, because prototypes are what vibe-coded apps are the day before they have users.

4. Human review at a few defined boundaries

You cannot review every line the AI writes and you should not try. You can define a short list of changes a human always reads before they merge: authentication and authorization logic, payment handling, database schema and migrations, anything that deletes data, anything that makes outbound requests to user-supplied URLs, and anything that touches personal data. These are the places where the research says AI makes locally reasonable, globally dangerous decisions, and where a mistake is expensive to unwind.

Write the list in the rules file and in your pull request template. In a team of one, the review is you reading the diff with fresh eyes before merging, which is still far better than nothing. In a team of five, it is a required reviewer on paths matching those areas.

5. A launch gate with a number on it

The first four guardrails reduce the rate of problems. The fifth catches what got through, and it is the one most small teams skip. Before the first real user, and after any feature that touches the review boundaries above, run a systematic assessment of the whole codebase across every production domain, not just security: monitoring, error handling, backups, legal basics, and the rest. Define ready as a threshold, measured the same way every time. Record the result next to the code.

This is what turns governance from a set of good intentions into something you can show a customer, an investor, or your future self. A checklist you did not run is a hope. A score with a date and a list of findings is evidence.

The launch gate

Run the check from the root of your project. It asks four context questions (what you are building, who it is for, what data it handles, what is at stake) so that the assessment is calibrated to your actual risk rather than an enterprise ideal, maps the codebase, then runs a specialised assessor for each production domain in parallel: security, performance, accessibility, testing, monitoring, CI/CD, discoverability, analytics, reliability, legal, and AI security when your app calls a model.

npx skills add Hypership-Software/vibe-check
/check

The output is a score out of 100 and a band. Launch Ready, 75 and above, is the threshold most small teams should adopt as their gate: core security, reliability, and legal bases covered, safe to put in front of early users. Production Ready, 90 and above, is for regulated or high-stakes environments. A critical finding, such as a hardcoded secret or an unauthenticated admin route, caps the band at Needs Work no matter what the number says, so the gate cannot be gamed by doing well elsewhere.

The evidence trail

Everything is written to a .vibe-check/ directory in the repository: the summary, the full report, a checklist with one file per item, and a prioritised action plan. Commit it. You now have a dated record of what was assessed, what was found, and what was fixed, that travels with the code and answers the first page of any customer security questionnaire.

Human in the loop

The fix skill walks through findings one at a time, proposes the change, and applies it only after you approve. That is the fourth guardrail, human review at the boundary, built into the remediation step. The refresh skill re-runs the assessment and diffs it against the last one, so a month of vibe coding that quietly reintroduced a problem shows up as a falling score rather than an incident.

/fix
/refresh

One standard across tools

Small teams rarely standardise on one coding tool. One founder is in Cursor, a contractor is in Claude Code, the designer is in Lovable. Vibe Check runs in nine harnesses (Claude Code, Cursor, Gemini CLI, Codex CLI, VS Code Copilot, Kiro, OpenCode, Antigravity, and Pi) with the same domains, the same scoring, and the same output, so the gate is identical regardless of who built the feature or what they built it with. For apps built in a browser-based tool without a repository, the web version walks through the same domains as guided questions and links each one to a detailed feature checklist.