Shipping Vibe-Coded Changes: The Pre-Merge Review Gate

Run this gate on any change produced with heavy AI assistance ("vibe-coded") before merge:

• New endpoints, permission changes, or role restrictions generated by an assistant.
• UI changes that also touch server behavior (delete, invite, onboarding).
• Anything that renders user-supplied content or calls an external provider.
• A port of AI-suggested code from another codebase or a prototype.

• Author — runs the self-checklist and live test before requesting review; states what was AI-generated.
• Reviewer — works the checklist below, focusing on the load-bearing risks, not style.
• Escalation — a senior owner for Strict-gate changes (auth, provider, data).

The pre-merge checklist. Read the diff against each; each has a real incident behind it.

1. 1

   Enforce Access

   1 — Is access enforced on the server, not just the screen? A UI-only guard is bypassable by hitting the server directly. We stopped admins locking themselves out with a server-side check and verified it by bypassing the screen — the screen change alone would not have held.

2. 2

   Handle Error Paths

   2 — Are the error and edge paths handled, or only the happy one? AI code loves the happy path. In one extension pass, live testing found four defects the happy path hid: a 401 returned as a redirect, provider errors crashing instead of failing gracefully, logout hitting the wrong method, and a frozen status. Exercise expiry, provider failure, and logout — not just success.

3. 3

   Encode Input

   3 — Is user-supplied content encoded? Any field that renders must be safe. We fixed an onboarding screen that rendered raw HTML from a team-name field and verified the fix with a real injection payload that then rendered as inert text.

4. 4

   Preserve Behavior

   4 — Does it silently change existing behavior? AI edits can quietly break or bypass working flows. We closed a gap that let chat produce finished output before required questions were answered, and separately caught a regression where GPT cards stopped responding to clicks — only end-to-end testing on a real copy surfaced it.

5. 5

   Reject Bad Patterns

   5 — Does it reject known-bad patterns rather than copy them? When porting AI-suggested or existing code, port selectively and reject the known-bad patterns instead of carrying them over wholesale.

6. 6

   Test Live

   6 — Was it exercised live, not just unit-tested? Green tests are not the gate. Bugs found in review and live testing get fixed before the merge to main. Where safe, test on a copy of the database, not live data.

- For every new restriction: hit the endpoint directly, bypassing the UI.
- Blocked at the server?  yes -> pass. no -> Strict fail.

• Strict-gate change (auth/provider/data) → all of Steps 1–6 must pass, and a senior reviews. No exceptions.
• Server bypass succeeds → hard fail; the UI guard is theater until the server enforces it.
• Only the happy path is covered → send back; require error, expiry, and provider-failure paths.
• Renders user input without encoding → hard fail; treat as an injection risk.
• Changes a working flow with no test proving the old path still works → send back.

When the gate finds a problem, ordered least → most invasive:

• A — Add the server-side check behind any UI restriction and re-test by bypassing the screen.
• B — Add explicit error/edge handling: map expiry to a real 401, fail provider errors gracefully, fix logout and status paths.
• C — Encode rendered fields and verify with an actual injection payload.
• D — Add a regression test proving the pre-existing flow still works, then re-run end to end on a copy.
• E — Rewrite the copied pattern rather than shipping a known-bad one; if the risk is deep, revert and redo the change deliberately.

1. Confirm every new restriction is enforced when the UI is bypassed.
2. Confirm error, expiry, provider-failure, and logout paths behave, not just success.
3. Confirm rendered user input is inert against a real payload.
4. Confirm the pre-existing flow still works via an end-to-end run on a copy, then merge.

Comms template:

AI change gate — {gate level} — {pass/fail}. Touches: {auth | render | flow}. Checks: server-enforced {y/n}, error paths {y/n}, encoding {y/n}, live E2E {y/n}. Verdict: {merge | send back}.

When an AI-assisted change causes an incident, add the exact miss (server bypass, unhandled error, injection, silent regression) as a standing checklist item and, where possible, a test. The gate should get stricter each time the model finds a new way to be confidently wrong.