A carpenter makes a thing. An experienced carpenter will sometimes make the thing that makes the thing: a jig that holds the material in place, guides the tool, and lets the same cut be made reliably again.
The jig is not the work itself. It is an understanding of the work made transferable.
Recipes, templates, checklists, macros and software functions all do something similar. Each takes a capability that lived partly in a person and gives it another form—one that can be repeated, inspected, handed over or scaled.
This is the abstraction of work.
As AI assumes more execution, defining the work becomes more central than doing it. Much of the new work is deciding what should happen, what good means, which conditions matter and where responsibility remains.
That sounds new. It is not.
AI makes the idea newly important because it gives us somewhere unusually capable to hand the abstraction. The recipient is no longer limited to following a fixed sequence. It can work in language, respond to context, compare possibilities and operate inside instructions that leave room for interpretation.
That changes what can be handed over. It does not remove the need to understand the work.
Doing something well and explaining how it can be done well are different abilities.
An experienced accountant may recognise that a number looks wrong before knowing exactly why. An editor may feel where an argument loses its nerve. A manager may know that the formally correct response will land badly with a particular person. Expertise contains rules, but it also contains habits of attention, remembered exceptions and judgments that have become too familiar to announce themselves.
Ask someone to transfer that work and the hidden structure begins to show.
What is essential? What is merely customary? Which decision can be specified? Which requires a principle? Where must the recipient stop and ask? What would a plausible but wrong result look like?
The abstraction is built from the answers.
This is why a prompt is not necessarily an abstraction, just as a list of steps is not necessarily a good process. An instruction can produce an acceptable result once without containing a reliable account of the work. A useful abstraction must survive variation. It must make room for the ordinary case, recognise the exceptional one and place accountability somewhere visible when it reaches its limit.
A bad jig does not always fail immediately. Sometimes it produces the right cut until the material changes.
There is a temptation to design the perfect system first: settle the principles, write the process and then begin the work.
In practice, useful abstractions often develop in the opposite direction.
Someone does the work. A pattern repeats. A handoff exposes what was previously implicit. The recipient gets something wrong, or succeeds for a reason nobody had articulated. The instruction changes. After enough contact with reality, a principle becomes clear enough to name.
Practice comes before principle—not because principles are unimportant, but because practice gives them something honest to describe.
This matters when working with AI. The first version of an instruction is rarely the asset. The asset is the developing ability to notice why one version worked, why another failed, and what should be retained beyond either attempt.
The role follows the work for much the same reason. Once a set of tasks has been performed, delegated and reflected upon, its real shape becomes easier to see. Responsibilities that looked separate may belong together. A supporting skill may turn out to be a standing duty. An apparent role may disappear because it described a tool rather than an enduring purpose.
Abstraction is therefore not just process documentation. It is one way an organisation learns what its work actually is.
Earlier forms of abstraction had a fairly obvious boundary. A jig could guide a cut. A checklist could preserve a sequence. A software function could apply explicit logic. None could notice that the situation no longer resembled the one for which it was designed.
Human judgment lived beyond the boundary.
AI makes that boundary less stable. It can be given examples, counterexamples, priorities, tones, decision criteria and conditions for escalation. It can apply a working model rather than merely execute a fixed sequence.
That does not mean judgment has been captured whole. It means parts of judgment can now be expressed, tested and transferred in ways that were previously impractical.
The distinction is important. “AI can exercise judgment” is too broad to guide a business. Better questions are:
- Which judgment?
- Under what conditions?
- Against whose standard?
- With what evidence?
- Who notices when the conditions change?
- Who remains answerable for the result?
The abstraction is not complete when the AI produces something impressive. It is complete enough to use when the surrounding system knows what the AI is doing, what good means, and where the handoff ends.
When a task is successfully abstracted, human work does not simply vanish. Some of it moves up a level into defining the work.
Instead of producing every instance, someone defines the conditions under which instances can be produced. They choose examples, set boundaries, inspect failures, revise the model and decide when the abstraction should not be used.
This can create leverage: more output, greater consistency, faster iteration. It can also create distance between the person and the consequences of the work. At scale, a small error in the abstraction becomes a large error in practice.
The new work is not automatically better work. It is work with a different object.
That object also ages quickly. An instruction built around today's model, market or organisational assumptions may be obsolete within months. The durable capability is not the prompt or playbook itself. It is the ability to look at a practice and find the transferable structure inside it—then to keep testing whether that structure remains true.
In that sense, abstraction is not a transformation project with an end date. It becomes part of normal operations. The jig keeps changing because the material, the tools and the desired result keep changing.
This is already happening in knowledge work. Law provides a particularly clear example because legal work combines repeatable form with consequential judgment, and because firms have spent years accumulating positions that experienced lawyers know how to apply without necessarily writing down each time.
A&O Shearman's ContractMatrix Analyze, developed with Microsoft and Harvey, reviews documents against client-specific playbooks and policy positions while keeping a lawyer in the review loop. Harvey's own playbook tools can build structured guidance from existing contracts: preferred positions, acceptable fallbacks, clauses requiring review and conditions that should stop the process.
That is more than making contract review faster. It is an attempt to convert part of a firm's accumulated practice into reusable decision guidance. The playbook does not contain the lawyer, and it does not settle the hardest case. It carries enough of the firm's working judgment to handle more of the ordinary cases consistently—and makes the boundary of that judgment easier to see.
Once a capability has been made transferable, the people who previously performed each instance by hand can begin to look like duplicates of one another.
That appearance needs care.
Some duplication is waste. Some is capacity. Some is resilience, contestability, apprenticeship or the second pair of eyes that catches a confident error. An abstraction may reduce the need to repeat the work without reducing the need to understand it.
The organisational consequence is therefore not determined by the technology. A business still has to decide what to do with the capacity it releases: remove it, use it to produce more, or reinvest it in depth and resilience.
That question continues in The Deduplication of Labour.
The carpenter's jig remains a useful image, provided we do not mistake it for a claim that all work has become mechanical.
The significant change is not that AI lets us write better checklists. It is that more of what once looked inseparable from a particular person can now be examined as a possible handoff.
Some of it will transfer cleanly. Some will transfer only under supervision. Some will reveal itself through failure. Some should remain with the person.
The serious work is knowing which is which.
Abstraction begins when we stop asking AI merely to make the thing and start examining the thing that might make it. It becomes a business capability when that examination is grounded in practice, revised through evidence and attached to an accountable address.
The product is not the instruction.
The product is a handoff that can survive reality.