Scoping a session
"One task per session" is easy to say. Here is how to tell what counts as one task.
The rule is only as good as your definition of a task. Here is a usable one.
A task fits one session if: - it has one sentence of intent - it produces one commit you would be happy to review as a unit - you can state "done" as something a command can check - it touches files you can name in advance
If any of those fail, you have more than one task. The fourth is the most diagnostic: if you cannot name the files, you have an exploration task first, and that is a separate session.
Common things that are secretly two tasks
| Looks like one task | Actually |
|---|---|
| "Add caching to the user service" | Decide the invalidation strategy (grill + plan) → implement it |
| "Fix the flaky test" | Find out why it is flaky → fix the cause |
| "Migrate to the new API client" | One session per module, plus a shared spec |
| "Add tests to the payments module" | Decide what to assert → write them in batches |
| "Clean up this file" | Not a task at all — no definition of done |
Sizing in the other direction
Sessions can also be too small. Four sessions that each change one line of the same file cost you four cold starts, four rounds of re-loading context, and a commit history that hides the actual change. If two tasks share the same files, the same intent, and the same review, they are one task.
The five-minute scoping ritual
Before any non-trivial session, write these four lines. It takes five minutes and it is the single practice that most reliably improves outcomes:
INTENT: one sentence. Why, not just what. SCOPE: files I expect to change. Anything else is a stop-and-ask. DONE: the command that proves it, plus anything the command cannot prove. NOT: what I am explicitly not doing in this session.
The NOT line is the one people skip and the one that pays. It is where you pre-empt the agent's helpfulness — "not renaming anything", "not touching the migration", "not improving the error messages" — before it produces a diff you have to unpick.
Watch out
When a session reveals a second task — and it will — write it down and do not do it. A note takes ten seconds; a scope expansion costs the reviewability of the whole diff and drags a second problem’s context into the first problem’s window.
Try it
Take the big task from your list — the one you have been avoiding — and apply the four-part test until you have decomposed it into session-sized pieces. Count them. That number is the honest size of the work, and it is usually the reason you were avoiding it.
Takeaways
- One task = one intent, one reviewable commit, one checkable definition of done, nameable files.
- If you cannot name the files, exploration is a separate session.
- Write the NOT line. It is the cheapest scope control available.
Why is "clean up this file" not a task?
It has no definition of done, so nothing can tell either of you when to stop — not a command, not the agent, not you. Every session against it ends arbitrarily, and the diff is unreviewable because there is no criterion to review against. Turn it into something checkable: "split this file so no function exceeds 40 lines and the check command still passes".
A course by Pieter Zandbergen