Cursor struggles with refactoring legacy Python monoliths

I’ve been fighting with Cursor’s Composer feature for the last two days trying to modernize a massive, poorly structured Python 3.8 codebase we inherited. The problem isn’t simple bug fixing; it’s architectural refactoring. I’m trying to break down a 4,000-line utility module into smaller, testable components while maintaining backward compatibility. Every time I prompt it to extract specific functions, it either hallucinates dependencies that don’t exist or breaks imports in unrelated files. It feels like the context window is getting flooded with too much noise, causing the model to lose track of the global state. I’ve tried using the @codebase directive, but it seems to just grab random snippets rather than understanding the specific call graph I need it to respect. I’m considering switching to a more manual approach with smaller, targeted prompts, but that defeats the purpose of using an AI assistant for bulk operations. Has anyone found a reliable workflow for large-scale refactoring in legacy projects? Are you using specific prompt engineering techniques to help the tool understand module boundaries better? Or is this just a fundamental limitation of current LLMs when dealing with complex, non-modular legacy code? I’d appreciate any tips on how to keep the context clean without manually copying and pasting entire file structures into the chat. One thing I noticed is that adding explicit type hints before asking for refactoring helped slightly, but it’s still hit-or-miss. I’m at the point where I’m questioning if automated refactoring tools are actually ready for enterprises with messy technical debt, or if we’re still just using them for boilerplate generation and unit test writing.