My AI Coding Setup: Agents, Skills, Terminals, and Worktrees

Nowadays, I rarely code a whole feature by hand. Agents have evolved so much over the last two years that it is now possible to describe a whole feature, how you want its code organized, and the agent will write all the logic. Tests included.

So, I had to prepare my local development environment to work faster and smarter with different agents, whether they are remote or local.

I have to say, though, that I use fewer local agents because it takes more time to receive answers from them and to go through bigger codebases.

Agents

Choose agents by role

I use either Claude or Codex for work and personal projects, not both at the same time. My company pays for access to one of them and is comfortable with me using it for personal projects, so availability is also part of the decision. Both have advantages and disadvantages, but I do not assign work based only on the model name. I choose an agent based on the kind of work I need it to do: research and planning, day-to-day implementation, or review.

For research and planning, I use either Fable or Sol when I need an agent to read documents, cross-reference information, and propose a draft solution. They are also useful when I need to summarize a conclusion by cross-referencing a lot of logs from different apps.

For implementation work where I already know the path forward, I use either Sonnet or Luna (Max). Sometimes I use Terra instead. This is the kind of task where I provide as much information as possible: the plan, the relevant files, the expected organization of files, and the constraints. It helps me move from a clear plan to execution without treating every task as a research problem.

For reviews, I use Terra with Opus to review my code and leave comments on other people’s pull requests. The important part is not using a specific model for every review. It is making sure the agent has enough context to follow the change, understand the existing patterns, and point out gaps before the code is merged.

Skills

Matt scripts

I have known of Matt since taking his course at totaltypescript.com. There, I saw that he had gotten really deep into AI programming over the past few months. That is when I checked out the skills he was creating, not just to give you a technical point of view, but also to really help the agent understand the feature before going into coding.

grill-with-docs

Grill with docs will modify the objective of the agent until it can understand the business rules that you want to achieve. Once an agreement is made, it will create an ADR with the scope, goals, and unwritten domain concepts for future agent development. With this one, the quality and scope of my features have been clearly explained, and it has helped me think about edge cases before the code is written.

Custom Commit skill

A personal skill that is basically a set of instructions for grouping files or hunks based on the feature and then starting to commit. The agent will ask you if the grouping makes sense before making the commit. It will also ask you to create a new branch if required.

Terminal

Herdr

My favorite terminal agent manager is Herdr. It has risen in popularity recently, and for me, it is the next step after Tmux. Last year, I was a heavy user of Tmux. But once I moved to Herdr, I had no problems creating new tabs and panes. There were no more errors during terminal shell initialization, and the number of plugins is growing every day.

Pane organization

I use a 3-pane layout, and I have used it since the days of Tmux. The left pane is the biggest one, and I use it for the agent conversation because I need space for READING. Yes, you read that right. For me, reading is the most crucial part of working with an agent; otherwise, I will see it start hallucinating if my instructions are not clear enough.

The top-right pane is usually used for lazygit, so I have visibility into which files my agents are modifying. Also, if it is faster and cheaper to make the commit myself, I am usually faster at typing the commit than asking the agent to do it, especially if there are only a couple of modified files.

The bottom-right pane is used to run commands, builds, deployments, or any other shell command that I want. I can run them through the agent as well. But sometimes, while the agent is thinking, I prefer to have visual output from a command that I am running.

Worktrees

Worktrees with Treehouse

Usually, I have three copies of the same project on my computer. Some people would say that I am wasting hard drive space. But I think that is a perfect balance for what I want to do.

The first copy is for feature development. The second is for log research, cross-referencing documentation, and planning. The third is for experiments and hotfixes.

On top of that, I work with worktrees. There are multiple ways to work with worktrees, including tooling from Claude and Codex. You can configure multiple agents to start research using a worktree, but you have to maintain the symlink between the installed libraries, especially for TypeScript projects, and make sure you have the same .gitignore files in the original project and the worktree.

I use Treehouse from Kunchenguid. Treehouse gives you a way to easily manage your worktrees with hooks and useful commands. Also, when the agent reads the Treehouse commands, it is able to understand how easily it can work with it.

Treehouse will take the latest commit from your main or master branch and start working based on that commit. Later, you can create a new branch based on that commit.

The only downside is that you have to use a long command:

treehouse

But since I already have Bash knowledge, it is pretty easy for me to configure aliases for some of my most-used commands.

alias th="treehouse"
alias ths="treehouse status"
alias the="treehouse enter"

Now, the other day, I was thinking: I want to have a single command to open a new Herdr tab with a layout: the usual left 50%, with the right side split horizontally.

And after a coding session with Codex, it was possible.

# Treehouse + Herdr worktree tab
function treehouse_herdr_tab {
  local name="$1"
  if [[ -z "$name" ]]; then
    echo "usage: thw <name>" >&2
    return 1
  fi
  if ! exist treehouse || ! exist herdr || ! exist jq; then
    echo "thw: requires treehouse, herdr, and jq" >&2
    return 1
  fi
  if [[ -z "$HERDR_WORKSPACE_ID" ]]; then
    echo "thw: must be run from inside a herdr pane" >&2
    return 1
  fi

  local worktree_path
  worktree_path=$(treehouse get --lease --lease-holder="thw:$name") || return 1

  local tab_json root_pane right_pane
  tab_json=$(herdr tab create --workspace "$HERDR_WORKSPACE_ID" --cwd "$worktree_path" --label "🌳 $name" --focus) || return 1
  root_pane=$(jq -r '.result.root_pane.pane_id' <<< "$tab_json")

  right_pane=$(herdr pane split --pane "$root_pane" --direction right --ratio 0.5 --cwd "$worktree_path" | jq -r '.result.pane.pane_id') || return 1
  herdr pane split --pane "$right_pane" --direction down --ratio 0.5 --cwd "$worktree_path" >/dev/null
}

alias thw=treehouse_herdr_tab

For every worktree created through this Treehouse flow, the script adds the 🌳 emoji to the Herdr tab label. It makes worktree tabs easy to recognize among the rest of my sessions.

By using the alias thw <feature-name>, Herdr will open a new tab, split the panes, and automatically enter the worktree in each one. So I am able to start experimenting or working on a feature.

Notion

Notion has become my personal organizer for everyday life, including technical documentation. Over the years, I have managed everything there: personal subscriptions, travel itineraries, a monthly expenses calculator, private code snippets, and content copied from the internet.

Now that they have added MCP support, connecting my code to Notion has become easier than ever: creating summaries of system design books, storing snippets of patterns that I can reuse in other projects, and drafting the first ideas for my blog posts. Everything is linked and includes an AI agent to help me with grammar before I write the final versions of my posts.

Conclusion

Over the past year, my workflow has focused on writing code as quickly as possible. I still have those tools installed, but nowadays shifting my workflows to be more AI-centric has become part of my normal routine. Cross-referencing as much information as possible and then creating more content based on it - code and writing - has been a useful productivity hack for me. I expect this to become normal for everyone who is also comfortable working with a computer.