Possibly, but does it cost them extra money to add the words “in agent mode” (i.e. “to choose from in agent mode”)? 
What I’m curious about is — doesn’t it remember past conversation rules?
For example, if I tell it in my project that all buttons must always be red, and then we continue developing — when I ask it to add another button, shouldn’t it remember that the button should be red?
In my opinion, these rules files are more confusing than helpful.
They might seem useful at first, but they just add more clutter on top of the already heavy codebase, and having to deal with rule files can become frustrating.
What I don’t understand is — since the model can sometimes review past conversations and update its behavior accordingly, why not use that memory more intelligently?
It’s explained in Context Window - memory only happens if you stay in the very same chat. But the longer the chat goes, the more overwhelmed it will get and start causing a mess.
So you have to choose between long term memory and more quality answers.
1 Like
Yes, I’m aware of that. In fact, when the conversation gets too long, I usually close it and start a new one.
But I’ve seen many examples where it feels like you’re building an entire project on top of the rules defined in an MCP (Model Code Protocol).
You’re spending more time writing rules than actually writing code.
this is exactly why they changed Cursor from having the entire codebase in context by default to only having relevant code in conversation memory. too much context is not helpful past a certain point
previous conversations aren’t in memory, only the current one, but rules files are (when attached) as is any code provided as context
if you want a button to always be red, add that to your .cursor/rules/
# General Rules
- always use #FF0000 for button color
// ... other rules
or even better, hardcode that variable into your codebase. defaults and things that should never change should be part of your code, not part of your rules or conversations
add a css stylesheet that includes how buttons should always look by default
.button {
/* primary colors */
background-color: #ff0000; /* red background */
color: #ffffff; /* white text */
/* ...other button styles */
}
you can do similar things with any type of code. every programming language has a means of defining default values
if you’re vibe coding, you technically are writing an entire project on top of rules. if something should persist through the entire project, tell the agent to set up constants within your code
when I go into a new codebase and need to determine what the “rules” are for that code, I look at things like constants, tests, and other parts of the code that define unchanging variables. Cursor AI is instructed to behave like a senior software engineer, and engineers look at certain parts of the code first
when codifying rules, use a prompt like:
“my code should always do XY or Z. make sure the source code reflects this rule/preference in a way that is obvious to future maintainers”
in most cases, this will ensure that your preferences are part of the source code and available regardless of conversation context
tldr; having too many sources of truth is confusing, so you make sure there is only one. it should go: code > rules files > docs > conversation context
1 Like
I understand that using config files and rule-based approaches can be seen as a more “professional” way to interact with AI agents. However, I’ve developed my own method that works better for me, especially when starting new projects. Here’s how I typically use AI tools:
Agent Mode First
Instead of defining strict rules upfront, I prefer to start by putting the AI into an agent mode — asking it to deeply analyze all files in my project. This helps the AI build full context before taking any specific actions.
Step-by-Step Instead of All-at-Once
Rather than providing all details at the beginning, I explain each part step-by-step. This results in more accurate outcomes and better understanding, especially in larger or more complex projects.
Short Conversations, New Threads
I avoid letting the conversation become too long. Once I finish a task or switch context, I prefer starting a new thread to avoid confusion. This keeps each session clean and focused on a single goal.
This approach has been more efficient and reliable for me, especially when building or maintaining evolving codebases.
Hope that helps others who might be struggling with overly rigid workflows! 
these are strictly conversation optimization tips and don’t address at all where the agent obtains standardization from which is very important as every model has it’s own way of doing things and preferred patterns
code review and short incremental work are both valuable, but in order to address issues like the problem you mentioned previously—i.e. the agent not remembering that all buttons should be red—you must have either rules or properly configured config code
this isn’t an “overly rigid workflow” it’s first principles, I’m all for people discovering how cool programming is through vibe coding but try to pick up a little bit of knowledge on your journey instead of shortcutting wherever you can
these problems have been solved way before AI existed, and it’s a hell of a lot easier to properly configure your codebase than trying to reinvent the wheel
1 Like