An independent journal. Not a shop, and not affiliated with the tools it writes about. Disclaimer

Programming

Keep a working log while you build

17 September 2026 ยท 1 min read

A chat scroll is not a project memory. Write down the decision, the command, and the result you actually observed.

A long session with a model produces a scroll that feels like documentation. It is not. It mixes rejected ideas, outdated file paths, and answers to prompts you later narrowed. The next morning you will not remember which paragraph was the decision.

Keep a working log in the repository or in the issue, and keep it dull. One line for the decision: what you chose and what you refused. One line for the command you ran. One line for the result you saw, especially when it failed. Link the diff. Do not paste the whole conversation.

Update the log when the plan changes, not at the end. A log written afterward tends to describe the code you wish you had. A log written at the time describes the constraint you actually hit, which is the part worth keeping.

When you start a new chat, paste the log, not the previous transcript. The model then continues from the decisions instead of from its own earlier digressions. That is also how a person joins the work. Five lines of log beat fifty lines of chat.

CursorUltra Blogs is an independent journal. It is not affiliated with the tools mentioned in this piece, and nothing on this website is for sale. Read the disclaimer.