Who is your next Agent?

An adventure into the agentic coding landscape of Autumn 2026

· 5 minute read

How are you coding these days? My current solo-project stack is Claude Desktop with Superpowers. (Can I say good ol’ superpowers at this point? It’s been more than a few months). There are so many options now and it feels I might be missing out on something. So I tried to see beyond my own nose and gave a couple of other solutions a spin over the last week or two. I’ll probably compile a more detailed landscape article in the next days / weeks, but here is the gist already.

Starting Point

I went along the same trajectory of agentic coding as most: from advanced auto-complete, to early agent panels, back to terminal coding agents, and now to full-on agentic coding applications. Claude Desktop in my case. I think many made that journey, probably most. Sure, a lot may argue here for terminal only - which I can empathize with, but coordinating multiple subagents I found just so much easier with proper application windows. But these are details that come down to personal preference and flavor. More important is the fact we are now running agents that run a multitude of subagents.

What I was curious about in my recent investigation is: What is the next level? What is the next step equivalent to when we went from advanced auto-complete to agentic coding? What may I be missing out on?

Next: More of the Same

What I found was more of the same. Quite literally: Where claude, codex, opencode provide primarily an interface to communicate with one agent to work on one task the next generation (I tried: Orca, Agent Orchestrator, Paseo) come with interfaces that allow you to work on multiple tasks simultaneously.

On the lower end the tools here behave more-or-less like Claude Desktop: You have multiple sessions, can make use of Git worktrees to work on concurrent tasks. On the upper end you truly feel like the dreaded micromanager: a Kanban-esque interface where your agents scurry to move the work from one stage to the next on remote machines, and you are only involved on the tail ends: spec and review.

From what I can tell you really need “fitting work” to reap the benefits of concurrent agents. For example: working on my local machine on a Rust project I am quite often bound to executing work sequentially, simply because cargo build and cargo test work well executing on different worktrees, yet any single execution will eat my whole CPU just fine. You can try to game the system (e.g. sccache and friends) only so much in my experience.

The hard constraint for productivity at this level is we humans. Whether you parallelize execution or not, you still have to review the spec and plans, you still must be available for in-plan-execution-questions (and yes, they will come, unless you work in a highly synthetic, predictable environment). And yes, you still have to rigorously review the work in the end; faster agents doing more work doesn’t mean their quality improves.

At best you can optimize your workload so that the agents wait only a little, while you alternate between tasks, spec review and code review - but wait they will. How much you can increase your work impact this way, before high-frequency context switching will either spiral your own error rate out of control, or send you into cognitive burn-out, remains to be seen.

Future: More Hope Trust

It’s not flying cars, but bottomless trust (or rather hope) that will power the future. Alas according to what you can find in terms of the next next generation. Welcome to the software factories, or how some call it lovingly: dark factories. Not nefarious at all! Well, the more you read into it, the more you may doubt that last statement. Or that is just me.

The gist is here: You provide goals, not tasks. The agents then go and run with it: They create their own specs and plans, but you are not involved in either their review. Nor would you review code. You review would be behavioral: does it do, does it feel, does it behave as I want it to? You would not need to know much about the implementation anymore. The end goal here is to enable “normal people”, not software developers, to write and maintain software. You are still a decision engine, but at a much higher level than before.

The tools in that realm are currently highly experimental. A big and well discussed candidate is Gas Town. Well, not is but was, as the developer kind of shut it down. The AAIF folks spun up an intentionally extremely transparency-focused clone called Glass Town - it seems I am not the only one finding this scary.

Another, even more experimental looking variant is fabro - just in case you want to give it a swing. I’d appreciate it if you would let me know how that went! I am simply not brave enough to try it myself in earnest.

There is plenty more if you go looking, but there be dragons for sure.

That’s it. I will share the research in a bit.

I’d be very curious to know what you are using and what constraints you are facing?