The Slippery Slope to Agentmaxxing
More parallelism, more problems
By Travis Knoche and Gus Lipkin
We have been using herdr quite a bit, and comparing it against three other ways of running and managing coding agents: plain Claude Code in a VS Code terminal, Ghosthub from Kenn Software, and the Claude desktop app. The comparison keeps bringing us back to one number: how many diffs we can read in a day.
herdr’s Easy Win
herdr is a terminal multiplexer built for coding agents. It can run as a background server, so agents keep working when you close the client or drop your SSH connection, and every pane is marked as working, blocked, or idle. It also puts remote boxes in the same window as local ones, with a combined agent list. Adding a machine is one command, copied from the homepage:
herdr machine add workbox
Ghosthub sits one layer up.
It is a native Mac terminal (alpha, Apple Silicon, macOS 15+, though Wes, creator of pandas, promised Jared that Windows is coming soon) that opens tmux, herdr, and Zellij sessions on your computer and on SSH hosts, reconnects after dropped connections, and manages Git worktrees from a sidebar.
Claude Code in a VS Code terminal is the low end of the range, with one session, or however many you split-pane, sitting next to the editor’s diff view. It’s barebones and good for a single simple project, but that’s not a very realistic, let alone productive setup.
Each step up that range removes friction from starting another agent. Once the fifth session costs the same keystrokes as the second, you’re more likely to start it. Then you start a sixth, because you have a pane sitting idle and you might as well ask that lazy agent to do something.
The Debt
Starting an agent got cheap, but reading diffs costs the same as it always did. When agents write faster than you can read, the gap fills with code that nobody on the team has read, or wants to read. Ordinary technical debt has an author you can ask. Here the author was a session that has since been compacted or closed, and the person whose name is on the commit cannot explain the logic either. Although we’ve all known that feeling even for code we wrote by hand after a caffeine-fueled moment of genius, it’s different when all your code is written that way.
You no longer know what is happening in a project: which features exist, what the service promises its callers, where the data goes. Answering a basic question about your own product then means asking an agent to summarize the entire repo and not just that one coffee driven feature. The issue here isn’t that you need a reminder like you would with something you wrote by hand and forgot about, it’s that you never knew what the code did in the first place.
Each multiplexer brings its own session model and its own config, and a half-migrated setup is an easy place to lose track of a branch.
The Guardrails
The cap on concurrent agents is your review rate. Count the diffs you can read properly in a day and work backward. The rule that enforces this is that an agent gets no new task until you have read its last diff. An idle marker in herdr’s agent list then means “waiting on me to read,” and the pane stays idle.
Give each agent its own worktree and pull request. Each diff then stays small enough to read in one sitting, and one agent’s changes never end up tangled in another’s. Merging stays with a human. Branch protection that requires human approval keeps that true on the days you are tired, and it ends the cases where Claude apologizes for committing to main or merging without permission. Ensuring proper branch permissions is part of our Agentic SDLC offerings.
Reviewing means reading every changed line. If you cannot explain a hunk to a colleague without opening the agent’s transcript, it does not merge. Give agents tasks sized to fit one sitting of review. A review agent such as Roborev is a useful extra pass for catching bugs, but it leaves you knowing exactly as little about the code as before.
Most repos already have a file that says what the project does: the README, or a CLAUDE.md or AGENTS.md the agents read at the start of every session. It is tempting to let the agents keep it current too. Write the parts that cover features, interfaces, and where data lives yourself, and update them by hand when a pull request changes them. If you cannot write the update, you did not understand the diff.
No matter how many agents you have running, there are some kinds of work that should not go to an agent you are not watching. Our list includes secrets and credentials, anything under IAM or Kubernetes RBAC, database migrations and anything else that discards data, CI workflow definitions and deploy pipelines, and Ansible playbooks that run against production inventory. A plausible-looking mistake in any of those is expensive and hard to reverse. Write them yourself, or pair with a single agent and watch every edit.
Treat herdr machine add as a permissions decision. An agent on a remote box runs with whatever that box can reach. Before adding a host, list the credentials, mounts, and network routes on it, and add it only if you trust handing all of that to an agent you are not watching.
The last rule covers the tools themselves. Before adopting the next multiplexer, write down which constraint it removes. herdr and Ghosthub remove the cost of switching between sessions and machines, but reading speed stays the same. If your constraint is review time, skip the install and spend the hour clearing your queue of unread diffs.
Travis Knoche
Senior Data Scientist
Lander Analytics
Gus Lipkin
Data Scientist
Lander Analytics
Subscribe to our Substack and below to our monthly emails for practical AI strategies for your organization: what to build, what to avoid, and how to make systems reliable in the real world.
Work with us: If you want help identifying the right first workflow, building a permissioned knowledge base, or training your team to ship responsibly, reach out at info@landeranalytics.com.
About the authors:
Travis Knoche is a Senior Data Scientist at Lander Analytics, where he designs, deploys, and maintains data science infrastructure in a wide variety of environments and constraints, and bridges the gap between backend infrastructure and frontend data science development work.
Gus Lipkin is a Data Scientist at Lander Analytics, where he writes software for data science practitioners and consumers.
