AI Agent Rules

Using Django
1

I’m curious if people have found success/frustration using Agent rules. If you’re unaware, this is something separate from your prompts, it’s more like a style guide that is sent to the LLM model in the context with each request. Here are examples from some of the major AI IDEs:

Examples:

@czue has a recent video talking about using Django + Cursor with rules and other things.

Anyway, this feels like something the community could sort out some best practices to save us all time and frustration here!

4 Likes
2

Thanks for the ping / shout out! This is something I’ve been trying to figure out as well and am very interested to hear best practices from others. My general sense is that everyone is figuring out this stuff and just throwing a bunch of things at the wall and seeing what sticks. Or at least that’s what I’m doing. :sweat_smile:

A general “Django rules” file would be awesome, but I didn’t find anything great in my research and a lot of stuff I did find was like “be a super duper smart senior developer” which… I’m skeptical helps? Plus every Django project will have its own set up and guidelines so I don’t know how generally useful rules can be across projects.

Some specific things I’ve found useful:

A big picture “architecture” section/file. This is somewhat useful when building out end to end features. Here’s what mine looks like:

## Architecture

- This is a Django project built on Python 3.12.
- User authentication uses `django-allauth`.
- The front end is mostly standard Django views and templates.
- HTMX and Alpine.js are used to provide single-page-app user experience with Django templates.
  HTMX is used for interactions which require accessing the backend, and Alpine.js is used for
  browser-only interactions.
- JavaScript files are kept in the `/assets/` folder and built by vite.
  JavaScript code is typically loaded via the static files framework inside Django templates using `django-vite`.
- APIs use Django Rest Framework, and JavaScript code that interacts with APIs uses an
  auto-generated OpenAPI-schema-baesd client.
- The front end uses Tailwind (Version 4) and DaisyUI.
- The main database is Postgres.
- Celery is used for background jobs and scheduled tasks.
- Redis is used as the default cache, and the message broker for Celery.

I also have a dedicated “commands” section/file. This is especially helpful for things like uv where the agents often try to use pip and virtualenv by default. So stuff like this:

- Adding python dependencies: `uv add <library>`
- You can run generic Python commands using `uv run <command>`

I also find giving it best practices around my project’s data modeling has been helpful when it’s generating new models. E.g.

- All Django models should extend `apps.utils.models.BaseModel` (which adds `created_at` and `updated_at` fields).
- The project's user model is `apps.users.models.CustomUser` and should be imported directly.

Obviously telling it your preferences on, e.g. CBVs vs FBVs, whether you use DRF or ninja and that sort of thing is useful.

Big picture, I think the most useful practice has been whenever it does something differently than I wanted, make a rule that tells it how to do it the right way and then tell it to read the rule and do it again. This has been a nice way to iterate on my rules and generally have it continually adapt more and more to my project’s specific setup.

4 Likes
3

Minor frustration - testing the different tools I’m frustrated that each has its own markdown file setting out the rules. Working in a team where each dev chooses their own IDE and tooling I have been meaning to set up a ci script to copy a single agents.md file into claude.md, github/copilot.... and .junie/inst... files.

4

Use symlinks? Git can store them.

1 Like
5

That’s an interesting point. I think/hope that the IDEs come to some sort of standardization on this as they’re all doing more or less the same thing. For now, @adamchainz idea probably makes sense, albeit annoying to have to implement.

6

`

The day after my post the market leader announced their own agents file using the exact name I suggested here on the Django forum. Coincidence? https://openai.com/index/introducing-codex/

1 Like
7

The JetBrains Junie repo now has a Python/Django section. The attempt is something broad enough to apply across all new Django projects, so this is a lot “less” detailed and opinionated than what I use myself, but the goal is something that is broadly “best practices” and helps somebody new get the most of out AI agents.

2 Likes
8

This is a great question. We’ve been talking about this at work just this week and I’ve been thinking about it a lot.

For what it’s worth, my conclusions are right on with @czue. Here are my guiding principles:

  • When I write prompts, I’m trying to be thorough.
  • If I find I’m repeating myself, I turn it into a rule.
  • If I find it’s doing something that I don’t want it to do, I make a rule about it.
  • I rely a lot on ruff to handle nit picky formatting, extraneous imports, etc.
  • I have found tools like pyupgrade and django-upgrade have become more useful to me.

Some example rules I’ve made:

  • feature.mdc: Where are the models, what are they called, how are they processed.
  • bun-tests.mdc: Explains that we use the Bun JavaScript runtime and test runner (it usually defaults to Node and Jest, respectively).
  • icons.mdc: Here’s where you should find and store SVG icons for reuse later.

I was underwhelmed with the agent rules initially, but now they are saving me a lot of time.