The Articulation Test: If You Can't Describe the Steps, You Can't Automate Them

The most expensive automation projects are not the ones that fail. They are the ones that half-work, forever, on a task that never deserved a system in the first place.

There is a cheap way to avoid most of them, and it takes about four minutes per candidate task.

Five questions before anything gets built

Teresa Torres, writing at Product Talk, lays out a screening filter that reads like common sense right up until you apply it to a real backlog and start crossing things out.

Is the task recurring or one-time. Can you articulate the steps. Does it require your judgment. Is success clearly definable. What is the cost if it is done badly.

The second question does the heaviest lifting. If a person cannot describe how the task is performed, in order, without hand-waving, then the task is not ready to automate. Not because the technology is inadequate, but because nobody has yet worked out what the task actually is. Automation does not resolve that ambiguity. It ships it into production and lets it accumulate.

Most stalled AI projects fail this question at the outset and nobody says so out loud, because "we cannot describe our own process" is a harder sentence to say in a planning meeting than "the model is not there yet."

Anthropic's version of the same rubric

The internal delegation guidance Anthropic has published lands in the same place from a different direction. Hand off work that is low-complexity, easily verifiable, well-contained, repetitive, and fast to prompt, meaning under roughly ten minutes of setup overhead. Keep design, strategy, and taste in-house.

"Easily verifiable" is the criterion that gets skipped most often, and it is arguably the most important one. A task whose output cannot be checked quickly is a task where errors compound silently. The automation looks like it is working right up until somebody audits it, which in practice means right up until a customer does.

There is a useful sizing detail in the same research: low-stakes papercut work, small refactors and minor tooling, makes up 8.6% of Anthropic's Claude Code tasks. Not the headline use case. Not the demo. A steady share of small, safe, verifiable work, which is exactly the category where trust gets built before anything consequential is handed over.

Full automation and augmentation are different products

The screening filter has a second output that teams tend to collapse. Every candidate task sorts into one of two piles: full automations that run without a person, and augmentations where a human stays in the loop.

Defaulting to hands-off is the common error. The Willison rule of thumb applies here with some force: models produce plausible-looking output, including plausible-looking libraries and plausible-looking logic, so verification cannot be outsourced to the thing being verified. Anything that sends, submits, or touches a live system belongs in the augmentation pile, where the agent proposes and a person confirms.

This is not caution for its own sake. It is a design decision that determines what the thing costs to run. An augmentation needs a review surface, a queue, and somebody's attention budget. A full automation needs monitoring and a rollback path. Picking the wrong one and discovering it later is how a project acquires an unplanned headcount.

Reframing what to look for

Torres suggests moving past raw time-saved into three categories: amplify what someone is already good at, remove friction from frequent tasks, and cut work that drains energy.

The third one is undervalued in most enterprise planning, because energy drain does not appear on a time sheet. A task that takes twenty minutes but ruins the following hour is worth more to automate than a ninety-minute task somebody genuinely enjoys. Time saved is the easy metric. It is not always the right one.

The filter is not sophisticated. That is rather the point. Most of the value in an automation program comes from the tasks nobody attempted, and the fastest way to find those is to stop attempting the ones that were never going to work.

If nobody in the room can say the steps out loud, the project is not an engineering problem yet.

Sources: Teresa Torres, Product Talk (five-question screening filter: recurring vs one-time, articulable steps, judgment required, definable success, cost of being done badly; the amplify/friction/energy reframing; full automation vs augmentation as a deliberate choice); Anthropic (delegation rubric favouring low-complexity, easily verifiable, well-contained, repetitive work under ~10 minutes of prompt overhead, keeping design, strategy and taste in-house; papercut work at 8.6% of Claude Code tasks); Simon Willison (models hallucinate plausible-looking libraries and logic, so verification cannot be outsourced; agent proposes and a human confirms on anything that sends, submits, or touches a live system).