Why I’m Abandoning Claude Code and Going Back to Sandstorm

For the past month, I did something that might seem counterintuitive for someone building a multi-agent orchestration system. I stepped away from Sandstorm, the agent orchestration platform I’ve been developing, and went back to working directly in Claude Code. This wasn’t a casual decision — it was a deliberate experiment to test whether Sandstorm was actually providing value or if I was just building something because I could. After 25 years of software engineering, I’ve learned that sometimes you need to step back from your own creations to see if they’re solving real problems or just adding complexity.

The Motivation Behind the Switch

I had legitimate reasons for this experiment. There were some slowdowns I had introduced into Sandstorm that were causing friction in my workflow, legitimate bugs that were blocking me from being as productive as I wanted to be. These weren’t catastrophic failures, but they were the kind of paper cuts that accumulate throughout a day and make you question whether the tool is helping or hindering. Rather than immediately diving into fixing these issues, I wanted to answer a more fundamental question: was I actually getting any benefit from Sandstorm, or was I just experiencing the sunk cost fallacy of a builder too attached to their creation?

So I committed to working exclusively with Claude Code for a full month across all my projects. I wanted to give it a fair shot, not just a few days where I might be biased by the frustration of switching contexts. I approached it the same way I’ve approached technical decisions throughout my career — with genuine curiosity and a willingness to be proven wrong about my assumptions. If Claude Code turned out to be sufficient for my needs, then maybe Sandstorm was solving a problem that didn’t really exist.

What I Discovered About Parallelization

The first major issue I encountered was the inability to parallelize my work efficiently. Now, to be fair, you can run async jobs in Claude Code — it’s technically possible. But here’s the thing: it’s not very clean, and it’s not very organized. The lack of structure around parallel work dramatically increases cognitive load in ways that aren’t immediately obvious until you’re living with it day after day.

When you’re working directly in Claude Code, you’re essentially operating in a single-threaded conversation by default. You ask for something, the AI responds, you review it, you iterate, and then you move to the next thing. Sure, you can try to parallelize by spinning up multiple conversations or async jobs, but the interface isn’t designed for that kind of orchestration. You end up juggling multiple threads without a clear way to track their status, coordinate their outputs, or manage dependencies between them. This might work fine if you’re tackling one focused task at a time, but that’s not how I work, and I suspect it’s not how most productive engineers work either.

In my normal workflow with Sandstorm, I’m spinning up ideas and having agents work on them asynchronously in the background. The key difference is that I do all the work and planning up front — everything gets captured in the ticket. I might start three or four different tickets across different projects, each one progressing independently while I focus my cognitive energy on the strategic decisions and architectural choices that actually require human judgment. Then, when the agents complete their work, it’s much easier for me to take the ticket and verify the output. All the context is there, all the decisions are documented, and I can quickly validate whether the work meets the requirements I specified.

With Claude Code, even when running async jobs, I found myself constantly juggling the orchestration itself. Instead of doing the cognitive work once — up front in the ticket — I was maintaining mental state across multiple unstructured conversations. The system still requires a significant amount of hand-holding to take work through to completion, and tracking multiple parallel efforts becomes an exercise in tab management and mental bookkeeping. It’s just not an efficient way to work when you’re trying to coordinate multiple agents across different projects.

This serialization — or inefficient parallelization — of work had a cascading effect on my productivity across all my projects. It didn’t just slow down Sandstorm development; it slowed me down across the board. The kind of exploratory work I love doing, where I can test multiple approaches simultaneously and see which one yields the best results, became almost impossible without Sandstorm’s organizational structure.

The Cognitive Load Problem

Beyond the parallelization issues, I noticed something more insidious: the dramatic increase in cognitive load. When you’re manually orchestrating multiple conversations or async jobs without a proper coordination layer, you’re forced to maintain much more context in your working memory. You can’t offload the routine work to autonomous agents and focus on the high-level thinking. Instead, you’re constantly making micro-decisions about which conversation to check next, what state each job is in, and how different pieces of work relate to each other.

The difference with Sandstorm is stark. Because all the planning and specification happens up front in the ticket, I can hand off the work to an agent and trust that it has everything it needs to execute. My cognitive energy goes into thinking deeply about the problem, designing the solution, and specifying the requirements — all valuable uses of my time. Then I can step away and let the agent work. When I come back, the ticket contains both my original specifications and the completed work, making verification straightforward and efficient.

With Claude Code, even when using async capabilities, this clean handoff doesn’t exist. I found myself opening multiple tabs to try to visualize and track different conversation streams, but it simply isn’t designed for orchestration — it’s designed for conversation. That’s fine for many use cases, but when you’re trying to manage complex software development across multiple projects, the conversational paradigm breaks down. You need visibility, you need state management, and you need the ability to coordinate multiple agents working toward different goals without becoming the bottleneck yourself.

The irony is that I built Sandstorm precisely to solve this problem, and stepping away from it reminded me viscerally why it needed to exist in the first place. Sometimes you need to experience the pain point again to fully appreciate the solution you’ve built.

Quality Degradation Through Bypassed Workflows

The slowdown and increased cognitive load weren’t the only issues — I also noticed a degradation in code quality. Because of the way I interact with Claude Code directly, the AI has the ability to bypass workflows that I’ve carefully designed in Sandstorm. For instance, if I tell it to start a ticket, it will sometimes use the tool properly and sometimes cherry-pick what it wants out of the skill. This cherry-picking can bypass important checks and balances that exist for good reasons.

In Sandstorm, I’ve built in review iterations that help improve the overall quality of what’s produced. There are standardized workflow and ticket quality checks that ensure consistency and catch issues early. These aren’t bureaucratic obstacles — they’re the accumulated wisdom of 25 years of software development, codified into repeatable processes. When you work directly in Claude Code without these guardrails, you lose that quality assurance layer. The AI is incredibly capable, but it doesn’t have the context of your broader quality standards unless you explicitly prompt for them in every single conversation.

I noticed this particularly in edge case handling and error checking. The Sandstorm workflows would catch scenarios where error handling wasn’t comprehensive or where assumptions were being made that hadn’t been validated. Working directly in Claude Code, these issues would slip through more frequently because I was focused on the immediate task rather than the holistic quality of the codebase. The front-loaded planning in Sandstorm tickets naturally surfaces these concerns before the work begins, whereas the conversational flow in Claude Code tends to privilege forward momentum over comprehensive consideration.

The Path Forward

All of this brings me back to where I started: Sandstorm. I’m now focused on working through the inefficiencies that initially drove me to experiment with Claude Code. The goal is to get Sandstorm back on its feet and really delivering on its original intention — multi-agent orchestration that allows for asynchronous, parallel work without sacrificing quality.

The inefficiencies I identified are real and need to be addressed, but the solution isn’t to abandon the orchestration paradigm. The solution is to fix the bugs, optimize the workflows, and build the tool I actually need. This is the builder’s journey: you create something, you stress-test it, you identify its weaknesses, and you iterate. The fact that going back to Claude Code — even with its async capabilities — was more painful than working with a buggy version of Sandstorm tells me that I’m solving a real problem, not an imagined one.

The key insight from this experiment is that it’s not just about whether you can run things in parallel — it’s about how cleanly and efficiently you can do it. Claude Code gives you the raw capability but not the organizational structure. Sandstorm provides both the capability and the framework to make parallel agent orchestration actually usable at scale.

What This Means for AI-Assisted Development

This experience has reinforced my belief that the future of software development isn’t just about having conversations with AI assistants — it’s about orchestrating multiple AI agents to work asynchronously on different aspects of complex problems with proper coordination and oversight. The conversational paradigm is powerful for certain tasks, but it doesn’t scale to the kind of parallel, multi-project work that characterizes modern software development without additional organizational layers.

We need tools that treat AI agents as team members that can work independently with clear specifications, not as assistants that require constant supervision or manual coordination across unstructured conversations. We need orchestration layers that provide visibility, enforce quality standards, and allow humans to focus on the strategic decisions — the up-front planning and verification — rather than the tactical execution and coordination overhead. This isn’t about removing humans from the loop; it’s about positioning humans where they add the most value.

My month-long experiment wasn’t wasted time. It validated the core premise of Sandstorm and gave me clarity about what needs to be fixed. Sometimes the best way to appreciate a solution is to experience the problem again with fresh eyes. Now I’m back to building, with renewed conviction about why this work matters and a clearer understanding of the specific value Sandstorm provides: not just parallel execution, but organized, efficient, low-cognitive-load parallel orchestration.