Flutter docs now contain the AI rules section. This section provides a link to the rules.md file, which is the template for the "Rules for the Agent".
"Rules for the Agent" is the common name for a document used by Agentic IDEs like Cursor, Windsurf, or Trae to instruct the agent how the code should be generated.
If you are a member, please continue, otherwise, read the full story here.
The file is pretty big, about 4000 words, and contains general guidelines for Flutter development. The question is, will it help, or rather, will it confuse the LLM? My typical request in Trae, which consists of a textual prompt, code, and my specific Agent rules, is far less than 1000 words.
Often, that 4000-word rules file will hurt more than help.
Why it might confuse the LLM
Think about how context works. When you send a request to an LLM through Cursor or similar tools, everything competes for attention — your actual prompt, the code snippets, and those rules. If your typical request is under 1000 words and you're adding 4000 words of rules, you're basically drowning your actual question in noise.
LLMs don't process information as humans do. They don't "read the rules once and remember them." Every single request includes those rules again, and the model has to figure out what's important right now. A 4000-word rules document contains advice about testing, state management, architecture, styling, performance — but if you're just asking "parse this JSON," most of that context is irrelevant and might actually lead the model to overthink a simple task.
Here are my Agent rules that I actually use with Trae:
If not specified otherwise, we use Dart and Flutter with GetX framework.
Use MVVM architecture. Keep View to ViewModel relationships as one-to-one.
Typical feature should be written using four classes/libraries: View,
ViewModel (GetxController), Model (data class(es)),
and Service (class that contains logic).
Use GetBuilder with update() method.
Always use named routes.
Use GetView<SomeController> instead of StatelessWidget.
There is no need to create an instance of SomeController.
GetView provides the controller getter.
Don't use StatefulWidgets. Put disposable resources in controller.
Inject controller's dependencies thru contructor from Binding class.
Don't extend GetXService. Services are always singletons.
They don't need to be part of view lifecycle.
Don't use functions or methods to create widgets;
use custom widget classes instead.
Method withOpacity(0.5) is deprecated. Use withValues(alpha: 0.5) instead.
Never use FloatingActionButton.
Replace with block (full-width) ElevatedButton.
Use relative imports only for the classes in the same folder.
Otherwise, use package imports.
Usually, I run my apps from the separated VSCode window.
Don't try to run terminal commands.
Don't be unconditionally supportive. Be friendly sceptical and open-minded.
Provide constructive critical feedback.
If there is a better solution, suggest it.It is just 200 words. And even those rules make sense only when I request to generate the whole feature, which I do relatively rarely. Most of the time, I ask the Agent to generate a single method.
General rule about AI-assisted coding:
More specific tasks with a smaller context provide better results.
"Rules for the Agent" should contain information about what makes your codebase different. Your coding style. Your preferred state management and routing solutions. Your layout habits. Packages you are using. Deprecated classes and methods.
The template from Flutter docs contains about 7000 tokens of general info about Flutter development. But LLM already contains, probably, hundreds of thousands, if not millions, of tokens from Flutter docs, pub.dev, and github repositories. And tokens from the initial LLM training are not the same as tokens that were received with the user request; they are much more valuable. Trying to resupply them might even conflict with the model's training or cause it to second-guess itself.
So, are those rules, recommended by the Flutter team, completely useless?
Absolutely not. While I will not use them as intended, I have already read them twice, and I will read them again. This is a very well-formatted document that contains all Flutter development guidelines in one place.