Superset — When One Coding Agent Is No Longer Enough

For the past year, most of my AI-assisted development workflow has revolved around a simple relationship: one developer, one coding agent, one task. I describe what I want, the agent explores the repository, edits files, runs tests, and hands the result back to me.

That already feels dramatically different from autocomplete. But a new category of tools asks a different question: what if several agents could work at the same time?

Superset is one of the clearest examples of that idea. It is not another foundation model and it is not trying to replace Claude Code, Codex, Gemini CLI, or the editor I already use. It sits above them, creating isolated workspaces, launching agents, and giving me one place to track and review their work.

The interesting part is what this category says about where software development with AI may be heading.

AI-generated image via Google Gemini

Table of contents

From pair programming to orchestration

The first generation of AI coding tools fit naturally into the pair-programming metaphor. The AI might write most of the code, but there is still one active stream of work. While it fixes a failing test, the documentation update and the unrelated UI bug wait.

Running several terminal sessions manually is possible, but it becomes messy quickly. Each agent needs the right branch, environment, dependencies, and context. Two sessions editing the same working directory can overwrite one another. Even if the code remains safe, remembering which agent is doing what creates exactly the context-switching overhead the tools were supposed to remove.

Orchestration tools turn those sessions into independent workstreams. The developer’s job becomes less like pair programming and more like running a small engineering team — except the workflow must keep every contributor isolated and visible.

What Superset actually does

Superset describes itself as an open-source platform for running AI coding agents in parallel. The important word is platform. It does not provide the intelligence itself; it provides the environment around it.

I can connect a repository, create a workspace for a task, and choose the agent I want to run inside it. Because Superset supports CLI-based agents, I can use Claude Code for one task, Codex for another, or keep the same agent everywhere.

Each workspace has its own terminal, branch, files, and agent session. Superset brings workspace status, code changes, commits, CI checks, and pull requests into one interface. Its diff viewer handles quick reviews, while IDE integration remains available for closer inspection.

This distinction matters. An agent answers the question, “Can this task be completed?” An orchestrator answers, “How do I run, isolate, observe, and review several of those tasks without losing control?”

Git worktrees are the quiet foundation

The enabling technology behind this workflow is not new or AI-specific. It is git worktree.

A worktree lets one Git repository expose several working directories, each attached to its own branch. One can contain a feature while another contains a bug fix, without repeatedly stashing changes or switching branches.

Superset maps that concept directly to its interface: one branch becomes one isolated workspace. An agent can modify files and run commands there without touching the workspace used by another agent.

Worktrees prevent agents from overwriting one another while they run, but they do not eliminate merge conflicts or incompatible decisions. Task selection matters more than agent count. Documentation, a flaky test, and a UI prototype can probably run independently; splitting one tightly coupled database migration across five agents will likely create more work than it saves.

Superset is part of a wider shift

Superset is not alone in seeing orchestration as the next layer of the coding stack.

Conductor follows a similar worktree-based model. The Codex app also manages parallel tasks, but integrates the agent and orchestration experience while Superset remains agent-agnostic. Lighter alternatives use terminal multiplexers, scripts, or hand-managed worktrees. The pattern remains consistent:

1. Turn a request into a clearly scoped task.
2. Give that task an isolated branch and working directory.
3. Run an agent inside the workspace.
4. Surface the result in a review queue.
5. Keep the human responsible for acceptance and integration.

Where parallel agents genuinely help

Parallelism is most useful when tasks are independent, well specified, and easy to verify.

A small release is a good example. One agent can update dependencies, another can add tests, and a third can investigate a UI regression while I focus on an architectural change.

Parallel work also makes experimentation cheaper. I can ask two agents for different approaches, compare their branches, and discard either attempt without disturbing my main workspace.

But ten agents do not produce ten times the output. They consume CPU, memory, API limits, and tokens. Test suites compete for resources, servers need separate ports, and ignored environment files must be recreated safely. Superset organizes these constraints; it does not remove them.

The bottleneck moves to review

When code generation becomes parallel, human attention does not.

Five agents finishing together produce five separate claims that something works. Review becomes the limiting factor. A green test suite cannot tell me whether an agent solved the right problem, introduced unnecessary complexity, or quietly changed product behaviour.

The temptation is to trust the summary instead of the implementation. To avoid that, every task needs a clear definition of done: tests to run, behaviour in scope, and constraints that must not change. Good specifications, automated tests, CI, and small diffs become more important, not less.

A practical workflow I want to test

The workflow I find most convincing is deliberately conservative:

1. Start with two or three independent tasks, not an army of agents.
2. Give each task a narrow scope and an observable success condition.
3. Use a separate worktree and branch for every task.
4. Let agents implement and verify their changes independently.
5. Review each diff before merging anything.
6. Integrate branches one at a time and rerun the full test suite after each merge.

This preserves control while gaining wall-clock time. If the real bottleneck is an unclear product decision or difficult review, more agents will only create a larger queue of uncertain work.

The operating system around the model

For a long time, discussions about AI coding focused almost entirely on models: which one writes the best code, has the largest context window, or scores highest on a benchmark. Those differences still matter, but they are no longer the whole story.

As agents become capable enough to complete meaningful tasks, the surrounding system matters more: isolation, permissions, testing, review, and integration. Superset treats the agent as one replaceable worker inside that larger system.

I am not convinced that every developer needs ten agents running at once. I am convinced that managing multiple independent agent sessions is a real problem, and Git worktrees provide a surprisingly solid foundation for solving it.

The future may look less like one perfect model and more like specialised agents working across isolated branches, while the developer decides what can run independently and what is good enough to merge. That is less magical than “an AI builds the whole application,” but much closer to how reliable software gets made.

Next time, I will step away from coding agents and show something more concrete: the personal infrastructure behind my DNS servers, how I deploy it, and the choices that keep it reliable.

Thanks for reading. If you are already running several coding agents in parallel — or have found that one is more than enough — I would love to hear how your workflow differs, via email or LinkedIn.

See you in two weeks.