Terminal Velocity: Why CLI-First AI Development Scales Better in 2025
By Jory Pestorious | May 11, 2025
My earlier presentation, Stop Coding Like It's 2024: An AI-Amplified Dev Playbook, argues that AI belongs inside an engineer's existing tools. I can pipe a file or diff into Claude Code, resume a session inside a repository, connect MCP servers, and run the same agent without waiting for an editor integration.
The appeal is not terminal aesthetics. The shell already connects processes, files, source control, and remote sessions. I can start with one agent in one repository, then add parallel work without replacing the rest of my setup.
Here, scaling means adding another agent, repository, tool, or persistent session while keeping the same instruction, review, and isolation layers. I have not measured whether this workflow finishes tasks faster than an IDE-first one.
The Stack
My setup centers on Claude Code, a terminal multiplexer, an editor, and a source-control view. I can swap among WezTerm, Warp, Rio, and Kitty without changing the rest of the workflow. Zellij and Tmux keep long-running sessions alive. I edit in Neovim and use LazyGit, Ripgrep, and FZF to inspect changes and find context.
I connect a small set of MCP servers when the task needs them. Memento stores entities and relations that the client explicitly writes to Neo4j, then exposes semantic search over them. Sequential Thinking Tools adds a structured thought sequence with tool recommendations. Context7 retrieves library documentation, while OmniSearch connects several search providers.
I do not install an MCP server because its category sounds essential. I keep one when it supplies information or state the task needs. A long tool list creates more choices for the agent and more configuration for me.
Claude Code 0.2.107 in the Shell
The commands below describe Claude Code 0.2.107, the version I use for this article. I check claude --version before running them instead of replacing another installed version.
# Expected output for this article
claude --version
# 0.2.107 (Claude Code)
# Import MCP servers from Claude Desktop
# This command supports macOS and Windows through WSL.
claude mcp add-from-claude-desktop --scope user
# Continue the latest session or choose an older one
claude -c
claude -r
# Give the model a file or an inspected diff
# Remove credentials, customer data, and unrelated proprietary content first.
cat error.log | claude -p "Explain the failure and cite the relevant lines."
cat data.json | claude -p "Convert this JSON to CSV. Return only CSV." > data.converted.new.csv
git diff --staged | claude -p "Draft one concise commit message for this diff."
# Stream structured output for another process to consume
claude -p "Generate deployment steps" --output-format stream-json
The conversion writes to a new path because shell redirection truncates an existing file before Claude succeeds. I validate the output as CSV before replacing the intended file. The commit-message command only drafts text. Sending the response through xargs git commit -m can split it into arguments and treat later words as pathspecs. I review the message and the staged diff before committing.
The claude_full alias I wrote is too broad: it preapproves Bash, write access, search, and a long named list of MCP tools. Permission prompts are part of the safety boundary. I grant the smallest set of tools the current task needs, especially when the agent can change files or run shell commands.
Instructions Stay in Plain Files
I use CLAUDE.md to give Claude Code the working sequence I want it to follow:
# Working sequence
1. Search Memento for relevant project knowledge.
2. Plan the task before changing files.
3. Check current library documentation when an API is uncertain.
4. Run the repository's checks after editing.
5. Store only reusable findings, with enough context to correct them later.
Claude Code loads a global file from ~/.claude/CLAUDE.md, repository instructions from ./CLAUDE.md, and more specific files from nested directories. I use CLAUDE.local.md for project instructions that should stay on my machine. The /memory command opens the persistent instruction files. /compact reduces an older conversation when its context grows too large.
~/.claude.json is configuration and account state, not a backup of the entire setup. Project transcripts live separately under ~/.claude/projects, so copying one configuration file does not restore every conversation. The file can also contain account data and does not belong in a casual backup recipe.
MCP tool names such as mcp__memento__semantic_search are real, but hand-written XML is not Claude Code's MCP interface. Claude Code registers the tool schemas and handles the calls. An emoji or confirmation phrase is still prompt text, not a protocol or proof that the tool ran. Stable rules work better for me when they stay near the repository, name the action the agent should take, and give it a result it can verify.
Review Before Parallelism
An agent often changes the right code alongside edits I do not want. A stage view lets me accept a line or hunk without taking the whole diff. I use LazyGit most often, while GitKraken and SourceTree provide the same kind of selective review. Jujutsu and GitButler treat undo and parallel work differently, but I still need to inspect the result.
Git worktrees give each agent an isolated directory and branch without cloning the repository history again:
git clone git@github.com:user/project.git
cd project
git worktree add ../project-feature -b feature/new-feature main
git worktree add ../project-bugfix -b bugfix/critical-issue main
git worktree list
I can run one Claude Code session in each directory, compare the approaches, and discard a branch that fails. Worktrees do not prove that the agents are productive, and parallel output can create more review and merge work. They provide clean isolation so I can decide after seeing the code.
If worktrees feel unfamiliar, separate full clones still keep each agent in a different directory. They cost more disk space but make the boundary obvious.
Background Work Needs Stronger Guards
I routinely run three or more Claude processes overnight, so I want them to continue while I am away from the terminal. Claude Code 0.2.107 has no root -t template option. Appending & returns control to the shell, but it does not by itself keep a job alive after the terminal or login session closes. My original loop also granted broad shell and write access, used a predictable file under /tmp as a non-atomic lock, trusted a reused process ID, and extracted its next task from unvalidated log text. I do not publish it as a template.
Tmux and Zellij already solve the session-lifetime problem. An unattended run also needs an isolated worktree, narrow permissions, bounded iterations, recorded output, exit-code checks, repository tests, and a notification that brings me back for review.
Prompts That Work for Me
The prompt pattern I keep using names the task, the allowed tools, the success check, and what to do after a failure. A request to "reflect" does little unless it points back to a test, diff, log, or another result the agent can inspect.
These are working observations from my own runs, not evidence for exact percentage gains or one optimal tool count. Explicit checks and recovery instructions still make those runs easier to review.
A Fixed-Cost Subscription
Claude Max costs $100 per month for the 5x tier and $200 for 20x, and Claude Code now accepts Max access. I like paying a fixed subscription while I experiment instead of watching API charges accumulate. The exact number of messages depends on prompt length, context, attachments, model, and tool use, so a fixed message-count table would promise precision the plans do not provide.
Where the GUI Helps
I do not treat the terminal and IDE as opposing choices. Cursor and Windsurf give me a unified project view with less setup. The shell gives me composition and isolation.
Claude Squad combines worktrees with terminal sessions for people beginning to explore parallel agents. It reduces worktree and session setup, though parallel runs still need the review and isolation rules above.
What I Am Building Next
I am prototyping a federation protocol for distributing tasks, a reusable set of safer AFK templates, and better recovery for unattended runs. They can use the same substrate: plain files for instructions, pipes for data, stage views for review, worktrees for isolation, and persistent sessions for process lifetime. I can add coordination without surrendering the pieces I already trust.