The Builder's Dispatch

**200,000 tokens vs. 1.2 million.** For surprisingly similar results. That was the outcome of a practical comparison by Chase Levin in his video **"GSD vs Superpowers vs Claude Code"**. Heavy orchestration layers versus the lightest baseline system. I found the result interesting, but not surprising: the lightest setup was much faster, much cheaper, and qualitatively much closer to the heavier setups than many people would expect. I wrote about **Spec Theater** a while ago. That pattern where teams react to weak agent results with more of everything: more specs, more phases, more meta-prompts, more orchestration. The assumption behind it is simple: **more structure = better outcomes** I think that assumption is often flipping into the opposite. Because structure has a cost: - time - tokens - attention - slower feedback loops And if that structure does not clearly earn its value, it stops being system design and starts becoming theater. This also fits with something Anthropic has been hinting at for months: when customers get poor results from agents, the problem is often not too little steering, but too much of it. Too many instructions. Too many constraints. Too much early railroading. At that point, the agent no longer gets more orientation. It gets less room to solve the problem. And for me, that connects to an even more important point: **AI does not decide. It opens the space.** That is not just intuition. It also fits what we see in practice and in research on search spaces, constraints, and LLM behavior: too many constraints do not automatically help. At some point they simply reduce the space in which the system can still work meaningfully. The key is not to strangle every decision in advance with more specification. The key is that I, as the human, can **iterate quickly and effectively**: - see my guidance reflected quickly - validate outputs quickly - correct assumptions quickly - steer direction quickly Not maximum upfront control. But fast, high-quality feedback. That is why I think the real design question is not: **How do we add more orchestration?** It is: **How do we build systems that raise structure only when complexity, risk, or ambiguity actually justify it?** That is the direction I am designing toward now. **Adaptive systems instead of permanent structure.** More on that soon.