Stop treating VB.

Cursor's Composer mode is a cheat code for refactoring legacy code, but most people are treating it like a glorified autocomplete rather than a system architect. If you're just highlighting a function and asking it to "fix this," you're wasting the context window and getting generic results.

The real power comes from forcing the AI to map the dependencies before it touches a single line of code. I've been migrating a massive, spaghetti-coded internal tool from an old JS monolith to TypeScript, and the "Plan-First" workflow is the only way to avoid introducing regression bugs.

Instead of jumping straight into the code, I use a specific prompt sequence in the .cursorrules file to enforce a strict architectural review. I've found that if you don't tell Cursor to explicitly list the side effects of a change, it will confidently delete a utility function that's being called by a file it hasn't indexed yet.

Here is the prompt logic I bake into my project rules to stop the "guess-and-check" cycle:

When refactoring, follow this strict sequence:
1. Analyze: Scan all imported modules and find every reference to the target function.
2. Impact Map: List every file that will be affected by this change in a bulleted list.
3. Proposal: Describe the logic change in plain English.
4. Execution: Only after I approve the map, apply the code changes.

Another huge productivity gain is leveraging the @Codebase symbol combined with specific file indexing. If you have a massive repo, @Codebase can sometimes get diluted. I’ve started using a "Context Anchor" strategy: I keep a docs/architecture.md file that maps out the data flow of the app. When I need a complex feature, I prompt with @architecture.md @FileA @FileB instead of just a general codebase search. This narrows the AI's focus and drastically reduces the "hallucinated API" problem.

One gotcha that burned me for a week: Cursor's "Apply" button in the chat can occasionally skip lines if the file is too long, leading to syntax errors that aren't obvious until you run the build. To solve this, I stopped relying on the one-click apply for files over 500 lines. Instead, I use the Cmd+K inline edit for specific blocks. It's a few more keystrokes, but it ensures the diff is precise.

For those using Claude 3.5 Sonnet inside Cursor, try pushing the "Reasoning" aspect. If the AI is stuck in a loop fixing the same bug, stop it and use this prompt:

Stop applying fixes. Analyze the last three failed attempts and explain why the logic is fundamentally flawed. Do not provide code yet; provide a diagnostic report.

This forces the model to step out of "coding mode" and back into "thinking mode," which usually solves the bug in the next iteration.

My current optimized setup for speed:

• Model: Claude 3.5 Sonnet (far superior for complex refactoring than GPT-4o).
• Indexing: Always keep the .cursorrules file updated with your naming conventions to stop it from inventing new variable styles.
• Workflow: Composer (Cmd+I) for multi-file orchestration → Inline Edit (Cmd+K) for surgical polishing.