FixBugs: Automating the production

Cursor's @Codebase indexing is a game changer, but relying on it for bug fixing often leads to "hallucination loops" where the AI keeps suggesting the same wrong fix. To actually automate the production of bug fixes without babysitting the LLM, I've moved toward a "Context-Injection" workflow rather than just asking the AI to "fix the error."

The secret is feeding the AI the exact execution trace and the relevant state, not just the stack trace. When I hit a production bug, I don't just copy the error message into Cursor. I use a custom shell alias to dump the relevant logs and the current state of the failing object into a temporary .txt file, then reference that file using @.

Here is my current workflow for rapid bug squashing:

1. The Context Dump
Instead of guessing, I force the AI to see the data. If a function is failing because of a null pointer or an unexpected API response, I log the payload to a file:

# Quick bash trick to dump problematic JSON to a file for Cursor
cat logs/error.log | grep "RequestID: 123" > bug_context.txt

2. The "Constraint-Based" Prompt
I stop using vague prompts like "Fix this bug." I use a strict format that forces the AI to analyze before coding. I've found that telling the AI to "think step-by-step in a hidden scratchpad" reduces regressions.

Try this prompt structure in Cursor's Composer (Cmd+I):

@bug_context.txt @relevant_file.ts 
Analyze the discrepancy between the expected output in the logs and the current implementation. 
1. Identify the exact line causing the state mutation.
2. Propose a fix that handles the edge case without breaking the existing type definitions.
3. Implement the fix.

3. Guarding the Fix with TDD
To prevent the AI from introducing new bugs while fixing old ones, I never let it apply a fix until I've forced it to write a failing test case first. This is the only way to ensure the "automation" is actually working.

My sequence:
Prompt A: "Based on @bug_context.txt, write a Vitest case in bug_fix.spec.ts that reproduces this exact failure."
Prompt B: (Once the test fails) "Now fix the implementation in @relevant_file.ts so that this test passes."

The "Gotchas" I've encountered:

• Over-reliance on Auto-Apply: Cursor's "Apply" button can sometimes delete surrounding boilerplate code if the file is too large. Always review the diff. If the file is >500 lines, I manually highlight the specific block I want changed instead of letting the AI rewrite the whole file.
• The Claude 3.5 Sonnet Loop: When Sonnet gets stuck in a loop, switching to GPT-4o for a "second opinion" on the architecture usually breaks the deadlock.

Productivity Gain:
By shifting from "Chatting about the bug" to "Injecting execution state → Writing failing test → Applying fix," my time-to-resolution for production hotfixes has dropped from an hour to about 10 minutes. You aren't just using an AI to code; you're using it to navigate the state space of your application.