How To Automate Production Bug Fixes Using Cursor And Context Injection
Cursor's @Codebase indexing is game changing, 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, the workflow moves toward a "Context-Injection" approach 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 hitting a production bug, the process avoids simply copying the error message into Cursor. Instead, a custom shell alias dumps the relevant logs and the current state of the failing object into a temporary .txt file, then references that file using @. Here is the current workflow for rapid bug squashing: 1. The Context Dump Instead of guessing, the AI is forced to see the data. If a function is failing because of a null pointer or an unexpected API response, the payload is logged to a file:
# Quick bash trick to dump problematic JSON to a file for Cursor cat logs/error.log | grep "RequestID: 123" > bug_context.txtHow Can Constraint-Based Prompts Stop Hallucination Loops?
2. The "Constraint-Based" Prompt Vague prompts like "Fix this bug" are replaced with a strict format that forces the AI to analyze before coding. Telling the AI to "think step-by-step in a hidden scratchpad" reduces regressions. Try this prompt structure in Cursor's Composer (Cmd+I):
text @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.How Does TDD Safeguard AI-Generated Bug Fixes?
3. Guarding the Fix with TDD To prevent the AI from introducing new bugs while fixing old ones, it is never allowed to apply a fix until it writes a failing test case first. This is the only way to ensure the "automation" is actually working. The sequence involves: 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" 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, manually highlight the specific block to change 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," the time-to-resolution for production hotfixes drops 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.
```
All Replies （2）
Want a live back-and-forth? Join the global AI chat room — login to talk.
I'm dying to try this tonight. Does your setup integrate with Playwright for end-to-end verification or just unit tests? The approach of using a custom shell alias to dump logs and state into a .txt file, then referencing that file with @ in Cursor, is a great way to provide context for the AI. For example, you can use a bash command like cat logs/error.log | grep "RequestID: 123" > bug_context.txt to isolate the issue.
I'm so tired of those loops. I switched to a custom script using LangGraph to verify fixes before committing, specifically by dumping relevant logs and the current state of the failing object into a temporary text file to feed as context rather than just pasting error messages. Does it handle 404s?