Anti-Vibe-Coding
Enforces the mindset and habits of a professional developer on every coding task — eliminating reactive, unplanned, AI-slop-generating behavior. Primary constraint: no code is written until its purpose, security boundary, and reusability are explicitly confirmed.
Core Rules
Rule: Never write frontend code without a wireframe or mockup existing first. Why: designing inside code using random utility classes produces inconsistent padding, visual misalignment, and a generic template look that cannot be fixed by tweaking CSS after the fact.
Rule: Never hardcode color values, pixel sizes, or config variables inside component files. Why: hardcoded values break global theming and force edits across dozens of files for a single brand change — one CSS variable change should be enough.
Rule: Never connect a frontend framework directly to a database. Why: this leaks credentials to the browser, bypasses backend security rules, and exposes the entire database schema to anyone who inspects network traffic.
Rule: Never store auth tokens in browser local storage or session storage. Why: any cross-site scripting attack can read these stores freely — stolen tokens grant full account access with no further credentials needed.
Rule: Always declare pointer cursor on every custom clickable element. Why: missing pointer cursor is the clearest visual marker of AI-generated UI — it makes custom buttons feel broken and signals the interface was not reviewed by a human.
Rule: Never animate UI elements with linear transitions. Why: linear motion looks mechanical and robotic — ease-in-out transitions simulate physical velocity and make motion feel natural and intentional.
Rule: Never create a state effect hook without a precise dependency list. Why: an undefined dependency list runs on every render and triggers infinite loops that crash real browsers under normal user load.
Rule: All state must flow in one direction — from parent to child. Why: circular state creates unpredictable re-renders and makes the codebase impossible to debug as it grows.
Patterns
Correct — security boundary respected: User clicks "Export PDF" → frontend calls backend API endpoint → backend generates PDF and returns file → frontend downloads it. Credentials never leave the server.
Incorrect — vibe coding breach: User clicks "Export PDF" → frontend calls database directly using client SDK → credentials exposed in browser network tab.
Correct — state is traceable: Form input updates a single grouped state object. One state update, one re-render, dependency list is explicit.
Incorrect — fragmented state causes loops: Every form field has its own independent state hook. Parent state updates trigger child effects with no dependency list. Browser freezes under normal typing speed.
Correct — intentional animation:
transition: all 0.3s ease-in-out on button hover with upward scale.
Motion feels physical — accelerates in, decelerates out.
Incorrect — vibe animation:
transition: all 0.3s linear — motion feels robotic and mechanical.
No hover scale. Default arrow cursor on a custom button div.
Pre-Code Checklist
Before writing any function, component, or route, answer all four. If any answer is "I don't know", resolve it before writing a single line.
- Where is the security boundary? Frontend displays only. Backend runs all logic.
- Is this component reusable? If yes, build it generically, not inline.
- Are colors and styles variable-mapped? No hardcoded values anywhere.
- Will this state update cause circular side-effects? Trace the data flow first.
Decision Guide
| Situation | Correct action | Why |
|---|---|---|
| About to hardcode a color value | Declare it as a root CSS variable first | One variable change must update the entire UI |
| About to call database from UI file | Route through backend API layer | Credentials must never reach the browser |
| About to write a component for the second time | Abstract the first into a reusable shared component | Duplication is the primary driver of unmaintainable frontends |
| About to write an effect hook without deps | Map exact dependencies before writing | Undefined deps runs on every render and causes loops |
| Site looks generic after coding | Identify root cause: no wireframe or mockup was built first | Visual decisions made in code always produce template aesthetics |
What Not To Do
Do not accept AI-generated code without reading every line. AI defaults to the most common, most generic pattern — without constraints it produces slop.
Do not treat "it works" as done. Working code with open database connections, local storage tokens, and hardcoded values is not production-ready.
Do not add glassmorphism or micro-interactions before security boundaries and component architecture are solid. Visual polish is finish work — it is never the first step.
Do not design inside the code. If no wireframe exists, stop and make one. Even a rough grayscale sketch on paper prevents the generic layout problem.