Skip to content

Why vibecodingisold

The diagnosis

Two years into the AI-coding era, the same scaffold ships to production over and over.

  • Auto-increment integer primary keys.
  • JWT in browser localStorage.
  • .env files committed to the repo.
  • No idempotency on payment endpoints.
  • No tenant_id column ("we'll multi-tenant later").
  • No rate limit on /login.
  • No structured logs, no PII redaction, no trace propagation.
  • No staging environment, no IaC, no rollback plan.
  • Mocked tests that pass while the real DB migration takes the database offline.

Each defect is forgivable in isolation. Stacked, they're a six-week rebuild that the founder will do under time pressure when a paying customer reports a double-charge or an auditor asks for the audit log.

The diagnosis: AI-coding tools generate code well. They do not generate the right requirements. Senior engineers don't catch these defects because they write better prompts; they catch them because they bring seven different roles' worth of mental checklists to the design conversation. AI tools don't have those checklists, and the user usually doesn't either.

vibecodingisold is the layer that closes the gap.

The bet, in three postmortems

These three real-world failures aren't trivia — each is a single item in the canonical knowledge base, with the postmortem cited as a Tier-1 source.

  • Knight Capital lost $440M in 45 minutes because they shipped without a runtime kill switch. → Architect Item 39 (kill-switch / runtime feature-flag commitment).
  • Cloudflare went down globally for 30 minutes in 2019 because one regex had no resource limit. → Backend Item 38 (ReDoS / catastrophic-backtracking protection).
  • GitLab almost lost everything in 2017 because all 5 backup mechanisms had silently failed. → Database Item 21 + DevOps Item 26 (verified-restore drill).

There are 311 more items, each with the same shape: a concrete pattern, a real failure mode, a code-level minimum implementation, the LLM-behavioral reason it gets missed, and >=2 Tier-1 primary citations. We refuse to wait for the postmortem to learn what was missing.

Who this is for

You are the target reader if any of these match:

  • Solo founder shipping with Claude Code, Cursor, or Cline who has watched a generated plan miss something obvious in retrospect.
  • Small engineering team that wants the equivalent of a senior architect / security engineer / SRE review on Day 1 without hiring three people.
  • Consultant / agency delivering AI-built MVPs and tired of re-explaining idempotency, multi-tenancy, and RPO/RTO to every fresh codebase.
  • Engineering lead at a 5–20-person team instituting standards for AI-tool usage and looking for a citation-anchored baseline.
  • Builder of an internal AI-coding platform wanting a profile-aware Stage-2 layer to slot in front of your custom planner.

You are not the target reader if:

  • You're looking for a coding agent. (We feed agents; we don't replace them.)
  • You're looking for a linter or static analyzer. (We work before code is written.)
  • You're looking for managed/SaaS automation. (V1 is open-source files only.)

The 4-stage pipeline

We are explicit about which stage we cover, and which we don't:

Stage What Where vibecodingisold fits
1 — Context Engineering What are we building? For whom? Which stack? Which scale? Your job. We require evidence (PROJECT.md / README.md) before running.
2 — Requirements injection What MUST be in the plan that the AI tool would otherwise miss? This is us. 314 Mandatory items, profile-filtered, cross-referenced.
3 — Planning How do we phase this? What's the architecture? What are the tasks? Your planning tool — Claude Code, Cursor, Cline, custom orchestrator. We feed it.
4 — Execution Build it. Your coding agent. Items in the plan inform every PR.

A senior engineer's value across stages 1–3 is roughly: 30% asking better Stage-1 questions, 60% bringing Stage-2 mental checklists, 10% making Stage-3 phasing crisp. We focus on the 60% — because it's both the largest and the most automatable.

See Where it sits in your pipeline for the longer treatment.

What "knowledge injection layer" means concretely

Concretely, every Mandatory item is a self-contained 9-field artifact:

  1. What exactly — the concrete pattern, with code where applicable.
  2. Why mandatory — failure mode + real-world citation.
  3. Minimum implementation — compileable code in the default stack.
  4. Failure modes of the minimum — when does the minimum break.
  5. Validation method — concrete test or command.
  6. Why AI tools systematically miss this — the LLM-behavioral reason.
  7. Sources — >=2 Tier-1 primary citations.
  8. Cross-references — other items this depends on.
  9. Estimated time to retrofit — the cost if you wait for production to teach you.

Field 6 is the load-bearing innovation. It's what no canonical reference (OWASP, 12-Factor, AWS Well-Architected) provides. See The 9-field item template for the full breakdown.

Why now

Two trends made this useful at this moment:

  1. AI-coding tools became plan-aware, not just edit-aware. Cursor / Claude Code / Cline now consume rules-files, conventions-files, and project-context files. There is finally a hand-off layer to inject senior-team knowledge into.
  2. Postmortem culture went open. AWS, Cloudflare, GitHub, Stripe, GitLab publish detailed retros. We can ground each Mandatory item in a public failure with $-amount or downtime-amount impact, instead of "trust me, this matters."

Without (1), there was no way to deliver the items. Without (2), there was no way to defend each item against "is this actually mandatory or just opinion?"

What we explicitly are not claiming

  • We are not claiming the items are exhaustive. They cover the production-readiness surface most AI tools systematically miss. We name the V1 gaps explicitly. See the Changelog and the per-profile gap notes.
  • We are not claiming we invented these patterns. They consolidate work from AWS Builders Library, Google SRE, Stripe Engineering, OWASP, postmortem authors, and a long list of named acknowledgements in the README.
  • We are not claiming this replaces a senior team. It encodes the what-to-ask-for portion of senior judgment. Architecture decisions, vendor trade-offs, domain modeling, on-call culture — all still require humans.

What we are claiming: shipping without these items is shipping with a known set of preventable failure modes. And until V1.0, there was no single open-source layer making the set legible to AI-planning tools.