Most development sessions start with the same chore: bring up the backend, start the frontend build, open the database, get version control where you can see it. Before any actual work happens, a few minutes go to setting up the workspace.

My setup gets rid of that. It runs almost entirely in the terminal, using tmuxp to build the session and a handful of tools for editing, file management, and version control. Once it’s configured, starting work is one command.

The Foundation: Automated Sessions with tmuxp

Many terminal users are familiar with tmux for managing multiple shell sessions. I use a tool called tmuxp to automate the setup of these sessions. It uses a configuration file to define all the windows, panes, and startup commands for a project.

This means that instead of manually opening tabs, navigating to directories, and starting servers each time, I can define the entire workspace once in a YAML file.

Defining a Workspace in YAML

Here is a simplified tmuxp.yml configuration for a standard web project:

session_name: my-project
windows:
  - window_name: 1-Editor
    panes:
      - shell_command:
          - cd code/project/
          - hx .
  - window_name: 2-Backend
    panes:
      - shell_command:
          - cd code/project/api
          - npm run dev
  - window_name: 3-Frontend
    panes:
      - shell_command:
          - cd code/project/web
          - npm run dev
  - window_name: 4-Git
    panes:
      - shell_command: 
          - cd code/project/
          - gitui
  - window_name: 5-Files
    panes:
      - shell_command: 
          - cd code/project/
          - yazi
  - window_name: 6-AI
    panes:
      - shell_command: 
          - cd code/project/
          - gemini

The bashrc Alias

To make this easily accessible, I add a simple alias to my .bashrc or .zshrc file that links a short command to the project’s configuration.

alias project="tmuxp load ~/projects/my-project/.tmuxp.yml"

Now I just run project. The alias hands the config to tmuxp, which builds the session, starts the servers, and opens the editor in the right directories. That one command is the whole setup.

The Core Tools: A Tab-by-Tab Breakdown

With the session automated, the next step is the set of tools used within each tab. I prefer tools that are designed for the terminal to maintain a consistent, keyboard-driven workflow.

Tab 1: The Editor - helix

My primary editor is Helix, a modal editor built around a “selection first, then action” model: you select the text you want to change, then choose what to do with it.

Two things keep me on it. It ships with Language Server Protocol support out of the box, so autocomplete and diagnostics work with almost no configuration. And it treats multiple cursors and selections as a core feature rather than an add-on, which makes refactoring a lot less tedious.

Tab 2 & 3: Backend and Frontend Servers

These tabs are straightforward. Tab 2 is the backend server (say, a Node.js API), and Tab 3 runs the frontend dev server (say, Vite). tmuxp starts both automatically, and I keep an eye on them for logs and compilation errors, with each server’s output in its own tab.

Tab 4: Git Operations - gitui

For a long time, this tab was simply a clean shell for running standard Git commands. My workflow involved git status, git add, and git commit typed out manually, and it served me well. It kept everything inside the terminal, which was the main goal.

Recently, however, I switched to gitui, a terminal-based user interface for Git. It offers a more visual and interactive way to manage version control without the weight of a full GUI application. It allows me to see diffs clearly, stage individual lines or files with single keystrokes, and browse commit history much more efficiently. It’s an upgrade that has sped up my commit process significantly while keeping me in the terminal.

Tab 5: File Management - yazi

For file operations like moving, renaming, or just browsing the directory structure, I use yazi. It’s a terminal file manager with built-in previews that lets me manage files without having to interrupt my editor. It’s useful for quick operations that might otherwise feel clumsy with standard shell commands.

Tab 6: AI Assistant - Gemini CLI

This tab is a dedicated shell for the Gemini CLI. Having direct access to a command-line AI assistant is useful for a number of tasks without leaving the terminal.

For example, I might use it to:

  • Generate a shell command for a specific task.
  • Get a brief explanation of a code snippet from another file.
  • Ask for help with syntax or programming concepts.

Keeping it one tab away means I actually ask, instead of breaking flow to go look something up elsewhere.

How It All Works Together

The payoff is that everything lives in one place, so I rarely have to switch out to another application mid-task.

A Typical Workflow

A common task looks like this:

  • Run project to start the session.
  • Work on code in Tab 1 (Helix).
  • After saving, glance at Tab 2 (Backend) and Tab 3 (Frontend) to confirm the servers have reloaded without errors.
  • If I need clarification on a library function, I switch to Tab 6 (Gemini CLI) to ask a question.
  • Once the feature is complete, I move to Tab 4 (gitui).
  • I visually review the changes, stage the necessary files or lines with a few keystrokes, and open the commit dialog.
  • After writing my message, I confirm the commit, all within the gitui interface.
  • If I need to reorganize some files, I can quickly do so in Tab 5 (yazi) before amending the commit.

Worth trying

The specific tools matter less than the idea behind them: let automation set up your workspace, and pick tools that keep you from jumping between windows. Swap Helix for Neovim, gitui for lazygit, whatever fits your hands.

If you spend too long getting set up before you can work, tmuxp is a small investment with a daily return. Writing your workspace down in one config file makes the start of every session a non-event, which is exactly what you want it to be.