The argument about vibe coding is usually framed wrong. Letting a model write the implementation while you steer outcomes isn't recklessness — it's the whole productivity win. The recklessness is downstream: merging what it wrote on vibes too. The failures that follow are always the same three — an SDK call that doesn't exist, a “success” path that never touches the real system, a loop that passes every test and dies at production volume.
The fix isn't reading every diff yourself; that gives back everything vibe coding bought you. The fix is a merge gate: an independent check with veto power, wired into the assistant's own loop, so rejected work comes back fixed instead of shipped.
Hard rules, not polite suggestions
Tools an agent may call are tools it skips under pressure. The difference between a gate that works and a gate that decorates your config is a standing rule the assistant can't reinterpret. Paste this into Claude Code once, in any project:
Set up Verificate as this project's mandatory code gate:
1. Confirm the "verificate" MCP server is connected (list its tools).
If not, stop and tell me what to add to my MCP config.
2. Create or append to CLAUDE.md a section "## Verificate gate (hard rules)":
- Every substantive code change MUST pass validate_ai_output (the complete
change, not a fragment) before being presented as done.
- REJECTED is a stop: fix every finding, re-validate, repeat until approved.
Never present rejected code as complete or summarise away findings.
- Any new feature or refactor requires validate_plan approval BEFORE coding.
- "Tests pass" / "deployed" claims require shown proof, not assertion.
- If the gate is unreachable, say so and stop - never skip it silently.
3. Prove the loop: write a deliberately flawed function, show me the REJECTED
verdict, fix it to approval, then delete the demo.Cursor users: same contract, but have it write .cursor/rules/verificate-gate.mdc with alwaysApply: true.
Why the gate has to be external
- Self-review inherits self-blindness. The model that invented an API will defend it on review. The reviewer has to stand outside the generator.
- Judgment needs a floor. Verificate runs 17 deterministic reality gates first — mock/placeholder veto, gaming and bypass detection, invented-API checks — and a frontier-model review scores only what survives. The review can lower a score; it can never override a veto.
- The verdict is binary. Approve or reject, with severity-ranked findings and the production arithmetic behind each one. An agent can act on that; it can't act on vibes about vibes.
What it catches on day one
A real first-session verdict from our production gateway: AI-written payment code, REJECTED at 30.8/100 — an N+1 making ~100 sequential roundtrips (~10–20s, straight into Stripe's rate limit), a nonexistent stripe.Inventory SDK resource, and float dollars where the API takes integer cents. Three findings, each an afternoon of production debugging, caught before the merge.
Vibe coding with a gate is just delegation with standards — which is how every good team already works. Start the 30-day trial (no card), paste the setup prompt, and let the first rejection make the case.