coding standard guidelines
vibe coding
ai-assisted-development
software-architecture
development-best-practices
Imagine everything is going well in your development, youโre vibing with the code, and suddenly the AI suggests something that doesnโt follow your conventions; it duplicates logic, changes patterns, or mixes styles. Itโs not being โcapriciousโโitโs lacking code-close context. The solution isnโt a 50-page manual, but rather short, living rules that the AI can read right where it works.
A context rule is a brief (Markdown) file that lives next to your code (for example, in .cursor/rules/) and explains how a specific file or module should look and behave:
When your AI-powered editor (e.g., Cursor) generates or modifies code, it reads these rules as a guide to maintain consistency. It doesnโt replace linters or tests; itโs a lightweight specification that guides the AI.
Mini-example (.mdc):
1# Purpose 2Consistent REST responses. 3 4# Conventions 5- JSON with `{ data, error }`. 6- Errors include `code` and `message`. 7 8# โ Correct 9return res.json({ data: user, error: null }); 10 11# โ Incorrect 12Responding with `{ result }` in some endpoints and `{ payload }` in others.
Practical rule: if youโve corrected the same type of AI output twice, itโs time to write a short rule.
Pick a โVIPโ file. Something that sets the tone for the rest: routes.py, UserService.ts, Form.tsx, theme.ts, etc.
Ask the AI to draft the rule. In Cursor, with the file open, request:
1Generate a short rule to keep this file consistent. 2Include: purpose, 3โ5 conventions, and at least 1 correct example. 3Donโt add prose outside the rule.
.cursor/rules/ folder and save as api-endpoints.mdc (use a descriptive name).1# Purpose 2<what it standardizes and why> 3 4# Conventions 5- <concrete rule 1> 6- <concrete rule 2> 7- <concrete rule 3> 8 9# โ Correct 10<minimal snippet with the expected format> 11 12# โ Incorrect 13<typical snippet we donโt want>
1# Purpose 2Standardize REST endpoints with consistent responses. 3 4# Conventions 5- Respond with JSON `{ data, error }`. 6- Errors include `code` and `message`. 7- Avoid business logic in the controller; delegate to services. 8 9 10# โ Correct 11router.get('/users/:id', async (req, res) => { 12 try { 13 const user = await svc.getUser(req.params.id); 14 return res.json({ data: user, error: null }); 15 } catch (e) { 16 return res.status(400).json({ data: null, error: { code: 'USER_GET_FAILED', message: String(e) } }); 17 } 18}); 19 20# โ Incorrect 21Responding with `{ result }` in one endpoint and `{ payload }` in another.
Frontmatter YAML and globs are optional in this basic module.
To test the rule, ask the AI for a real modification to the VIP file (for example, โadd GET /users with paginationโ) and check if it follows the rule. If it deviates, adjust the rule with a single change (delta prompting), for example: โadd that successful responses use status 200 and errors โฅ400; change nothing else.โ Repeat until the suggestions are consistent and always add a section with correct and incorrect examples, since seeing what you do and donโt want helps the model lock in the standard.
Imagine youโre adding a new chat feature to your app using WebSockets. Hereโs how you could use rulesโcreate a file like chat-websocket.mdc and outline the following:
1# Purpose 2Consistent errors and reconnection in WebSocket (chat). 3 4# Conventions (why) 5- `onerror` + `onclose` (visibility and stability). 6- Exponential backoff max 30s (avoid aggressive loops). 7- Encapsulated connection (avoid fragile global state). 8 9# โ Correct 10const socket = new WebSocket(URL); 11socket.onerror = (err) => { log('ws_error', err); attemptReconnect(); }; 12 13# โ Incorrect 14Just `console.error` without reconnection or encapsulation.
Now ask for โtyping notificationsโ and the AI should maintain onerror + reconnection without further reminders.
To keep rules organized, store them in .cursor/rules/ with clear names and, if helpful, subfolders by module or layer. Version everything like code, commit them to git, and review them in PRs. In each PR, explain why the rule exists or changes (what problem it solves) so the team understands the context. Also, when writing and maintaining rules, avoid common pitfalls. If a rule gets long, trim it to the essentials and move large examples to a separate file. Replace vagueness (โclean codeโ) with concrete actions (โuse try/catch in async fetch callsโ). If there are duplicates or conflicts, unify or document precedence (โif it overlaps with X, X takes priorityโ). And donโt skip the testโask for a real modification and verify the AI follows the rule.
Creating rules mid-development is often easier because you have real code to start from. If, instead, youโre repeating a well-known pattern (e.g., a simple REST API youโve built before), you can prepare 1โ2 rules from day one. There are also public collections of pre-written rules you can adapt (e.g., cursorrules).
/Generate Cursor Rules and refine the output, the better your promptsโand the better the AI will help you!You donโt need a perfect system to start. With a good rule in a key module, youโll already notice less friction and more consistency. Create your first one today, test it, and tweak it with small changes; tomorrow, your AI will already be suggesting code more aligned with your project.