Agentic Coding in Practice

Chapter 1 excerpt: deciding what counts as a unit of work

A supervised approach to coding agents

Mira opens Patchboard and notices that completed issues disappear when she selects the Open filter, then return after she refreshes the browser. She sends the coding agent a short request: “Fix the issue filter.”

The agent finds a comparison between a selected status and each issue's status. It changes the comparison, runs a test, and announces that the filter is fixed. Mira refreshes the page. Completed issues return again.

The agent may have improved one piece of the application. It has not yet resolved Mira's problem. The problem includes an action, a state transition, and an expectation that extends beyond the first render. Until those parts become visible in the task, the agent can work hard on a narrower interpretation and still sound finished.

This fictional scene introduces the most consequential design choice in an agentic coding workflow: deciding what counts as a unit of work.

People usually describe software problems from the point at which the software disappoints them. “The filter is broken” is a useful report. It directs attention to a behavior. It rarely specifies the full set of conditions needed to investigate and repair it.

An engineering task grows out of that report. It identifies a starting state, a desired outcome, and a way to recognize the difference. For Patchboard, a useful first formulation might be:

Given a list containing open and completed issues, selecting Open shows only open issues. The selection is preserved after refreshing the same page. Selecting All restores both kinds of issue.