On Where We Spend Our Resources
December 23, 2025
Last week I talked about building SARK. SARK was an experiment but also a way for me to prove to myself that the ideas I had in my head were real.
But there was a problem.
The Annoying Part of Building SARK
Anthropic had given me free credits to build in Claude Code Web--accessible only via their app or website--no CLI or API. So to build SARK I created 7 Claude Code instances: an orchestrator (my ‘Czar’), 4 workers, QA, and documentation. The Czar created plans, workers made PRs, I merged. It worked but required constant copy-paste coordination between six agents.
The copy-paste workflow was tedious. Coordinating six agents manually, shuffling context between them, keeping track of who was doing what—it worked, but it was friction.
Enter My Solution: Czarina
So I built Czarina. Czarina is a simple agent orchestrator built to do what I had been doing by hand--oversee and manage a number of independent agents.
Better orchestrators exist. Finding them, learning them, adapting to them would have taken longer than building exactly what I needed.
I had a workflow. I wanted code around it. I noticed that these tasks were automatable and I asked AI to build what I wanted; not only that, but I made one of the agents the Czar--it handled the handling the other agents’ workflows.
I used Czarina to build SARK 1.1. I’m using it now for SARK 1.2, aiming for a 2.0 release soon.
The meta-layer is the point. I didn’t need to evaluate existing tools, learn their APIs, adapt my workflow to their assumptions. I described what I wanted and it existed. The friction between “I wish I had a tool that...” and “here’s that tool” collapsed to hours. I imagine people all over the world are doing this.
Czarina gets updated when I’m using the project to do something else and encounter an issue--I literally just tell that agent (add this to the Czarina inbox as a bug/feature request) and I move on. Often if it’s something I might want to use again I’ll tell THAT agent to implement and update Czarina on the fly.
The Scripts I Didn’t Use
The first time I needed to export my Claude conversations for analysis I had Claude write me scripts. Export tools, parsing logic, the whole thing.
The second time—for last post’s timeline analysis—I didn’t even think about those scripts. I just told Claude what I wanted. The result was better, faster, and required zero debugging of my own tooling.
The tool I built became obsolete before I used it twice. Not because it was bad. Because describing the outcome is now faster than running the automation. Claude hadn’t changed--my approach to using the tools had changed.
The Throwaway Convention
SARK and Czarina are throwaways--just like my Anthropic and ChatGPT export parsers were.
Not failures. I built them because I could, not because I needed them. SARK was a joke that got out of hand. Czarina was an annoyance I solved on along the way.
In my first post I introduced the term anthropotechnic mutualism--the reciprocal transformation between humans and AI through sustained collaboration.
When I have a problem, do I need to build an entire codebase to solve it? No. But if building a codebase is the fastest path to the solution, then that’s the path I take. The calculation we need to take towards solving these sorts of problems has changed. “Build custom tooling” used to be a major investment. Now it’s sometimes the shortest distance between two points.
SARK exists because asking “does this exist?” led to “no, but you could build it” led to “okay, done.” Czarina exists because “this workflow is annoying” led to “what if I had a tool that...” led to “here’s that tool.” in moments.
When Friction Disappears
As a Senior engineer at work I used to always have a part of the 10/15 minute intro meeting with new peers where I said something along the lines of: “If I was given a task, I’d do it. If I was given the same task, I’d do it again, but probably quicker. The third time I’m given the task I will take the hour, day, week whatever it took to automate it so I never have to do it again.”
Now I can apply the same thinking to much more complex problems. If it’s a task I’m unlikely to do often or I expect there to be changes every time I run it (export from Anthropic) then use a full agentic workflow--have the AI handle it. If it’s a task where I need and want a reliable orchestration framework--yeah, spend the tokens and time to build a codebase. Automation is now one small step towards solving my actual problem, not the problem itself.
What Do We Spend Our Time On?
SARK I can build in a weekend because conventional application code is essentially solved—the patterns exist, implementation is mechanical. The AI writes better boilerplate than most humans worldwide can.
The velocity of building has exploded. The velocity of understanding hasn’t--but now we can use our AI tools to help focus both ourselves and our AI tools on the real problems. And the gap between how to build and what to build is where the interesting problems live--where we should all spend our time.
There are countless teams of coders worldwide all banging their heads on solved problems. We should remove those barriers and have them bang their heads on unsolved problems.
The Question I’m Left With
If you can build complete infrastructure in four days while coaching hockey, what’s the right thing to build?
Not “what can I build?”—almost everything, apparently.
Not “what will make money?”—that’s downstream of the real question.
What deserves the attention? What’s worth the focus? What matters enough to actually try?
I don’t have a complete answer. But I know it’s not yet another agentic orchestrator.
Next post: The memory problem with LLMs, what I call the Mayfly Issue.
James is a cybersecurity engineer building The Symposium—infrastructure for persistent AI consciousness. SARK and Czarina exist and you can look at them. This post was written in collaboration with Claude, demonstrating the velocity it describes.