# Cursor Agent repeatedly generates Python code that violates the same explicit, deterministic repository hard rules **URL:** \ **Category:** Bug Reports\ **Tags:** python, context, rules\ **Created:** [August 30, 2026, 4:47am UTC](https://forum.cursor.com/t/cursor-agent-repeatedly-generates-python-code-that-violates-the-same-explicit-deterministic-repository-hard-rules/169954 "2026-08-30T04:47:19Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![javiermarcon](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/javiermarcon/32/6989_2.png) [@javiermarcon](https://forum.cursor.com/u/javiermarcon)\ **Post date:** [August 30, 2026, 4:47am UTC](https://forum.cursor.com/t/cursor-agent-repeatedly-generates-python-code-that-violates-the-same-explicit-deterministic-repository-hard-rules/169954/1 "2026-08-30T04:47:19Z")
### 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** : ```plaintext [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** : ```plaintext 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** : 1. Behave failed to execute because Agent had introduced an incorrect import for a shared helper. 2. Agent repaired that. 3. Tests were run again. 4. The repository structural audit then detected module-size violations. 5. 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: ```plaintext MODULE_SIZE physical LOC MODULE_SIZE logical LOC PLR2004 TC001 ``` The resulting pattern is therefore not simply: ```plaintext AI made a mistake → user reports it → AI fixes it ``` It is: ```plaintext 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 1. Use a Python repository with strict repository-level hard rules. 2. Enable Ruff rules including at least: ```plaintext PLR2004 TC001 ``` 1. Add deterministic module-size hard limits, including both: ```plaintext module physical LOC module logical LOC ``` 1. Document these rules explicitly in repository instructions such as `AGENTS.md` and architecture guardrails. 2. In the Agent prompt, explicitly require the Agent to read those instructions before changing anything. For example, my prompts include instructions equivalent to: ```plaintext 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: ```plaintext 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. ``` 1. Ask Agent to implement a normal non-trivial Python change. 2. Run the repository gates over the generated patch. 3. In my usage, more than 95% of implementation responses contain one or more of: ```plaintext [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 ``` 1. Allow Agent to repair the findings. 2. Observe Agent explicitly acknowledging that the violation should not have been introduced. 3. Continue the same request or another implementation slice. 4. 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: ```plaintext inspect module → consider remaining LOC budget → plan responsibility placement → implement within hard rules ``` Not: ```plaintext 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: 1. receives the rule before generation, 2. violates it, 3. receives deterministic gate output identifying the violation, 4. explicitly acknowledges that it should not have happened, 5. 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: 1. explicitly acknowledging that the reported violations were real and should not have reached the next implementation slice; 2. fixing those violations; 3. running Ruff again; 4. encountering a Behave failure caused by an incorrect helper import introduced during implementation; 5. fixing that; 6. running additional tests; 7. subsequently hitting structural `MODULE_SIZE` violations; 8. 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 ```plaintext Linux x64 Kernel: 6.8.0-138-generic ``` Ubuntu 24.04. * * * ### Version Information Cursor IDE: ```plaintext 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 ```plaintext 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: ```plaintext [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: ```plaintext 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: 1. Are repository instructions such as `AGENTS.md` actually present with sufficient priority in the effective Agent context throughout a long implementation request? 2. Can Agent lose or de-prioritize repository hard rules after several tool calls / implementation slices inside one request? 3. Why does explicit acknowledgement and repair of a deterministic rule not materially improve compliance with the same rule later in the same Agent workflow? 4. Does Agent perform any lint/static-quality planning or review of its generated patch before proceeding to the next implementation slice? 5. For module-size limits, does Agent consider the current module size before deciding to append new responsibilities to an existing module? 6. Why are Ruff `PLR2004` and `TC001` repeatedly introduced when Ruff compliance is explicitly required before implementation and completion? 7. Could deterministic quality failures be checked earlier in the Agent loop, before Agent proceeds with additional implementation work? 8. 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. --- _[View the full topic](https://forum.cursor.com/t/cursor-agent-repeatedly-generates-python-code-that-violates-the-same-explicit-deterministic-repository-hard-rules/169954)._