Answer
How should coding-agent sessions be divided?
One session per reviewable change. When the diff is ready to be looked at, the session has done its job.
One session per change that can be reviewed on its own. The session ends when the diff is ready, which keeps the context matched to the work and the diff matched to a single claim.
Session boundaries are usually set by the person getting tired or the tool running out of room, which produces divisions unrelated to the work. A better unit is available and it is already defined by the process: the reviewable change. Everything needed to produce one change belongs in one session, and when that change is ready the session has finished whether or not anything is exhausted.
This alignment gives several things at once. The context stays relevant, because everything read during the session bears on the change being made. The diff stays proportional, because a session working on one change does not accumulate a second. And the handover problem largely disappears, since the artefact that survives is the change itself rather than a description of where the work got to.
The corollary is that a task requiring several reviewable changes should be several sessions, each starting from the merged state of the previous one. This is more reliable than one long session producing a large diff, and the reason is not stamina: each session begins with the previous change actually integrated, so the second piece is built against reality rather than against an assumption about what the first piece will look like.
There is a case for a longer investigative session that produces no change at all. Understanding a problem, tracing behaviour, reading the system: this is legitimate work and its output is a written finding rather than a diff. Keeping it separate from the change that follows is worth doing, because the investigation reads widely and the change should be made in a session that has read narrowly.
The failure to avoid is the session that produces two unrelated changes because both came up. The resulting diff makes two claims and can only be accepted or rejected as one, which forces a reviewer to either approve something they had questions about or reject something that was fine. This is a common consequence of continuing a session past its natural boundary, and it is visible in the diff before anyone reads the code.
Divide by what a reviewer will look at, because that is the unit the work has to survive anyway.
Siddharth Sharma, Context Theory
Related questions
What about a change that is genuinely too large to review in one piece?
Then it needs decomposing into changes that stand alone, which is the same problem it would present without an agent. The useful discipline is to find the sequence of individually safe steps — a refactor that changes nothing, then the behaviour change, then the cleanup — and run each as its own session. Agents make this cheaper rather than unnecessary.
Should a session end when the tests pass or when the change is merged?
When the change is ready for review, because everything after that is a different activity with different participants. Addressing review comments is best done in a new session with the diff and the comments, and not the entire history of how the change was produced, which is material that argues for what is already there.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Aligning the session boundary with one reviewable change keeps the accumulated context relevant to that change and keeps the diff proportional, because a session working on a single change does not accumulate a second. | Comparing diff size and unrelated file counts between change-bounded and time-bounded sessions. |
| Software | Running successive changes as separate sessions starting from the merged state means each is built against integrated reality rather than against an assumption about the shape of the preceding change. | Comparing rework required when a second change is built on an unmerged first against a merged one. |
| Response | Investigation and modification want different context profiles — wide reading against narrow reading — so separating an investigative session from the change session that follows improves both. | Comparing the file set read during investigation against the file set relevant to the resulting change. |
| Constraint | A diff carrying two unrelated changes makes two claims that can only be accepted or rejected together, forcing a reviewer to approve something questioned or reject something sound. | Identifying diffs in the recent history that contain more than one independent change. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one