Managing the Herd
One of the defining shifts in being a good engineer in this agentic era is learning to work with several agents at once, along with the harnesses that surround them.
Early AI-assisted work meant one task, done a bit faster. Now agents handle the grunt work, which frees us to run multiple implementations in parallel. The challenge then becomes keeping quality and coherence, which means tracking every change and stopping agents from polluting one another's work.
I don't claim any secret sauce, nor do I think you need to sacrifice your context window at the altar of the Industrial Markdown Complex. There are, however, a few simple tools and lessons that have made a real difference to how I work.
1. Herdr
No single tool has been more valuable to me than Herdr. Yes, it's essentially fancy tmux, but its first-class support for agents makes it hard to recommend anything else.
Herdr organises your terminal into workspaces, tabs and panes, with a mouse-friendly feel somewhere between a terminal and a GUI. Unlike tmux, it automatically detects Claude Code, Codex and a dozen or so other agents, with a sidebar showing whether each is working, blocked on your input, or done. Instead of cycling through terminals to see who needs you, you glance at the sidebar and go where you're needed.
Agents keep running in the background even when you close the terminal, and you can reattach from anywhere, even over SSH. With the built-in skill, Claude can drive Herdr itself, spawning panes, reading their output and setting up layouts for whatever workflow you need.
There's also a healthy plugin ecosystem, ranging from notifications when an agent needs attention to tools that fan a task out across several agents.
Two plugins I've found incredibly useful:
- herdr-automatic-rename names each tab after what's running in it or, for agents, after what the session is actually working on ("Debug transient issue" rather than "3"). With several agents on the go, it makes the right one much easier to find.
- herdr-reviewr opens a review pane beside your agent showing its diff, including just what the last turn changed. You comment on specific lines and send the notes straight back to the agent, so the whole review loop stays in the terminal.
2. Worktrees
The other big change to my workflow is the religious use of worktrees. A worktree lets you check out the same repository several times, each in its own directory and on its own branch, so you can work on multiple branches in parallel.
For agents, that means each one gets its own copy of the repository and can't interfere with or pollute another's work. Two agents sharing a checkout will sooner or later overwrite each other's files or break each other's builds. Each change also ends up on its own branch, ready for its own PR.
Claude Code supports worktrees natively, and a single line in your global instructions (e.g. CLAUDE.md) makes it always create one. By default, each new worktree branches from your remote's main branch rather than whatever you happen to have checked out, so agents start from a clean, up-to-date tree. A few gotchas worth knowing:
- Gitignored files such as
.envdon't come along, though Claude Code will copy them over if you list them in a.worktreeincludefile. - Dependencies don't need reinstalling, since Claude Code can link folders like
node_modulesfrom your main checkout into each worktree. They're shared, so an agent that adds or upgrades a package changes it for every worktree. If that happens often, pnpm's global virtual store gives each worktree its ownnode_modulesfor almost no extra disk or install time. - Worktrees only separate the code, so two dev servers on the same port, or two agents migrating the same local database, will still trip over each other.
- Worktrees pile up quickly, so clean up the merged ones as you go.
3. Harnesses
The other conceptual change in how I approach development is recognising that, as engineers, we're moving through an abstraction chain that not only changes rapidly but keeps shifting in what it can do. The harness, by which I mean the tools, context and workflows you wrap around a model, is how you keep up with it.
The latest models, for example, are far better at vision tasks than their predecessors, so an agent can now screenshot the page it just changed, compare it with the design and attach the evidence to the PR. Spotting capability changes like this and folding them into your harness can significantly change your velocity, and it's worth revisiting your setup whenever a new model lands. Building a harness can feel administrative at first, but an effective one gives a significant return on the time you put in.
Connecting MCP servers or CLIs for tools like Figma, Atlassian or Datadog is one of the easiest wins. An agent picking up a bug can read the Jira ticket, pull the Figma frame and check Datadog for errors before it writes a line of code. That's context you'd otherwise have to paste in by hand, and it's usually more complete than anything you'd have pasted anyway.
4. Guardrails
Whilst agents are non-deterministic, much like the humans they're working alongside, the guardrails around them don't have to be. Unit tests, end-to-end tests and static analysis give the same verdict every time, which makes them a far more reliable way to enforce quality than trusting any one agent, or person, to get it right.
One tool I'd particularly recommend is Fallow, a fast static analyser for TypeScript and JavaScript that catches the kind of mess agents are prone to leaving behind, like dead code, duplication and creeping complexity. Pair it with something like OSV-Scanner to flag dependencies with known vulnerabilities, and you've covered two of the more common ways agent-written code degrades a codebase over time.
All of these checks also need to be fast, because a suite that takes the best part of an hour soon becomes the bottleneck when several agents are shipping changes at once. An agent can only correct course as fast as it gets feedback. Wire them into hooks and CI and they put constant pressure on the agent to get things right, whilst giving reviewers confidence that whatever reaches them has already been checked.
5. Reviewing Intent & Shape
This is probably the most controversial change to accept. As we produce more code, scrutinising every line becomes unfeasible. Yet we still need a human steering the solution over the long horizon. Models write code very well, but often miss how a solution fits the problem it's meant to solve.
I suspect that's partly down to how they're trained. Much of a model's reinforcement learning comes from tasks with objectively right or wrong answers, where the tests either pass or they don't. That result is fed back through the model via backpropagation, adjusting its weights to make whatever earned the right answer more likely next time. Architectural decisions offer no such clean signal, since whether a design was right might not be clear for months.
That's why maintaining the architecture is still a critical part of the human role, whereas scrutinising individual lines adds little, especially when the next person to read the code is likely to be another agent. Agents should still produce elegant, secure code, but at the level of syntax the implementation matters less than its shape and intent and how they fit the overall solution.
Within the PR process, the focus should be on giving the reviewer the intent and a clear description of the change. Reviewing then becomes less about reading individual lines and more about whether the solution has the right shape for the problem and for the system around it. Attaching test results and screenshots helps too, because the reviewer can see the change working for themselves.
There are still times to read closely, such as security boundaries and data migrations, but we must accept that newer models like Claude Opus 5.5 and Claude Fable 5.1 are arguably more capable at producing code than any human ever was. There's nothing to be ashamed of in that when models can now apparently solve the Navier-Stokes Millennium Prize problem (though not without a fair bit of controversy over who deserves the credit). Much like a calculator, they surpass human ability within their domain. We can't keep up by reading harder, so we have to adapt our processes rather than pretend it's still 2010 in the year 2026.
Where this leaves us
Fundamentally, our role as engineers has shifted in so far as that role ever was about writing code to begin with, to directing it. I don't think there's much value in trying to "out-code" a model.
The value we has moved up a level, ensuring we're building the right thing and keeping the agent unblocked so it can get on with it. Which in essence is what an engineer was always measured against, our ability to produce a solution. Not code. It just so happens for the past couple of decades, they've often been inextricably linked. Undoing some of that mental link takes time.
The tools will keep changing, probably faster than this post ages but the habits underneath them, I suspect, will hold for a while yet.