The Human Boundary

Implementation can be handed over whole; judgment cannot. What judgment means, which work can go, and a three-second test for the rest.

One lesson left in assigning work: should this job go to the model at all? The test comes down to one line — it can complete the implementation; it cannot supply the judgment. The line is not drawn at capability but at accountability. Implementation is "build it to a standard that has already been set." Judgment is "set that standard, and answer for setting it wrong." The first half can be handed over whole. The second cannot, because it has to land on a party that can be held responsible — and the model has no standing to be one.

After reading, you should be able to answer:

• What does "judgment" come down to in your day-to-day work?
• How does a three-second test tell you whether a piece of work can be handed over?
• Which points need a human, and why is "this one obviously needs no checking" the riskiest kind?
• Once the direction is set, in what order should the handover happen?

The line is drawn at accountability, not capability

On the implementation side it is nearly unlimited: writing code, producing documents, batch cleanup, translating and rewriting, drafting. Fast, tireless, unlimited in volume, never bored by repetition. That is its irreplaceable value.

On the judgment side it is close to zero: it has no stance, no values, no motive for whether this work should exist, and no capacity to bear consequences. The one thing it does is return "the most fluent text for the given input."

So the division is simple: implementation goes to it, judgment stays with you. Judgment sets the direction and the standard; it turns them into reality at maximum efficiency.

Here is a blunter way to put it: it will not carry the blame for your team. No court recognises "the AI decided" as an answer, and nobody can sign a post-mortem on its behalf. The EU AI Act makes human oversight a hard obligation for high-risk uses for exactly that reason — accountability has to land on someone who can be questioned. eu-ai-act The three layers — judgment, implementation, responsibility — are laid out in more detail in You Own the Judgment, It Owns the Execution.

"Judgment" is too abstract — on the job it is four things

• What to build. "What are we actually making?" has only one source of answers: your situation, the resources you have, and the trade-offs you cannot avoid. A probability model cannot supply it. It can lay the options out and compare them, but the choosing is yours to answer for.
• What to trade away. "Is this feature worth building?" "What does raising the price cost us?" These involve who benefits, long term against short term, and who you answer to. They have no optimal solution, only the one you pick.
• What the output means for the business. A figure, a conclusion, an experiment — whether it is good or bad news for your business, and whether to change direction because of it, needs business context that was never in its input.
• Whether the result is acceptable. "Is this good enough?" "Can we ship at this error rate?" That is an acceptance standard, and it cannot supply one. It can tell you what it did; it cannot tell you whether that counts as enough.

All four share one property: they require someone to bear the consequence. So handing judgment over is not sharing the load; it is passing your responsibility to something incapable of carrying it. What it saves you is the time of getting the work produced. The part about deciding whether the work should exist is not reduced by a minute.

Three seconds, three questions, and a no means downgrade

Whether to hand something over is a question about the task, not about your attitude. Three questions, three seconds.

1. Is the rule clear? Can you state the input, the required output, and what counts as done, in one sentence? If yes, it can do the work. If not — "what do you think we should do next" has no edges to it — it will invent a goal you never stated, and that goal is probably not yours.

2. Can the error be undone? A draft, a dry run, a first pass that stays internal: wrong costs a redo. A quote already sent, a source spreadsheet already overwritten, a payment instruction already executed: no way back. Whether something is reversible depends on having a backup and a route back, not on how undoable the action sounds — "just reset this environment" sounds like it can always be restored, unless that environment holds the only copy of live data, in which case the reset is final.

3. Can you check the result? Once it hands the work over, is there any way for you to see whether it is right? With a source to consult, a standard answer to compare against, or a test a machine can run, you can afford to let go. If it could invent something and you would never find out, then build the means of checking first and discuss delegation after.

Answer "no" to any one of the three and the verdict is downgrade: add a human confirmation, or shrink the scope. Most entries in the incident database trace back to exactly these — an irreversible action run automatically, an impact underestimated, a check skipped. incident-db

Note that question three is not the same thing as blast radius. Blast radius does not appear in the three questions, because it measures how much checking an action deserves, not whether the task can be delegated at all. That belongs to the next section.

Where a person stops the line depends on what a mistake would cost

Beyond judgment itself, there are several kinds of work that must not run to completion on their own. What they share is that once the work is done, you cannot put the result back — or putting it back costs more than the work was worth.

One: irreversible actions. Merging a branch to main, overwriting a production config, running a data migration, firing off a batch of notifications. None of them have a way back afterwards, so the pause belongs before the action rather than in the cleanup. In engineering terms these are held by permissions and approval — if the credential is never issued, the action is unreachable. owasp-llm How to grade actions and where approval attaches is the subject of Sandboxes, Credentials, and the Human Boundary.

Two: output that leaves the building. A quote sent to a customer, a public announcement, an interface agreement handed to a partner. Estimate impact by worst-case propagation, not by direct audience — "just the internal version" gets forwarded like anything else. Anything going out gets read by a person first.

Three: conclusions you cannot check that carry heavy consequences. Money, law, health, safety — where you have no independent way to test whether the claim is true: how a tax rule applies, what a security assessment concludes, what dose to take. This work is not "slow to delegate"; it should not go to a component that only produces the plausible.

Four: the kind that looks like it needs no checking. "It is only summarizing this record, no need to verify" — this is exactly the work that goes wrong most easily, because a model fabricates with far more confidence than people expect. The more a task looks self-evidently safe, the more you should ask: if this went wrong, would I ever find out?

One more thing has to be said plainly: the category is not fixed — it depends on how you design the flow. Add a mechanical check and work you would not have dared to delegate becomes "it does it, code checks it." Insert an approval step and the same work becomes "it does it, a person nods." What changed is your process, not its capability.

Then hand the work over in this order

Set the direction and the standard first, then let it start. For the same piece of work, "tidy up this customer interview" and "organize it under role, scenario and follow-ups, thirty words each, do not add anything that is not in the transcript" come back very different. The clearer the direction, the more useful the return — and where that direction comes from is the part of the judgment you supply.

Then remember: use the options it gives you, not a decision it makes for you. Have it lay the routes side by side with their cost, risk and migration effort, and mark the one it leans toward — note that the leaning exists only to make your comparison easier. The route you take is still yours to pick.

The last layer is the division of labour itself: it produces version one, you own the final gate. Push efficiency as far as it will go on its side; hold quality on yours. How that gate is actually run is the subject of Verifying Answers: check the source, find a counterexample, recompute the key numbers. And delegation itself is handed over in stages — do not build a "fully automatic" feature and then hope. Sort every step into its class while you are designing, and write the human confirmation points and checking points into the flow in advance. Trust is not achieved by praying; it is achieved by design. How that line gets handed over in stages is the engineering half, in Launch Is Not a Switch.

One last line: in the end it is a colleague — not a superior, and not someone who takes the blame for you. What it saves you is the time of getting the work produced; none of the responsibility for deciding is lifted. Call it a limit if you like — it is more accurately the reason you are irreplaceable.

With the assignable jobs settled, the next chapter takes up a different question: how to turn one lucky success into a repeatable one. It starts with changing one thing at a time.