The most expensive sentence in a small company is some version of this:
"She would be perfect for this, if only she knew how to set up the project."
I have watched this block real work more times than I can count. An office manager who had the context and the patience to reproduce a nasty intermittent bug - but not the local toolchain to reach it. An artist whose eye was exactly what a feature needed - who could not run npm install
against a private registry. A teammate who could tell you in ten seconds whether a workflow made sense, but who had never written a prompt that a coding agent could act on.
None of that is a story about talent. It is a story about where the gap sits.
Here is the structural problem. The missing knowledge is usually small - twenty minutes of tooling trivia. Which command starts the app. Where the staging test account lives. What a good delivery report looks like.
But that small gap sits at the entrance to the task. And a gap at the entrance doesn't cost you twenty minutes; it costs you the entire task, because the task now has to wait for one of the three people who can cross the threshold unaided. Those three people are, of course, the people who are already the bottleneck for everything else.
So the work queues behind them. Not because it is hard. Because it is unenterable.
We ask it constantly, and it's malformed. "Engineering" isn't one act. Shipping a change involves at least: understanding a requirement, locating the relevant code, changing it, running it, noticing a visual defect, checking permissions, testing an edge case, and deciding whether the result is acceptable.
Those are genuinely different skills, and almost nobody is uniformly strong across all of them.
Once you stop treating "engineering" as a single competency, a task stops being all-or-nothing and starts being decomposable.
The instinct is to split work into "the technical part" and "the rest." That's too coarse. In practice a bounded task becomes transferable when you separate four distinct things:
1. The domain brief. Somebody who actually understands the problem writes down the outcome, the constraints, and the boundaries. What "done" means. What is explicitly out of scope.
2. The agent guidance. The coding agent gets technical context, setup instructions, the work request, and - critically - stop conditions. When should it refuse to continue and ask?
3. The human runbook. The person running the task gets a short, concrete list: which access to use, what to observe, what judgment only they can supply, what to QA, and when to escalate.
4. The acceptance step. Evidence goes back to a qualified reviewer who decides whether the thing is actually complete. This is a separate decision from "the work was performed."
domain expert's brief + technical context
|
v
human runner <--> coding agent
access, eyes setup, implementation,
judgment explanation
|
v
evidence + recorded delivery
|
v
qualified review and acceptance
Notice what this is not. It is not "give the task to somebody cheaper and hope the model covers the difference." The expert's knowledge stays in the system in two places: once in the brief, and again at review. The runner's role is real rather than ceremonial, because the task explicitly names a check they are equipped to perform.
The strongest caution about this idea is also the clearest case for it.
In a preregistered experiment, BCG gave consultants access to and training on GPT-4 for tasks outside their existing skill sets. On tasks that sat inside the model's competence, assisted consultants performed substantially better than unassisted ones. On tasks positioned just outside it - where the model was confidently wrong - assisted consultants did worse, because they accepted plausible output they lacked the expertise to challenge.
Read that carefully, because both halves matter:
That is exactly why the fourth part - acceptance by a qualified reviewer - isn't bureaucratic overhead. It's the thing that makes the other three safe. Assisted performance is not the same as expertise, and a handoff design that forgets this converts a skill gap into a silent defect.
If you want a task to be transferable, the work is mostly front-loaded and mostly writing:
The payoff isn't that job titles stop mattering. It's that a narrow twenty-minute gap stops being able to hold an entire task hostage.
I work on Wagglet, which is built around this pattern - an author prepares a task for two audiences, a teammate claims and runs it on their own agent subscription, and acceptance stays a separate decision. If you want the longer version of the argument above, it's written up as a field note: How AI task handoffs help more teammates complete technical work. The five-stage lifecycle is documented at how it works.
How does your team handle this? I'm curious whether anyone has found a good way to decide in advance which tasks are safe to hand off.