Mostly Done.
Contents

14 Divide the work where each side is strongest

No formula for dividing work with coding agents survives contact with real tasks. Human plans, machine codes fails, and so does the tidier human supplies taste, machine supplies execution. The line moves from task to task. What stays stable is the kind of contribution each side makes best.

You keep the tactile, product-level judgment: whether the software feels coherent when you actually run it, not merely whether it satisfies repository contracts. You set the standing pressure toward simplicity, decomposition, and incremental work. You watch plans as they form, challenge assumptions, and recruit adversarial reviewers from other domains. Agents choose frameworks and implementation approaches, and they supply search, implementation breadth, repetition, and stamina. Neither side certifies its own work.

14.1 Name the symptom, not the fix

A precise perceptual report can be more useful than a detailed implementation request:

The cursor lands between the n and g of formatting.

The fail and reject labels are crowding each other.

The midpoint should exclude the arrows.

Each report tells the agent where reality violated intent without forcing a solution. The agent can dump offsets, inspect geometry, trace the render path, and build the regression proof.

You do not need to translate taste into code before asking for help. That translation is part of the work you are delegating.

14.2 Ask questions that raise the bar

Some of the most valuable directions you can give are questions:

Each one exposes a standard the current work may not meet. A question is often cheaper and more generative than a full specification because it invites the agent to investigate rather than comply.

A strong question points at evidence. Make it robust is vague. What known-bad input proves this harness can fail? changes the next action.

14.3 Keep corrections cheap

Corrections should be fast and small. A day’s worth might read:

The value is the low ceremony. The correction enters the system, the work changes, and a repeated failure may become a standing rule.

Cheap correction is what permits broad delegation. If every correction requires a defense of the original work, you will micromanage and the agent will optimize for reassurance.

14.4 Delegate judgment, then verify state

You can safely say keep going when the repository already encodes the limits: the test gate, the branch protocol, the documentation sweep, the review requirement, the completion bundle.

You still spot-check state at important boundaries:

This is not micromanagement. It is checking the places where conversational state and repository state commonly diverge.

The spot checks do not stop at the repository. Even with execution fully delegated, you still run the application, exercise the interaction, and open the published page. The shipped result exists outside the code and the test suite, and someone has to meet it there. These product-level checks are a deliberate part of the division, not a residue of distrust.

14.5 Delegation is not autonomy

It is tempting to assume that broad delegation lets agents run indefinitely. It does not. Delegation does not create autonomy; a completion harness does.

Agents tend to stop after a bounded unit and ask you to inspect it. That behavior does not disappear because the permission was broad or the prompt was confident. Sustained execution comes from machinery that defines completion and makes premature stopping difficult: tests that must pass, workflows that continue, review loops that consume the output, and completion criteria the agent cannot satisfy by summarizing.

The operating model this produces keeps you interactive. You watch plans form, ask questions, and apply pressure, while the harness supplies the persistence. That much interaction looks like a bottleneck. The expensive arrangement is the other one, where your attention is the only thing keeping the work moving.

14.6 Supply facts outside the checkout

You may know how a downstream runtime behaves, why a product promise matters, or which compatibility break users will accept. A decision about retry semantics can hinge on how a consumer in another repository calls your library, and no amount of reading the local checkout will surface that fact.

Agents should make these dependencies visible rather than invent them. A design can list its external assumptions and ask for the one fact that changes the policy. Once supplied, the fact should move into a contract test or a durable note.

Your knowledge is most valuable when it becomes less necessary next time.

14.7 Do not let either side self-certify

You can be wrong about a screenshot. The agent can be wrong about a test. A reviewer can be wrong about a typesetting rule. A profiler can be wrong about work deferred by lazy evaluation. The remedy is not a better judge. It is disagreement between independent representations:

This is why high trust can coexist with skepticism. People and agents get wide freedom to produce. Evidence decides what survives.

use ← and → to turn pages