In February 2025, Andrej Karpathy gave a name to a habit a lot of developers had already quietly adopted: "vibe coding"—describing what you want to an AI assistant, accepting the diff, and barely reading the code in between. By April the phrase was everywhere, and so was the practice. A feature that used to take a week now lands in an afternoon. That is genuinely useful, and it is not going away. The problem is the second half of the sentence nobody finishes: code reaches production faster than the processes most teams built to verify it. As the CTO at Softechinfra, I review releases across our web development projects, and the question I get most often this spring is not "should we use AI to write code?"—that ship has sailed—but "how do we let people vibe-code without it blowing up in production?" This is the guardrail set we actually run.
The Gap Vibe Coding Opens
Vibe coding is not bad. It is a step-change in how fast intent becomes a running feature, and on the early, exploratory end of a project it is a superpower. The danger is purely structural: the bottleneck used to be writing the code, and writing was where understanding happened. Remove the writing, and you can ship a feature whose behavior nobody on the team actually understands.
That gap shows up in three predictable ways:
Plausible-but-wrong
AI output compiles, passes the happy path, and reads cleanly—while quietly mishandling an edge case, a timezone, or an empty array. It looks reviewed because it looks tidy.
Invisible dependencies
An assistant reaches for a package, an API call, or a pattern the team never chose. Each one is a new thing to patch, secure, and reason about—added without a decision.
Orphaned code
Nobody wrote it, so nobody owns it. When it breaks at 2am, the on-call engineer is reverse-engineering a feature for the first time during the incident.
None of these are arguments against AI-assisted development—we wrote about the upside at length in our guide to AI code generation. They are arguments for putting verification back where the writing used to be. The speed you gain from generation has to be partly reinvested in checking, or you are not shipping faster—you are just deferring the cost to your future self with interest.
The Production-Readiness Checklist
Before any AI-assisted change merges to a branch that deploys, it clears the same gate as hand-written code—no exceptions, no "but the AI wrote it" discount. The gate is five binary checks:
- A human who understands the change has read it line by line and can explain what it does without the AI in the room
- Automated tests cover the new behavior, including at least one failure path—not just the happy case the assistant demonstrated
- The full CI suite is green on the release branch, including lint, type-check, and existing regression tests
- A dependency and secrets scan has run, and any new package the assistant introduced is justified and pinned
- The change has a named owner who is accountable for it in production
The first check is the one teams are tempted to skip, and it is the one that matters most. The rule we enforce is simple: if you merged it, you can explain it. "The AI wrote it" is not an acceptable answer to "why does this work?" in a review. This single norm does more to keep quality up than any tool, because it forces the understanding back into a human head before the code is load-bearing.
Review Gates: Trust the Code, Not the Author
Once you accept that the author of a change might be a language model, "I trust this developer" stops being a useful basis for review. You have to trust the code itself, and that means the review has to get more rigorous, not less, as generation gets faster.
We grade every change by blast radius and apply review depth accordingly:
| Change Type | Examples | Review Depth |
|---|---|---|
| Low blast radius | Copy changes, isolated UI, internal tooling, throwaway scripts | One reviewer, fast pass |
| Medium blast radius | New endpoints, shared components, data transformations | Line-by-line read plus test verification |
| High blast radius | Auth, payments, migrations, anything touching user data or money | Two reviewers, manual test, no AI-only authorship allowed |
The high-blast-radius row is non-negotiable. Authentication and authorization code in particular should never be vibe-coded straight to production—the cost of a subtle mistake is the whole system. We learned that lesson loudly when a middleware auth-bypass vulnerability hit Next.js applications in March 2025; we wrote up the response in our Next.js CVE post-mortem, and the durable takeaway—never trust a single layer, defend in depth—applies double to code a model wrote in seconds. The broader engineering hygiene here lives in our secure software development guide.
Tests as the Real Safety Net
Reviews catch what a human notices. Tests catch what nobody thought to look at—and with AI generation, the volume of code that nobody looked at carefully goes up. That makes the test suite the load-bearing guardrail, not the optional extra.
There is a pleasant symmetry here: the same assistants that write the code are excellent at writing the tests, if you ask them the right way. We have the assistant generate tests before or alongside the implementation, and we are explicit about wanting failure paths—empty inputs, nulls, concurrent access, the malformed request—not just the case it already knows works. Then a human reads the assertions, because a test that asserts the wrong thing is worse than no test: it is false confidence with a green checkmark.
The non-negotiables we enforce in CI:
New behavior ships with new tests
A pull request that adds behavior and no tests is incomplete by definition. The assistant generates the first draft; a human validates the assertions actually encode the intended behavior.
Failure paths are explicit
For every feature, at least one test proves it fails safely—rejecting bad input, handling the empty case, surviving the timeout—rather than only proving it succeeds when everything is perfect.
The suite gates the merge
Red CI blocks the merge button, full stop. The whole point of automation is that the rule does not bend under deadline pressure the way a tired human reviewer does.
On ExamReady, our exam-preparation platform, the scoring and timing logic carries the highest test coverage in the codebase precisely because it is the area where a plausible-but-wrong change does the most damage—a mis-scored mock test quietly erodes the trust the whole product depends on. The settings screens, by contrast, get a smoke test and move on. Test effort follows blast radius, exactly like review depth.
Security Scanning and Dependency Hygiene
AI assistants are trained on enormous corpora of public code, which means they cheerfully reproduce the average—including the average's insecure patterns and its taste for pulling in a dependency to solve a one-line problem. Two automated scans, wired into CI so they cannot be skipped, close most of that gap.
The dependency discipline deserves its own emphasis. Every package an assistant adds is a new thing to keep patched, a new supply-chain surface, and a new license to clear. The rule we apply: a new dependency is a decision, and decisions get made by people, not pattern-matched in by a model. If the assistant reaches for a library, the human asks whether the standard library or an existing dependency already does the job—usually it does.
Ownership: The Guardrail That Holds the Rest Up
Every other guardrail rests on one foundation: a named human owns each change. Not "the AI" and not "the team"—a person whose name is on the commit and who is accountable when it runs in production. The moment ownership goes fuzzy, the review gets perfunctory, the tests get skipped, and the orphaned-code failure mode arrives on schedule.
This is also why vibe coding and good engineering culture are not in tension. Used inside these guardrails, AI assistants let your strongest engineers spend their judgment where it matters—on architecture, edge cases, and the explain-it-back review—instead of on boilerplate. We covered the team-level rollout of that shift in our AI coding assistant adoption playbook; the short version is that you measure outcomes that survived production, not lines of code generated.
We hold ourselves to exactly this on our own products. On TalkDrill, our in-house English-speaking practice app, AI accelerates how we build the surrounding features—but the speech-scoring and payment flows clear every gate above before they ship, because those are the parts where "looks correct" is not good enough.
The tooling will keep churning; the assistants that feel cutting-edge as I write this will look quaint soon enough. The guardrails do not churn. A human who can explain the change, tests that prove the failure path, a green pipeline, a security scan, and one name on the commit: a team that practices those five things can vibe-code as fast as the tools allow and still sleep through the night. Adopt the speed—just put the rigor back at the edge of production, where it always belonged.
Shipping AI-Generated Code to Production?
We help teams adopt AI-assisted development without sacrificing reliability—review gates, test strategy, security scanning, and release processes that keep up with fast shipping.
Talk to Our Engineering Team
