Then, Now, Next: My Agentic Coding Setup

René Kulik on 02.11.2026

Introduction

How I write code has changed a lot over the last months, and the tools around it changed with it. In my post about setting up Claude Code, I wrote about the system I built around the agent: instructions, skills, and boundaries. This post is about the layer below that: where the agent runs and how I talk to it.

I will go through it in three steps: what I used, what I am using now, and what I think will be used in the future.

Then: Claude Code Inside Visual Studio Code

When I started with agentic coding, I stayed in the editor I already knew. I opened Visual Studio Code, started Claude Code in its integrated terminal, and worked side by side with the agent. It generated code, and I adjusted that code myself in the editor right next to it.

That setup made sense at the time. The editor was still the center of my work, and the agent was one more tool inside it. I read every change in the file tree, fixed the parts I did not like by hand, and moved on.

This is no longer how I work. Today, I generate the code and almost never write it myself. In 99 percent of the cases, a change goes through the agent, including the small corrections I used to make by hand. Once that happened, the editor lost its place in the middle. I still read code, but I do not need a full editor open all day to do that.

Now: tmux and Claude Code

My current setup is tmux and Claude Code, nothing else. tmux is a terminal multiplexer: it lets me split one terminal into several windows and panes, and it keeps them running independently of the terminal window I see them in.

Sessions That Outlive the Terminal

Two things make tmux the right fit for me.

First, I can run multiple Claude Code sessions in parallel. One session works on a feature in one project, another one answers a question in a different project, and I switch between them with a key binding. Together with desktop notifications, I know which one needs me without checking each of them.

Second, the sessions are not lost. They belong to the tmux server, not to the terminal window, so closing the window does not end them. When I close the terminal window, or the laptop goes to sleep, I reattach later and everything is where I left it: the running sessions, their history, and the panes around them.

My tmux Configuration

My tmux configuration lives in my dotfiles repository. It is deliberately small: a key binding to reload the configuration, Vim-style keys to move between panes, and mouse support for the moments when scrolling or clicking into a pane is simply faster. Everything else is tmux’s default behavior. I never needed more than that.

Why Not Herdr

There is a promising alternative built specifically for this way of working: Herdr. It is an agent multiplexer for the terminal. Like tmux, it gives you panes, tabs, and workspaces that keep running when you detach. On top of that, it knows about the agents running inside them and shows in a sidebar whether each one is working, blocked, done, or idle.

That is a real improvement over plain tmux, especially for people who run many agents in parallel on the same project, each in its own git worktree. That is not how I work. I rarely run parallel work in one single project, so I do not use worktrees much, and the sessions I run side by side are usually spread across different projects. For that, tmux with my few customizations is enough, and I am used to it.

If you are starting in this direction today and want to use a terminal for agentic coding, I would skip tmux and try Herdr right from the start. It solves the same problems tmux solves for me and adds the parts that only matter once agents are involved, without years of habits pulling you towards something else.

Next: GUIs Instead of Terminals

Even though I am happy with my terminal setup, I do not think terminals will be the main way to work with coding agents in the long run. I expect GUI applications like Claude Desktop or T3 Code to take over that role.

The terminal is a good fit for developers who already live in it. But when you no longer write the code yourself, the interface you need is a different one. It is mostly a conversation: writing or talking to an agent, reviewing what it did, and keeping an overview of what several agents are doing at the same time. A GUI built for exactly that can do this better than a grid of terminal panes.

I am not there yet myself. I am too used to my tmux setup, and I also do other things in the terminal besides talking to agents: organizing files, running scripts, managing my dotfiles. As long as the terminal is where the rest of my work happens, it is also where my agents run.

Next: Agents on Remote Servers

The second shift I expect goes further: I think most agents will stop running on our local machines.

Running an agent locally made sense when I was writing code alongside it. The editor, the language server, the tests, and the agent all needed the same machine. With Claude Code, the model already runs on Anthropic’s servers. What still runs on my laptop is the agent itself and everything it does: editing files, installing dependencies, running builds and tests. When I mostly review instead of writing code, none of that has to happen on the machine in front of me.

So instead of a powerful laptop, you can rent a server and run your agents there. You connect to it from wherever you are, through a terminal or through a GUI, and write or talk to the agents running on that server. The session lives on the server, so closing the laptop does not matter at all. This is something my local tmux setup cannot do: tmux keeps my sessions from getting lost, but when my laptop goes to sleep, the agents inside them pause too. On a server, they keep working while the laptop is closed, and the results are waiting when I open it again.

None of this is new. People already run their agents on rented servers, and Claude Code on the web runs sessions in the cloud out of the box. So the shift is not about something that does not exist yet. Today, running agents remotely is something you choose deliberately. I expect it to become the default, and running an agent on your own laptop to become the exception.

Conclusion

My setup went from an editor with a terminal inside it to a terminal with agents inside it. The reason was not the tools themselves but how I work: once I stopped writing code by hand, the editor moved out of the center, and the ability to run several long-lived sessions moved in.

For now, tmux and Claude Code cover everything I need. If you are starting from scratch with a terminal, I would point you to Herdr instead. And looking further ahead, I think both will be replaced by something that already exists today but is not yet the default: GUI applications as the way we talk to agents, and remote servers as the place where those agents run.