[{"data":1,"prerenderedAt":104},["ShallowReactive",2],{"blog-back-to-sandstorm":3},{"id":4,"title":5,"body":6,"date":95,"description":96,"extension":97,"meta":98,"navigation":99,"path":100,"seo":101,"stem":102,"__hash__":103},"blog/blog/back-to-sandstorm.md","Back to Sandstorm: Why I'm Abandoning Claude Directly for Multi-Agent Orchestration",{"type":7,"value":8,"toc":86},"minimark",[9,13,20,23,28,31,34,38,41,44,47,51,54,57,60,64,67,70,73,77,80,83],[10,11,12],"p",{},"After a month-long experiment working directly in Claude instead of my own multi-agent orchestration system, I've come to a definitive conclusion: going back to basics actually slowed me down and reduced the quality of my work.",[10,14,15],{},[16,17],"img",{"alt":18,"src":19},"A developer at a fork in the road — one path lit by a multi-agent orchestration dashboard running in parallel, the other a sequential manual-development path marked \"longer, harder, more errors\"","/blog/back-to-sandstorm.png",[10,21,22],{},"For the past month, I made a deliberate choice to step away from Sandstorm, the agent orchestration system I've been building, and return to using Claude directly for my development work. This wasn't a casual decision—I had legitimate reasons for wanting to test whether my custom tooling was actually providing value or just adding complexity. There were some performance issues I'd introduced into Sandstorm that were creating friction in my workflow, bugs that were genuinely blocking me from getting work done efficiently. More importantly, I wanted to validate my hypothesis: was Sandstorm actually making me more productive, or had I just convinced myself it was because I'd invested so much time building it?",[24,25,27],"h2",{"id":26},"the-appeal-of-going-back-to-basics","The Appeal of Going Back to Basics",[10,29,30],{},"The reasoning seemed sound at the time. When you're building developer tools, there's always a risk of over-engineering solutions to problems that don't really exist. I've seen countless engineers fall into the trap of building elaborate frameworks when a simple script would suffice. With over 25 years of experience in software development, I've learned to be skeptical of my own solutions and constantly question whether I'm adding genuine value or just adding layers. So stepping back to use Claude directly felt like the right scientific approach—establish a baseline, gather data, and make an informed decision about whether my custom orchestration system was truly worth the investment.",[10,32,33],{},"During that month, I committed fully to the experiment. I wasn't half-using Sandstorm while dabbling in Claude—I went all in on the direct approach. This meant handling all my development tasks, across all my projects, using Claude's standard interface and tooling. I wanted to give it a fair shot and see if perhaps I'd been overcomplicating my workflow. After all, if Claude could handle everything I needed efficiently on its own, then continuing to develop and maintain Sandstorm would be wasted effort that could be better spent on other projects.",[24,35,37],{"id":36},"the-reality-of-single-threaded-development","The Reality of Single-Threaded Development",[10,39,40],{},"What I discovered over that month was eye-opening, but not in the way I expected. The most significant issue wasn't about individual task completion—Claude is perfectly capable of helping solve specific programming problems. The real problem was parallelization, or rather, the complete lack of it. When working directly in Claude, I found myself constantly being the bottleneck in my own development process. The system would ask me for tool usage permissions, present me with choices about implementation approaches, and generally require my active participation in ways that prevented me from spinning up multiple workstreams simultaneously. Even when using auto mode, which theoretically reduces the need for constant interaction, I still found myself hand-holding tickets from inception through to completion far more than I had with Sandstorm.",[10,42,43],{},"This created a fundamental shift in how I could work. With Sandstorm, my typical workflow involved spinning up ideas and having agents work on them asynchronously in the background while I focused on higher-level thinking or moved on to other tasks. I could have multiple agents working on different aspects of different projects, all progressing simultaneously without requiring my constant attention. But with Claude directly, I was locked into a serial workflow—one task, one conversation, one thread of execution at a time. If I wanted to work on multiple things, I had to resort to clunky workarounds like opening multiple browser tabs, which made it incredibly difficult to visualize progress across my various workstreams. This isn't an efficient way to work when you're managing multiple simultaneously running agents across several projects.",[10,45,46],{},"The cognitive load increased dramatically as well. Instead of delegating work to autonomous agents that followed established workflows and quality checks, I became the orchestrator who had to manually guide every single piece of work through to completion. This meant I was spending mental energy on coordination and task management rather than on the actual creative and architectural work that requires deep thinking. For someone who's spent years building systems to automate repetitive tasks and reduce cognitive overhead, this felt like a massive step backward. The work didn't just slow down Sandstorm development—it slowed me down across the board on all my projects.",[24,48,50],{"id":49},"the-quality-problem","The Quality Problem",[10,52,53],{},"Beyond the productivity hit, I noticed something more insidious: quality degradation. This surprised me initially because I assumed that more direct involvement in the development process would naturally lead to higher quality outcomes. The opposite turned out to be true. The issue stems from how Claude interacts with workflows when you're using it directly versus through a structured orchestration system. When I tell Claude to start a ticket directly, it sometimes uses the proper tools and workflows I've established, but other times it cherry-picks what it wants out of the available skills and shortcuts the process. This inconsistency means that important checks and balances get bypassed unpredictably.",[10,55,56],{},"In Sandstorm, the review iterations are built into the workflow. Code doesn't just get written and committed—it goes through standardized quality checks, automated reviews, and validation steps that ensure consistency and catch potential issues before they become problems. These aren't just bureaucratic processes for the sake of process; they're guardrails that have evolved from years of experience building production systems. When Claude bypasses these workflows because I'm interacting with it directly, those guardrails disappear. The result is code that might solve the immediate problem but doesn't maintain the same standards of quality, consistency, or long-term maintainability that the structured Sandstorm workflows enforce.",[10,58,59],{},"This quality issue compounds over time. One ticket with slightly lower standards doesn't break anything, but when that becomes the pattern across multiple tickets and multiple projects, you start accumulating technical debt and inconsistencies that will eventually need to be addressed. As someone who's been building software for over 25 years, I know that the cost of fixing quality issues later is always higher than preventing them in the first place. The short-term speed gains from skipping workflow steps get erased by the long-term costs of dealing with the consequences.",[24,61,63],{"id":62},"coming-full-circle","Coming Full Circle",[10,65,66],{},"This experiment has reinforced something I already knew intellectually but needed to experience viscerally: multi-agent orchestration isn't just a nice-to-have feature for working with AI—it's fundamental to productive software development in the age of AI assistants. The original intention behind Sandstorm was exactly this: enabling efficient multi-agent orchestration where multiple autonomous agents could work on different tasks simultaneously while maintaining quality standards and reducing the cognitive load on the human developer. That vision remains valid, and stepping away from it for a month has only strengthened my conviction that it's the right approach.",[10,68,69],{},"The key now is addressing the inefficiencies that drove me to step away in the first place. The bugs and slowdowns I introduced into Sandstorm are fixable problems, not fundamental flaws in the architecture. By identifying what wasn't working and understanding exactly how it was impacting my workflow, I'm now in a better position to make targeted improvements. I know what needs to be optimized, what workflows need to be streamlined, and where the friction points are that prevent Sandstorm from delivering on its full potential.",[10,71,72],{},"I'm recommitting to Sandstorm development with fresh eyes and validated conviction. The experiment wasn't wasted time—it provided crucial data about what happens when you remove the orchestration layer and try to work directly with AI tools. That data confirms that the orchestration layer provides real, measurable value in both productivity and quality. Now it's about refining that layer, removing the inefficiencies, and getting Sandstorm to the point where it consistently enables the asynchronous, multi-threaded development workflow that I know is possible.",[24,74,76],{"id":75},"the-broader-implications-for-ai-assisted-development","The Broader Implications for AI-Assisted Development",[10,78,79],{},"This experience has broader implications for how we think about AI in software development. There's a temptation to view AI coding assistants as direct replacements for human developers, where you just interact with the AI conversationally and it produces code. That model might work for simple, isolated tasks, but it breaks down when you're managing real-world software projects with multiple moving parts, quality requirements, and the need for parallel work streams.",[10,81,82],{},"The future of AI-assisted development isn't about having one super-intelligent AI that you chat with—it's about orchestrating multiple specialized agents that can work autonomously on different aspects of your projects while maintaining consistency and quality through structured workflows. This requires building systems and tooling specifically designed for multi-agent orchestration, not just using general-purpose chat interfaces. As AI continues to transform the software development lifecycle, the developers who will be most productive are those who learn to orchestrate multiple AI agents effectively, not those who become really good at prompting a single AI assistant.",[10,84,85],{},"My month away from Sandstorm taught me that the problem I'm solving is real and valuable. The challenges I faced working directly in Claude—the serialization of work, the increased cognitive load, the quality inconsistencies—these aren't unique to me. They're fundamental challenges that every developer will face as they try to integrate AI into their workflows. Building robust orchestration systems that address these challenges isn't optional; it's essential for unlocking the full potential of AI in software development.",{"title":87,"searchDepth":88,"depth":88,"links":89},"",2,[90,91,92,93,94],{"id":26,"depth":88,"text":27},{"id":36,"depth":88,"text":37},{"id":49,"depth":88,"text":50},{"id":62,"depth":88,"text":63},{"id":75,"depth":88,"text":76},"2026-05-28","After a month-long experiment working directly in Claude instead of my own agent orchestration system, I'd become a serial bottleneck in my own workflow — and the quality guardrails I'd built into Sandstorm quietly disappeared along the way. Here's why I'm recommitting to multi-agent orchestration.","md",{},true,"/blog/back-to-sandstorm",{"title":5,"description":96},"blog/back-to-sandstorm","gDK88Z6ujG_kDAlcynj9BPcYvFBmFb0qMPICgTcxUCE",1779974390969]