Yes, my codebase has gotten bigger and I hit a rut where every change was blowing up one way or another. The fix was to create a few Cursor rules files. You can have Cursor make this - one to define the overall structure of the project, one to define where dataclass types are (I have a Python codebase), a few different ones for generic patterns for what needs updating when adding new code paths. In Cursor you can also select when Cursor consults these files, every time or when doing specified changes.
This has made the biggest difference with o3. If I want to "add a new module" I first explain the goal and have it create a plan (no code). Then I have it save that plan to a TODO.txt. And I just have it start implementing it. I spot check the code along the way to make sure its going down the correct path. I run a few "continue implementing" until it has created tests that pass. Then I test things myself. If all that checks out, I actually look at the code. Most of the time now everything is functioning and I have just a few minor tweaks.
Because I'm working on a new project I let some things stay a little wrong because I know I can focus on an across-the-board solution to it later, with a single prompt. The most important thing is to have everything well-typed and well-structured. LLMs thrive in structure.