When Cursor's New Memory Feature Still Isn't Enough
If you’ve been following my coding journey, you know that Cursor’s lack of memory has been my biggest frustration. Every debugging session felt like starting from scratch—Cursor would forget our goals, our past fixes, and just start deleting features to eliminate bugs. It was like pair programming with a very polite goldfish.
When I’m in a generous mood, I find myself wondering: why does Cursor’s forgetfulness feel so much worse than a human’s? When a person forgets something mid-conversation, we just remind them. Or, if you're a little conflict-avoidant like me, quietly move on. But when an AI forgets? It feels like a full system failure. Something I would’ve called “magic” a year ago now feels broken if it doesn’t behave exactly how I want. Wild.
When I’m not in a generous mood (like when deer ate all my tomato plants), that’s when the computer-throwing fantasies start.
So when Cursor recently released their new memory feature, I got excited. Finally! But after trying it out, I realized it wasn't going to solve my specific problems. The feature remembers coding standards, project specifications, and coding styles – which sounds great if you're an actual programmer. But since we've established I'm not a real programmer, I don't have coding standards or a consistent coding style to remember.
Where things really fell apart was debugging. Cursor’s version of “forgetting” during debugging isn’t just annoying—it’s dangerous. It defaults to its (our?) most basic instinct: eliminate the error source. Which, in my experience means deleting half your app. It’s like watching someone in a crisis revert to their lizard brain. Picture a kid told they can’t have screen time until they clean their room: left alone, you know that cleanup is going to mean shoving everything under the bed and calling it a day.
After a few rounds of whack-a-mole debugging (which I covered in my last post), I tried a new tactic: creating documentation Cursor could reference. Genius, right? I had Cursor generate two key files:
Architecture decisions and best practices – all the specs we needed to avoid accidentally breaking stuff.
Context – basically a mini-PRD: what we’re solving, how we’re solving it, and what features are in play.
I thought I'd cracked the code. I felt so smart. But then came the disaster. APPARENTLY you have to actually TELL Cursor to read these files. It doesn't just... know to do that?!?!? That little oversight led directly to the chat deletion disaster I mentioned before. Whoops.
So I asked Cursor how to actually make these docs useful, and its advice was… surprisingly helpful. It told me to:
Be clear about which docs to review
Be specific about what I want to know
Say how I want the answer structured
Cool cool cool, would’ve been nice to know that earlier. I also realized I hadn’t updated the files before that debugging session. If I’d been clearer that I just wanted to hide the button—not nuke the entire auto-recording feature—we might’ve avoided the whole mess.
Here's how I fixed it this time:
Getting the chat working again was step one. While Cursor was busy deleting chat functionality, it also decided to expose all my API secret keys. Apparently, when I was getting started, I saved them in a file I shouldn't have, and that file got pushed to GitHub. Thankfully, GitHub and Google's monitoring immediately caught the security breach and disabled everything. Good news: no rogue usage that could have cost me money. Bad news: I had to set up new keys.
Once that was sorted, I started working on my local file to avoid the dreaded linter error saga. After trying to revert back through several prompts, I realized we'd been debugging too long to roll back to the last working version. So we essentially started over with the chat functionality, but this time I prompted Cursor to reference our documentation from the start.
What I'll do differently next time:
Better prompts that reference documentation at critical moments: "Give me a step-by-step plan to fix this error, and a checklist of what to test to make sure nothing else is broken. Please ensure you reference docs/context.md and docs/architecture-decisions.md and ensure all steps align with the information in them."
Ask for code review or diff analysis: "Show me a summary of the code changes and confirm which modules are not affected."
Be explicit about what must not break: "When fixing the chat API, make sure the voice controls, topic selection, and auto-play features still work."
The lesson here isn't that Cursor's memory feature is useless – it's that understanding how to work with AI tools requires as much strategy as the actual coding. Sometimes the solution isn't waiting for the tool to get better; it's learning to communicate with it more effectively.