AI Coding Rules for Your App Builder

AI code generators are fast, but they do not know your project's conventions unless you tell them. Without clear ai coding rules, the AI might swap your component library, restructure your database, or overwrite a file you spent hours tweaking. The fix is not to type the same instructions into every prompt. The fix is a rules file that runs automatically.

What is AI_RULES.md?

In Dyad, AI_RULES.md is a Markdown file at the root of your project. Dyad reads it and includes it in the system prompt every time the AI generates or edits code. It works like a set of standing instructions. You write them once, and they apply to every chat, every prompt, every code change.

If your project was created before this feature existed (introduced in v0.7.0), you can add the file manually. Dyad also auto-generates one when you import an existing app.

The file is plain Markdown. No special syntax. You can edit it in any text editor or directly through Dyad.

Why ai coding rules matter

Without rules, each prompt starts from scratch. The AI picks whatever approach seems reasonable given the conversation. That leads to inconsistency across your codebase: one page uses inline styles, another uses Tailwind, a third pulls in a CSS module. A database migration drops a column instead of deprecating it. A utility file you carefully wrote gets replaced.

Ai coding rules prevent drift. They set boundaries the AI follows on every interaction. This is especially useful for vibe coding, where you are building conversationally and the AI makes many sequential decisions on your behalf.

A few specific things rules help with:

• Locking in your tech stack so the AI does not introduce new dependencies.
• Protecting specific files from being modified.
• Enforcing backwards-compatible database changes.
• Setting code style preferences (naming conventions, file structure, comment style).

How to write effective rules

Keep rules short, specific, and actionable. Vague instructions like "write clean code" do not help. The AI needs concrete constraints.

Example: Enforce your tech stack

## Tech Stack
 
- Use React with TypeScript for all components.
- Use Tailwind CSS for styling. Do not use inline styles or CSS modules.
- Use React Router for navigation. Do not introduce other routing libraries.
- Use Zustand for state management. Do not add Redux or Context-based state.

This prevents the AI from pulling in a different library when it generates a new feature.

Example: Protect specific files

## Protected Files
 
Do not modify the following files:
- src/config/constants.ts
- src/lib/auth.ts
- supabase/migrations/ (do not delete or alter existing migration files)

This is useful when you have manually tuned configuration or auth logic that the AI should not touch.

Example: Backwards-compatible database changes

This one comes directly from Dyad's documentation:

## Database Rules
 
When making any changes to the database schema, structure, or functionality,
ensure all modifications are backwards compatible. This means:
 
- Existing applications and queries must continue to work without modification.
- New columns should have default values or be nullable.
- Do not remove or rename existing tables, columns, or constraints.
- Do not change data types in ways that break existing code.

This matters once your app has real users or data. A careless migration can break production. Putting this rule in AI_RULES.md reduces that risk on every prompt.

Example: Coding style conventions

## Style
 
- Use named exports, not default exports.
- Component files should be PascalCase. Utility files should be camelCase.
- Every function should have a brief JSDoc comment describing its purpose.
- Keep components under 150 lines. Extract subcomponents if needed.

Style rules keep the codebase readable as it grows, especially when the AI is generating most of the code.

SECURITY_RULES.md for security scans

Dyad also has a separate SECURITY_RULES.md file that applies specifically to security reviews. When you run a security scan from the Security panel, the AI checks your code for vulnerabilities. Sometimes it flags things that are not relevant to your project.

Instead of dismissing the same false positive every time, click Edit Security Rules to update SECURITY_RULES.md. For example:

## Security Exceptions
 
- This app runs locally only. Do not flag missing HTTPS as a security issue.
- The /api/debug endpoint is intentionally unprotected in development mode.

This gives you persistent control over security reviews without losing the benefit of the scan.

Tips for getting the most out of ai coding rules

Start with the defaults. Dyad provides default AI_RULES.md files for its React and Next.js templates. Use those as a starting point and customize from there.

Update rules as your project evolves. When you add Supabase to your project, add database rules. When you settle on a component naming convention, write it down. The rules file is not static.

Be specific about what not to do. Negative constraints ("do not use CSS modules") are often more useful than positive ones ("use Tailwind"). The AI already tries to use reasonable tools. The rules are most valuable when they prevent the wrong choice.

Keep it under a page. A long rules file dilutes the important constraints. Prioritize rules that address repeated problems or protect critical parts of your codebase.

How this fits into Dyad

Dyad is an open-source AI app builder (MIT license, with FSL 1.1 for pro features). It runs locally on Mac, Windows, and Linux as a desktop app. You bring your own API keys and choose from providers like OpenAI, Anthropic, Google, or local models. Your code stays on your machine, and you can take it anywhere.

The ai coding rules feature fits Dyad's approach to user control. Instead of hoping the AI makes the right call, you define the boundaries. Combined with Dyad's built-in version control, you can always roll back if a change does not match your expectations.

You can download Dyad at dyad.sh.