You sat down to change one line of code. To change it you needed to update a library, which needed a newer runtime, which broke the build config, which sent you into the docs for a tool you had never heard of, and now it is three hours later, you have seven browser tabs open about a YAML schema, and the one line is still not changed. You are not procrastinating. Every single step felt necessary. That is exactly what makes it dangerous.

This is yak shaving, and it has a name precisely because everyone who builds things falls into it. Here is what the term actually means, why the chain of prerequisite tasks feels logical at every step, how to tell the productive version from the wasteful one, what changes when an AI assistant is in the loop with you, and a simple way to climb back out when you notice you are deep in the stack.

What is yak shaving?

Yak shaving is a series of seemingly unrelated, cascading tasks you have to complete before you can get to the thing you actually set out to do. Each task in the chain exists only because the previous one blocked you, so you keep descending into smaller and smaller prerequisites until, metaphorically, you are standing in a zoo shaving a yak and have forgotten you wanted to wax your car.

The term was coined in the 1990s by Carlin Vieri, a PhD student at the MIT AI Lab, after a "Yak Shaving Day" segment on the cartoon The Ren and Stimpy Show. It spread through engineering culture and was popularized by a widely shared 2005 post, Don't Shave That Yak!, by Seth Godin, whose running example is the car wax that ends at the zoo. The Jargon File records the canonical definition: "any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you are working on."

The word "pointless" there is doing a lot of work, and it is slightly misleading. The individual steps are usually not pointless at all. The hose really is broken; the library really does need updating. The problem is the recursion, and the fact that each level hides the one above it. If you keep your work in Scribelet, the fix is to make the stack visible, which turns an afternoon you cannot account for into something you can see and stop. More on that below.

Why the yak stack feels necessary

The reason yak shaving is so hard to catch in the moment is that it is not laziness and it is not avoidance. It is the opposite. It is a chain of locally rational decisions that add up to a globally irrational afternoon.

At every single step, the next task genuinely does block the previous one. You cannot change the line without the library; you cannot get the library without the runtime; you cannot get the runtime without fixing the config. Each link in the chain passes the test "is this actually required to make progress," so your focus stays high and your sense of productivity stays intact. You feel busy and purposeful the entire time, because you are solving real problems. They are just not your problem.

This is what separates yak shaving from ordinary procrastination. Procrastination feels like avoidance; you know you are dodging the work. Yak shaving feels like work, which is why it survives your own attention. The signal that you are in it is not boredom or guilt. It is a quiet realization, often hours in, that you can no longer quickly state why you are doing the thing in front of you without reconstructing three or four steps backward.

It is a close relative of second-order thinking, turned inward and gone wrong. Second-order thinking asks "and then what" to see where a decision leads. Yak shaving is what happens when you only ever ask "and then what is blocking this," descend into the answer, and never ask "and is the original thing still worth it from down here."

Yak shaving and its lookalikes

Yak shaving gets lumped in with several other focus failures, and the differences matter because the fix for each is different. Google's own results for the term even surface the question of how it relates to bikeshedding. Here is how the common ones line up.

Pattern	What it is	How to tell it apart
Yak shaving	A chain of prerequisite tasks, each required by the last, that pulls you far from the original goal	Every step is genuinely necessary; the problem is the depth of the recursion, not any single task
Bikeshedding	Spending disproportionate time on a trivial, easy-to-grasp detail while the hard, important part goes untouched	The work is not required at all; you do it because it is comfortable and legible, not because it blocks anything
Rabbit-holing	Following curiosity or research far past the point of usefulness	Driven by interest, not by a blocker; the tasks are not prerequisites, they are tangents
Analysis paralysis	Over-deliberating a decision until you make none	You are not doing tasks at all; you are stuck before the first one
Feature creep	Scope quietly expanding past the original intent	Happens to a product or project over time, not to a person in an afternoon

The practical takeaway: if the detour is genuinely required and you have simply gone too deep, that is yak shaving, and the fix is to resurface and re-decide. If the detour was never required, that is bikeshedding or a rabbit hole, and the fix is to stop entirely. Scope that expands over weeks rather than hours is feature creep, which is its own problem with its own defenses.

Productive yak shaving versus the wasteful kind

Not all yak shaving is bad, and the writers who popularized the term are careful about this. Sometimes the yak genuinely needs shaving. If updating that library also fixes a security hole, unblocks three other tickets, and you were going to have to do it this quarter anyway, then the detour produced durable value beyond your immediate goal. You did more than one thing, and the extra things were worth doing.

The distinction is not "did I stray from the plan." It is "did the detour create value that outlasts the task that triggered it." A useful test, when you notice you are a few levels down:

Would I do this task on its own merits, this week, if it were not blocking me right now? If yes, it is probably productive. If the honest answer is "no, I would never otherwise touch this," you are shaving a yak nobody needed shaved.
Is the chain getting shorter or longer? Productive detours resolve; you fix the real blocker and climb back. Wasteful ones fractal outward, each fix revealing two more.
Can I still state the original goal in one sentence without reconstructing it? If you have lost the top of the stack, you have lost the thing that decides whether any of this is worth it.

This is the same discipline as knowing when a task is actually complete rather than endlessly adjacent to complete. A clear definition of done for the original task is one of the best defenses against yak shaving, because it gives you a fixed point to measure every detour against. If the detour does not move you toward "done" on the thing you actually came to do, it is a candidate to cut or defer.

The AI twist: your assistant shaves yaks too

Two things change now that an AI assistant is usually somewhere in the loop, and they pull in opposite directions.

The first is that AI coding agents yak shave with enthusiasm, and faster than you do. Point an agent at a one-line fix and it will cheerfully update dependencies, rewrite adjacent code it decided was untidy, and generate three helper files, each step locally defensible and the sum far past what you asked for. The agent has the same failure mode you do, with none of the fatigue that eventually makes a human look up and ask what they are doing. The accumulated edits are a yak stack you did not descend yourself, which makes it harder to notice and harder to unwind.

The second is subtler. When you get stuck on a prerequisite, an AI can resolve it in seconds, which feels like the cure for yak shaving but is often an accelerant. The friction of a hard prerequisite used to be a natural stopping point, a moment where you might look up and reconsider the whole detour. Remove that friction and you descend further, faster, because every blocker now has an instant answer. You can shave a much taller yak before anything forces you to pause.

The defense is the same in both cases: keep the top of the stack explicit and in front of you, and review what actually happened rather than trusting that it was all necessary. When an agent does the shaving, read its full set of changes against your original one-line intent, the way you would talk a stuck bug through to a rubber duck before accepting a fix. The confident, plausible, slightly-too-much output is exactly where unexamined yaks hide.

How to climb out: make the stack visible

The core problem with yak shaving is not the detour. It is that the stack is invisible, held in your head, and your head quietly drops the top of it. The single most effective fix is to externalize the stack the moment you take the first detour, so the original goal cannot silently fall off. A note does this in about fifteen seconds.

A descending stack of prerequisite tasks from the real goal down to the yak, with a dashed line back to the top showing the climb-out path.

Write down the real goal at the top, then push each detour onto the stack as you take it, one line each:

GOAL: change the retry timeout to 5s   <- the thing I actually came to do

  push: bump http-client to 3.x (old version ignores the config)
    push: 3.x needs node 20 (we are on 18)
      push: node 20 breaks the docker base image
        push: <- I am here. shaving a yak.

Climb-out check:
- Is "change the retry timeout" still worth an afternoon?  [yes/no/defer]
- Does the docker fix help anything besides this?          [yes/no]
- Shortest path back to GOAL from here?

The stack does three things a mental model cannot. It keeps the original goal pinned at the top where losing it is impossible, so you always know what the detour is in service of. It shows you the depth at a glance, and depth is the single best signal that a productive detour has turned wasteful. And because it is written down, it survives the interruption: if you get pulled away and come back, you resume from the stack instead of from scratch, which is the same reason writing down the "why" rather than trusting it to memory beats keeping it in your head.

When you reach a level that fails the climb-out check, you have three honest moves. Cut the whole chain and come back to the real goal with the detour abandoned. Defer the detour by filing it as its own task to do properly later, which is often the right call for the "this really should be fixed, but not right now, not like this" yaks. Or decide the yak genuinely needs shaving today, which is fine, as long as it is a decision you made at the top of the stack rather than a place you drifted to at the bottom.

When shaving the yak is the right call

None of this means detours are bad. Software, writing, and research are full of real prerequisites, and refusing to ever follow one is its own dysfunction. The skeleton-key skill is not avoiding yak shaving. It is doing it deliberately: noticing when you have taken a detour, deciding on purpose whether it is worth it, and keeping the decision reversible by keeping the stack visible.

The afternoons that vanish are the ones where every choice was made at the bottom of the stack, in the narrow light of the immediate blocker, with the real goal long out of view. Kept notes also protect you weeks later, because a detour you fully understood today is just knowledge quietly going stale if you cannot find the reasoning again when the same yak reappears. The next time a one-line change starts to grow a tail, the question is not whether to follow it. It is whether you can still see the top of the stack while you do.

Scribelet is built for exactly this kind of visible thinking: a fast place to pin the real goal, push each detour onto a stack you can actually see, and ask an AI about your own stack without handing it the wheel. The next three-hour yak is coming. The only question is whether you will be able to see it while it happens. Try it free.