Vibe Coding in Production: Code That Compiles Is Not Code That Was Fine

In February 2025, Andrej Karpathy posted a tweet that put a name to something that was already happening: "vibe coding" — describe an intent in natural language, accept whatever the AI generates, and move on without reading the diffs. A year later, Karpathy himself wrote that the term was already obsolete for professional use. His proposed replacement was "agentic engineering": orchestrating agents with active supervision, not riding the vibes — which, not coincidentally, is the subject of our previous article.

That retraction from the term's own author is the best warning available. Vibe coding was born for weekend prototypes. The problem is what happened next: the same practice Karpathy conceived as a game is now being used to build software that touches real data, real users, and in some cases medical or financial information.

This article is not about whether vibe coding "works". It works, and works well, for what it was designed for. It is about what happens when an application built that way crosses the line from demo to production without anyone auditing that crossing — and about what concrete evidence, not speculation, exists today for what goes wrong when it does.

Why isn't code that works the same as code that's fine?

Because "works" and "is correct" are verified in completely different ways, and vibe coding only optimizes for the first one. A model produces a function that compiles, passes the developer's manual spot-check, and handles the happy path. That says nothing about what happens when someone sends a malicious input, an endpoint receives an attacker-controlled URL, or a dependency the model imported never actually existed.

The real security risk in AI-assisted development is not just one vulnerable function or one exposed dependency: it is the false confidence produced by systems that look finished before anyone has actually tested, questioned, and understood them. That is the core of the problem, and that is why this article's title doesn't talk about "risks" in the abstract: it talks about the gap between compiling and being fine.

2026 evidence confirms that gap isn't closing with better models. A Veracode analysis from March 2026 found the security-test pass rate held flat at roughly 55%, with no improvement, while coding-capability benchmarks kept climbing over the same period — and larger models did not outperform smaller ones on security. Translated: AI writes functionally better code every month. It does not write safer code.

Which security risks show up most often?

Four categories keep recurring in the available evidence, and none of them is hypothetical.

Access-control failures. This is OWASP's own Top 10 category number one, and vibe coding makes it worse because every prompt can produce a slightly different implementation of the same control. A Tenzai study from December 2025 tested five leading coding agents on the same type of functionality, and all five introduced an SSRF vulnerability — five for five, one hundred percent.

Exposed secrets and credentials. IBM documented that 64% of credentials exposed in vibe-coded applications were still active and unrevoked as of January 2026, including a case — Football Australia — where AWS keys sat exposed in the site's source code for more than 700 days. This is not a rare bug: it's what happens when nobody audits what ends up written into the repository.

Dependencies that don't exist. A Cloud Security Alliance research note from April 2026, covering 2.23 million samples of AI-generated code across 16 models, found that 19.7% contained at least one hallucinated package name that doesn't actually exist. This opens the door to "slopsquatting": an attacker registers that invented package name, and the next developer who generates similar code installs malware without knowing it.

Classic injection vulnerabilities, at greater scale. Research from New York University found that 45% of code generated by Copilot contained at least one OWASP Top 10 issue, concentrated in injection, authentication failures, and security misconfiguration. None of this is new in the history of software security. What's new is the speed at which it's being produced.

OWASP itself now recognizes this as a phenomenon, not an anecdote. The 2025 Top 10 update explicitly notes that development practices are shifting toward code written and merged with almost no human oversight — what's commonly called vibe coding — and warns that whoever commits code must be able to fully read and understand any code they submit, whether AI-written or not. When the industry's reference standard dedicates a section to this, that's a signal it stopped being a Twitter debate.

What happens to architecture when nobody designed it, only generated it?

A different kind of technical debt piles up: not "ugly code that works," but architectural decisions nobody consciously made. An agent solves each prompt locally and optimally for that prompt. It has no memory of the rest of the system beyond what you explicitly pass it, so the same authorization problem can end up solved three different ways across three endpoints, because each one was generated in a different session.

That pattern has a measurable effect on how code gets integrated into a real repository. Developers working with AI assistance produce more than triple the commits of their non-AI peers, but bundle them into significantly fewer and much larger pull requests. It is the least desirable combination possible for human review: more changes, packaged into blocks that are harder to audit one by one.

The result in production, measured with real analysis tooling, isn't ambiguous. Apiiro deployed its code-analysis engine across tens of thousands of repositories at Fortune 50 companies between December 2024 and June 2025: AI-assisted developers committed code at a rate three to four times higher than their peers, and monthly security findings rose from roughly 1,000 to more than 10,000 — a tenfold increase in six months. It's not that AI introduces a new type of vulnerability. It's that it multiplies the volume of code without multiplying the capacity to review it.

What does a pipeline that doesn't let vibe coding through unfiltered look like?

You don't have to ban vibe coding to manage it. You need the CI/CD pipeline to assume, by default, that any change might have been generated without anyone reading it carefully — and treat it accordingly.

A reasonable starting point, in a GitHub Actions workflow:

# .github/workflows/pr-gate.yml
name: Pull request quality gate

on:
  pull_request:
    branches: [main]

jobs:
  quality-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1. Nobody merges secrets into the repo, human-written or AI-written.
      - name: Secret scanning
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

      # 2. If the package name doesn't exist, the build fails here,
      #    not on an attacker's production server.
      - name: Dependency verification
        run: |
          npm ci --strict-peer-deps
          npm audit --audit-level=high

      # 3. Strict typing as the cheapest hallucination detector.
      - name: Type check
        run: npx tsc --noEmit

      # 4. Tests + minimum coverage. Without this, there's no source of truth.
      - name: Tests with coverage
        run: npm run test -- --coverage --coverageThreshold='{"global":{"lines":70}}'

      # 5. SAST targeting patterns common in AI-generated code
      #    (client-only auth, permissive CORS, missing rate limiting).
      - name: Static security analysis
        uses: github/codeql-action/analyze@v3

  human-review-gate:
    needs: quality-gate
    runs-on: ubuntu-latest
    steps:
      - name: Require at least one human approval
        run: echo "Configured as a branch protection rule, not a step: 1 review minimum, no auto-merge."

What matters here isn't the specific tool for each step — that changes depending on your stack — but the order: no step in this pipeline trusts that the code "looks fine". Each one verifies one concrete claim and fails loudly if that claim is false. And the last step, human approval, is neither negotiable nor automatable: it's the gate that decides whether something enters main, and by design it can't be skipped with a config flag.

It's worth measuring this explicitly instead of assuming "we already reviewed it": how much time goes into generating code versus how much goes into rereading it, questioning it, and understanding it before approving it. If that ratio tilts heavily toward generation, the speed you gained by writing it is the speed you're losing — or worse, inheriting as incidents — later on.

Who's responsible for the code when an agent wrote it?

Legally and operationally, the person who approved and deployed it. That doesn't change because the material author was a model. But in practice, the question that causes the most trouble isn't "whose fault is it when something breaks?" — it's a more boring and more frequent one: who maintains this six months from now?

When the person who built a vibe-coded application leaves the team or changes roles, and there's no clear process for handing off responsibility, the result is what's often called "zombie apps": applications that keep running, that nobody fully understands, and that accumulate silently through normal staff turnover. In a clinic or a mid-size company in Venezuela, where technical teams tend to be small, that risk isn't hypothetical: it's exactly the kind of internal application someone quickly generated to solve a one-off problem, that nobody knows how to safely touch two years later.

The answer isn't to ban people from using these tools to solve problems quickly. It's to require, before anything built that way touches a system with real data, three things that don't depend on the model: an identified, documented human owner, a repository with real history (not the final export of a chat session), and an explicit decision that the code moves into formal maintenance, under the same review standards as the rest of the system. If nobody can or will sign off on those three conditions, the right conclusion isn't "we'll fix it later." It's that the application shouldn't be in production yet.

What should a team do before taking vibe coding to production?

Three decisions, in order of importance.

First, draw the line between prototype and production explicitly, don't let it happen on its own. A prototype that "works fine in the demo" and gets deployed because nobody said no is the most common way these risks materialize. The line should be a conscious decision, backed by a checklist — security, dependencies, ownership — not inertia.

Second, flip the time-spending ratio. If generating a function takes minutes and reviewing it carefully takes longer than that, that ratio is correct, not wasteful. The warning sign is the opposite one: when generation time far outstrips review time, that's where the security findings pile up that end up costing far more than the time you saved.

Third, treat the CI/CD pipeline as the real verifier, not a formality. Secret scanning, dependency verification, strict typing, and mandatory human approval aren't bureaucracy: they're the only layers that catch what a successful demo doesn't reveal.

Vibe coding isn't the problem. Treating "it compiles and works" as synonymous with "it's ready for production" is. The difference between a team that benefits from this and one that accumulates incidents isn't which model they use. It's whether they built the verification system before trusting the speed.

Frequently asked questions

What is the difference between vibe coding and agentic development?

Vibe coding, as Andrej Karpathy defined it in 2025, describes accepting AI-generated code without reviewing the changes line by line, originally meant for throwaway projects. Agentic development — the term Karpathy himself later proposed as a replacement for professional use — means orchestrating agents with active supervision: output validation, a step budget, and human review before a change is merged. The distinction is not cosmetic: it is the difference between trusting and verifying.

Is it safe to take a vibe-coded application to production?

It can be, but not by default. 2026 evidence shows vulnerability rates holding steady around 45-55% in code generated without supervision, and specific risk categories — access control, exposed secrets, nonexistent dependencies — that show up far more often than in code that got human review. It is safe when it passes through the same security controls as any other code before touching real data, not when it "worked in the demo".

What minimum controls does a CI/CD pipeline need for AI-generated code?

At minimum: secret scanning before every merge, verification that declared dependencies actually exist, strict typing, a test suite with an enforced minimum coverage threshold, and a branch protection rule that blocks merging without at least one human approval. None of these controls is exclusive to AI-generated code — they are longstanding good practice — but they become non-negotiable once the volume of change grows faster than the team's capacity to review it one PR at a time.

Who is responsible if an AI-generated application fails in production?

The person or team who approved and deployed it, not the tool. That is why every application moving from prototype to production needs an identified human owner, a repository with a real history of changes, and an explicit decision that it now enters formal maintenance under the same standards as the rest of the system. Without those three conditions, the risk is not just technical: it is that a year from now nobody knows who can safely touch that code.