After working with this tooling for about a month, I've found the biggest struggle is adapting my mental model as the paradigms change. Because make no mistake, this is a research-stage tool that has been thrust into the spotlight while in its infancy.<p>There's definitely shift between versions of cursor. One time I had an unpleasant crash that also upgraded the version, and suddenly .cursor/ files I thought were working (but hadnt been) showed up mid prompt, and derailed the entire composer run.<p>I've tried ideas ranging from TODO documents, append-only work logs, blueprint documents, faux-team interactions through role definitions, and much much more.<p>The most success I've had is by adding manual lines at the end of every prompt, akin to phrases like "be respectful of the existing code and functionality, make deliberate changes with caution and consideration". Beyond the normal "plan and take it step by step" type phrasing.<p>It would also be nice if .cursor/ rule files actually were actively used, instead of sometimes being hooked in if you wrote the description right.<p>Sometimes I have great success at utilizing specialized roles, with named team members and explicit direction, to elect the "appropriate" role for the items being worked on, and discuss pros/cons and facilitate brainstorming.<p>At the end of the day, I think I end up doing an annealing pattern for changes:<p>- Build the features and breaking is okay so long as we get the features.<p>- Distill the built features into a doc with examples and roll back the code by git.<p>- Build a v2 based on the distillation.<p>- Rinse repeat, usually until v4 or v5, when i tear it all down and write it 99% by hand from the distilled documents.<p>Definitely a rocky road so far.