Terminal as a Dev Environment in the Age of Agents

Jon Fir — Wed, 06 May 2026 12:14:35 +0000

When the IDE Stopped Being the Center of Development

At some point, I realized something strange: I no longer have a “main development tool.”

There’s Xcode, VS Code, the terminal, a task tracker, a wiki, a Git client—and a dozen other windows. Every task turns into constant context switching.

And that felt normal. Because there wasn’t really an alternative.

But things started to change when LLMs entered everyday workflows.

I’ve been using them for over a year now, and I gradually came to a simple conclusion:
most of what I do now goes through an agent.

Agents:

do research
write code
work with tasks
interact with calendars
and handle dozens of other things

Before, each of these required a separate tool.

Now—there’s a single interface.

And that completely breaks the traditional development model.

Why a Single Chat Isn’t Enough

Once agents become your main tool, an important limitation becomes obvious.

An agent is not a “smart IDE.” It’s a system with very real boundaries.

First problem: context.

The context window isn’t infinite. In fact, its effective size is quite limited.
If you keep stuffing everything into it, the model quickly degrades: it loses track, gets confused, and produces weaker results.

Second problem: artifacts.

To work effectively, agents need structure:

documents
plans
code snippets
saved outputs

This leads to an important shift:
your workflow stops being chat-centric and becomes artifact + context driven.

The chat is just an interface—not the source of truth.

From this follows a simple rule:
each task needs its own isolated context.

Which means:

separate chats
separate file sets
separate states

At first, I tried to manage this in VS Code. It has everything: chat, files, terminal.

But it quickly turned into chaos:

dozens of tabs
unclear task boundaries
unclear agent permissions
unclear connected “skills”

And most importantly—a loss of control.

Meanwhile, some tasks still drifted into the terminal anyway.

At some point it became obvious:
the IDE was no longer the center of development.

So I moved to the most basic and universal environment—the terminal.

Ghostty: Terminal as the Foundation

The terminal turned out to be almost ideal: you can run anything, access everything, and structure your workspace.

You can even organize tabs per task.

I chose Ghostty—it’s fast and has great defaults.

Installation:

brew install --cask ghostty

Basic config to avoid keybinding conflicts with a multiplexer:

# config.ghostty
macos-option-as-alt = true
keybind = alt+left=unbind
keybind = alt+right=unbind
keybind = alt+up=unbind
keybind = alt+down=unbind

Without this, some Zellij shortcuts won’t work properly.

Zellij: Sessions and Panes per Task

Next step—structuring the terminal workspace.

I needed a multiplexer to keep multiple sources of information visible at once.

I chose Zellij. Yes, partly because it’s “modern and shiny,” but mostly because it’s fast and ergonomic.

Zellij supports panes, plugins, sessions—everything you need.

Installation:

brew install --cask zellij

Layout example:

# ~/.config/zellij/layouts/dev.kdl
layout {
    default_tab_template {
        pane size=1 borderless=true {
            plugin location="zellij:tab-bar"
        }
        pane split_direction="vertical" {
            pane stacked=true {
                pane command="yazi"
                pane command="lazygit"
                pane
            }
            pane command="claude" size="30%"
        }
        pane size=2 borderless=true {
            plugin location="zellij:status-bar"
        }
    }
}

You can create multiple layouts—for different workflows or task types.

Helper function:

# .zshrc

dev() {
  local title

  if [ $# -gt 0 ]; then
    title="$*"
  else
    title="$(basename "$PWD")"
  fi

  title="${title//\//-}"
  zellij options \
    --session-name "$title" \
    --attach-to-session true \
    --default-layout dev
}

This creates a session named after the current folder (or a custom name).
It makes it much easier to stay organized across tasks.

Claude Code and Codex: Agents Inside the Environment

For agents, I use Claude Code and Codex in the terminal.

Not much to say here—they actually feel better in CLI than in UI.

The key difference is this:
the agent stops being a separate window somewhere else.

It becomes part of your working environment—next to your files, Git, logs, and artifacts.

Vim: An Editor That Stays in Flow

My editor is Vim.

Yes, partly because “real engineers use Vim.”

But seriously—it fits perfectly into a terminal workflow.

No app switching. No breaking context.

Open a file, edit, go back to the agent, check diff, run commands—all in one place.

Yazi: Fast File Navigation

For file navigation, I chose Yazi.

It’s fast, modern, and supports Vim-like keybindings.

Minimal config—just a helper to keep the last directory:

function y() {
    local tmp="$(mktemp -t "yazi-cwd.XXXXXX")"

    yazi "$@" --cwd-file="$tmp"

    if cwd="$(cat "$tmp")" && [ -n "$cwd" ] && [ "$cwd" != "$PWD" ]; then
        cd "$cwd"
    fi

    rm -f "$tmp"
}

Small detail, big usability win.

Lazygit: Git Without Leaving the Session

For Git, I use lazygit.

It covers most daily workflows:

view diffs
create commits
switch branches
rebase
understand repo state quickly

Maybe one day I’ll find something faster—but for now it just works and fits perfectly into the terminal setup.

How It All Comes Together

Over time, this setup evolved into a coherent workflow:

each task = a separate session
each session = its own context
the agent works in an environment, not a chat
the terminal becomes the integration layer

The terminal is no longer just an alternative to VS Code.

It becomes something bigger—
an operating system for working with agents.

IDEs were built around code.

The terminal is built around processes.

And in the age of agents, processes become the primary abstraction.

What a Typical Workflow Looks Like

I have three main types of workflows:

code changes
research & documentation
quick questions

1. Working with Code

Goal: make specific changes.

Usually minimal artifacts—maybe just a plan.

I open a terminal, go to the project, and start a Zellij session (dev layout), naming it after the task.

Then:

explore structure via Yazi
check repo state via Lazygit
interact mostly with the agent

I pass the task and context to the agent.
If there’s no plan—I ask it to create one (plan.md).

I quickly review it via Yazi or Vim, then let the agent execute.

The agent occupies a fixed pane, while I switch the other between Git and file navigation.

2. Research & Documentation

Here I work with ideas, not code.

I keep a directory of projects—from notes to large research.

Same flow: open project → start Zellij session.

Inside—mostly Markdown files.

Yazi + Vim allows me to:

navigate quickly
edit manually
delegate to the agent

The agent also connects to external systems:

wiki
task tracker
internal tools

In both directions:

it pulls information
and updates systems

This is where agents shine—they structure thinking, enrich content, and connect local and external contexts.

3. Quick Questions

The simplest case.

A separate terminal tab with just the agent.

No sessions, no structure—just ask:

how something works
where things are
who owns what
what’s relevant

Final Thoughts

At any moment, I might have a dozen sessions open.

But I don’t get lost—names make everything clear.

Each session contains a full toolkit:
agent, Git, editor, file navigation, terminal.

If needed, I add panes on the fly—without breaking context.

Everything lives in one place:
no app switching, no lost state.

The terminal becomes more than an interface.

It becomes an environment where each task lives independently—
while still remaining fully under control.

DEV Community: Jon Fir