Vibe coding: risks, and how this lab mitigates them
Fast AI-assisted iteration is powerful; without guardrails it erodes tests, security, and ownership. Here is how this repo keeps velocity without surrendering discipline.
“Vibe coding” usually means leaning on an assistant or autocomplete to move quickly from idea to diff. The upside is flow; the downside is invisible debt — skipped tests, inconsistent patterns, leaked secrets, and features nobody can explain.
Risk one: correctness drift. When generation outpaces review, regressions show up late. Mitigation here is a predictable verify path: i18n key parity, ESLint, unit tests, production build, and Playwright E2E against a known environment. They are not glamorous, but they turn “feels fine” into “green on CI”.
Risk two: security and secrets. Models suggest filenames and env keys; a tired accept-all can paste keys into the wrong place. Mitigation: .env examples only in Git, documented contact-email setup, lazy Firebase init, and project docs that say explicitly what must never be committed. Dependency review and audit scripts reduce supply-chain surprise.
Risk three: homogeneous sludge — every file reads like the same generic tutorial. Mitigation: Cursor rules and AGENTS.md encode project-specific constraints (navigation from @/i18n/navigation, hub patterns, no drive-by refactors). The goal is not to ban assistants; it is to steer them toward this codebase’s actual conventions.
Risk four: i18n and copy debt when English-only strings land in components. Mitigation: strings live in locale JSON; a check script fails if keys diverge across languages. That forces either intentional English-only exceptions or proper translation.
Risk five: architecture tourism — rewriting to the framework you read about last week. Mitigation: document why Hosting fronts Cloud Run, why one Next app, and when micro-frontends are logical rather than physical. Architecture notes are part of the product, not a slide deck.
None of this requires a huge team. It requires treating automation and review as part of vibe: if the tool helps you ship, the next question is always “what breaks when this ships wrong?” and the answer should live in a script or a test.
If you vibe-code solo or in a small lab, steal the minimum set: one command that means “ready to merge”, secret hygiene, and a written “why we did it this way” for your future self — who will not remember the vibe, only the stack trace.