The Terminal Was Never the Point: Managing Parallel AI Coding Agents

The assumption underneath the hierarchy#

Give the command line its due, fully and once: for linear work, nothing has ever beaten it. You type one command, it does one thing, you see the result. No hidden state, no interpretation layer, nothing between your intent and the machine. For an engineer working a task by hand, one branch and one commit and one merge at a time, that directness is the whole point. Against it, a diagram of your repository really was optional. If you change one thing at a time, you can hold the state in your head.

But that judgment rests on a single assumption, invisible because it was always true: the work is sequential. One human, doing one thing at a time.

That assumption just stopped being true.

What parallel agents broke#

The question in a lot of engineering teams has changed. It is no longer “should I use an AI coding agent.” It is “how do I run more than one without losing track of what they are all doing.”

Let me be precise about the case I mean, because it is not the only one. Plenty of agent work is moving into ephemeral cloud environments and coming back as pull requests, and in that world the review dashboard, not the desktop, is where you watch. But that is not where most people are right now. Right now, millions of engineers run agents locally against real working directories on their own machines: Claude Code, Codex CLI, Copilot CLI, Gemini CLI. For them the visibility problem is not a forecast. It is Tuesday.

Return to those three agents. The terminal shows you one. And yes, before anyone says it: you can tile five terminals with tmux, or zellij, or a split pane, and watch every log stream at once. But look at what that actually gives you. Five waterfalls of output. A log tells you what an agent is saying. It does not tell you where that agent is in your codebase, what it has committed, or how its work relates to the other two. A multiplexer scales the output; it does not scale your grasp of the state. You are still reconstructing the real picture in your head, from scrolling text: who changed what, and whether it collides.

This is not a failure of the terminal. It is doing exactly what it was built to do, representing linear work with total fidelity. The work simply stopped being linear. Agents produce parallel, overlapping, simultaneous output, and no linear interface represents parallel work well, no matter how skilled the driver or how many panes they have open.

The interface built for parallel work#

Think about what an air traffic controller needs. Not one radio channel checked in sequence, one aircraft at a time; that collapses the instant there are five planes up. A controller needs one surface showing every aircraft at once: where each is, where it is heading, which needs attention now. The value is in seeing all of them together, in relation to each other.

That is exactly what a linear interface cannot give you and a visual one always could. It is also exactly what got waved off as a crutch for years, because until now nobody needed to watch five things at once. One human working by hand never had five parallel streams to monitor. The moment the machines did the writing, and did it in parallel, the thing that looked like a convenience became a control tower.

The tools built around visualization, it turns out, did not need to reinvent themselves for this moment. Their premise was already the one the moment demanded: you should be able to see the state of your work, every branch and every commit and how they relate, on a single surface, instead of rebuilding it in your head from a scroll of output. That premise sat for years, filed under “nice for people who find git log intimidating.” It turned out to be the right architecture for a future that had not arrived yet.

Managing parallel agents in practice#

GitKraken is the clearest example to reach for, partly because it made the most stubborn bet on visualization and partly because it has now extended that bet, feature by feature, straight into agent work. Read its recent additions not as a feature list but as a map of the specific ways parallel machine work goes wrong.

The first problem is not knowing what is happening at all. Start an agent session and GitKraken spins up an isolated working directory (a Git worktree), runs your setup, and launches the agent, all from one action instead of the old manual dance of creating the worktree, installing dependencies, and starting the agent by hand. Each session becomes a card on one surface, with live status: running, waiting on you, or done. The blind window-switching was the disease; a single board showing every agent’s state is the cure.

Worth being exact about that isolation, because it is easy to overclaim. A worktree gives each agent its own working directory but shares the repository’s history. Main stays untouched until something is committed. It is not a sealed sandbox, and it is not meant to be one. It is the right level of isolation for managing parallel Git work, and nothing more is promised.

The second problem is knowing where the work is, not just that it exists. The commit graph now includes every active worktree, so each agent’s branch sits in the graph beside all the others: what it has committed, and how those commits relate to everything else in the tree. That is the difference between a status light reading “running” and a map showing the actual position. The limit is worth stating plainly. Seeing three agents converge on the same auth module does not prevent the collision they are heading toward; no tool could stop that on its own. What it buys you is what logs never will: you watch the collision forming while there is still time to step in, instead of meeting it at merge time as a thousand-line pileup.

The third problem is what to do with the output once an agent is done. A finished agent tends to dump one sprawling diff across a dozen files, and committing that as a single blob called “update auth” destroys the readability of your history. Commit Composer restructures that machine output into clean, logical commits before it reaches a teammate. You are giving human shape to machine work, which is most of what the human is for now.

And when a branch does collide with main, Auto-resolve with AI proposes a context-aware resolution and explains its reasoning, so you accept it, adjust it, or take over. It clears the rote line-by-line analysis; you keep the final call. It will not untangle a semantic conflict, where one agent’s logic breaks another’s in ways no merge tool resolves, but it removes the mechanical noise so your attention is free for the part that actually needs a human.

None of that is a new idea. It is the same premise, the state of the work visible on one surface, meeting a moment when the work turned parallel and fast and hard to hold in your head.

(Commit Composer and Auto-resolve with AI are part of GitKraken AI, which requires a paid GitKraken plan; both are currently in preview.)

The argument was never about taste#

Underneath the posturing about who counts as a real engineer, the whole fight was about one thing: which shape of work your tools are built to serve. When the work was one human doing one thing at a time, the linear interface was ideal and the visual layer optional. Now that it is many machines doing many things at once, a linear interface cannot represent it, and the surface that shows everything at once stops being a convenience and becomes the only way to stay in control.

The terminal keeps the ground it always ruled: pointed, deterministic, one-shot commands. It will be on every serious machine for the rest of our careers. It did not lose; it has a boundary, and the boundary is where linear work ends.

The crutch argument was never really about tools but about work: the belief that serious work is sequential and solitary and lives at a prompt. That belief held for as long as the work did. It stopped holding the day the machines started writing in parallel. Betting on a full view of everything at once looked like overkill for years. It turned out to describe exactly how we work now.

The terminal was never the point. Seeing the work was. It just took the machines writing the code for everyone to notice.