Yaks All the Way Down

Seth Godin wrote about yak shaving back in 2005. The idea: sit down to wax the car, but first need a hose. The hardware store is across the bridge. The bridge needs an EZPass. The neighbor's EZPass requires returning a borrowed pillow. The pillow needs new stuffing. The stuffing is yak hair.

So there you are, shaving a yak. Twenty-one years later, the yaks have learned to code.

I sat down to build an agent orchestrator

The project was clear enough. Multiple AI agents coordinating on tasks. One plans, one builds, one reviews.

But I need to see what they're all doing. So I need a monitoring dashboard. The dashboard needs real-time updates, so I need server-sent events. The events need to fire from Claude Code, so I need lifecycle hooks. The hooks need to capture state transitions reliably, so I'm learning how tmux session management actually works. Tmux needs to talk to iTerm2, so I'm deep in AppleScript and terminal multiplexer integration.

I sat down to build an agent orchestrator. I'm debugging tmux send-keys.

That's a yak.

Dependency chains at every layer

This isn't one bad morning. This is the shape of building with AI right now.

Want agents to report their progress? First, build hooks. But hooks need somewhere to send data, so build a server. The server needs to push updates to a browser, so set up SSE. The browser needs a dashboard, so build a frontend. The frontend needs to send commands back to agents, so now you're piping keystrokes into tmux sessions from a web app.

Want to know which agent needs your attention? Build a priority scoring system. The scoring needs context about what each agent is doing, so feed it summaries. Summaries need an LLM call, so build a summarisation pipeline. The pipeline needs to handle rate limits and failures gracefully, so build retry logic and fallback chains.

Yaks, all the way down.

AI made the yaks faster, not fewer

AI-assisted development delivers on its promise of speed. Code generation is fast. Feature assembly is fast. The gap between idea and working prototype has collapsed. And the bugs that come with that speed don't announce themselves until the prototype hits reality.

But the yak problem operates at a different level. AI generates code in minutes that would have taken days. Then that code sits waiting while three layers of infrastructure beneath it still need building. The bottleneck moved from "write the code" to "build everything the code depends on."

Same pattern as the PoC graveyard. The demo is the easy part. Everything the demo needs to survive contact with production is where the yaks live.

Which yaks actually block production

Godin's original point was about discipline. Stop the chain reaction early. Accept compromise. Ship the imperfect version.

Twenty-one years later, the principle holds. When the tooling doesn't exist, the temptation is to build it. When the framework is missing a feature, the temptation is to fork it. When the integration isn't clean, the temptation is to write the integration layer from scratch.

Each one feels productive. Each one is shaving a yak.

The discipline is knowing which yaks stand between the work and production, and which ones stand between the work and an ideal that only exists in the builder's head. Some infrastructure is genuinely missing. Some of it is perfectionism wearing a hard hat. A spec-driven process like OpenSpec helps draw the line. If the yak isn't in the spec, it's not blocking production; it's blocking the ideal.

Before picking up the clippers: is this yak blocking the work, or blocking the version of the work that lives only in my head?

The answer changes what gets built next.