Vibe coding is as safe as the verification you attach to it. The speed of describing a feature and accepting generated code isn't inherently risky — shipping that code with no independent check is. Teams that gate merges on deterministic verification get the speed without inheriting the failure rate.

Do I need to review every line of AI-generated code?

No — and trying kills the speed that made vibe coding worth doing, while still missing provider-specific requirements reviewers don't have memorized. Let deterministic checks cover the known failure categories in CI, and spend human attention on architecture, product logic, and the diffs the checks flag.

What checks should run on AI-generated code before merge?

At minimum: your test suite, a secrets scan, dependency verification against real registries, and a deterministic API-integration check like api-doctor that knows provider requirements (idempotency keys, webhook signatures, tenant scoping, error handling). The principle: the checks must not share the generator's blind spots.

Why not just ask the coding agent to double-check its own work?

Because the reviewing model shares the training priors that produced the bug. Self-review is least reliable on confident, plausible, wrong patterns — exactly the ones that dominate AI integration failures. A deterministic gate doesn't share those priors and gives the same verdict every run.

Vibe Coding Isn't the Problem. Skipping Verification Is.

Quick Answer

Vibe coding — describe what you want, let the agent write it, accept it, move on — is not what's putting bugs in production. Skipping verification is. The evidence that AI-generated code fails at high rates is real (covered in depth here), but the failure isn't generation speed. It's that most teams either ship agent output unchecked or try to hand-review every line and quietly give up. The fix is structural: a deterministic check that runs automatically in CI, between "agent writes code" and "code merges" — fast enough to keep the loop fast, strict enough to catch the bug categories the data says are common.

The wrong lesson from the scary numbers

The statistics have produced a predictable split. One camp concludes vibe coding is reckless — real engineers review every line. The other keeps shipping and hopes the numbers are someone else's problem. Both are drawing a lesson about speed from data that's actually about verification.

Fast code generation was never the risk. Compilers generate code fast, and nobody audits their assembly, because the output is verified by decades of testing and the type system. The risk was always shipping code nothing independent has checked. Vibe coding just industrialized it: generation got 100x faster, verification stayed manual, and the gap became the failure rate.

So the useful question isn't "is vibe coding safe?" It's "what does verification look like when generation is nearly free?"

The two failure modes teams actually adopt

Mode 1: ship it. The code ran, the feature works in the browser, merge. This is the mode the breach case studies are made of. It's a category error — treating "it ran" as evidence of correctness, when AI integration bugs are invisible in the happy path. The demo can't show a missing idempotency key or a query that returns every tenant's rows; the demo has one user and no retries.

Mode 2: review everything. Every AI PR gets line-by-line human review. This fails more slowly but just as surely. It deletes the economics — a senior engineer reading every line at pre-agent speed bought you a faster typist, not a faster team. It doesn't catch the bugs either: the failure categories are provider-specific requirements reviewers don't have memorized, and the code looks complete. A reviewer who's never read Resend's idempotency docs approves the send function without an idempotency key every time. And attention decays — PR #3 gets scrutiny, PR #40 gets a scroll and an approve.

Both modes treat verification as a human judgment call — skipped or heroic — instead of as infrastructure.

What the fix looks like

Teams getting this right haven't slowed their agents. They've inserted a gate the loop can't skip: a deterministic check on every PR, with merge gated on the result. Four properties matter:

Automatic. It runs because a PR exists, not because someone remembered. Our telemetry says this is the gap — under one run in ten happens in CI today.
Deterministic. Same code in, same findings out. A reviewer (human or LLM) that flags a bug Tuesday and misses it Thursday can't gate a merge. AST rules can — and they don't share the generator's training priors.
Fast. Seconds, not minutes, or the team routes around it.
Specific. A finding with a rule ID, file, line, and documented fix is something an agent can act on. "Something looks off" isn't.

Note what's not on the list: exhaustive. The gate needs to reliably catch the known, repeatable categories — where the volume is — so human attention goes where it's valuable: architecture, product logic, and the PRs the gate flagged.

The loop with the gate in place

Prompt. "Add transactional email on signup, use Resend."
Generate. The agent writes client setup, send call, webhook handler. Ninety seconds.
Accept. You skim the diff for intent and open the PR. You don't go read Resend's docs — you don't have to.
Gate. The api-doctor check runs on the PR. It knows what neither you nor the agent had loaded: the send call has no idempotency key, and the webhook handler never verifies the signature. Two findings, each with a rule ID and documented fix. Merge blocked — by an exit code, not by a person having a busy day.
Fix in the loop. The findings land with the agent that's already there (installed as a skill, it scans, reads the report, and fixes). Rule-level findings are exactly the feedback agents act on well — this review step gets faster with an agent.
Merge. Total added wall-clock: a couple of minutes, mostly agent time.

Your experience of vibe coding is unchanged. What changed is that "accept" no longer means "personally vouch for provider requirements you've never read."

Setting it up

Two pieces, both one-time. The CI gate is a GitHub App, not a workflow file: go to apidoctor.co/ci, connect your GitHub account, pick the repos. No YAML, no runner config. The App scans every PR and reports findings as a check; error-severity findings fail it, so marking the check required in branch protection is the entire gating mechanism. The rules update on our side as provider SDKs change, so the gate improves without your team touching it.

The second piece: npx @api-doctor/cli install registers api-doctor as a skill for your coding agent, so the agent that wrote the code can fix its own findings before the PR even reaches CI. The skill makes the loop fast; the gate makes it safe. Only the skill, and you're back to trusting the check gets run. Only the gate, and you're fixing by hand.

One deliberate non-feature: no "warn but allow merge" default. A gate that can be waved through on a busy Friday is a suggestion with a dashboard — exactly the posture that produced the current failure rates.

"But that only covers API integrations"

True. api-doctor covers the integration layer — the seams between your code and Supabase, Resend, Auth0, and the rest. That's where a disproportionate share of agent bugs concentrate, but you still want your test suite, a secrets scanner, and dependency verification in the same pipeline. The principle generalizes even where the tool doesn't: every known category of agent failure should have an automatic, deterministic check in front of merge. The categories are knowable, so a missing check is a choice.

The reframe

"Is vibe coding safe?" is the wrong question, the way "is merging code safe?" is the wrong question. Merging is safe when CI is green — verification is infrastructure, so trust is cheap. Vibe coding is in its awkward adolescence: generation became infrastructure overnight, verification is still artisanal. Fix the asymmetry and you get what the optimists promised. Don't, and you keep generating the case studies.

Install the gate: connect the CI check, or npx @api-doctor/cli install for the agent-side skill — and let every PR get verified whether anyone remembers or not.