Vibe-Coding Anti-Patterns: Ten Ways It Becomes Tech Debt

Vibe-coding anti-patterns are the recurring AI-assisted coding mistakes that turn productivity gains into tech debt — accept- without-read approvals, copy-paste sprawl the agent never saw, agent-blame in postmortems, skipped evals on AI-authored changes, and six others that compound quietly until the debt curve crosses the productivity curve. We see them in every engineering audit.

The frame matters because the productivity story is real. Teams running Claude Code, Copilot, or Cursor at default settings genuinely ship faster in the first quarter — sometimes meaningfully faster. The debt story is also real. Without explicit gates, the same teams accumulate review-bypassed code, duplicated implementations the agent didn't see, untested branches that pass CI because the agent wrote the test against the same hallucinated contract, and postmortems that stop at "the model got it wrong." The curves cross somewhere between twelve and eighteen months.

This essay walks the ten patterns in severity order, with a diagnostic signal you can run today, the corrective pattern that prevents recurrence, and a worked example for the three highest- severity items. The intent is a punch list for engineering leaders — the kind of artifact that survives the meeting where someone says "we should write a policy about that."

The productivity story behind AI-assisted coding is real. Teams adopting Claude Code, Copilot, or Cursor at default settings consistently report meaningful first-quarter velocity gains — faster PRs, more parallel feature work, fewer hours spent on boilerplate. The story we don't hear as often is what happens in quarters three through six, when the velocity curve flattens and the debt curve starts to bite.

The mechanism is straightforward. AI-assisted coding accelerates output at every layer where the human used to be the bottleneck: scaffolding, test writing, refactor sweeps, doc generation, boilerplate translation. Each of those layers also accelerates the production of code that nobody read carefully, code that duplicates work the agent didn't see, code that passes a test written against a hallucinated contract, and commit messages that don't mention which tool produced the diff. None of that is inherently bad — it's the absence of gates that turns it into debt.

The ten anti-patterns below are the ones that recur across the engineering audits we run. They're grouped by severity tier rather than by chronological order — S1 patterns are incident-drivers that should be addressed within a sprint, S2 patterns accumulate debt over quarters and need gating in the current planning cycle, and S3 patterns are smells worth tracking but not at the top of the punch list.

Accept-without-read is the highest-severity pattern in this list, and the one most engineering leaders underweight. The shape: an engineer asks an agent to fix a bug, the agent produces a fifty-line diff across three files, the engineer skims the summary, accepts the changes, opens a PR, and the reviewer approves on the same skim. The code ships. Nobody read it carefully — not the author, not the reviewer, not anyone after.

The diagnostic signal is easy to instrument. Sample any merged AI-authored PR from the last quarter and ask the original author three questions about the diff that require having read it — "why did you choose this API over the obvious alternative," "what does this catch block do when the upstream service returns 429," "why is the loop bounded at thirty rather than the configured limit." If the author can't answer without re-reading, the pattern is live in the workflow. The follow-up question to the reviewer surfaces the same gap one layer up.

The corrective pattern has three components. First, the PR template requires explicit AI-attribution and a one-line summary the author wrote (not the agent) explaining what the diff does and why. Second, the review rubric for AI-authored diffs includes a single sentence requirement that reviewers cannot complete by skimming — "name one decision in this diff that you'd push back on if a junior engineer had written it," for example. Third, retroactive sampling of merged AI-authored PRs at five to ten percent per quarter, with the sample reviewed by an engineer who wasn't the original reviewer.

One operational note. Accept-without-read does not require malice or laziness — it's the default that emerges when the agent produces a clean-looking diff, the CI passes, and the review tool doesn't differentiate AI-authored diffs from human-authored ones. The fix is structural, not cultural. Reviewers who genuinely care about quality still skip readings when the workflow doesn't prompt them. The gates do.

Copy-paste sprawl is the second-highest-severity pattern because it scales with adoption rate and is almost invisible in any single PR. The shape: an engineer asks an agent to write a function that handles, say, retry-with-backoff on an upstream service call. The agent obliges and produces a perfectly reasonable implementation. The engineer ships it. A week later, a different engineer in a different file asks an agent for the same thing — the agent has no memory of the first request and produces a second, slightly different, perfectly reasonable implementation. Multiply by ten agents, fifty engineers, six months.

The diagnostic signal is structural duplication that wouldn't have happened with a human-only workflow. Static analysis tools that detect near-duplicate functions across files are the obvious primitive — codebase-wide grep for common patterns (retry logic, error formatting, validation helpers, date math) and count the distinct implementations. A baseline number doubling over two quarters with no corresponding feature growth is the leading indicator.

The corrective pattern is the "shared module first" rule for agent prompts. Before asking an agent to write a new utility, the prompt template requires a one-sentence search for existing implementations. Some agents handle this natively if the prompt asks them to. Others need scaffolding — a pre-prompt hook or workspace rule that injects "search the codebase for existing implementations before writing a new one" into every agent call. The rule is cheap and the effect compounds.

The sprawl pattern is the strongest argument for treating agent prompts as code — versioned, reviewed, and explicit about codebase-search expectations. A workspace rule that lives in a tracked file and applies to every agent call is dramatically cheaper than the cleanup required when twelve near-duplicate retry implementations need consolidation in eighteen months.

Agent-blame is the postmortem pattern where the root-cause analysis stops at "the model hallucinated" or "the agent produced incorrect code." It looks like a complete answer because the immediate cause of the bad diff genuinely was the model. It is not a complete answer because it produces no preventive action. Models will continue to hallucinate. The policy question is what humans did to allow the hallucination to ship.

The diagnostic signal is the postmortem template itself. If your postmortems include a root-cause field and the AI-related entries consistently read "model produced X" without naming the human decision that allowed X to merge, the pattern is live. Read the last three AI-attributable incidents and ask whether the preventive actions would have prevented the incident if the model had behaved identically. If no, the analysis stopped too early.

The corrective pattern is a postmortem template that explicitly treats AI tools as part of the workflow rather than as autonomous agents. Required fields include: which human approved the diff, what review gate did or didn't catch the issue, what test gate did or didn't exist for the changed path, what policy or tooling change makes the catch automatic next time. The test for a useful postmortem is that the preventive actions would close the gap independent of which specific model version produced the diff.

One operational note. The agent-blame pattern is sometimes a symptom of a deeper problem — engineers who don't feel psychologically safe naming the human decision in front of leadership will default to blaming the tool. The fix is partly cultural (blameless postmortem hygiene applied consistently to AI incidents the same way it would be to human-authored incidents) and partly structural (the template doesn't accept "model error" as a terminal root cause). Both layers earn their keep.

For the policy framework that operationalizes these accountability rules across review gates, IP exposure, secrets, and approved tools, our 50-point vibe-coding policy audit walks the gates that prevent the patterns in this essay from ever becoming postmortems.

Eval-skip is the pattern where AI-authored changes ship without tests covering the changed paths, on the implicit assumption that the agent produced "obviously correct" code. The assumption is wrong roughly the same fraction of the time that human-authored code is wrong — except the AI is faster, the volume is higher, and the "obviously correct" label is harder to push back on at review time because the diff looks polished.

The diagnostic signal is the asymmetry between coverage on AI- authored versus human-authored diffs. Sample fifty PRs from the last quarter, label each by AI-authorship, and compare the rate at which test files are touched. If AI-authored diffs touch test files at a meaningfully lower rate than human-authored diffs, eval- skip is live. Some teams find the asymmetry is the other direction — AI writes more tests than humans do — which is its own pattern (see Coverage Illusion below).

The corrective pattern is asymmetric eval policy. AI-authored changes require tests for the changed paths even when the equivalent human-authored change would not. The asymmetry is intentional and grounded in the cost structure: AI is faster at writing tests than humans are at noticing missing ones, so the cheapest enforcement is to require tests on AI diffs and let CI block merges that don't include them. Score the gate at the PR template, not at the postmortem.

One nuance worth surfacing. The policy should require tests for the "changed paths" rather than tests for the diff as a whole. AI-generated tests that exercise the exact lines the agent wrote without exercising the contract those lines fulfill are not real coverage — they pass forever because they pin the implementation. Reviewers checking the eval-skip gate need a second sentence in the rubric: "do the tests exercise the contract or pin the implementation?" The first answer is the useful one.

The pattern is hard to enforce without tooling because reviewers face their own time pressure. A PR template field that asks "tests added for changed paths — Y/N" with required justification on N is the cheapest first layer. CI checks that flag AI-attributed diffs without test changes form the second layer. The combination holds; either layer alone slips.

The remaining five anti-patterns share a structural property — each one accumulates quietly across weeks and surfaces as an incident only when something else triggers it. Treat them as S2 (quarterly debt) rather than S1 (incident-driver) and gate them in the next planning cycle. None require novel tooling; all require explicit policy.

Of the five, secrets-in-prompts is the only S1 — every other pattern accumulates over quarters rather than surfacing as a named incident. The reason secrets-in-prompts ranks differently is that one instance is enough to trigger a compliance event, rotate production credentials, and write a postmortem. The other four don't produce that kind of immediate harm, but they consistently produce the long-tail debt that makes AI-assisted workflows less productive over time than they appeared at adoption.

The prompt-graveyard pattern deserves a brief expansion because it's the one most teams underweight. When the team's best agent prompts live in individual IDE configs and never get shared, three things happen. The team can't reproduce its own production output. New hires bootstrap from worse prompts than tenured engineers. And when a tenured engineer leaves, the prompts leave with them. A tracked prompt library — even a flat file in the repo — fixes all three failures at near-zero cost.

Model-version drift is the under-discussed counterpart. The same prompt produces meaningfully different output across model versions. Teams running prompts that were tuned against an older model and not re-evaluated when the version bumped are silently shipping different behavior than the prompt's comment block suggests. Pin the model version per shared prompt, run a quick eval against the new version on every bump, and the drift becomes an explicit decision rather than a surprise.

The coverage illusion is the pattern where AI-generated tests inflate coverage metrics without actually validating the contract the code is supposed to fulfill. The shape: an engineer asks an agent to add tests for a module, the agent generates a thorough- looking test file with high line coverage, the engineer ships it, the coverage dashboard goes up, and the team marks the work done. Six months later, a refactor breaks the tests in ways that surface no bugs — because the tests were pinning the implementation, not the contract.

The diagnostic signal is brittleness under refactor. If routine refactors break a meaningful fraction of AI-generated tests without surfacing real regressions, the tests are pinning implementation details. Sample five AI-generated test files and run a structural refactor on the code they cover — rename a private method, reorder argument lists, inline a helper. The tests that break without the public contract changing are the ones measuring nothing useful.

The corrective pattern has two layers. First, the review rubric for AI-generated test files includes a single question — "do these tests exercise the public contract or pin the implementation?" — that reviewers cannot answer by skimming. Second, the prompt template for generating tests asks the agent to enumerate the contract first, then write tests against it, rather than generating tests directly from the implementation. Both layers earn their keep.

The coverage illusion is the pattern with the longest tail. Lines- covered is easy to measure, easy to optimize, easy to celebrate. Contract-asserted is none of those things — it requires a human reading the test file with the public API in front of them. The policy that lands is the one that explicitly retires lines-covered as a quality metric and replaces it with a per-PR review checkpoint: does this test file exercise the contract, or pin the implementation? Answer once per PR, in writing, and the pattern stops compounding.

For teams ready to install the gates that prevent the patterns in this essay, our AI transformation engagements audit the AI-coding practice against the ten anti-patterns and ship the policy plus tooling that closes them. The companion framework — the Claude Code team adoption audit — scores the adoption side of the same coin, so the gates land without slowing the productivity story.