DEV Community

Cover image for Stop Asking AI to Code. Give It a Rules File Instead.
Thameem Azfar Ansari
Thameem Azfar Ansari

Posted on

Stop Asking AI to Code. Give It a Rules File Instead.

#ai #webdev #programming #productivity

AI coding tools are amazing.

They can generate components, write functions, explain bugs, refactor code, create tests, and help us move faster.

But there is one problem:

Most developers are using them like this:

Build me a dashboard.
Enter fullscreen mode Exit fullscreen mode

or:

Fix this bug.
Enter fullscreen mode Exit fullscreen mode

or:

Add authentication to my app.
Enter fullscreen mode Exit fullscreen mode

Then the AI returns a huge block of code.

It looks impressive at first.

But after a few minutes, you notice the problems:

  • It changed files you did not ask it to touch.
  • It invented functions that do not exist.
  • It ignored your project structure.
  • It used a different coding style.
  • It added unnecessary complexity.
  • It skipped edge cases.
  • It forgot error handling.
  • It gave you code that works in theory but does not fit your actual project.

The issue is not always that the AI is bad.

The issue is that the AI does not have enough rules.

We keep asking AI to code, but we do not tell it how to behave inside our codebase.

That is why one of the best things you can do is create a simple file:

AI_RULES.md
Enter fullscreen mode Exit fullscreen mode

or:

AGENTS.md
Enter fullscreen mode Exit fullscreen mode

or:

CONTRIBUTING_AI.md
Enter fullscreen mode Exit fullscreen mode

The name is not the important part.

The important part is this:

Give AI clear rules before you ask it to write code.

AI Does Not Need More Freedom. It Needs Better Boundaries.

When people first start using AI coding tools, they usually try to make the prompt bigger.

They write things like:

Build a full-stack app with authentication, dashboard, database, admin panel, responsive UI, dark mode, settings page, and payment integration.
Enter fullscreen mode Exit fullscreen mode

That sounds productive.

But it often creates a mess.

Why?

Because the AI has to guess too many things at once.

It has to guess:

  • your framework
  • your styling system
  • your folder structure
  • your naming conventions
  • your state management approach
  • your API patterns
  • your error handling style
  • your testing strategy
  • your security expectations
  • your definition of “done”

When AI has to guess, it will still give you an answer.

That is the dangerous part.

It may not say:

“I do not have enough context.”

It may just confidently produce code.

That is why AI coding should not begin with code.

It should begin with rules.

What Is an AI Rules File?

An AI rules file is a simple markdown document that tells your AI assistant how to work in your project.

It is like onboarding documentation for a new developer.

But instead of writing it only for humans, you write it in a way that AI can also follow.

A good AI rules file explains:

  • how the project is structured
  • what coding style to follow
  • what files should not be touched
  • how to handle errors
  • how to approach testing
  • what security rules matter
  • how the AI should respond before and after writing code

It does not have to be complicated.

In fact, simple rules are usually better.

Here Is a Simple AI Rules File You Can Copy

Create a file called AI_RULES.md in the root of your project and paste this:

# AI Coding Rules

You are helping inside an existing codebase.

Your job is not just to generate code.
Your job is to make careful, minimal, maintainable changes that fit the project.

---

## General Rules

1. Do not rewrite large parts of the project unless specifically asked.
2. Do not modify unrelated files.
3. Follow the existing project structure and coding style.
4. Prefer small, focused changes over large rewrites.
5. Reuse existing components, utilities, functions, and patterns.
6. Do not invent APIs, files, database fields, environment variables, or functions.
7. If something is unclear, ask a question before making assumptions.
8. Explain your plan before writing code.
9. After making changes, summarize what changed and why.
10. If a requested change has risks, mention them clearly.

---

## Code Quality Rules

1. Write readable code.
2. Use clear variable and function names.
3. Avoid unnecessary abstraction.
4. Avoid duplicating logic.
5. Keep functions small when possible.
6. Prefer simple solutions over clever ones.
7. Add comments only when they make the code easier to understand.
8. Do not remove existing comments unless they are incorrect.
9. Do not remove tests or error handling unless there is a clear reason.
10. Keep the code easy for another developer to review.

---

## Security Rules

1. Never expose secrets, tokens, passwords, API keys, or credentials.
2. Do not log sensitive user data.
3. Validate user input where necessary.
4. Avoid unsafe HTML injection.
5. Be careful with authentication and authorization logic.
6. Do not weaken existing security checks.
7. Explain security-sensitive changes clearly.

---

## Testing Rules

1. Add or update tests when behavior changes.
2. Do not fake passing tests.
3. Mention any tests that should be run manually.
4. Include important edge cases.
5. If tests cannot be added, explain why.

---

## Response Rules

Before writing code:

- Explain your understanding of the task.
- Give a short implementation plan.
- List the files you expect to modify.
- Mention any unclear requirements or risks.

After writing code:

- Summarize the changes.
- Explain how to test them.
- Mention anything that still needs review.
Enter fullscreen mode Exit fullscreen mode

That one file can make your AI coding workflow much better.

Not perfect.

But much better.

Bad Prompt vs Better Prompt

Here is a common prompt:

Add dark mode to my app.
Enter fullscreen mode Exit fullscreen mode

This is not a terrible request, but it is too open-ended.

The AI might:

  • create a new theme system
  • install a package you do not need
  • change every component
  • ignore your existing CSS
  • forget persistence
  • break your current design

A better prompt would be:

Read AI_RULES.md first.

I want to add dark mode to this app.

Before writing code:
1. Inspect the current styling approach.
2. Explain the simplest implementation.
3. List the files that need to change.
4. Do not modify unrelated files.
5. Do not install new packages unless necessary.

Wait for my approval before writing code.
Enter fullscreen mode Exit fullscreen mode

This prompt is slower.

That is the point.

When using AI for real projects, speed is not just about how fast code appears on the screen.

Speed is also about avoiding bad code, broken features, and painful debugging later.

The Real Problem Is Not AI Code. It Is Unreviewed AI Code.

AI-generated code should not be treated as finished work.

It should be treated like a pull request from someone who is fast, helpful, and sometimes confidently wrong.

That means you still need to review it.

Before accepting AI code, ask:

  • Does this solve the actual problem?
  • Did it follow the existing project style?
  • Did it change unrelated files?
  • Did it duplicate existing logic?
  • Did it invent anything?
  • Did it handle errors?
  • Did it handle empty states?
  • Did it handle loading states?
  • Did it create security risks?
  • Do I understand the code?

If you do not understand the code, do not merge it.

AI can help you move faster, but it should not remove your responsibility as a developer.

My 5-Step AI Coding Workflow

Here is a safer workflow for using AI inside a real project.

1. Ask AI to Understand the Project First

Before asking it to write code, ask it to explain the project.

Read the project structure and AI_RULES.md.

Do not write code yet.

Explain:
1. What this project appears to do.
2. How the main folders are organized.
3. What patterns are being used.
4. Anything important I should know before making changes.
Enter fullscreen mode Exit fullscreen mode

This helps you catch misunderstandings early.

If the AI misunderstands the project, you can correct it before it starts changing files.

2. Ask for a Plan Before Code

Do not jump straight into implementation.

Ask for a plan.

I want to add [feature].

Before writing code:
- Explain the approach.
- List the files you expect to modify.
- Mention possible risks.
- Suggest the smallest reasonable implementation.

Do not write code yet.
Enter fullscreen mode Exit fullscreen mode

This is one of the most important steps.

If the plan is bad, the code will probably be bad too.

Fix the plan first.

3. Break Big Features Into Small Tasks

Bad prompt:

Build the full admin dashboard.
Enter fullscreen mode Exit fullscreen mode

Better prompt:

Create only the admin dashboard layout using existing components.
Do not connect APIs yet.
Do not add charts yet.
Do not add authentication changes.
Enter fullscreen mode Exit fullscreen mode

Small tasks are easier to review.

They also reduce the chance of AI making random changes across the project.

A good rule is:

If the AI response would require a massive diff, the task is probably too big.

Break it down.

4. Review the Diff Like a Pull Request

After AI makes changes, do not just run the app and move on.

Review the diff carefully.

Look for:

  • unrelated file changes
  • unnecessary dependencies
  • duplicated code
  • inconsistent naming
  • missing error states
  • missing tests
  • security issues
  • over-engineering
  • code that looks correct but does not match your project

AI can create clean-looking code that is still wrong.

Your job is to catch that.

5. Ask AI to Criticize Its Own Work

One of the best prompts is:

Review your own changes.

Look for:
- bugs
- missing edge cases
- security issues
- unnecessary complexity
- files changed by mistake
- better ways to follow the existing project style

Be strict.
Enter fullscreen mode Exit fullscreen mode

AI often performs better when reviewing code than when generating it.

Creation mode gives you output.

Review mode gives you criticism.

Use both.

A Better Prompt Template

Here is a prompt you can reuse:

Read AI_RULES.md first.

Task:
[Describe the task clearly]

Before writing code:
- Explain your understanding.
- Give a short implementation plan.
- List files you expect to modify.
- Mention risks or unclear requirements.

Rules:
- Keep the change small.
- Follow existing project patterns.
- Do not touch unrelated files.
- Do not invent APIs, functions, or fields.
- Add or update tests if behavior changes.
- Explain how to test the change.

Wait for my approval before writing code.
Enter fullscreen mode Exit fullscreen mode

This is not magic.

But it creates structure.

And structure is what most AI coding workflows are missing.

Example: Refactoring With Rules

Bad prompt:

Refactor this file.
Enter fullscreen mode Exit fullscreen mode

This is too vague.

The AI might rewrite everything.

A better prompt:

Read AI_RULES.md first.

Refactor this file only for readability.

Rules:
- Do not change behavior.
- Do not rename exported functions.
- Do not modify other files.
- Keep the public API the same.
- Explain each change.
- Mention how I can verify behavior stayed the same.

Before editing, give me a plan.
Enter fullscreen mode Exit fullscreen mode

This makes the task safer.

Refactoring should reduce risk, not create it.

Example: Bug Fixing With Rules

Bad prompt:

Fix the login bug.
Enter fullscreen mode Exit fullscreen mode

Better prompt:

Read AI_RULES.md first.

There is a bug where users sometimes stay on the login page after submitting valid credentials.

Before writing code:
1. Explain possible causes.
2. Identify which files are likely involved.
3. Suggest a debugging plan.
4. Do not change code until the cause is clear.
Enter fullscreen mode Exit fullscreen mode

This is much better because you are not asking AI to guess a fix.

You are asking it to investigate first.

That is how real debugging works.

Example: Adding Tests With Rules

Bad prompt:

Write tests for this.
Enter fullscreen mode Exit fullscreen mode

Better prompt:

Read AI_RULES.md first.

Add tests for the checkout calculation logic.

Focus on:
- normal checkout
- empty cart
- discount code
- invalid discount code
- tax calculation
- rounding issues

Do not change production code unless you find a bug.
Explain any behavior that seems unclear.
Enter fullscreen mode Exit fullscreen mode

Specific testing prompts produce much better results.

AI is useful for tests, but only when you define the cases clearly.

What You Should Not Put in Your Rules File

Do not make your AI rules file too long.

If it becomes huge, the important rules get buried.

Avoid rules like:

Always write perfect code.
Enter fullscreen mode Exit fullscreen mode

That means nothing.

Avoid rules like:

Make the app scalable.
Enter fullscreen mode Exit fullscreen mode

Too vague.

Avoid rules like:

Use best practices.
Enter fullscreen mode Exit fullscreen mode

Everyone says this, but it does not tell the AI what to actually do.

Better rules are specific:

Do not modify unrelated files.
Enter fullscreen mode Exit fullscreen mode 
Reuse existing components before creating new ones.
Enter fullscreen mode Exit fullscreen mode 
Do not add new dependencies without explaining why.
Enter fullscreen mode Exit fullscreen mode 
Ask before changing database schema.
Enter fullscreen mode Exit fullscreen mode

Specific rules beat inspirational rules.

Add Project-Specific Rules

The best rules file is not generic.

It should include details about your actual project.

For example:

## Project-Specific Rules

- This project uses TypeScript.
- This project uses React components from `/components`.
- Shared utility functions are stored in `/lib`.
- API calls should go through the existing API client.
- Do not call `fetch` directly inside components.
- Do not create new global styles unless necessary.
- Forms should use the existing form components.
- Error messages should follow the existing format.
- Do not change database schema without approval.
Enter fullscreen mode Exit fullscreen mode

These rules are much more useful than saying:

Write clean code.
Enter fullscreen mode Exit fullscreen mode

Because they tell AI what “clean” means in your project.

AI Should Not Replace Thinking

There is a dangerous mindset around AI coding:

“The AI wrote it, so it must be fine.”

That is not how software works.

AI can help with:

  • boilerplate
  • explanations
  • refactoring ideas
  • test cases
  • debugging suggestions
  • documentation
  • code review
  • repetitive tasks

But you are still responsible for the final result.

You still need to understand the code.

You still need to review the changes.

You still need to test the behavior.

You still need to think.

AI does not remove engineering judgment.

It makes judgment more important.

Why This Workflow Works

A rules file works because it changes the AI from a random code generator into a more disciplined assistant.

Without rules, AI optimizes for giving you an answer quickly.

With rules, AI has boundaries.

It knows:

  • what not to touch
  • what to explain
  • what risks to mention
  • what style to follow
  • what quality level you expect

That does not make the AI perfect.

But it makes the interaction more predictable.

And predictable is good.

In software, predictable usually beats impressive.

Quick Checklist Before Accepting AI Code

Before you accept AI-generated code, run through this checklist:

[ ] Does this solve the actual problem?
[ ] Is this the smallest reasonable change?
[ ] Did it follow existing project patterns?
[ ] Did it avoid unrelated file changes?
[ ] Did it avoid unnecessary dependencies?
[ ] Are errors handled?
[ ] Are loading and empty states handled?
[ ] Are security risks considered?
[ ] Are tests added or updated where needed?
[ ] Do I understand the code?
Enter fullscreen mode Exit fullscreen mode

That last one is the most important.

If you do not understand the code, you are not done.

Final Thoughts

AI coding tools are not going away.

They are becoming part of how many developers work.

But using AI well is not just about writing better prompts.

It is about creating better systems.

A simple AI_RULES.md file gives your AI assistant context, boundaries, and expectations.

It helps you avoid random code.

It helps you get smaller diffs.

It helps you review changes more safely.

Most importantly, it reminds you that AI is not the owner of your codebase.

You are.

So the next time you want AI to build something, do not just ask:

Can you code this?
Enter fullscreen mode Exit fullscreen mode

Start with:

Read the rules first.
Enter fullscreen mode Exit fullscreen mode

Because the goal is not to generate more code.

The goal is to ship better software.

What rule would you add to your own AI_RULES.md file?

Top comments (0)