The Inversion of Software Engineering described how coding agents make production cheap and move the engineer toward selection and subtraction. This note follows that shift into the workflow: how should the work be divided when humans and agents operate differently?
A medium-sized software feature looks like one item on a roadmap. In practice, it is several different jobs packed into one line. Someone has to understand the existing system, design the change, implement it, write unit tests, exercise it end to end, and update the documentation. Sometimes there is a migration, a rollout plan, or a round of UI polish as well.
Calling all of that one task hides the cost of moving between its parts. Designing an API and debugging a browser test draw on different kinds of attention. Writing docs means reconstructing the user's view after spending hours inside the implementation. Even though the work is related, each transition asks a human to load a different mental model.
This is where humans and agents start to look less alike. The difference is not just that an agent can type faster. It is that the two have very different working styles.
One feature contains several modes of work
I find it difficult to take a feature from design all the way through documentation in one sitting. That is not because any single step is unusually hard. The friction comes from changing modes without losing the decisions made in the previous one.
A human session usually has a dominant mode. I might spend a morning getting the design right, then return later to implement it. Tests happen in another block of time. End-to-end testing gets postponed until the environment is ready. Documentation becomes the last open item, often on the next day. Each return begins with a small act of reconstruction: what was I doing, why did I choose this shape, and what remains?
An agent can often carry that same feature through as one continuous working set. It can inspect the repository, form a plan, edit the code, run unit tests, read a failure, correct the implementation, open the application, verify the flow, and update the docs without putting the task down. The design decisions remain close to the code and the test results remain close to the fix.
This does not make the output correct. It changes what is cheap. Continuity across a long chain of related actions is relatively cheap for the agent. For a human, the same chain consumes attention at every boundary.
A feature may be one unit of intent, but it is not one unit of human attention.
Parallelism means another worker, not divided attention
The difference becomes clearer when a second task arrives. A person cannot create a clean copy of their working memory and send it down another path. We can switch, keep notes, and manage a queue, but apparent parallelism is usually fast serial work with a context-switching cost between each item.
An agent system can start another session. One session can investigate a failing test while another updates an independent part of the product. The original session does not have to drop its working set to make that happen.
This kind of parallelism still needs boundaries. Two agents editing the same files can create more coordination than progress. Vague ownership produces duplicate work, and weak checks let inconsistent decisions meet late. But when tasks are independent and the success criteria are clear, adding another session is closer to adding another worker than asking one worker to juggle faster.
Humans work best when the queue protects focus. Agents can work across several queues when each one has its own context, tools, and verification loop. A useful system should respect both facts instead of asking people to imitate machine parallelism.
Boredom is not a scheduling constraint for an agent
A serious implementation can require a long, dull sequence of commands: search for a symbol, inspect a file, change it, run a focused test, read the log, check the diff, run the full suite, start the app, inspect the browser, fix one edge case, and run the checks again. None of these steps is difficult on its own. Following the entire chain without skipping a step is the hard part.
People get tired of mechanical repetition. Attention drifts, especially when the first twenty commands report that everything is fine. We start sampling the process. We run the likely test, skim the likely file, and trust that the rest is probably unchanged. That shortcut is often reasonable, but it is still a shortcut.
An agent is well suited to the full list. It can keep making tool calls as long as the environment returns useful signals. This is one reason tests, types, linters, and machine-readable errors matter so much. They turn tedious checking into a path the agent can follow without asking a person to watch every step.
Making a human follow the same transcript is not supervision. It is a new form of toil. The person should see the decision, the evidence, and the unresolved risk, not a replay of every command that produced them.
Agents prefer exact interfaces; humans prefer visible ones
The command line is a good interface for an agent. It exposes files, state, logs, exit codes, and composable tools as text. Actions can be repeated exactly. Results can be searched and compared. The interface is dense, but density is useful when a worker does not need the screen to explain itself visually.
Humans have a different advantage. We are quick to notice that a page feels crowded, a hierarchy is weak, a flow is awkward, or a button is in the wrong place. A glance can reveal a problem that is hard to express as an assertion. Product taste often arrives first as visual discomfort and only later as a sentence.
Agents can inspect screenshots and operate browsers, but visual work still benefits from human perception and judgment. Humans can use terminals, but asking us to absorb hundreds of lines of output is a poor use of that judgment. The preferred interfaces are almost reversed: agents benefit from structured, exact tools; people benefit from a clear view of the result.
The workflow should be asymmetric
The practical mistake is to put an agent into a human workflow and treat it as a faster pair of hands. That leaves the person coordinating every transition, watching every command, and repeatedly rebuilding context so the agent can continue. The machine is fast, but the workflow still moves at the pace of human attention.
A better division gives the agent the long horizontal chain: inspect, implement, test, verify, and document. It gives separate sessions work that can genuinely proceed in parallel. It also gives those sessions command-line tools and standing checks so they can make progress without constant observation.
The human role is narrower at any given moment, but more consequential. Set the intent. Resolve the ambiguous tradeoff. Inspect the behavior and the visual result. Decide whether the work fits the product. Then return a clear correction that can become part of the next verification loop.
Give the agent the long mechanical chain. Give the human a clear decision.
Humans are built for focus, not for multiplying themselves across a queue. Agents are built to preserve a working set across tool calls, and agent systems can create more sessions when the work separates cleanly. The productive arrangement is not to make one work like the other. It is to design the handoff around what each one does well.
Designing that handoff requires a standing system that can check the agent's work without constant observation. That is the subject of the next note, The Verification Loop.