Vibe coding with guardrails: how we use Claude Code and Cursor

We keep vibe-coding speed and try to catch vibe-coded bugs before they ship by deciding in advance what an AI coding agent may do, then checking its work. Rule files brief the agent, project skills script the risky jobs, review agents check changes in one of our own apps, and tests and CI run the same checks every time.

Part of our work is rescuing apps built with Lovable, Bolt and Cursor, and I have written up what breaks in them: build errors silenced, secrets committed, authentication that isn't enforced, rate limits that fail open, and jobs that report success while doing nothing. This post is the other half of that story. We use the same kind of tools, and this is what we put around them.

Which AI coding tools do we use, and what do they get wrong?

We build with Claude Code, Cursor, OpenAI Codex and Antigravity, across Node.js, Python and .NET repositories. They read a codebase, write working code from a paragraph of intent, run the commands that check it and fix what fails.

They also make mistakes, and the expensive ones aren't random. An agent works toward the goal it can see. If the goal is a green build, switching off the check that fails is a path to it. If the goal is a page that only signed-in users see, hiding the page is a path to it, whether or not the API behind it checks anything. Those are the same defects we find in vibe-coded apps.

So nothing below assumes the tools get it right. It assumes they will sometimes get it wrong, and arranges for something other than a customer to notice.

What goes in a CLAUDE.md or AGENTS.md file?

A rule file is the briefing an agent reads before it works in a repository. Claude Code reads CLAUDE.md, and Codex and Cursor are among the tools that read AGENTS.md. In this website's repository, AGENTS.md simply points to CLAUDE.md, so every tool gets the same rules.

We keep rule files in our own repositories and in client repositories we work on: the shared AI backend, the FCA compliance scanner, our HR and payroll platform (in development), Aidfolk's front end, and Zentally, our AI expense tracker (In development, not yet on either store). The HR platform's file shows what one should hold:

• The stack, and what not to use. .NET 10 and Clean Architecture in a service-injection style, plus an explicit list of patterns the codebase doesn't use, such as MediatR, AutoMapper and generic repositories. Without that list, each agent session can bring in a different pattern for the same job.
• One feature to copy. The file names a reference feature, end to end, so a new feature copies a known-good shape instead of inventing one.
• The security rules. Permissions are checked twice, on the endpoint and again in the service, and the tenant comes only from the signed-in user's claim.
• The commands that prove a change works. The exact lines for building, testing and checking migrations.
• Assumptions, written down. Where a feature was built on stated assumptions, the file says so, for the lead to review.

This website has a rule file too. It forbids naming clients and requires a source for every number. A script fails the build on banned compliance wording, superlatives, unsourced comparisons, MCP-server claims, status drift and client names from a private list. It can't tell whether a number has a source, so that rule is checked in review. This post went through both.

Why isn't a rule file enough?

Because it's advice. Anthropic's documentation says Claude Code treats CLAUDE.md as context, not enforced configuration. An agent can misread a rule or lose track of it in a long session.

So anything that must never happen should also be a check that fails. On the HR platform, 7 architecture rules run as tests in CI, analyzer warnings and code style count as build errors, and CI checks that the database migrations match the model. The rule file explains the rule. The check enforces it.

What are project skills for?

A skill is a set of instructions an agent loads for one job. We write them for jobs where a mistake is expensive. Aidfolk, our AI customer-support product, has three:

• Release and rollback are marked so that only a person can start them; Claude Code won't load them on its own. The release skill is written to stop and ask for a yes in the conversation before it pushes to the production branch.
• Production status is written as a read-only check. In the skill's own words: "Look, don't touch." It is told to propose fixes, never to make them.

A skill is still instructions, like a rule file, so the controls that don't depend on the agent sit in the pipeline behind it. Aidfolk's pipeline drafts a release only once its checks pass, publishing that draft is the approval, a release that didn't come through those checks is refused, and the deploy takes a database backup first and finishes with a smoke check.

How do review agents check an AI agent's work?

So far, review agents exist in one repository: Zentally. I wrote four, architect, QA, security and design, each a read-only reviewer with a rubric written for that codebase, and none of them edits code. Zentally's rule file asks for architect, QA and security review after any non-trivial change, plus design review for changes that affect the UI, and for every Blocker and High finding to be fixed before the change counts as done. Docs, comment and typo changes skip them.

What each one looks for:

• Architect: layering and the codebase's own conventions. All money arithmetic goes through one module, for example, so a raw + on two amounts is a finding, not a style note.
• QA: starts from the assumption that the happy path works and everything else is untested. It asks whether each path fails closed, and it runs the type check, lint and Jest suite, reporting failures verbatim.
• Security: assumes the code is hostile until proven safe. A client-side route guard counts as user experience, not authorization; the real boundary is row-level security and server-side checks. A new endpoint without an auth check is a Blocker, and the service key must never appear in the app bundle.
• Design: layouts on small and large phones, tablets, foldables, landscape and large font sizes, plus dark mode and contrast.

Each reviewer starts with a fresh context and sees only what it is handed, the diff and the intent, so it judges the change, not the conversation that produced it.

What can't review agents do?

Two limits are written into the repository itself. All four reviewers run on Claude, so they bring a clean context and a narrow rubric, not the blind-spot coverage of a second model. And they are guidance, not a CI gate: nothing blocks a merge because a reviewer objected. That is why they don't get the last word.

Deciding in advance what an agent may do on its own is also how we build AI agents for clients.

Why do tests and CI carry more weight than review?

A reviewer's finding can be argued with. A failing test can't. In three of our repositories, these checks run the same way every time:

• Zentally: every push, on any branch, runs type checks, lint, 1,332 Jest tests, 24 Deno tests, secret scanning and a build-integrity check.
• Aidfolk: 1,077 backend tests, browser tests with accessibility checks on desktop and phone, and releases that deploy only after an explicit approval, with a backup taken first.
• The HR platform: 463 backend tests, 328 front-end tests and 7 architecture rules enforced in CI.

The FCA scanner, below, still has a gap here, which is why it isn't on that list.

How do the guardrails map to the bugs we find in rescues?

Each defect class from our rescue work maps to at least one guardrail meant to catch it before it merges, though not every guardrail runs in every repository.

None of these rows is a guarantee, and the review-agent rows are guidance rather than a gate. Each one is a second chance to catch the mistake before a customer does.

What does this look like on a rescue?

The FCA compliance scanner arrived as a Bolt.new prototype with the first five defects in that table, down to an ingest script that had built an empty knowledge base for months while reporting success. We audited it function by function, wrote a defect register and fixed the silent failures first.

Then the guardrails went into the product itself. The model decides only what needs judgment: Claude flags non-compliant claims, while severity comes from a versioned rule pack in code, and deterministic code checks for missing statutory text. When the model had been asked whether the firm behind a promotion was identified, it flagged a missing firm reference number on essentially every scan. If retrieval fails, the scan still runs and says it is ungrounded; if the model fails, the code's findings are still returned, the result can't read as a pass, and the user's quota is refunded. A health endpoint asserts on what the corpus actually contains.

It now has 250+ test definitions in 11 files and a 34-case eval corpus. One gap is still open: the repository has no CI pipeline yet, so its coverage thresholds (90% of lines, 80% of branches, on the compliance engine) apply only when someone runs the coverage command. A guardrail that only runs when someone remembers to run it is still a rule file.

FAQ

What should a CLAUDE.md or AGENTS.md file contain?

What a new senior engineer would need on day one: the stack and the patterns the codebase avoids, one reference feature to copy, the security rules, and the exact commands that prove a change works. Anything that must never happen should also be a failing check, because a rule file is advice and a test isn't.

Can AI review agents replace human code review?

Not on their own. Ours exist only in Zentally, where they review non-trivial changes in a fresh context with a narrow rubric. All four run on one model, Claude, so they don't bring a second model's view, and they aren't a CI gate, so they don't block a merge. On Aidfolk, a production release still waits for a person's explicit approval.

Is vibe coding safe for a production app?

The speed is real; the safety isn't automatic. A vibe-coded app usually has the right shape and the wrong failure behavior: errors silenced, keys in the repository, checks that pass when they should refuse. With rule files, tests and CI around them, plus review agents on Zentally, the same tools are what we build with.

Can you add these guardrails to an app we've already built?

Yes. A rescue starts with an audit and a defect register, fixes the silent failures first, and ends with tests around what broke, a working deployment pipeline and a written handover. Rule files and the checks behind them fit into that handover, so the next agent or engineer starts with the rules written down.

If your app was vibe-coded and you want to know what it's hiding, our AI-built app rescue starts with that audit.