Cursorwith Claude 3.5 Sonnet, feeling smug because the AI was writing 80% of my boilerplate. Then I hit a wall.
The app would crash intermittently. No clear stack trace. Just a silent failure that left my local server hanging.
I tried the usual "Fix this" prompt. Cursor looked at the file, told me the code looked fine, and suggested I check my network connection. I almost threw my keyboard.
The loop of hallucinations
The problem was a useEffect
hook in a React component that was triggering an infinite re-render loop, but only when a specific API response came back in under 50ms.
I kept feeding the error log to the AI. It kept giving me the same generic advice: "Check your dependency array." I did. It was empty.
TypeError: Cannot read properties of undefined (reading 'map')
That was the only clue. But the line it pointed to wasn't actually where the error was happening. It was a ghost in the machine. The AI was hallucinating the state of my variables because it was relying on an outdated index of my codebase.
This is where most people give up on AI coding and go back to manual debugging. I didn't. I realized I was treating Cursor like a magic wand instead of a tool.
Forcing the AI to actually see the bug
I stopped asking it to "fix" the bug and started asking it to "prove" the state.
I wrote a series of console logs to track the exact millisecond the state changed. I didn't let the AI write the logs—I wrote them manually so I knew exactly where they were. Then, I copied the raw terminal output and pasted it back into the chat.
The shift in results was instant. Instead of guessing, the AI saw the timestamps.
"Wait," the AI responded, "the second request is finishing before the first one, but the first one is overwriting the state."
The fix was a simple AbortController
to cancel previous requests. It took three lines of code. The previous four hours were spent fighting the AI's confidence rather than the bug itself.
For anyone struggling with similar loops, here are the Cursor debugging tips that actually saved my sanity: | Technique | Why it works | When to use it |
| :--- | :--- | :--- | | Log-Driven Prompting | Feeds real-time data, not cached code | Intermittent bugs / Race conditions |
| File Pinning (@File) | Forces the LLM to focus on the source of truth | Large projects with similar function names |
| Context Clearing | Wipes the chat history to stop "hallucination loops" | When the AI keeps suggesting the same wrong fix |
| Pseudo-Code Verification | Asks AI to explain logic in English before coding | Complex architectural changes |
Where ChatGPT Projects usage fits in
Once I fixed the race condition, I realized I had a recurring problem. Every time I started a new feature, I had to explain my project's naming conventions, my preference for Tailwind utility classes, and the specific way I handled API errors to the AI.
I started using ChatGPT Projects to act as a "Knowledge Base" for my coding style.
Unlike a standard chat, I uploaded my .eslintrc
, my global CSS variables, and a "Style Guide" markdown file to the Project's custom instructions. Now, when I move a snippet of code from Cursor over to ChatGPT for a high-level architectural review, the AI already knows that I hate using any
and prefer Zod
for validation. It turns the AI from a freelance contractor who doesn't know your codebase into a senior dev who has been on the team for three years.
If you're tired of repeating yourself, start a Project, dump your docs in there, and stop wasting tokens on introductory prompts.
Breaking the "AI dependency" trap
The wild part is that I almost let the tool make me a worse programmer. I was relying so much on the "Tab" autocomplete that I stopped reading the code I was shipping.
I've found that the best way to actually grow is to engage with people who are hitting the same walls. That's why I spend a lot of time in the PromptCube community. It's not just about finding a "golden prompt" (those don't really exist), but about seeing how other devs are structuring their AI Coding workflows to avoid the exact burnout I felt last Thursday.
Sometimes you just need to see someone else's failed attempt to realize your approach is wrong.
Getting the most out of the workflow
If you want to stop the hallucination cycle, change your prompt structure. Instead of: "Why is this breaking?"
Try: "Analyze the execution order of these three functions. List the state of variable X at each step. If you cannot determine the state, tell me which log I need to add."
It forces the model to be analytical rather than predictive.
For those who want to see how these strategies look in practice, checking out some Prompt Sharing threads can give you a baseline for how to prompt for debugging versus prompting for feature generation. They are two entirely different skill sets. The goal isn't to have the AI write the code; it's to use the AI to find the mistake you're too tired to see.
If you're looking for a place to refine these skills or want to see how others are integrating MCP servers into their IDEs, the PromptCube homepage is a great starting point to dive into the deeper technical discussions. Stop trusting the "Fix" button blindly. Write your own logs. Trust the data, not the LLM's confidence.
Next Connecting LLM agents to Slack or Teams usually feels like a →
these AI tool field notes, with plenty of directly applicable cases.
All Replies （0） #
No replies yet — be the first!