Vibe Coding Wiki

200+ hrs, 70k lines, non-developer PM. Distilled lessons + community insights.
Tags: #vibe-coding #ai #workflow #security

1. Planning

• Write a PRD first. Define goal → roadmap → first milestone. AI cannot one-shot non-trivial work — it needs constrained scope.
• Build micro-feature by micro-feature. One independently testable unit per session.
• Use OpenSpec + grillme to stress-test your documents before building.

2. Session & Token Management

• One session per feature. Long sessions degrade context and burn tokens fast.
• /compact focus on <X> to trim context mid-session.
• Plan with the best model, code with a cheaper one.
  • Architecture / reviews → Claude Sonnet, GPT-4o
  • Implementation / boilerplate / tests → Codex, Haiku

3. Build Order

UI-First (recommended for solo vibe coding)

Build frontend with mock data → validate AI understood the spec → refine data model → implement backend.

• Catches misunderstandings early when they're cheap
• Gives fast visual feedback before real logic exists

Backend-First (traditional / team projects)

Build the API → frontend just displays what exists. Cleaner business logic, fewer rewrites.

Contract-First (best of both)

Define OpenAPI spec → build both sides against it independently → use Postman to test endpoints before the frontend exists.

Verdict: UI-first works well solo. Backend/contract-first for teams or complex logic.

4. Testing

Rules for CLAUDE.md

TDD Flow for Tricky Features

1. List everything that could go wrong
2. Ask AI to write a failing test for each
3. Run it — confirm it fails for the right reason
4. Ask AI to write the implementation
5. Confirm test passes

This stops the AI writing code first, then writing tests that rubber-stamp whatever it did.

Key Practices

• Cross-check tests with a second model — the model that wrote the code has the same blind spots
• Run Stryker (mutation testing) periodically — confirms tests actually catch bugs, not just confirm existing behaviour
• Save one well-crafted test as a reference example for that module — instruct AI to follow it
• Automate in CI — runs on every PR

5. Version Control (Git)

• Start Git on day one. Starting at 16k lines is too late — you regret it.
• Commit at every logical checkpoint, not every trivial change (noisy rollbacks)
• Feature branches for every new feature or refactor; merge only when tested
• Rolling back to a known-good commit is often the fastest fix

6. CLAUDE.md / AGENTS.md

Persistent instruction file the AI reads every session. Without it, the AI repeats the same mistakes across sessions.

Essential rules to include:

- Split components aggressively — one responsibility per component
- No business logic in components — belongs in hooks/services
- Max file size: 300 lines
- Test behaviour, not implementation
- Always cover failure paths
- API keys never reach the browser
- AI-generated content sanitized before rendering

7. Refactoring

• Schedule 1–2 refactor days every week or two. Hard to stop shipping features, but unchecked growth tanks quality.
• Refactor sessions: remove dead code, split large files, improve naming, reduce duplication.

⚠️ When refactoring with AI:

Explicitly tell it not to touch existing logic — only port. Models will silently delete things. Always diff carefully after a refactor. Never trust "I didn't change any logic."

Watch for:

• Files over your line limit (e.g. 500 lines)
• Components with multiple responsibilities
• Business logic in the wrong layer

8. Code Review & PR Discipline

• Run /review + /security-review on every PR — build custom subagents tuned to your codebase's patterns
• Review with a different model than wrote the code — the author has the same blind spots as its own output

Review checklist:

• Logic correctness
• Auth checked on every protected endpoint
• No data exposed to client that shouldn't be
• Test coverage — what's missing, not just what's there
• No hardcoded secrets
• Component boundaries respected

9. Security & Anti-Hacking — The Bible

Honest baseline: AI security reviews pass flawed code regularly. AI also flags correct, framework-current code as broken (false positives). For any multi-tenant or sensitive-data app, get a human security review before launch. This section is the canonical reference — work through it top to bottom.

9.0 First Principles (memorize these)

1. Never trust the client. Anything from a browser — form fields, query params, headers, cookies, hidden inputs, IDs — is attacker-controlled. The server is the only trust boundary.
2. The UI is not a security control. A disabled button, a hidden menu, a missing link — all bypassable with one curl. Every rule must be re-checked on the server.
3. Fail closed. On any doubt — missing session, unknown role, error mid-check — deny. Default-deny, then allow explicitly.
4. Least privilege. Every user, token, and service gets the minimum access needed. No "admin can do anything" shortcuts.
5. Defense in depth. Assume each layer fails. App-level check and rate limit and firewall and monitoring. No single point of trust.
6. Verify, don't assume — especially with AI. AI works from stale training data and confidently "fixes" things that aren't broken. Check the current framework docs before changing security-relevant wiring. (See 9.12.)
7. Specify authorization with zero ambiguity. "Only admins" is not a spec. "Only an admin of the same tenant as the target record, and never to elevate a user above the caller's own role" is.

9.1 Authentication

• Hash passwords with a slow, salted KDF — argon2id, scrypt, or bcrypt. Never SHA/MD5. Compare with a constant-time function.
• Never set or reset a password on an existing account from an unauthenticated request. A "sign in or sign up" form that silently sets a password on an account that has none (e.g. Google/magic-link users) is account takeover — the attacker just needs the victim's email. New accounts only; existing → send to the real reset flow.
• OAuth / magic-link accounts have no password. Don't auto-create one for them on a password form.
• Password reset tokens: long random, hashed at rest, single-use, short expiry (≤15 min), prior tokens invalidated.
• Build reset/verify links from a canonical, server-configured base URL — never from the request Host/X-Forwarded-Host header (host-header poisoning lets an attacker mint links pointing at their server).
• Verify email ownership before granting trust / sending sensitive mail.
• Re-read role/permissions from the DB each request (or on a short TTL) — don't trust long-lived claims baked into a token at login.

9.2 Authorization & Multi-Tenancy — the #1 vibe-coding killer

• Centralize authorization in helpers (requireAdmin, requireOwnerOf(resource), …). Call them before every mutation and sensitive read, in one place — never re-implement per endpoint.
• "Is an admin" ≠ "is an admin of this record." Always scope by tenant/owner. The classic bug (IDOR) is accepting a client-supplied id and operating on it without checking it belongs to the caller. Put the ownership constraint in the query's WHERE clause, or fetch-then-verify — but never skip it.
• Never let client-controlled input select whose data or credentials you use. A cookie/param that picks "which account's API key" or "which tenant" must be validated against the authenticated user's permissions — or removed. Trusting it = cross-tenant takeover.
• Enforce on the server, not the UI. If admins can "lock" a setting, the server action must reject a locked change — not just grey out the toggle. Attackers call the action directly.
• Privilege-escalation guards on role changes. An endpoint that promotes/invites/edits users must refuse to: elevate anyone above the caller's own authority, overwrite a higher-privileged account, or move a user across a tenant boundary. Never reset another user's password through an "invite" path.
• Deny by default. New routes/segments should be unreachable until explicitly allowed.
• Know your DB's authz model: Postgres RLS, Firestore Security Rules, etc. — and make the app, the DB rules, and any gateway read from one source of truth.

9.3 Input Handling & Injection

• SQL/NoSQL injection: use parameterized queries / the ORM query builder. The trap is the raw escape hatch (queryRawUnsafe, string-built queries, $where). Never interpolate user input into a query string.
• XSS: React/Vue/Angular auto-escape — the danger is dangerouslySetInnerHTML / innerHTML / v-html / bypassSecurityTrustHtml. Sanitize all user- and AI-generated HTML (DOMPurify) before those sinks.
• Command injection: never pass user input to a shell. Use execFile/array-arg APIs, never exec("… " + input).
• Path traversal: never build filesystem paths from user input without normalizing and confining to a base dir (reject ..).
• SSRF: dangerous when the user controls the host or protocol of an outbound request (path-only control is usually fine). Allowlist destinations.
• Deserialization / template injection: never eval, pickle.loads, unsafe YAML, or render user input as a template.
• Validate on the server with a schema (Zod, Pydantic, …). Client validation is UX only.

9.4 Secrets & Cryptography

• Never hardcode secrets. Env vars in dev, a secret manager in prod (GCP/AWS Secrets Manager, Vault, platform env). Generalize all sensitive/config values to env (URLs, keys, tunables) with safe defaults.
• Keys never reach the browser: browser → your backend → third-party API. No NEXT_PUBLIC_/VITE_ secrets.
• Encrypt sensitive data at rest (third-party API keys, tokens, PII) with AES-256-GCM (authenticated encryption). Derive/load the key from the secret manager. Version your ciphertext (enc:v1:…) and keep reads backward-compatible so you can migrate without downtime.
• Keep the encryption key stable (rotating it orphans existing ciphertext) and out of the database it protects.
• Don't log secrets or PII. Logging URLs/IDs is fine; logging API keys, passwords, tokens, emails-in-bulk is not.

9.5 Rate Limiting, Lockout & fail2ban — anti-brute-force

• Rate-limit every abuse-prone action: login, signup, password reset (request and submit), magic link, OTP, invite, and expensive mutations. Limit per-IP and per-identity (email) — fixed or sliding window.
• Progressive lockout/bans: repeated failures accrue "strikes"; past a threshold, ban the IP/identity for a window that escalates with each offense.
• App-level ban store works with zero new infra — a small table (key, count, resetAt) + a ban table. Use Redis only when you need multi-node sharing.
• Host-level fail2ban for blanket blocking: emit one stable, structured log line per security event (event=auth_fail ip=… reason=…), then a fail2ban filter/jail bans the IP at the firewall (iptables) for all traffic. App-level guards the endpoints; fail2ban guards the network.
• Get the real client IP correctly: behind a proxy, read the left-most X-Forwarded-For — but only trust it if your proxy sets it and strips client-supplied values. Direct-exposed apps must not trust XFF.

9.6 Honeypots & Deception — catch scanners before they find anything

• Hidden form-field trap: add a visually-hidden input real users never fill; any submission that fills it is a bot → reject + record (and feed the ban list).
• Decoy routes: /wp-login.php, /.env, /xmlrpc.php, /phpmyadmin, /.git/config — paths only scanners request. Record the hit, strike the IP toward a ban, and return a plain 404 (don't reveal it's special).
• Surface the data: an admin view of recent honeypot hits / active bans makes the protection actionable and lets you lift false positives.

9.7 Browser & Transport Hardening (Headers + Cookies)

• Content-Security-Policy. Lock the directives that can't break you first: frame-ancestors 'none', object-src 'none', base-uri 'self', form-action 'self'. Tighten script-src/style-src with nonces when you can; stage with report-only if unsure.
• Strict-Transport-Security (HSTS, long max-age + includeSubDomains), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy.
• Disable framework fingerprinting (x-powered-by off).
• Cookies: HttpOnly + Secure + SameSite=Lax/Strict for anything auth-related.
• CSRF protection for cookie-based auth (token or SameSite); strict CORS allowlist for cross-origin APIs.

9.8 Dependencies & Supply Chain

• Dependency audit in CI (npm/pnpm audit, pip-audit, Dependabot). Fix highs promptly — but never --force into a major downgrade to silence a transitive advisory; some only clear on an upstream patch (document those).
• Gitleaks in CI + a pre-commit hook — scans history for committed secrets.
• One package manager, one lockfile. Mixed lockfiles drift and re-introduce vulnerable versions. Raise the dependency floor in the manifest so every resolver gets the patched version.
• Pin and review notable upgrades; don't blind-bump.

9.9 Data Protection & Privacy

• Never commit real databases or .env files. A dev SQLite/dev.db checked into git leaks customer data, password hashes, tokens, and keys — and stays in history forever. Untrack + .gitignore it; if it was ever committed, rotate the exposed secrets (history removal alone isn't enough).
• Don't commit reports that enumerate your vulnerabilities into a shared repo.
• Minimize PII, encrypt it at rest, and have a deletion/retention story.

9.10 Logging, Monitoring & Incident Basics

• Log security events (auth failures, bans, honeypot hits, privilege changes) as structured lines — no secrets/PII in them.
• Error tracking (Sentry) wired early; alert on spikes in auth failures/5xx.
• Incident quickstart: revoke/rotate affected credentials → patch the hole → assess blast radius from logs → notify if data was exposed → write a short post-mortem.

9.11 Testing Security (behaviour, not vibes)

• Write tests named after the attack they prevent: "rejects cross-tenant record access", "reset token is single-use", "locked control can't be toggled via direct call", "Nth failed login is rate-limited", "stored secret round-trips and never leaks plaintext".
• Cover failure/abuse paths, not just the happy path. These are exactly the regressions a refactor silently reintroduces.

9.12 Working with AI on Security (meta-rules)

• AI passes flawed security code and flags correct code as broken. Treat its security output as a draft, not a verdict.
• VERIFY THE FRAMEWORK against current docs. AI's training data lags releases; it will "fix" wiring that is actually correct for your version (e.g. renamed file conventions, new config APIs) and break it. Read the installed docs before touching framework-level security wiring.
• Review with a different model than wrote the code — the author shares its own blind spots.
• Authorization needs zero-ambiguity prompts (see 9.0 #7). Side-effect bugs — a change here that exposes something there — are nearly impossible for AI to catch; that's what human review and tenant-isolation tests are for.

OWASP Top 10 — Highest-Risk in Vibe Coding

Pre-Launch Security Checklist (copy-paste)

AUTH
- [ ] Passwords hashed (argon2/scrypt/bcrypt), constant-time compare
- [ ] No password set on existing accounts from unauthenticated forms
- [ ] Reset tokens: random, hashed, single-use, expiring; links from canonical URL
AUTHZ
- [ ] Central authz helpers called before every mutation
- [ ] Every record access scoped to the caller's tenant/ownership (no IDOR)
- [ ] No client input selects whose data/keys are used
- [ ] Server enforces every rule the UI implies; role changes can't escalate
INPUT
- [ ] Parameterized queries only; user HTML sanitized; no eval/unsafe deser
SECRETS
- [ ] No hardcoded secrets; secret manager in prod; keys never in browser
- [ ] Sensitive data encrypted at rest (AES-GCM); key outside the DB
ABUSE
- [ ] Rate limiting per-IP + per-identity on auth/reset/signup
- [ ] Progressive ban/lockout; fail2ban fed by structured logs
- [ ] Honeypot field + decoy routes
HEADERS
- [ ] CSP, HSTS, X-Frame-Options, nosniff, Referrer/Permissions-Policy, COOP
- [ ] Auth cookies HttpOnly+Secure+SameSite; CSRF + CORS handled
SUPPLY CHAIN
- [ ] Dependency audit + gitleaks in CI; single lockfile
DATA
- [ ] No DB/.env committed; PII minimized & encrypted; secrets rotated if leaked
OBSERVABILITY
- [ ] Security events logged (no secrets/PII); error tracking + alerts
- [ ] Tenant-isolation & abuse-path tests; human security review done

10. Multi-Model Strategy

• Write with Model A → Review with Model B — catches what the author misses
• Gemini: Run its feedback past Claude/Codex before acting — hit or miss

11. Deployment

• Never deploy directly to production.
• Preview channel is a mandatory gate: Commit → Preview → Verify → Promote
• SHA-locked promotion: deploy script refuses to promote if current commit SHA ≠ verified SHA. Prevents shipping a version you didn't actually test.

12. Multi-Agent Workflows

• Run parallel agents only on completely unrelated features with zero shared files
• Each agent gets its own git worktree (separate directory, separate branch)
• Run a status script to flag any file both agents have touched
• Never let two agents work on the same thing — conflicts every time

git worktree add ../feature-b-dir feature-b-branch

13. TypeScript

• Adopt earlier than feels necessary — benefits compound, late migration is painful
• Start at the boundaries: API layer → data models → shared utils → inward
• AI writes better code when types are defined — can't make assumptions about data shapes
• Refactors are dramatically safer with type checking

14. Tooling Reference

React Native specific:

• Test both Android and iOS from day one
• Move from Expo Go to DevBuilds ASAP — Expo Go behaves differently from real builds

15. Beginner Ramp

Tier 1 — Day One

• Use Git, commit often
• Write CLAUDE.md before you start
• One session per feature
• Manual test before moving on
• Never commit .env/databases; no hardcoded secrets
• Auth checked on the server for every protected action (not just the UI)

Tier 2 — First Month

• Automated unit tests on core logic — including tenant-isolation & abuse paths
• Preview/staging environment
• Secrets in a secret manager, never in code
• Understand your DB auth model
• Per-record/tenant authorization (kill IDOR); rate-limit auth flows
• Security headers (CSP/HSTS/…), gitleaks + dependency audit in CI

Tier 3 — Once Shipping

• TypeScript at the boundaries
• Mutation testing (Stryker)
• Multi-model PR reviews
• Git worktrees for parallel agents
• Encrypt sensitive data at rest; progressive bans + fail2ban; honeypots
• Security event logging + alerting; human security review for sensitive apps

Where to Learn

• Ask the AI to explain any term in plain language — fastest teacher available
• Fundamentals of Software Architecture (O'Reilly) — theory behind all of this
• OWASP Top 10 — free, canonical security reference

Glossary