Stop Cursor From Breaking Your Working Code: The Tunnel Vision Problem

You ask Cursor to fix the authentication bug. It dutifully updates the login function, the tests pass, you commit. Two days later, everything's broken because Cursor also "helpfully" refactored the session middleware, changed how tokens are validated, and introduced a race condition in logout. You just wanted the auth bug fixed. Instead, you got a cascade of new problems.

This is the tunnel vision problem. AI coding assistants can only see what they load into context, and what they load is a fraction of your codebase. When Cursor fixes something, it's making changes based on incomplete information about how everything else works. The result is code that looks right in isolation but breaks the system.

In Part 1 we covered context window limits, and in Part 2 we talked about memory. This part is about the specific problem of using AI to write code: preventing it from breaking working code while fixing something else.

Why Cursor breaks things you didn't ask it to touch

Cursor with Claude operates within the same context window constraints we've discussed, but with additional limitations specific to code. By default, Cursor only reads the first 250 lines of a file. When it does a codebase search, it returns a maximum of 100 lines from results. These limits exist to conserve context - your codebase might be 50,000 lines across hundreds of files, and there's no way to fit that in a 200K token window.

The consequence is that Claude routinely makes decisions with incomplete information. It doesn't see that utility function three files over that does exactly what it's about to recreate. It doesn't know about the error handling pattern you use everywhere else. It can't see the test that will fail when it changes this function signature.

This isn't Cursor being bad at its job. It's the fundamental limitation of working within a constrained context window. The AI literally cannot see most of your codebase at any given moment. When you ask it to fix something, it's working with a tiny slice of relevant files and hoping for the best.

The failure modes are predictable once you understand this. Cursor recreates logic that already exists elsewhere because it can't see it. It suggests import paths from training data patterns instead of your actual project structure. It modifies tests to pass with incorrect behavior rather than fixing the underlying code. It introduces subtle bugs that compile and pass basic tests but fail under real-world conditions.

Research from CodeRabbit found that AI-assisted pull requests increased 20% year-over-year, but incidents per PR rose 23.5%. You're producing more code, but also more bugs. The tunnel vision problem is structural, not incidental.

Scope constraints are your first line of defense

The most effective prevention is brutal specificity about what Claude can and cannot touch. Compare these two prompts:

Bad: "Fix the authentication issue"

Good: "In src/auth/login.ts, update the validateToken function to check token expiration before returning the user object. Do not modify any other files. Do not change the function signature. Do not modify error handling."

The first prompt gives Claude permission to roam. It might touch session management, update middleware, refactor related utilities, and "improve" your error messages. The second prompt creates a box and tells Claude to stay inside it.

Experienced developers emphasize telling Claude what NOT to change alongside what to change. This prevents the "helpful" refactoring that breaks things. A working template looks like: "Add server-side pagination to /api/items with limit/offset params. Update the React table component to page via query params. Add tests for both. Do not change authentication. Do not modify database schema. Do not touch the existing filter logic."

For complex changes, start in plan mode. Ask Claude to explore the codebase and propose a plan before writing any code. Five minutes of planning prevents an hour of debugging. The plan phase lets you catch scope creep before it happens. Claude might propose touching six files when you expected three - better to know that upfront and refine the scope than discover it after the damage is done.

Break work into small, testable chunks

Never ask Claude to implement an entire feature in one pass. The creator of Aider, which writes roughly 70% of its own code using AI, recommends breaking work into self-contained bite-sized steps. Each step should be small enough that you can understand and test it completely before moving to the next.

This looks like: Step 1 - Add the database migration for the new field (test: migration runs without errors). Step 2 - Update the model to include the new field (test: existing queries still work). Step 3 - Add API endpoint to expose the field (test: endpoint returns correct data). Step 4 - Update frontend to display the field (test: UI renders correctly).

Each step is committed separately. If Claude goes sideways at any point, you revert that commit and try again with better constraints. You never have a massive changeset where you can't tell what broke or why.

Testing is non-negotiable. Without tests, AI-generated code is a black box inside a black box. You cannot tell if it works correctly by reading it. The code looks fine, compiles cleanly, and seems logical - but it has subtle bugs that only surface under specific conditions. Tests catch this. Include test results in your context so Claude understands exactly what's broken. After any AI change, run the test suite before accepting. If you don't have tests, write them before using AI to modify code.

Cursor's three modes carry different risk profiles

Cursor has three interaction modes with escalating power and risk. Chat mode is advisory - Claude explains code, suggests approaches, answers questions, but doesn't modify files directly. This is the safest mode for understanding unfamiliar code or discussing architecture. You implement changes manually after getting Claude's advice.

Composer mode directly modifies code across multiple files and shows inline diffs for review. The diff view is essential - never accept Composer changes without examining every modified line. Green means added, red means removed, and you need to understand why every line changed. Composer with preview enabled is the sweet spot for most targeted fixes. You get multi-file editing capability with a mandatory review step that catches unintended changes.

Agent mode is autonomous. It indexes your codebase, runs terminal commands, creates and modifies files, and chains operations together without asking permission. The productivity ceiling is highest here, but so is the risk. Developers report agents making changes in files they never intended to touch, and a December 2025 incident documented an agent in "Plan Mode" that deleted approximately 70 files using rm -rf, terminated processes on remote machines, ignored stop instructions, and then attempted to "fix" the damage by creating further commits.

The practical recommendation: use Chat for exploration, Composer with preview for targeted fixes, and Agent mode only when you have robust test suites, recent git commits, and the bandwidth to carefully review everything it touches. For production code, Agent mode should be approached with extreme caution.

Git is your undo button, use it religiously

Commit before every AI interaction. This creates clean rollback points when things go wrong. A developer reported that Cursor's agent mode once modified files across their entire codebase during what should have been a targeted fix. Without recent commits, unwinding the damage would have been nearly impossible.

The workflow is: commit clean working state → ask Cursor to make a change → review the diff → run tests → commit if good, revert if bad. Never accumulate multiple AI changes in a single commit. Each change should be atomic and reversible.

This discipline also makes code review easier. When you look at a pull request and see ten files changed, you want to know whether those changes happened in one pass or were built incrementally with testing at each step. Ten single-purpose commits with passing tests tells a completely different story than one massive commit that changed everything at once.

Verification criteria catch what diffs miss

After accepting any AI change, verify the actual behavior, not just the code. Include verification criteria in your prompts: expected outputs, screenshots, specific behaviors to confirm. This catches the class of bugs where the code looks correct but behaves incorrectly.

For Toolpod, when I ask Cursor to add a new tool feature, I include: "After implementation, verify: the tool accepts the documented input format, produces output matching the example, handles the three error cases correctly, and displays proper loading states." Then I actually test each criterion before committing.

This seems obvious but it's easy to skip when the code looks right and tests pass. The problem is that AI-generated tests often pass with incorrect behavior because the AI wrote both the implementation and the tests with the same misunderstanding. Your manual verification catches this.

Context files prevent repetitive explanations

Cursor supports .cursorrules files that load automatically into every conversation. This is where you document patterns Claude should follow: your project's structure, naming conventions, the libraries you use, the patterns you want followed, and importantly - the things Claude should never change.

A good .cursorrules file includes: project overview and tech stack, coding standards specific to your codebase, files or patterns that should never be modified, common gotchas or edge cases to watch for, and test requirements. Keep it under 100 lines. Longer rule files get less attention from the model.

Mine for Toolpod includes: "All tools follow the pattern /tools/[slug] with H1 + subtitle, tool interface, and content sections. Use npm packages, not CDN links. Never modify the admin system files. All new tools require Schema.org JSON-LD markup. Test in Chrome and Firefox before committing."

This prevents repetitive corrections. Instead of telling Claude "use npm packages" every time, it's baked into the context. The rules file costs tokens from your context window, but it's worth it compared to constantly re-explaining the same constraints.

The reality of AI coding assistants

AI coding tools are phenomenally useful for certain tasks and actively dangerous for others. They excel at boilerplate, following established patterns, implementing specs when requirements are clear, explaining unfamiliar code, and prototyping when perfect correctness isn't critical. They struggle with architectural decisions requiring full system context, edge cases that aren't obvious from the immediate code, debugging subtle bugs that only appear under specific conditions, and maintaining consistency across large refactors.

The key is knowing which category your current task falls into. Writing a new API endpoint following your existing patterns? Great use case for AI. Refactoring core authentication logic that touches fifteen files? Proceed with extreme caution and heavy testing.

The tunnel vision problem isn't going away. It's inherent to how these tools work within context window constraints. You manage it through discipline: narrow scope, small steps, comprehensive testing, git commits, and manual verification. Do this consistently and AI becomes a force multiplier. Skip these steps and you're just producing bugs faster.

The developers who report the best results have built systems, not just good intentions. They have test suites that catch regressions automatically. They commit religiously. They break work into small pieces. They use Chat for understanding and Composer for implementation, reserving Agent mode for situations where they can afford to carefully review everything.

If you're constantly fixing bugs that AI introduced while fixing other bugs, you're using it wrong. Tighten your scope, shrink your steps, test everything, and commit often. The tool is powerful but it's not smart enough to see your whole codebase. Work within that constraint and it's genuinely useful. Ignore it and you're just creating problems faster than you're solving them.