Most developers are still asking which AI coding agent is best.

I think that question is already obsolete.

The advantage will not come from choosing one agent. It will come from knowing how to operate all of them as a system.

So I redesigned my Arch Linux workstation around agents.

I have been using Arch Linux since March 2002, the month it was first released.

It has remained one of my main operating systems ever since. I use many others, I have accumulated plenty of computers over the years, but Arch has been a primary environment in which I have built, experimented and worked for more than two decades.

For me, Arch was never mainly about minimalism, aesthetics or proving that I could install Linux from a terminal. It taught me to build environments instead of merely consuming them: to understand what runs, how each layer is assembled and where the abstractions begin and end.

That philosophy has found a new application.

More than two decades later, that mindset has become the foundation for an AI-native development workstation: not a computer with a chatbot attached, but an engineering platform designed around human direction, parallel agent execution and verifiable outcomes.

The workstation is becoming the engineering organization

Traditional development environments are organized around a human operator. The developer opens an IDE, checks out a branch, edits files, runs tests and pushes the result. Automation usually begins after the human has produced a change.

Agentic engineering changes the sequence. I define intent, constraints and acceptance criteria. Agents inspect repositories, modify files, execute commands and validate their work. The workstation becomes a software organization in miniature, and the developer moves from producing every change to designing the system that produces changes.

That environment must be explicit, composable and observable. Arch is a natural fit because packages, services, shells, permissions and processes are deliberately assembled and easy to inspect. The same legibility that attracted me in 2002 now helps agents operate predictably.

A herd, not a chatbot

The system starts with Arch Linux, with pacman for official packages, yay for tooling distributed through the AUR and mise for managing development tools such as the agent runtime. XFCE provides a lightweight graphical environment, while Bash and Kitty form the primary command surface for repositories, agents, tests, logs and persistent processes.

Interactive development happens in Visual Studio Code, with agent extensions for the human-in-the-loop workflow, and through terminal-based coding agents. The workstation is deliberately not standardized on one of them. Claude Code, Codex, Cursor, OpenCode, Grok, GitHub Copilot, Pi and Hermes can coexist in the same operating model, alongside other CLIs detected by Herdr. Each agent remains native; the runtime owns its terminal rather than replacing its interface.

This is the difference between assistance and agency. Autocomplete helps someone type code faster. An engineering agent helps move a repository from one verified state to another.

Git provides the state model, and SSH connects repositories to their remotes. I keep projects under a predictable root, using neutral names here:

/srv/dev/projects/foobar-web
/srv/dev/projects/foobar-commerce
/srv/dev/projects/foobar-labs

The path itself is not important. The stable topology is. Agentic systems amplify disorder: ambiguous repository boundaries, scattered instructions and inconsistent commands create confusion faster when work runs in parallel.

Isolation is what separates a system from chaos

Running several agents in the same working directory is not a multi-agent architecture. It is a race condition with a user interface.

Git worktrees provide the isolation layer. Each task receives its own branch and filesystem view. An agent can work without overwriting another agent's files or disturbing the human's primary checkout, while every result remains ordinary Git history that can be reviewed, merged or discarded.

The workflow is deliberately simple:

  • Define the task, scope and acceptance criteria.
  • Create a dedicated branch and worktree.
  • Let the assigned agent operate only inside that worktree.
  • Run tests, linters and project-specific build checks.
  • Review the resulting diff.
  • Let a human decide what is merged and deployed.

A repository-level agent policy makes these rules part of the codebase. It tells agents where they may work, which commands they should use, what evidence they must produce and which actions remain outside their authority. In this setup, agents do not push directly to main or deploy autonomously.

This boundary is what makes autonomy useful. Isolation prevents interference, automated checks reduce uncertainty, and human review retains operational control.

Herdr, installed through mise, provides the runtime above that isolation layer. It gives coding agents persistent terminals, keeps their sessions running and makes them accessible again from another machine. It detects many agent CLIs out of the box and is not tied to one provider, model or interface. Herdr is where concurrent agents live; Git worktrees define where each of them may act.

Different agents. Different jobs.

Using every agent does not mean sending every task to every model. It means treating the available agents as a heterogeneous engineering team and routing work deliberately.

The workstation is being built around this routing policy:

  • Claude Code for long-running implementation, deep repository exploration and broad refactors;
  • Codex for scoped implementation, debugging, tests and worktree-based code review;
  • Cursor and GitHub Copilot for interactive, editor-centered work where rapid human feedback matters;
  • OpenCode for provider-independent workflows, model comparison and tasks that benefit from changing the underlying model without changing the operating pattern;
  • Grok for technical reconnaissance when the answer depends on what is happening right now;
  • Pi for lightweight, scriptable and highly customized agent loops;
  • Hermes for autonomous background work and experiments that need a persistent general-purpose agent.

These assignments are policies, not identities. They will evolve with the agents, the repositories and the evidence produced by each run. A task can also be sent to two different agents: one implements while another reviews the specification, challenges architectural assumptions or searches for failure modes.

The point is not to crown one universal winner. It is to combine different reasoning styles, interfaces and execution profiles while keeping the same isolation, validation and authority boundaries underneath.

The model is not the moat. The harness is.

The model is the most visible component, but it is not the whole capability. Reliable agentic engineering comes from the harness surrounding it:

  • repository instructions and task specifications;
  • explicit permissions and authority boundaries;
  • isolated execution environments;
  • deterministic setup, test and build commands;
  • logs, previews and observable state;
  • review, merge and deployment gates.

The stronger this harness becomes, the less time is spent repeatedly explaining the repository and the more independently agents can perform verifiable work.

The agent CLIs are workers. Herdr is the runtime. Git and worktrees provide state and isolation. The architecture is the contract connecting all of them through context, execution, validation and control.

One developer, multiplied

The workstation is designed to supervise several unrelated products without coupling their code, context or runtime state. The goal is not to keep more editor windows open. It is to let independent engineering loops continue while I set priorities, inspect results and make architectural decisions.

Herdr already provides persistent, remotely resumable agent sessions. The remaining operational layer includes automated task dispatch, remotely accessible application previews and enough observability to show what is running, blocked, awaiting review or ready to merge.

The order matters. First make one agent reliable. Then make several agents independent. Only then make the system persistent.

Most of the intelligence may execute remotely, but the workstation remains the control plane. It holds the repositories, tools, policies, execution environments and human interface. Its most important upgrade is therefore not computational; it is architectural.

The next divide between developers

We used to configure development machines for languages and frameworks: install a compiler, an IDE and a database, then clone the repository and start coding.

The AI-native workstation adds delegation. It must define how intent is expressed, how context is loaded, where agents may act, what proves completion and where human authority begins.

I am not trying to become slightly faster at typing code. I am building a system that can continue engineering while I operate at the level of intent, architecture and judgment.

The motivation that kept Arch Linux among my primary systems since 2002, understanding and controlling the environment, has simply found its next application.

Soon, using AI will no longer distinguish one developer from another. Everyone will use it.

The real divide will be between those who prompt an agent, and those who know how to design, coordinate and govern an entire artificial engineering organization.

That development model is only beginning.