Your agents should run your coding tools too

Why the best tools for agentic coding give humans and agents the same programmable workbench.

Claude Code pulled many developers out of their perfectly configured, stylish IDEs back into the terminal. At first, the change looked like a downgrade: from rich graphical interfaces to plain text and blinking cursors.

But the terminal that stayed pretty much the same for decades, quickly evolved for the agentic era. It opened the doors for a new category of terminal-based coding tools that treat the agent an equal class of user as a human. Some even allow the agent to not only use the workbench, but configure or extend it from within.


As coding agents became capable to perform complex, long running tasks, a growing part of software development shifted from executing the work to delegating, observing and verifying it. A software engineer of today spends less time traversing a directory tree to open a new file or applying a manual code change, but more time coordinating agents and reviewing their output.

IDEs support these workflows, often with a nice graphical interface. But the terminal has a clear advantage: it’s not a single application but a moldable, programmable environment, easily shared between humans and agents. Both can see the same logs, panes and diffs.

Today, we see a new generation of developer tools that capture that new model of collaboration. Below are some of my favorite examples.


Herdr: AI-first terminal multiplexer

Herdr terminal multiplexer with several agent sessions
Herdr terminal multiplexer with several agent sessions

Running multiple agents from a raw terminal can be a challenge. To reconcile them operating on a single repository, you need a galaxy brain. I don’t have one, so I am glad I discovered Herdr.

Herdr is an agent-native terminal multiplexer (like tmux). It allows you to (programmatically) split your terminal into persistent sessions and panes.

What’s unique about Herdr is that it was built with agents in mind. It plugs into your coding agent and notifies you when a session is in progress, blocked or done. It surfaces a CLI and a skill that helps agents understand and control the environment they run in. It even accommodates worktrees by giving them a special place in the UI.

That’s most of the components you need to do highly-parallelized agent work today.

Hunk: review-first diff viewer

Hunk is a diff viewer that lives in your terminal.

It’s easy to dismiss it as something that must be subpar to the diff viewers we’ve had in our IDEs for years. Prompting the agent from the terminal to write code is one thing, but reviewing that code in terminal? That’s gross (for non-VIM users).

But because Hunk is a terminal-based diff viewer, it can do things that are much harder for traditional IDEs: it can change based on the user inquiry.

Let’s say you are reviewing a large, end-to-end change. To fully understand it, you want to approach it from different perspectives: top-down, front-end only, back-end only.

Backend changes selected in Hunk with an agent annotation
Backend changes selected in Hunk with an agent annotation

What Hunk allows you to do is tell your agent: “Use Hunk to show me backend changes only. Start with the database schema, then walk me through the API. Remove noise like dependency upgrades, markdown documents, changesets. Add annotations that will help me understand the changes better.”

That gives you a personalized diff that’s much easier to digest than if you had to filter out those files manually.

Pi: an agent harness that grows with you

On a foundational level, an agent harness could be described as a program that turns a prompt into model response. The majority of harness’ work is deciding what context should be attached to that prompt.

The context grows not only on users’ request (when they use skills, connect MCPs, and so on) but also due to harnesses’ design choices. Some harnesses decide to ship opinionated system prompts and workflows, while some - like Pi - choose minimalism.

Pi coding agent configuring its own tool
Pi coding agent configuring its own tool

Pi makes no assumptions about how you work with coding agents. Instead, it lets you build your own scaffolding. Why agree on universal “plan mode” if your idea of planning may be different from somebody else? You may want to build a plan mode that uses Matt Pocock’s batch-grill-me, I may want to plan in High Valyrian. We are not the same.

By opening its internals and making it easy for agents to edit them, Pi lets you build a harness that feels truly own.


That’s my evidence for proving that nimble, open coding tools can provide better agentic experience than closed, proprietary ones. If software developers are expected to parallelize and accelerate ad infinitum, maybe it’s worth to invest some time in building a unique workflow that helps you keep up.

PS. Just before I made final touches to this article, David Crawshaw of exe.dev and Tailscale fame, published a timely article I can recommend reading:

“Devtools must be open source”