Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Where does the bug appear (feature/product)?
Editor, Tab & Chat — Cursor IDE Agent
Describe the Bug
Cursor Agent repeatedly generates Python code that violates the same explicit, deterministic repository hard rules, even though those rules are provided before any code changes and the Agent is explicitly instructed to validate them before continuing.
This is not an occasional lint failure.
In my regular usage, the following four violations appear in more than 95% of Agent implementation responses:
[MODULE_SIZE] module physical LOC
[MODULE_SIZE] module logical LOC
PLR2004 Magic value used in comparison
TC001 Move application import into a type-checking block
These rules are already explicitly documented in repository instructions such as AGENTS.md / architecture guardrails, and the implementation prompts explicitly tell Agent to read and follow those rules before modifying anything.
The prompts also explicitly require Agent to validate the implementation using Ruff, Pylint, Mypy, Pytest, Behave, pre-commit and the repository’s quality-check workflow before considering the work complete.
Despite this, the same violations are introduced over and over.
The most problematic behavior is that this does not only happen between separate prompts.
Agent enters repeated self-repair cycles inside the same request:
Agent receives explicit hard rules
↓
Agent implements code
↓
Ruff / structural audit rejects the patch
↓
Agent acknowledges that the violation should not have happened
↓
Agent repairs it
↓
another quality gate finds another avoidable issue
↓
Agent repairs that
↓
structural audit finds MODULE_SIZE
↓
Agent refactors again
↓
more validation / more Agent work
For example, during the attached run Agent explicitly said:
“Tenés razón: esos dos hallazgos son incumplimientos concretos y no debieron llegar al siguiente slice.”
(“You’re right: those two findings are concrete violations and should not have reached the next slice.”)
Agent then repaired the reported Ruff problems.
Still within the same original request:
- Behave failed to execute because Agent had introduced an incorrect import for a shared helper.
- Agent repaired that.
- Tests were run again.
- The repository structural audit then detected module-size violations.
- Agent started another refactoring pass to repair those violations.
The Agent itself acknowledged:
“La auditoría estructural bloqueó correctamente dos problemas: el método diferencial supera por 3 LOC el hard cap y el servicio legacy de reprogramación creció sobre su ratchet.”
So Agent clearly understands the rule once an external gate reports it.
The problem is that the same classes of violations are then introduced again in subsequent implementation work.
This happens repeatedly with:
MODULE_SIZE physical LOC
MODULE_SIZE logical LOC
PLR2004
TC001
The resulting pattern is therefore not simply:
AI made a mistake
→ user reports it
→ AI fixes it
It is:
rule exists before generation
→ Agent violates it
→ deterministic gate catches it
→ Agent explicitly acknowledges the violation
→ Agent repairs it
→ Agent later introduces the same class of violation again
This significantly affects autonomous Agent workflows.
Every preventable violation results in additional semantic Agent work and additional usage/credits even though the violated constraint was explicitly known before the initial generation.
I am not reporting that Agent must produce perfect code or that functional tests should never fail.
I am reporting the extremely high recurrence of the same deterministic, explicitly supplied static/architectural constraints.
Steps to Reproduce
-
Use a Python repository with strict repository-level hard rules.
-
Enable Ruff rules including at least:
PLR2004
TC001
- Add deterministic module-size hard limits, including both:
module physical LOC
module logical LOC
-
Document these rules explicitly in repository instructions such as
AGENTS.mdand architecture guardrails. -
In the Agent prompt, explicitly require the Agent to read those instructions before changing anything.
For example, my prompts include instructions equivalent to:
Before changing anything, read and strictly follow:
AGENTS.md
ARCHITECTURE_GUARDRAILS.md
DOMAIN_MAP.md
TESTING.md
AI_CONTEXT.md
ARCHITECTURE.md
REPO_MAP.md
ARCHITECTURE_DECISIONS.md
CODEBASE_ENTRYPOINTS.md
ORDER_LIFECYCLE.md
STYLE.md
They additionally require, before finishing:
Always verify:
pylint
pytest
behave
ruff
mypy
PEP 8
PEP 257
PEP 484
Run pre-commit on the host.
Use Docker for:
ruff
pylint
mypy
pytest
behave
Run the repository quality-check workflow before completion.
-
Ask Agent to implement a normal non-trivial Python change.
-
Run the repository gates over the generated patch.
-
In my usage, more than 95% of implementation responses contain one or more of:
[MODULE_SIZE] module physical LOC
[MODULE_SIZE] module logical LOC
PLR2004 Magic value used in comparison
TC001 Move application import into a type-checking block
-
Allow Agent to repair the findings.
-
Observe Agent explicitly acknowledging that the violation should not have been introduced.
-
Continue the same request or another implementation slice.
-
Observe the same violation classes being introduced again.
This is reproducible across many implementation tasks, not one isolated response.
Expected Behavior
When deterministic constraints are explicitly provided before implementation, Agent should incorporate them into implementation planning and first-pass code generation.
MODULE_SIZE — physical and logical LOC
Before adding code to an existing module, Agent should account for the repository’s configured physical and logical LOC limits.
If a module is already close to its hard limit, Agent should design the implementation accordingly during the first pass, for example by extracting the new responsibility into an appropriate module.
The expected workflow is:
inspect module
→ consider remaining LOC budget
→ plan responsibility placement
→ implement within hard rules
Not:
append implementation to existing module
→ violate MODULE_SIZE
→ external audit rejects it
→ Agent acknowledges violation
→ Agent refactors
Both physical and logical module-size limits are deterministic and can be evaluated before or immediately after code generation.
PLR2004
If Ruff PLR2004 is enabled and explicitly required, Agent should avoid introducing magic values in comparisons and should create semantically appropriate constants where required.
This violation appears repeatedly in newly generated code despite the rule already being known.
TC001
If Ruff TC001 is enabled and explicitly required, Agent should correctly identify application imports that are only needed for type checking and structure them appropriately.
This also appears repeatedly in newly generated code despite being part of the repository’s required Ruff contract.
Self-validation
If Agent claims it followed the repository quality contract, the generated patch should not routinely violate those exact rules.
Occasional failures are understandable.
A greater-than-95% recurrence rate for the same four known constraints is not expected behavior.
Repeated repair behavior
Once Agent:
- receives the rule before generation,
- violates it,
- receives deterministic gate output identifying the violation,
- explicitly acknowledges that it should not have happened,
- and repairs it,
I would expect substantially higher compliance with that same rule during subsequent work.
Instead, I repeatedly observe the same violation classes being reintroduced.
Screenshots / Screen Recordings
I am attaching two screenshots from an actual Agent run.
The screenshots show Agent:
- explicitly acknowledging that the reported violations were real and should not have reached the next implementation slice;
- fixing those violations;
- running Ruff again;
- encountering a Behave failure caused by an incorrect helper import introduced during implementation;
- fixing that;
- running additional tests;
- subsequently hitting structural
MODULE_SIZEviolations; - starting yet another refactoring pass, all within the same original request.
I can additionally provide:
- complete Agent conversation logs;
- the original effective prompts;
- repository hard-rule definitions;
- diffs produced before each repair;
- Ruff output;
[MODULE_SIZE]audit output;- pre-commit output;
- repeated independent occurrences;
- additional Request IDs if needed.
Operating System
Linux
Linux x64
Kernel: 6.8.0-138-generic
Ubuntu 24.04.
Version Information
Cursor IDE:
Version: 3.17.19
VS Code Extension API: 1.128.0
Commit: ae3a2b7231dd56194447fe4570dfdc61640b1e90
Date: 2026-08-24T06:42:14.583Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 6.8.0-138-generic
For AI issues: which model did you use?
Auto
The behavior is not limited to a single implementation task; it has been repeatedly observed across Agent work.
For AI issues: add Request ID with privacy disabled
Request ID: c8051450-2e83-4f95-aeaa-957a2f277262
I can provide additional Request IDs from independent occurrences if useful.
Additional Information
The distinction between ordinary implementation errors and the failures reported here is important.
A business-logic test failure can reveal behavior that required implementation and execution to discover.
The four recurring violations in this report are different:
[MODULE_SIZE] module physical LOC
[MODULE_SIZE] module logical LOC
PLR2004
TC001
They are static or architectural constraints that:
- are explicitly defined before implementation;
- are deterministic;
- are repeatedly supplied to Agent;
- can be evaluated without discovering new runtime business behavior;
- are detected by automated repository gates;
- and repeatedly require semantic repair after the initial implementation.
In particular, PLR2004 and TC001 are not automatically fixed by Ruff in this workflow, and MODULE_SIZE necessarily requires a semantic architectural/refactoring decision.
Therefore these recurring failures create additional Agent work rather than being removable by a simple formatter pass.
Why this matters for usage-based Agent workflows
In an autonomous workflow, a request may become:
initial implementation
→ static violation
→ Agent repair
→ another violation
→ Agent repair
→ structural violation
→ Agent refactor
→ more validation
All of this can happen during a single original user request.
This makes request cost materially dependent on Agent repeatedly repairing violations of constraints that were already present before code generation.
Again, I am not claiming Agent should never make mistakes.
The issue is that the same known constraints are violated with extremely high frequency and continue recurring even after Agent has explicitly acknowledged and repaired those exact classes of failures.
Questions / areas that may help investigate
I would appreciate the Cursor team investigating:
-
Are repository instructions such as
AGENTS.mdactually present with sufficient priority in the effective Agent context throughout a long implementation request? -
Can Agent lose or de-prioritize repository hard rules after several tool calls / implementation slices inside one request?
-
Why does explicit acknowledgement and repair of a deterministic rule not materially improve compliance with the same rule later in the same Agent workflow?
-
Does Agent perform any lint/static-quality planning or review of its generated patch before proceeding to the next implementation slice?
-
For module-size limits, does Agent consider the current module size before deciding to append new responsibilities to an existing module?
-
Why are Ruff
PLR2004andTC001repeatedly introduced when Ruff compliance is explicitly required before implementation and completion? -
Could deterministic quality failures be checked earlier in the Agent loop, before Agent proceeds with additional implementation work?
-
Is there a known issue with instruction persistence/context priority during long Agent sessions?
I can provide full logs and diffs if an engineer wants a reproducible trace.
Does this stop you from using Cursor?
Sometimes - I can sometimes use Cursor.
Cursor remains usable, but this issue significantly reduces the reliability and cost-effectiveness of autonomous Agent workflows because non-trivial requests repeatedly enter avoidable self-repair cycles.