What changed in the work you hand over
You already know how to turn a brief into an implementation and explain it to a receiving team. Claude Code changes how much of that implementation you can delegate. The decision is whether the whole job improves: accepted behavior, time spent, cost and the work left for whoever maintains it.
Take an illustrative calculation, not a measured result. A task previously took ninety minutes. The agent produces a candidate in ten. If the previous ninety included review and the new review takes five minutes, the apparent saving is seventy-five; if it takes forty, the saving is forty. That calculation still omits any additional specification, rework, integration and later recovery. Keep those costs in the comparison before calling the candidate a productivity gain.
The useful question is what happens to the rest of your day when implementation stops being the slow part. This article gives you four habits and a small measurement exercise for finding out. You can apply them to an integration handover, a notebook becoming an application, or a change to an existing agent workflow.
What actually changed: the agent has hands
Autocomplete suggested. You accepted or you didn't, and nothing happened to your files until you said so.
An agent with tool access can read files, run commands and make changes within its configured authority. Some actions require a prompt; others may already be allowed. Claude Code's permission modes and rules control that boundary. The important distinction is between authorizing a tool action and accepting what it produces.
A suggestion waits for someone to use it. A permitted action can change the working state before you review the result. Decide what may change, what must wait, and how you will establish the outcome. A permission prompt alone does not answer whether the result is correct.
Three parts of the workflow deserve attention:
Your unit of work can get bigger. Asking to make the export handle the missing-country case may touch more files than asking for a country parser. The short instruction still needs a scope: which inputs, what output, what existing behavior must remain, and what evidence the reviewer needs.
More attention may go into review. You inspect work you did not produce line by line. That does not remove the need for decisions before and during the run. Set checkpoints around expensive or externally visible actions instead of leaving every decision to the final diff.
A second request is easy to make. A second implementation still consumes model usage, tool runtime and review capacity. Compare approaches when the decision warrants it, and budget for checking both candidates.
What did not change, and gets ignored
Knowing what you actually want. A capable agent can complete the wrong interpretation of a brief. It can also fail at the intended task. State the intended behavior and acceptance cases, then investigate failures without assuming either the model or the specification must be the cause.
Responsibility for the handover. Someone still has to accept the work, explain its limits and maintain it. Name that owner. Include known failures and unresolved checks in the handover so the receiving team can distinguish a demonstrated result from an assumption.
The operating details. Suppose an invoice must go out before the 5th because the customer's finance team runs a batch on the 6th. If that requirement exists only in someone's memory, the agent has no dependable basis for honoring it. Put the deadline, its source and the exception path in the brief. Existing documentation and integrations help only when the agent receives the relevant facts.
Test whether checking became the bottleneck
Faster production creates value only when the result meets its acceptance criteria at an acceptable total cost. Checking may become the constraint; measure whether it does in your workflow.
The argument here is conditional: when producing candidates gets faster than accepting them, review becomes a queue. Better tests or a smaller change may shorten that queue. A harder task, insufficient model capability or a slow external system may put the constraint somewhere else.
Work through the arithmetic on comparable tasks in your own week. Record active human time and elapsed delivery time separately; a long tool run may need little attention but still delay a customer. Include review on both sides of the comparison.
An unchecked candidate leaves correctness unknown. Its shorter production time is real, but it is not yet evidence of faster delivery at the required quality.
Consider three illustrative failure patterns, not measured incidents: a plausible report using last quarter's figures; a cleanup that silently drops forty rows; and a refactor whose tests pass because the expected results changed with the implementation.
Each needs a different check: source dates, reconciliation of records, or independent acceptance cases. Polished output is not evidence that those checks passed.
The economics behind the workflow
Ronald Coase's 1937 The Nature of the Firm asks why work is organized inside firms when market transactions are available. His later account of the argument compares the costs of internal coordination with market transactions and alternative firms. Internal coordination is costly too.
The application to software agents is an analogy: delegating implementation may reduce some costs while adding specification, integration, monitoring and recovery work. Reading the same files does not make coordination disappear. Verification capacity can limit what one person operates, alongside model capability, available capital, customer demand and the obligations of the business.
The intellectual sources include Williamson on transaction costs, Herbert Simon on scarce attention, and Jensen and Meckling on agency costs. These works do not establish a productivity result for Claude Code. They provide questions to ask about its costs; the workflow measurements have to supply the answer.
The four habits that make it work
These four habits make changes easier to inspect. They reduce particular risks; they do not make every task safe to delegate.
Choose a task with acceptance cases you can establish independently. For a deduplication task, define which records may merge, which must remain distinct and how every input record will be accounted for. A row count alone cannot prove the right records survived. A strategy memo needs different evidence, including whether its sources and assumptions support the recommendation.
Work on a bounded change and keep the original available. A copy or branch makes local file recovery easier. It does not undo an email sent, a database changed or a customer affected. For your first comparison, use synthetic or approved local inputs and prevent external writes. Record what the recovery procedure actually covers.
Compare the actual changed files with the requested behavior. A summary may omit a changed test or an unrelated edit. The diff establishes what changed in those files, but it does not establish that the application runs correctly. Run the relevant acceptance cases and inspect the resulting behavior. Preserve failures and unknowns in the handover.
Separate data cleanup, file restructuring and naming changes when each can be reviewed on its own. That makes unexpected differences easier to trace. When changes must land together, explain the dependency and test the combined behavior; splitting a required integration into disconnected pieces does not improve the handover.
Define the acceptance cases, bound the permitted effects, inspect the changes and test the outcome. Leave a receiving team enough evidence to understand both the result and its limits.
Where delegation needs stronger boundaries
Use the consequences of failure to set the review and release boundary.
Work where being wrong is expensive to discover. Anything that leaves your control and takes weeks to surface, such as a pricing change or something a customer relies on quietly. Keep acceptance with someone qualified to judge it. If you cannot establish the required check, narrow the task to a draft or analysis that cannot make the external change.
Work where recovery is hard. A cascading error across three systems can take longer to reconcile than it took to create. Include that recovery path in the decision before granting write access. More output is not useful if its expected benefit cannot justify the cost of handling failures.
Work that depends on what you have not written down. The undocumented judgement. Every step of making it explicit is real work. Include that work in the comparison instead of attributing the entire task to the time the model spent generating.
The number that tells you whether any of this is true
Compare one contained task with your normal workflow, using the same acceptance standard. Record specification, implementation, review, rework and handover time; tool charges; and any unresolved recovery work. Keep the inputs and model/runtime version with the result. Repeating an identical task introduces a learning advantage, so a single before/after run is a useful probe, not a causal study or a forecast for your whole business.
There are several useful outcomes:
Accepted work takes less total effort or elapsed time. Record which improved and whether costs and quality remained acceptable. Repeat on a comparable task before expanding the claim.
Generation is faster but review or rework consumes the gain. Investigate whether a narrower scope, a better check or a different approach changes the result. Improvement is a hypothesis.
The task is slower, fails acceptance, or remains unverified. Keep that result too. It may expose a capability limit, missing context, an unsuitable workflow or insufficient evidence. Do not score an unknown outcome as successful delivery.
A Zero-Employee Organization (ZEO) is the operating model this site explores: an owner delegates bounded work to software while retaining responsibility for the business. It is an ambition to increase useful output without adding headcount for every task, not a guarantee of staffing levels or profit. These measurements help decide which work supports that ambition and which still needs a different arrangement.
Use the customer-list exercise to practice defining cleanup rules and reconciling the output with the original records. Keep the timing and unresolved cases with your result; a clean-looking file alone does not establish that nothing was lost.
