Once a task gets a little fuzzy, the session starts accumulating bad context. Changes that should have been separate get mixed together, commit boundaries get blurry, and I stop knowing whether I should keep going in the same chat or restart in a new one.
My current rough guess is that the right unit is "one reviewable change with one reason to exist", but I haven't found a clean way to turn that into rules for new tasks, new chats, new branches/worktrees, and commit boundaries.
For people using coding agents on mature codebases, what boundaries have held up in practice?
- What makes something a new task instead of a continuation?
- When do you start a fresh chat instead of continuing the existing session?
- How do you decide branch/worktree and commit boundaries?
Concrete examples would be especially helpful, especially cases where your first boundary was wrong and you had to split or redo the work.