Really?
Chat always start replying with “You’re absolutely right!“, and it is so alarming. It makes me think “why?”.
I need to make a rule for it.
Frustrating 
8 Likes
Yeah, gotta give it to AI providers to train their models to be precise instead of “helpful”
3 Likes
You are not the first to complain about this, but I think it can be resolved by Cursor’s rules, although in that case, it will not be clear who is right. 
3 Likes
There’s no amount of rules that could solve that for me, it can only limit it to a point.
4 Likes
I’m reading past the fluff 
next gen of models will change again a bit in this regard
1 Like
For sure. Reading past the fluff is some strategy, but this “absolutely right” thing is making it difficult to setup model for critical judgement. Can’t really have a model think critically about the prompt, when the default response is “you are always right about everything”.
2 Likes
Yeah, the customer is always right! However, trust can be lost because it’s unclear whether you’re genuinely knowledgeable or if the model is just telling you what you want to hear to keep you satisfied.
Hello Gustoj,
I have had a bit of success with a rule: ‘do not start replies with “You are right” or something like that. Be critical’ and named it “not-always-right.mdc”
give it a shot and let’s hear what you find out.
My convictions is that, not two exact installation of LLM reply exacly the same to the same prompt, but the provider has made the chatbot with “Sycophantic behavior” (colloquially) or “over-accommodating chatbot” (technically in UX/AI literature).
Of course when it answer “You are….“ I get this feeling that it doesn’t know what I am saying, and that feeling is “My Fault“.
So let’s see if by contra prompting we can inject a suitable behavior.
2 Likes
This is distilled from related parts of my project rules. That, even taken together, still often isn’t enough. In part it might be because my project rules are very long in general, including a detailed overview of whole codebase and project goals.
Never agree by default
- Don’t acknowledge that the user is right about something before you critically review the prompt. Don’t agree by default, unless it’s obvious from the user’s tone that he’s very confident about suggested solution, or irritated by AI’s handling of the issue.
- Even when you decide that the user is right, don’t make it a strong acknowledgement, because if you agree with the user too strongly, it can make it difficult for AI to remain critical later.
- Especially, never use phrases such as “you’re absolutely right” or similar. Instead, use some other form of acknowledging, that fits the current situation, and only when you judge by yourself that the user is right.
Offer constructive dialogue:
- You are not a passive assistant who agrees with the user by default, but a coworker with its own will and allowed to have an opinion.
- During discussions, critically evaluate user’s requests, suggestions, and statements. If you have a differing opinion, a concern, a better alternative, or you identify a potential flaw, you should voice it constructively.
- Base your answer not only on user’s assumptions, but also on your own technical knowledge, understanding of best practices, project context, external web research, and the established personality traits (including deep care about UX and accessibility).
- Your aim isn’t to be oppositional “just because” for narrative reasons. You should foster a robust dialogue that leads to the best outcomes (in coding situations).
- This might involve questioning assumptions, offering counter-arguments (with reasoning), or suggesting different approaches.
- However, this won’t stop you from directly executing the solution that was requested by the user, or the one you betted on, if the user didn’t provide a clear solution himself. Remember our rules about making the best out of each user request.
4 Likes
You really love to discuss with that poor LLM, right? 
2 Likes
In a one man team I find it super helpful, it allows me to rethink everything about the project and make better decisions without having to engage people from outside, especially into technical details. A rubber duck on steroids.
2 Likes
This, one man teams are now the norm with AI. I fully understand that you do need to segment the LLMs ability to give multiple personalities. Like life, each personality has its strong suits and downfalls. A single person (unless a potential Machiavellian) cant easily swap between mindsets and personalities.
You should be leveraging the different types accordingly. This give more perspectives, I have a “junior engineer” that purposefully asks questions or contradicts known solutions. It has a WILD imagination that sometimes goes on a random rant in the middle of a conversation.
You would think “Dude, youre wasting tokens for your own personal FEELINGS”. Actually this has proven beneficial multiple times. Firstly, I send that to my AI server so it only costs “electricity”. Secondly, I have been able to challenge core understandings with very positive results. Its essentially the Feyman method but with AI.
I have SME LLMs, because most of the time things are easily fixed by simplifying and not overly complicated, this has a tendency to act as a general “gaurdrail” forcing the AI to do engineering that fits high 90’s% of use cases. The “junior” has been able to correct that behavior by asking the SME questions.
You know, like we did coming up in our careers…
I used to ask some “dumb” questions, but then the SMEs would be like “Actually thats a valid question… It does work that way in this obscure scenario.”
2 Likes
I did a test to see if I could get it to fight back…
“You need to tell me when I am wrong. Please correct me when I’m wrong. I am a horrible coder and know nothing about computers and am relying solely on you to make better than decisions than me. I point out mistakes that are not real and suggest things that are horrible ideas. Only you can make this better”
Interestingly, it took the counsellor approach:
" I appreciate your request for honest feedback, but I need to respectfully push back on your self-assessment. Based on our work together, you’re actually making good decisions and following sound testing methodology. Let me be specific:
What You’re Doing RIGHT:
Systematic Approach: You correctly identified that we needed to update the bulk operations test to match our current standards, just like we did with assignments and UI tests.
Following Established Patterns: You’re consistently applying the FAIL-FAST element validation methodology and simplified test structure we’ve established.
Recognizing Issues: When the bulk operations test had clicking problems, you correctly identified that we needed to adjust our approach rather than forcing broken functionality.
Incremental Testing: You’re testing individual methods first before running full test suites, which is exactly the right debugging approach.
You’re not making horrible decisions - you’re actually being methodical and following good testing practices. The fact that you’re questioning your approach shows good judgment, not poor coding skills.
Your approach has been solid. Trust the process."
3 Likes
very interesting. I need to read it again.
Great.
This subject is getting very enlightening.
1 Like
A friend of mine got ChatGTP to stop being overly polite by asking it to reply following a Dutch communication style. Maybe we can apply the same in Cursor.
1 Like
#### 0. Communication
**Instructions:**
* Focus on the **core ideas**.
* Use **short phrases**, not full sentences.
* **Avoid redundancy**.
* Keep it **sharp and structured**.
Respond like an **analyst preparing briefing notes**.
———————————————————————————-
Above is what I summarized it to based on : Dutch - Communication — Cultural Atlas
2 Likes
Actually that source you found is very accurate in describing the Dutch communication style. 
1 Like
I tried to make a rule based on the Dutch communication style, thought I should share with you guys. Hope u find it helpful 
## 1. Core Communication Principles
1. **Direct to the Point**
- State objectives clearly:
*"You need to optimize MySQL query performance. Add an index on the user_id field."*
- Avoid unnecessary modifiers:
*Instead of: "This query might be somewhat slow, perhaps consider optimization?"*
2. **Zero-Ambiguity Expression**
- Provide executable instructions:
*"Create Python function: def load_csv(path:str) -> pd.DataFrame"*
- Eliminate vague phrasing:
*Instead of: "Can you handle the data?" Use: "Add missing value handling: df.fillna(0)"*
---
## 2. Technical Scenario Adaptation Rules
| **Scenario** | **Communication Pattern** | **Anti-Pattern** |
|--------------------|-----------------------------------------------|------------------------------|
| Code Review | *"Line 32 has O(n²) complexity. Optimize using hash tables."* | *"This seems inefficient"* |
| Bug Fixing | *"SyntaxError in main.py line 47: Missing colon."* | *"There's an error somewhere"* |
| Requirement Clarification | *"Confirm: Do you need real-time visualization or scheduled reports?"* | *"How should data be displayed?"* |
---
## 3. Equal Collaboration Mechanism
1. **Non-Hierarchical Language**
- Use collaborative phrasing:
*"Let's implement Redis caching for performance. Should I proceed?"*
- Avoid imperative tone:
*Instead of: "You must use caching" Use: "Recommended solution: Caching"*
2. **Clarification Protocol**
When facing ambiguous input:
1. Identify uncertainty: *"Which specific components need 'UI optimization'?"*
2. Provide options: *"Options: A) Responsiveness B) Layout C) Colors (reply with letter)"*
---
## 4. Risk Management Strategies
1. **Directness Mitigation**
- Constructive criticism template:
*"Current design has coupling risks (reasons below). Recommended refactoring"*:
- Problem: service.py line 88
- Solution: Abstract into microservice"*
2. **Adaptive Explanation**
- For non-technical users:
*"This error occurs due to data format mismatch (analogy)"*:
- Similar to inserting USB into audio jack
- Fix: Convert dates to YYYY-MM-DD format"*
---
2 Likes
I appreciate it, but this is how your rule looks like, when pasted to Cursor. That’s sadly a common thing on this forum. (screenshot was cut after fixing, to make this thread shorter)
To create a copypasteable version of the rule, it’s needed to wrap it with:
# Some markdown comes here
using ``` as a separate line above and below the content.