Before you start your next Cursor project, do this
The first session always goes well. The agent is fast, the code is clean, and the thing you described in your initial prompt starts taking shape in a way that feels almost unreasonably good. You close the laptop thinking you've finally found the right way to build.
Then session three happens. You come back with the next piece of the project, give the agent the context you remember to give it, and it builds something that quietly contradicts a decision you made two sessions ago. Not a bug exactly. The code works. It just doesn't fit with what was already there, because the agent had no way of knowing what was already decided.
By session five you're spending more time explaining the system to the agent than building it. The correction loop starts to feel familiar.
This isn't a Cursor problem. The agent can only work with the context it receives in the session. If the architectural decisions that shape the whole system aren't written down somewhere the agent can read, it fills in the gaps itself. Those gaps seem small at first, but they start to compound.
The fix isn't complicated, but it's easy to skip when you're moving fast and the first session went so well. Before you start, write down the things that should never change: what you're building, the tech stack, the main components and how they connect, and the decisions that are locked. Not a full specification. Just enough that the agent isn't treating settled questions as open ones.
The decisions that matter most are the ones with the highest downstream reach: your data model, your authentication approach, which part of the system owns which responsibility, and the order things need to be built in. If the agent doesn't know those four things, it guesses. If it guesses across enough sessions, you end up with a codebase that works in pieces and fights itself at the seams.
The reason this keeps getting skipped is that the first session produces something coherent without it. The scope is narrow, the prompt is specific, and the agent has enough to go on. The problems surface later, when the agent needs to understand the whole system rather than just the piece in front of it. By then you're already invested.
Ten minutes of thinking before session one saves you from spending sessions four through ten undoing decisions the agent made because you hadn't made them first.
If you want the guesswork removed before your first session, that's what Zalcro does. You describe what you're building, answer a set of questions, and get a phased ticket backlog your agent can follow from session one. The decisions that would otherwise live in your head get written down before anything gets built. Free to start at zalcro.ai.