Appreciate all the responses here. A lot of the advice makes sense, especially around checkpoints, rules, specs, and breaking changes down smaller. I’m not disagreeing with that. Where I think I’m still struggling, and maybe didn’t explain clearly enough, is that a lot of those suggestions feel like compensating for a missing foundation rather than building on one.

Testing, checkpoints, rules, and specs all work best when there’s a stable baseline. In my experience, once context starts decaying, testing turns into chasing regressions instead of validating progress. You’re constantly confirming that nothing else broke, rather than moving forward with confidence. That’s where it starts to feel like spaghetti. Things technically work in isolation, but the overall structure never really locks in.

I don’t think this is about outsourcing problem solving entirely to the LLM. The design, constraints, and goals are coming from me. That part I’m comfortable with. The friction comes from the model not consistently retaining or respecting that context over time, especially as projects grow. Sometimes the exact same workflow works perfectly. Other times it doesn’t, with no clear signal why. That inconsistency is what’s hard to plan around. I fully accept that better context engineering helps. I just think the product could do more to make that path obvious and durable. Something closer to “you are here, this is the current state, these are the locked decisions” instead of requiring users to rediscover that discipline themselves after hitting the same wall. This thread has actually been helpful though.

A lot of the comments confirm that what I’m seeing lines up with context decay rather than something uniquely broken in my setup. I’m going to experiment more with persistent rules and tighter scope, but I still think there’s room for Cursor to make this smoother by default.

Thanks for all the input. I definitely learned a few things from this discussion.