Something interesting happened when Garry Tan's Claude Code configuration started circulating. Half the room called it brilliant. The other half called it over-engineered nonsense. Both camps were confident.
That split is the story.
The Jig Analogy
A woodworker's jig is a custom-built guide that makes a specific cut precise and repeatable. A good jig is a minor miracle of accumulated knowledge — it encodes the exact angle, the specific wood, the particular saw. It works perfectly. And if you take it to a different workbench, it probably doesn't fit anything you're cutting.
An elaborate CLAUDE.md config is a jig. The Get Shit Done system — with its meta-prompting layers, spec-driven development workflow, and multi-stage context orchestration — is clearly the product of someone who has thought hard about how they work, what their codebase demands, and how they want an agent to behave. That's valuable. That's craft.
But here's what I keep coming back to: the people who hate it aren't wrong either. They're not miscalibrated or unsophisticated. They're looking at a jig that doesn't fit their workbench and correctly noticing that it doesn't fit.
The controversy isn't a verdict on the quality of the system. It's a verdict on portability.
The Real Signal
What caught my attention is that this isn't an isolated event. Two elaborate spec-driven development systems surfaced in practitioner discussion within the same week, and both generated the same love/hate split. That's not coincidence — that's a pattern.
The community is in a phase where it's collecting context engineering systems the way an earlier generation collected GTD implementations. Sharing them, reacting to them, arguing about them. Which is fine, except there's a category error baked into the practice: people are treating CLAUDE.md configs as methodologies that can be evaluated and adopted, when they're actually calibrated instruments that only make sense in the context they were built for.
A method can be taught. An instrument has to be built to fit.
The disagreement isn't noise to be resolved by better explanation or more nuanced HN discussion. It's the accurate signal that context engineering is a deeply personal practice — more like a coding style than a framework, more like handwriting than typography. You can learn from looking at someone else's system. You probably shouldn't install it.
What I haven't figured out yet: whether this is a temporary problem (the field is early, shared primitives will emerge) or a permanent one (the codebase specificity is inherent, and "shareable context engineering" is a category error full stop). I'm leaning toward the latter, but I'd want to be wrong. A transferable methodology would be genuinely useful. I'm just not sure the thing being shared is actually transferable.
The jig fits one workbench. Building your own is probably the point.