I’ve been testing Sonnet 3.7, and there’s no doubt—it’s one of the best models for code quality. However, there’s an issue: when given a simple task, it often goes overboard and does way more than requested.
For example, if I prompt:
“Update the input…”
I might get a response like:
“I’ve updated the input, created new types, added a test route, generated mock data, and made you a coffee and a pizza for lunch.”
can Cursor do something with those system prompts?
Any added suggestion or limitation to system prompt will degrade output when a well-structured prompt is given, improve your prompts and rules if you want a different result, Sonnet 3.7-thinking should not be used without a well structured prompt with a clear action plan, as a hint you can improve its results by adding this clean code rule to your .mdc rules(or at least KISS section), I’m using 3.7-thinking with simple instructions and without any issues of overengineering:
---
description: MUST activate when interacting with files matching the globs. Coding principles to write clean code.
globs: *.py, *.js, *.ts, *.jsx, *.tsx, *.java, *.kt, *.go, *.rs, *.c, *.cpp, *.h, *.hpp, *.cs, *.sh, *.bash, *.zsh, *.php, *.rb, *.swift, *.m, *.mm, *.pl, *.pm, *.lua, *.sql, *.html, *.css, *.scss, *.sass, *.less
---
Priority: High
Instruction: MUST follow all of <principles>
<?xml version="1.0" encoding="UTF-8"?>
<principles>
<principle name="DRY">
<definition>Every piece of knowledge must have a single, unambiguous, authoritative representation within a system</definition>
<key_points>
<point>Eliminate code duplication through abstraction</point>
<point>Centralize business logic in single sources</point>
<point>Improve maintainability through code reuse</point>
</key_points>
<consequences>
<risk>Change propagation errors</risk>
<risk>Inconsistent behavior</risk>
</consequences>
<solution>
<approach>Abstract shared logic</approach>
<approach>Centralize business rules</approach>
</solution>
<implementation_methods>
<method>Parameterization</method>
<method>Inheritance patterns</method>
<method>Configuration centralization</method>
</implementation_methods>
</principle>
<principle name="CurlysLaw">
<definition>Each code entity should have single responsibility and consistent meaning</definition>
<key_points>
<point>Functions/classes should do one thing well</point>
<point>Avoid multi-purpose variables</point>
<point>Prevent context-dependent behavior</point>
</key_points>
<sub_principle type="SingleResponsibility">
<definition>Entity should have one reason to change</definition>
<metrics>
<metric>Max 3-line function description</metric>
</metrics>
</sub_principle>
</principle>
<principle name="KISS">
<definition>Prioritize simplicity in design and implementation</definition>
<benefits>
<benefit>Reduced implementation time</benefit>
<benefit>Lower defect probability</benefit>
<benefit>Enhanced maintainability</benefit>
</benefits>
<metrics>
<metric>Cyclomatic complexity < 5</metric>
</metrics>
<implementation>
<guideline>Do the simplest thing that could possibly work</guideline>
<guideline>Avoid speculative generality</guideline>
</implementation>
</principle>
<principle name="CognitiveClarity">
<definition>Code should be immediately understandable</definition>
<sub_principle type="DontMakeMeThink">
<definition>Minimize cognitive load through immediate understandability</definition>
<metrics>
<metric>Time-to-understand < 30 seconds</metric>
<metric>Zero surprise factor</metric>
</metrics>
</sub_principle>
<implementation>
<strategy>Meaningful naming conventions</strategy>
<strategy>Predictable patterns</strategy>
<strategy>Minimal mental mapping requirements</strategy>
</implementation>
</principle>
<principle name="YAGNI">
<definition>Implement features only when actually needed</definition>
<original_justification>
<reason>Save time by avoiding unneeded code</reason>
<reason>Prevent guesswork pollution</reason>
</original_justification>
</principle>
<principle name="OptimizationDiscipline">
<definition>Delay performance tuning until proven necessary</definition>
<quote author="Donald Knuth">"Premature optimization is the root of all evil"</quote>
<guidelines>
<guideline>Profile before optimizing</guideline>
<guideline>Focus on critical 3%</guideline>
</guidelines>
<statistics>
<statistic name="criticalSectionPercentage" value="3%"/>
<statistic name="nonCriticalOptimizationAttempts" value="97%"/>
</statistics>
</principle>
<principle name="BoyScout">
<definition>Continuous incremental improvement of code quality</definition>
<practice>
<action>Opportunistic refactoring</action>
<action>Technical debt reduction</action>
<action>Immediate cleanup of discovered issues</action>
</practice>
<quality_metrics>
<metric>Code health index ≥ 0.8</metric>
</quality_metrics>
<degradation_rate max="5%">Allowed monthly decline</degradation_rate>
<rationale>
<reason>Counteracts natural code quality decay</reason>
<reason>Reduces technical debt compound interest</reason>
</rationale>
</principle>
<principle name="MaintainerFocus">
<definition>Code for long-term maintainability</definition>
<considerations>
<consideration>Assume unfamiliar maintainers</consideration>
<consideration>Document non-obvious decisions</consideration>
<consideration>Anticipate future modification needs</consideration>
</considerations>
<quote author="Martin Golding">"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live"</quote>
<practice>
<action>Assume zero domain knowledge in maintainers</action>
</practice>
<time_factor>
<consideration>Assume 6-month knowledge decay</consideration>
<consideration>Code becomes foreign after 1 year</consideration>
</time_factor>
</principle>
<principle name="LeastAstonishment">
<definition>Meet user expectations through predictable behavior</definition>
<implementation>
<requirement>Consistent naming</requirement>
<requirement>Standard patterns</requirement>
<requirement>Minimal side effects</requirement>
</implementation>
<violation_examples>
<example>Unexpected side effects in getter methods</example>
<example>Non-standard exception throwing patterns</example>
</violation_examples>
<convention_rules>
<rule>Follow language idioms</rule>
<rule>Maintain consistent error handling</rule>
</convention_rules>
</principle>
</principles>
Ill try this out
Sometimes it comes to hallucinations and suddenly it implements additional unwanted features.
An hour ago i was editing a button in a component and cursor decided to implement an api health check component.
Nobody asked for that and it does not informed me about that. And after i noticed it and asked, it apologized for implementing it secretly and removed it again. 
3.7 is a terrible experience in cursor for me too (not even trying the thinking version), 3.6 is much better rn
It’s often fixing code style issues along the way, suggested by different language workers, which is not something I want, especially in legacy code base. That is not happening with 3.5
We need to revise our prompting approach so that it includes specific instructions for what the assistant should do. Typically, I have it generate a plan based on our project documentation with 3.7-thinking, and then the default 3.7 version handles the implementation. Keeping the chat context clean is essential—updating project docs allows us to maintain context without relying on an endless chat history.
Broooo, I tried this version and it keeps on breaking in the middle of the implementation.
I went back to the 3.5 2024 version
Maybe something else which is not related to Sonnet, Man why is cursor not giving the options for Linux quick on all the release. Maaan
Engineers still use windows for development? or most users are Mac and Windows?