Vibe Coding in Production: Patterns, Pitfalls and Guardrails (2026)

In February 2025 a casual social media post gave a name to something developers were already doing at midnight: describe what you want, accept whatever the model produces, paste error messages back in, and never read the diff. Twenty months later, vibe coding is a dictionary entry, a funding category and a line item in security audits. The uncomfortable part is that the same behaviour that makes a weekend prototype delightful makes a payments service dangerous, and the tools do not know the difference. Your agent will happily write the migration, the retry loop and the authentication check with the same confident tone.

This article is for engineers and engineering leads who have to decide what happens after the demo. It separates the original meaning of the term from the broader “AI-assisted engineering” that most teams actually practise, shows where the evidence says things go wrong, and lays out a control system (spec, sandbox, tests, CI gates, review, observability) that lets you keep the speed without inheriting the incidents.

What this covers: the definition and origin of vibe coding, where it works and where it fails, what the published studies do and do not show, spec-driven development, the agentic tool landscape, the guardrail pipeline, team workflow, maintainability debt, a decision matrix and the failure modes that keep recurring.

Context and Background

The term comes from a post by Andrej Karpathy on 2 February 2025. As widely quoted, he described “a new kind of coding I call vibe coding”, in which you “fully give in to the vibes” and forget that the code even exists. In that account he used Cursor’s Composer with a Claude Sonnet model, dictated requests by voice, accepted changes without reading diffs, and copied error messages straight back to the model. He framed the approach as fine for throwaway weekend projects. Collins Dictionary later named “vibe coding” its Word of the Year for 2025, which tells you how quickly the phrase left its original niche.

The original definition matters because it is narrow. Simon Willison made the point in March 2025 that not all AI-assisted programming is vibe coding: if you review, test and understand the code an LLM wrote, you are using the model as a typing assistant, which is a different activity with a different risk profile. In this article, vibe coding means accepting generated code without meaningful comprehension or review, and agentic engineering or AI-assisted engineering means the disciplined version, in which an agent does much of the typing but a human owns the design, the tests and the merge decision. Most of what is sold as vibe coding to enterprises is, or should be, the second thing.

The tooling arrived in layers. Inline completion (GitHub Copilot, generally available in 2022) predicted the next few lines. Chat-in-the-editor tools added multi-file edits. Agentic tools such as Claude Code, Cursor’s agent mode, OpenAI Codex, Gemini CLI, Cline and others went further: they read the repository, plan, edit many files, run the test suite and the compiler, observe the failures and iterate. App-generation platforms (Lovable, Bolt, Replit Agent and similar) pushed the idea to its limit by letting people with no programming background produce deployed applications. Our earlier explainers on Claude Skills architecture and the Model Context Protocol cover the plumbing that lets these agents load procedures and call tools.

Adoption is no longer in question. The 2025 DORA report on AI-assisted software development, summarised by InfoQ, surveyed nearly 5,000 technology professionals and reported that close to 90 percent use AI in their work. The same summary reports that AI adoption now correlates positively with delivery throughput, but that software delivery instability continues to rise. That pairing is the whole story of this article in one sentence: faster output, and a quality system that has not caught up.

Why does this matter more in 2026 than in 2025? Because agents now run longer unattended. A model that produced forty lines per request in 2024 can in 2026 work for tens of minutes, touching dozens of files, running commands and making infrastructure changes. The blast radius of an unreviewed accept has grown from “a bad function” to “a bad pull request, a bad migration or a bad deploy”. Controls that were optional for autocomplete are mandatory for agents.

The Production Control Loop: A Reference Architecture

Figure 1: The control loop around an agent. Every arrow back to the agent is a feedback path that is cheap; every arrow forward is a gate that is expensive to skip.

Direct answer: Production-grade vibe coding means wrapping the agent in the same controls you would demand of a new junior contractor with root access: a written spec, a sandboxed workspace, automated tests the agent cannot weaken, CI security gates, human review focused on the diff and the tests, staged rollout and fast rollback. The model is not the control; the pipeline around it is.

Figure 1 shows the loop. The agent works inside a tight inner cycle of edit, lint, type-check and test, which is cheap and fast. Only code that survives that cycle becomes a pull request. The pull request then faces gates the agent cannot modify: static analysis, dependency and secret scanning, coverage and mutation checks, and a human reviewer. Only after approval does code reach a staged rollout where observability and rollback close the loop. The dashed line back to the spec is the part teams forget: incidents should change the spec and the rules file, not just the code.

Principle one: the agent proposes, the pipeline disposes

A language model is a probabilistic generator conditioned on context. It has no stake in your uptime, and it can be wrong with the same fluency it is right. The first design principle is therefore that nothing the agent says about its own work is evidence. “All tests pass” in the agent’s summary is a claim; the CI log is evidence. This sounds obvious, but a large fraction of the incidents later in this article trace back to trusting the narrative instead of the artefact.

Operationally this means the agent’s permissions should be a strict subset of the developer’s. It can write to a feature branch, but not to main. It can run tests, but not edit the CI configuration or the test-runner thresholds. It can read a development database, but never hold production credentials. Those are plain least-privilege rules, and they matter more when the actor is non-deterministic. If the agent can edit the thing that checks it, you do not have a check.

Principle two: make the cheap feedback loop as fast as possible

Agent quality is dominated by feedback. A model that can run the type-checker in two seconds and the unit tests in thirty will converge on correct code far more often than the same model with a ten-minute test suite it is tempted to skip. Investing in fast, deterministic local verification is the highest-leverage thing you can do for agentic coding. Typed languages, strict compiler flags, linters with autofix, hermetic unit tests and a single command that runs everything (make check or equivalent) act as a steering mechanism: they turn vague intent into concrete red and green signals the agent can act on without human help.

A useful rule of thumb, which is an engineering heuristic rather than a measured law: if a human cannot tell within a minute whether a change is plausibly correct, the agent cannot either, and you should expect it to guess. Slow or flaky test suites do not just waste time; they teach the agent that failures are noise.

Principle three: context is a deliverable

Agents read a rules file (commonly CLAUDE.md, AGENTS.md, or a tool-specific equivalent such as Cursor rules) at the start of a session. This is the cheapest and most underused control. A good rules file states the stack and versions, the commands for build, test and lint, the module boundaries, the forbidden patterns (no dynamic SQL, no new dependencies without a note, no changes under infra/ without a human), the error-handling convention and the definition of done. Keep it short enough that it gets read: bloated instruction files dilute the rules that matter, and models follow a focused page better than a hundred-line wish list.

Treat the rules file as code. Review changes to it, version it, and update it when a postmortem finds a class of mistake the agent keeps making. Teams that do this report, anecdotally, that the same classes of review comment stop recurring, because the comment has been converted from a human chore into a standing instruction. That is a reasonable expectation, but note it is anecdote, not a benchmark.

Principle four: bound the blast radius structurally

Do not rely on instructions such as “never touch production” to prevent damage. Instructions are suggestions to a probabilistic system. Enforce boundaries with infrastructure: separate accounts or projects for development and production, read-only replicas for exploration, short-lived scoped tokens, network egress limits in the sandbox, and branch protection that cannot be bypassed by the agent’s credentials. The July 2025 incident in which an AI coding assistant on the Replit platform deleted a live production database during a declared code freeze, as reported by eWeek, is the canonical illustration. The user said he had instructed the system not to make changes without approval; the commands ran anyway. The vendor’s response was structural, not rhetorical: automatic separation of development and production databases, a planning-only mode and one-click restoration from backups. Those are exactly the controls that should have existed before the agent had the ability to run the commands.

Where Vibe Coding Works and Where It Fails

The right question is not “is vibe coding good?” but “what is the cost of being wrong here, and how quickly will I find out?” Value is highest where errors are cheap and visible, and risk is highest where errors are expensive and silent.

Figure 2: A risk ladder. The more severe and less visible the failure, the more review and testing the same generated code needs.

Where it works well

Throwaway prototypes and spikes. If the output will be discarded, or exists to answer a question (“can we parse this vendor file format?”), reading every line is a poor use of time. This is Karpathy’s original use case and it remains sound. The discipline is to actually throw it away, or to rewrite it, rather than letting a spike quietly become the product.

Internal tools with a small, known audience. Admin dashboards, one-off data migrations that you verify by diffing outputs, report generators and CLI utilities have low blast radius. Failure is noticed quickly by the three people who use them. Even so, the tool should not hold broad credentials; many internal tools turn out to be the soft underbelly of a company’s data access.

Boilerplate and mechanical transformations. Adapters, serialisers, test scaffolding, API client generation from a schema and large renames are tasks with a clear oracle (the compiler, the schema, the existing tests). Agents are good here because correctness is mechanically checkable.

Tests, documentation and refactors with a safety net. Generating characterisation tests for legacy code, then refactoring against them, is a high-value pattern: the tests pin current behaviour and the agent can iterate until they pass. The caution is that the generated tests encode whatever the code currently does, bugs included.

Learning and exploration. Asking an agent to implement something you do not know how to do, then reading and questioning the result, can compress learning. It only works if you read.

Where it fails

Security-sensitive paths. Authentication, authorisation, cryptography, input handling, session management and anything that parses untrusted data. These are areas where code that looks right and passes the happy-path test is exactly the failure mode. We return to the evidence below.

Concurrency, distributed state and failure handling. Race conditions, idempotency, retry storms, exactly-once illusions and partial failures do not show up in a single-threaded unit test. Models write plausible-looking locking and retry code that is wrong in ways only a design review or a fault-injection test reveals. For a feel for how subtle these are, read our write-up on Raft versus Paxos failure modes.

Large, mature codebases with implicit conventions. The randomized trial discussed below found slowdowns precisely here, where the human already holds a detailed mental model and the agent must reconstruct it from files.

Anything with weak oracles. If there is no test, no type, no schema and no quick way to observe wrongness (pricing logic, compliance rules, medical or safety calculations), the model’s output cannot be mechanically validated, so the entire burden falls on review.

Dependency and supply-chain decisions. Agents add packages freely, sometimes pick abandoned ones and, as widely reported by security researchers, sometimes recommend package names that do not exist, which attackers can then register. Any new dependency should be a deliberate, reviewed event; see our guide to SBOM and VEX for supply-chain triage.

What the Evidence Actually Shows

The public conversation is dominated by anecdotes at both ends: “10x productivity” and “it deleted my database”. A handful of studies give firmer ground, and each has limits worth stating.

The METR randomized controlled trial

METR ran a randomized controlled trial in early 2025, described in an arXiv paper. Sixteen experienced open-source developers, who averaged about five years on their own repositories, worked on 246 real issues. Each issue was randomly assigned to allow or disallow AI tools; the tools were mainly Cursor Pro with Claude 3.5 and 3.7 Sonnet. Developers forecast that AI would cut completion time by 24 percent, and after the study still believed it had cut time by about 20 percent. The measured result was a 19 percent increase in completion time.

The authors are careful about scope, and so should we be. This was a small sample, in mature codebases the developers knew intimately, with tools that have since improved. It does not show that AI never helps. What it does show is a perception gap: the people doing the work felt faster while being slower, which is a warning against using self-reported productivity as your only metric. If you adopt agents, measure cycle time, change failure rate and review load rather than asking people how they feel.

Veracode’s GenAI code security study

Veracode’s 2025 GenAI Code Security Report, announced in a press release, tested more than 100 large language models on 80 curated coding tasks designed so that one secure and one insecure implementation were possible. According to Veracode, the models introduced OWASP Top 10 vulnerabilities in 45 percent of test cases. By language, Java was the worst, with a security failure rate above 70 percent, while Python, C# and JavaScript ranged from 38 to 45 percent. For cross-site scripting and log injection the models failed in 86 and 88 percent of cases respectively. Veracode also reported that syntax accuracy improved over time while security performance stayed flat, and that larger models did not do significantly better than smaller ones.

Read this with its method in mind. It is a vendor study using synthetic tasks that deliberately offer a choice between secure and insecure code, so the 45 percent is not the rate at which real pull requests contain exploitable bugs. But the shape is informative: functional correctness and security are different axes, and scaling model size has not moved the second. A model optimised to make tests pass has little incentive to add the output encoding nobody asked for.

DORA and the amplifier effect

The DORA 2025 findings, as summarised by InfoQ, say AI adoption now has a positive relationship with throughput while instability still climbs, and that the “fail fast, fix fast” idea did not offset the instability. DORA’s framing, in the coverage we reviewed, is that AI acts as an amplifier of whatever engineering system it enters; the report proposes a model of seven organisational capabilities that magnify the benefit. We cannot list them reliably from the secondary sources we checked, so consult the report itself. The practical reading holds regardless: strong version control, small batches, good tests and fast feedback make AI help; their absence makes AI hurt faster.

What we do not know

There is no authoritative, independent measure of the defect rate of agent-written code in real production repositories, nor a trustworthy estimate of lifetime maintenance cost. Claims such as “AI code has X times more bugs” circulating on social media are rarely backed by controlled data. Treat anyone quoting a precise multiplier without a method as selling something. The honest position is that risk is real, concentrated in security and in unreviewed volume, and best managed by controls rather than by prohibition.

Spec-Driven Development: Replacing Vibes with Intent

The most important pattern to emerge since the original post is spec-driven development (SDD). The insight is simple: vibe coding fails when intent lives only in a chat transcript. The prompt is ephemeral, the model’s interpretation is invisible, and six weeks later nobody can say why the code does what it does. SDD moves intent into versioned documents that the agent reads and the team reviews.

Figure 3: The spec-driven loop. The spec, plan and task list are reviewed artefacts; tests derive from the spec; drift sends you back to the spec rather than patching code silently.

GitHub’s open-source Spec Kit is the most visible example. Its documentation describes an intent-driven toolkit that guides coding agents through phases: specify what to build, plan how, break the plan into tasks, then implement. Each phase produces a Markdown artefact that feeds the next, and the project lists dozens of agent integrations, so it is not tied to one vendor. Other tools, including AWS’s Kiro IDE and several open-source projects, follow the same shape under different names. The specific tool is less important than the discipline.

What a useful spec contains

A spec is not a long prompt. It is a short document that answers, in order: what problem this solves and for whom; the observable behaviour in concrete examples (inputs and expected outputs, including error cases); non-goals; constraints (performance budgets, compatibility, security requirements); and acceptance criteria that can be turned into tests. The most valuable section is non-goals, because agents tend to over-deliver: add a caching layer, refactor an unrelated module, “improve” an interface. A line such as “do not change the public API of the billing module” prevents a surprising amount of review pain.

The plan then records the design decisions: which modules change, which data structures, which libraries, and the reasoning. A reviewer can disagree with a plan in five minutes; disagreeing with a four-hundred-line diff takes an hour. Reviewing the plan before code exists is the cheapest review in software engineering, and SDD makes it routine.

Tasks as the unit of agent work

The task list breaks the plan into steps small enough that each yields a reviewable diff, ideally a few hundred lines at most, with its own tests. This mirrors how good teams already work with small pull requests, but it matters more with agents because long agent runs accumulate drift. An agent given “build the whole feature” will make hundreds of micro-decisions you never see; an agent given “implement task 3 of 9 and make these two tests pass” has little room to wander.

Tests as an executable spec

The strongest form of SDD derives tests from the acceptance criteria before the implementation, in the spirit of test-driven development. The agent then has an objective target, and a reviewer can read the tests to understand intent without reading the implementation. There is one critical safeguard: the agent must not be able to weaken the tests to get green. Protect test directories and thresholds with code-owner rules, and flag any pull request that deletes or loosens assertions. A common failure is an agent that, faced with a failing test it cannot fix, edits the test, adds a skip or special-cases the expected value. Mutation testing, which injects small bugs and checks that tests fail, is a useful audit: generated tests often achieve high line coverage while asserting almost nothing.

The limits of SDD

SDD is not free. Specs can become stale, burying teams in documents nobody reads. A spec precise enough to generate code deterministically is, at the limit, a program written in a worse language. And models still interpret specs: two runs of the same spec can yield different implementations. The sensible stance is to use SDD where intent is non-trivial and the code will live long, and to skip it for spikes. Keep specs short, store them next to the code, and treat a spec that no longer matches reality as a bug.

The Agentic Coding Tool Landscape

Tool names and capabilities move monthly, so treat this section as a map of categories rather than a buyer’s guide; verify current versions and pricing on vendor sites before deciding.

Terminal and CLI agents such as Claude Code, OpenAI Codex CLI and Gemini CLI run in your shell and your checkout. They are strong at repository-wide tasks, scripting and CI integration, and they inherit your environment, which is both their power and their risk: whatever your shell can reach, they can reach unless you sandbox them.

IDE-integrated agents such as Cursor, GitHub Copilot’s agent mode, Windsurf, Cline and Kiro offer inline diffs, approval prompts per edit and tight editor context. They suit interactive pairing, where the human watches each step. Their approval prompts are a real control, but one that degrades: after fifty “accept” clicks, people stop reading, and “auto-accept” settings quietly remove the control entirely.

Cloud and background agents run in remote sandboxes on a branch, open pull requests and report back. This is the model closest to treating the agent as a contractor: it never touches your laptop, its credentials can be tightly scoped, and the output arrives as a standard pull request. The trade-off is slower feedback and the need to provision a faithful environment. Our piece on OpenAI’s agents API and managed versus self-hosted sandboxes discusses that sandbox decision.

App-generation platforms such as Lovable, Bolt and Replit Agent target non-programmers and short time-to-deployed-app. They are the purest vibe coding experience and the one with the weakest default guardrails, because their users often cannot review the code. They are fine for prototypes and personal tools; deploying customer data on an app nobody on the team understands is where incidents are born.

Review and security agents form a newer category: automated reviewers that comment on pull requests, and security scanners that propose fixes. They help, but they inherit the same blind spots as the generators when built on similar models. Use them as an additional filter, never as the sole gate.

The tool-use surface: MCP and permissions

Modern agents extend themselves through the Model Context Protocol and similar mechanisms, connecting to issue trackers, databases, cloud consoles and browsers. Each connected tool is an expansion of the agent’s authority and of the prompt-injection surface: a malicious string in an issue, web page or log line can steer an agent that has write access elsewhere. The defensive posture is the standard one for any confused-deputy risk: scope tokens narrowly, prefer read-only tools, require human confirmation for destructive actions, and log every tool call. Our guides on LLM red teaming and guardrails and AI agent audit logging and identity go deeper on both.

Guardrails in the Pipeline: Review, Test and Security

Figure 4: A guarded agent session. The sandbox gives the agent fast feedback; CI and the reviewer provide independent verification the agent cannot influence.

Figure 4 traces a single task. The developer hands the agent a spec and rules. The agent iterates against the sandbox until local checks pass, then opens a pull request. CI runs checks the agent cannot alter and hands the evidence to the reviewer. Review comments flow back to the agent, and a human, not the agent, merges. The independence of the verification layer is the point.

Layer 1: the sandbox

Run agents in an environment where mistakes are contained: a container or VM with no production credentials, a scratch database seeded with synthetic data, restricted network egress and a filesystem limited to the working tree. Disable or tightly scope “run any command” permissions. Maintain an allowlist for commands that are safe to auto-approve (test runner, linter, formatter) and require confirmation for everything else, especially anything that deletes, migrates, publishes or touches the network.

Layer 2: automated gates in CI

A reasonable baseline for any repository accepting agent-authored code looks like the following. The configuration is illustrative; adapt tool names to your stack.

# .github/workflows/agent-pr-gates.yml  (illustrative)
name: agent-pr-gates
on: [pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install and build
        run: make deps && make build
      - name: Lint and type-check
        run: make lint typecheck
      - name: Unit and integration tests with coverage
        run: make test COVERAGE_MIN=80
      - name: Mutation sample on changed files
        run: make mutate CHANGED_ONLY=1 SCORE_MIN=60
      - name: SAST
        run: semgrep ci --config auto
      - name: Dependency and licence audit
        run: make audit-deps
      - name: Secret scan
        run: gitleaks detect --redact
      - name: Block weakened tests
        run: ./scripts/check-test-diff.sh origin/main

The last step deserves explanation. A simple script can fail the build if a pull request removes assertions, adds skip markers or lowers coverage thresholds, unless a human code owner approves. This single check neutralises the most common way agents “fix” red builds. Pair it with a CODEOWNERS entry that requires a human on CI configuration, infrastructure code, authentication modules and migration folders.

Coverage numbers need care. A coverage threshold is a proxy that agents optimise readily: they can write tests that execute lines without asserting behaviour. Mutation scores, property-based tests and a short list of hand-written invariants for critical logic are stronger signals. The thresholds in the example are placeholders, not recommendations; choose them from your own baseline.

Layer 3: security-specific controls

Given the Veracode finding that models fail OWASP-category tasks in a large share of cases, and that cross-site scripting and log injection are the worst, bake security into both the prompt context and the pipeline. In the rules file, name the required mechanisms: parameterised queries only, a single approved output-encoding helper, a central authorisation check, a vetted cryptography library, no hand-rolled token handling. In the pipeline, run static analysis tuned for your languages, software composition analysis for known-vulnerable packages, secret scanning, and for web apps a dynamic scan against a preview deployment. For identity flows, check against known pitfalls such as those in our OAuth 2.1 and JWT validation guide, because generated authentication code is a frequent source of subtle flaws such as missing audience checks.

Threat-model the agent itself. Prompt injection through repository content, dependency README files or fetched web pages can cause an agent to exfiltrate secrets or insert backdoors. Keep secrets out of the agent’s environment, review any change to build scripts and lockfiles with suspicion, and pin dependencies by hash where feasible.

Layer 4: human review that is actually useful

Review is where the economics shift. Agents can generate code faster than humans can read it, so reviewing every line at the old pace is a bottleneck, while skimming is how defects ship. The way out is to change what reviewers look at.

Review the spec and plan first; if they are wrong, the code is irrelevant. Review the tests second: do they assert the behaviour that matters, including failure paths? Then review the diff for risk hotspots (authorisation, data access, concurrency, external calls, configuration) rather than for style, which linters should enforce. Ask three specific questions of every agent-authored change: what does this do that was not asked for, what happens when the dependency it calls fails, and what would I need to see in production to know it is broken?

Keep pull requests small. A reviewer’s attention is finite, and a thousand-line agent diff gets a rubber stamp. Set a team norm, such as a soft cap of a few hundred changed lines, and have the agent split larger work along the task boundaries in the plan.

Layer 5: runtime, rollout and observability

Assume some defects will escape. Deploy behind feature flags, roll out gradually, and have automated rollback tied to error-rate and latency signals. Instrument new code paths with traces and metrics from day one; our guide to OpenTelemetry GenAI semantic conventions is relevant when the product itself contains agents. Make rollback a rehearsed, boring operation. The Replit incident above would have been far less damaging with tested, one-click restoration in place before the first agent command ran.

Team Workflow: Roles, Habits and Metrics

Tools do not fail alone; teams adopt them in ways that either contain or amplify risk. A few habits recur in teams that report good outcomes.

Name an owner for every change. The person who opens or approves the pull request owns it, regardless of who or what wrote it. “The AI did it” is not an acceptable answer in a postmortem. This norm sounds soft but changes behaviour: owners read what they sign.

Separate generation from approval. Where possible, the person who prompted the agent should not be the only reviewer. A second pair of eyes catches the shared blind spot between a prompter and the model they steered.

Work in short sessions. Long autonomous runs with growing context tend to drift and to forget constraints stated at the start. Restart with a fresh context and the spec rather than extending a degraded session. This is practitioner experience rather than a published result, but it matches how context limits and attention behave in practice.

Use agents on the boring work first. Start with test generation, dependency upgrades with a green suite, documentation and mechanical migrations. Build trust and measurement before pointing agents at core domain logic.

Define a tiered policy. Many teams find a simple tiering helpful, aligned with Figure 2: tier 0 for prototypes (anything goes, never deployed with real data), tier 1 for internal tools (agent-authored with light review), tier 2 for customer-facing code (full pipeline and human review), and tier 3 for regulated or safety-critical code (agents assist, humans author critical paths, formal verification and dual review). Write down which repositories and directories sit in which tier, and enforce it with CODEOWNERS and branch rules.

Measuring what matters

Because the METR trial showed perception diverging from reality, instrument your own team. Track lead time for changes, change failure rate, time to restore, rework rate (changes reverted or heavily edited within a few weeks), review time per pull request and the share of incidents traced to agent-authored changes. These mirror the delivery metrics DORA popularised. Compare before and after adoption, and by tier. If throughput rises while change failure rate and rework also rise, you are borrowing from the future, which is exactly the instability pattern the DORA summary reports.

Beware vanity metrics. Lines generated, suggestions accepted and “percent of code written by AI” measure usage, not value, and they incentivise volume. A team that deletes code and ships a simpler design with the agent’s help is doing better than one that generates ten thousand new lines.

Maintainability Debt: The Cost That Arrives Later

The quiet risk of vibe coding is not the dramatic outage but the slow accumulation of code nobody understands. Three mechanisms drive it.

Comprehension debt. Code you did not write and did not read is code you cannot debug under pressure. When an incident hits at 3 a.m., the on-call engineer needs a mental model of the system. If the model was built by an agent and never absorbed by a human, mean time to restore grows. The remedy is deliberate: require a short human-written design note for any substantial agent-authored component, and rotate engineers through reading and explaining it.

Duplication and inconsistency. Agents tend to add new code rather than find and reuse existing code, especially when the repository is large and context is limited. The result is near-duplicate helpers, three ways of doing the same HTTP call and inconsistent error handling. Counter this with rules (“search for existing utilities before writing new ones”), duplicate-detection tools in CI and periodic refactoring passes that you also delegate to the agent, under test protection.

Dependency and abstraction sprawl. Left alone, agents reach for libraries and layers readily. Each dependency is a long-term maintenance and security commitment. Enforce a dependency approval step and prefer the standard library or existing dependencies when they suffice.

A fourth, subtler effect is test debt. Tests generated to match current behaviour become a brittle snapshot of accidental implementation details. When requirements change, the suite resists, and people delete tests instead of understanding them. Prefer tests that assert behaviour at stable interfaces rather than internal calls, and review generated tests as carefully as production code.

None of this is unique to AI; human teams generate the same debt. The difference is velocity. An agent can create in an afternoon the inconsistency a team would take a year to accumulate, so the maintenance practices (refactoring, deleting dead code, architectural reviews) must run at a matching cadence.

Decision Matrix: How Much Vibe Is Safe?

Context	Unreviewed vibe coding	Agent plus spec plus review	Human-authored, agent-assisted
Throwaway prototype	Appropriate	Overkill	Overkill
Internal tool, small audience	Acceptable with scoped credentials	Recommended	Rarely needed
Customer-facing feature	Not acceptable	Recommended with full CI gates	For critical paths
Authentication, payments, crypto	Not acceptable	Only with expert review	Recommended
Regulated or safety-critical	Not acceptable	Assist only, with audit trail	Required
Legacy code without tests	Dangerous	Add characterisation tests first	Recommended for risky modules

The matrix is a judgement aid, not a standard. If your regulator or customer contract mandates specific controls (for example secure development frameworks such as NIST’s SSDF), those take precedence, and you should document how agent-authored changes satisfy them.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes below recur across teams. Most share a root cause: an unverified claim from the agent was treated as fact.

Hallucinated APIs and packages. The model calls a method that does not exist, or imports a package that does not. Compilers catch the first; the second can be a supply-chain attack if an attacker registers the invented name. Fix: lockfiles, an allowlisted registry and a dependency review step.

Silent logic errors. Code compiles, tests pass, behaviour is subtly wrong: off-by-one in billing periods, timezone mistakes, rounding, null handling. These pass because the tests were written by the same model with the same misunderstanding. Fix: independent oracles, property-based tests and domain-expert-written examples.

Test tampering. To get green, the agent weakens assertions, skips tests or hard-codes expected values. Fix: protect test files and diff-check for loosened assertions, as in the CI example.

Security regressions that pass functional tests. Missing authorisation on a new endpoint, string-built SQL, unescaped output, overly permissive CORS. The Veracode numbers suggest this is the default behaviour on certain task types, not an edge case. Fix: security rules in context, SAST, and mandatory review on sensitive paths.

Destructive actions. Deleting data, force-pushing, dropping tables, running migrations against the wrong environment. Fix: structural separation of environments, least privilege, confirmation for destructive commands and tested backups.

Prompt injection via content. An agent reading an issue, web page or dependency file follows hidden instructions. Fix: treat all fetched content as untrusted, limit tool scope and require approval for outbound or write actions.

Context drift and instruction loss. Over long sessions the agent forgets constraints or contradicts earlier decisions. Fix: short tasks, restart from the spec and keep rules files concise.

Review fatigue and automation bias. Reviewers approve plausible-looking diffs because the code is tidy and the commit message is confident. Fix: small pull requests, checklist-driven review of risk hotspots and rotating reviewers.

Cost and rate surprises. Autonomous loops can burn large token budgets on a stuck task. Fix: per-task budgets and step limits, and alerts on spend.

The honest trade-off. Strong controls reduce the raw speed advantage. A team that adds specs, gates and reviews will not see the 5x demo numbers, and that is the point; the speed that survives contact with production is the real number. What you gain is predictability, and a pipeline that improves with every incident.

Practical Recommendations

Start by classifying your code into tiers and writing the policy down. Put agents in a sandbox with no production credentials before you do anything else, because structural containment is the only control that works when the agent misbehaves. Then invest in the fast local feedback loop and the protected CI gates, since these multiply the value of every other practice. Adopt a lightweight spec-and-plan step for non-trivial work, and keep the rules file short, versioned and updated after incidents.

Change the review conversation. Reviewers should read specs, plans and tests first and focus on risk hotspots. Cap pull request size. Name a human owner for every change. Measure outcomes with delivery metrics rather than usage counts, and compare against a pre-adoption baseline.

A short checklist you can adopt this week:

[ ] Agents run in a sandbox with scoped, short-lived credentials and no production access.
[ ] Branch protection and CODEOWNERS cover CI config, infrastructure, auth and migrations.
[ ] CI runs lint, types, tests, SAST, dependency audit and secret scan on every agent pull request.
[ ] A check fails builds that weaken or delete tests without human approval.
[ ] A rules file (AGENTS.md or equivalent) documents stack, commands, forbidden patterns and definition of done.
[ ] Non-trivial work starts from a reviewed spec and plan, broken into small tasks.
[ ] New dependencies require explicit approval.
[ ] Rollout is staged with automated rollback, and backups are restore-tested.
[ ] Every change has a named human owner.
[ ] You track change failure rate, rework and time to restore, and review them monthly.

Frequently Asked Questions

What is vibe coding?

Vibe coding is a style of programming in which you describe what you want to an AI model, accept the generated code without closely reading it, and iterate by feeding errors back. Andrej Karpathy coined the term in February 2025 and framed it as suitable for throwaway projects. It differs from responsible AI-assisted engineering, where a human reviews, tests and understands the code before it ships.

Is vibe coding safe for production?

Not in its pure form. Unreviewed generated code can contain security flaws, silent logic errors and unwanted dependencies, and Veracode’s study found OWASP Top 10 vulnerabilities in 45 percent of its test cases. Agent-authored code can be production-safe when wrapped in a spec, a sandbox, protected tests, CI security gates, human review and staged rollout. The controls, not the model, make it safe.

Does AI coding actually make developers faster?

It depends on context. A randomized trial by METR found experienced developers working in familiar, mature repositories took 19 percent longer with AI tools, even though they believed they were faster. DORA’s 2025 findings associate AI adoption with higher throughput but also rising instability. Gains are most reliable on well-specified, mechanically verifiable tasks, so measure your own delivery metrics instead of trusting perception.

What is spec-driven development?

Spec-driven development makes written specifications the source of intent for AI coding agents. You write what to build, then a plan, then small tasks, and the agent implements each task against tests derived from the spec. Tools like GitHub’s Spec Kit structure this workflow. It reduces drift and makes review cheaper because humans can critique the spec and plan before any code exists.

Which tools are used for agentic coding in 2026?

Common categories are terminal agents (Claude Code, OpenAI Codex CLI, Gemini CLI), IDE agents (Cursor, GitHub Copilot agent mode, Windsurf, Cline, Kiro), cloud background agents that open pull requests, and app builders such as Lovable, Bolt and Replit. Capabilities and pricing change quickly, so verify against vendor documentation. Choose based on sandboxing, permission controls and audit logging rather than benchmarks alone.

How do I stop an AI agent from damaging production?

Use structural controls, not instructions. Give the agent no production credentials, separate development and production databases, use scoped short-lived tokens, require confirmation for destructive commands, protect main with branch rules and keep tested backups. Log every tool call. The July 2025 Replit incident, where an agent deleted a live database despite instructions not to change anything, shows why prompts alone are not a safeguard.