What planning actually produces
"Planning mode" sounds like a delay. You have described what you want; now something wants you to answer questions about it before you get to see anything. The instinct to skip it is reasonable, and for a weekend project it is correct.
What planning actually does is turn one ambiguous sentence into several specific documents, each of which constrains what comes next. The value is not the documents. It is that a disagreement surfaces while it is still a paragraph rather than after it is a schema.
What gets produced
Four artefacts, each answering a different question, in an order where each depends on the last:
The BRD asks what this is for. Who uses it, what they are trying to achieve, what counts as success. It is the document that catches "we are building an approvals system" when what the business needs is an audit trail, and those are not the same product.
The SRS asks what it must do. Specific behaviours: an approver may delegate, a rejected request returns to the requester with a reason, an audit entry is written on every state change. These are the statements that later become tests, which is the only reason a test suite ever tests the right things.
The architecture pass asks how it hangs together. Entities, relationships, where the boundaries fall. This is where "a user belongs to one department" gets challenged, because someone remembers the regional managers who belong to three.
Then the schema, derived from the architecture rather than inferred from the screens — which is why the API and the interface end up describing the same application instead of two compatible-looking versions of it.
Why writing it down changes the outcome
Without artefacts, every decision you made lives in a conversation. Ask for a change six weeks later and the model re-derives your intent from the code — which means it re-derives it slightly differently, and the fifth change starts contradicting the second.
With artefacts, a change is checked against a written statement. A request that contradicts the SRS shows up as a conflict, at the point of asking, rather than as a bug three screens away.
None of this is an AI insight. It is why teams have written specs for fifty years. What changed is the cost: a BRD used to be a day of someone's week, which is why it was skipped on anything under a certain size.
When to skip it anyway
Planning is worth its cost once you are reasonably confident what you are building. Before that it is expensive precision about the wrong thing — and worse, it makes you committed, because a document feels official in a way a chat log does not.
If you would rebuild this app the same way after deleting it, plan. If you would build something different because you have learned something, keep exploring.
In CodeSky
The BRD, SRS and architecture agents each cost 4 credits per run, and generation afterwards is staged against what they produced — intent, then schema, then API and interface built against that schema. The documents stay in the project as files, so the readiness checks and the agents you run later have something to check against.
The thing worth noticing is what it costs to find out you were wrong. Eleven credits and twenty minutes to discover the data model does not survive contact with the regional managers is a good trade against discovering it in month three.