Agentic Coding Setup: The 2026 Developer Stack

The "AI-first developer stack" meme is exhausting because most of it is screenshots of thirty different subscriptions. The actual stack I use is smaller than you'd think, and most of the magic is in how the pieces connect — not in which pieces you pick.

Here's what's on my machine in 2026, why each piece is there, and what I've removed in the last year because it stopped paying for itself.

The stack, one sentence each

• Editor: Neovim with a minimal LSP setup. Cursor optional.
• Agentic CLIs: Claude Code (primary), Codex (secondary), Qwen (backfill).
• Terminal: A grid terminal with one CLI per pane. I use SpaceSpider.
• Repo isolation: git worktrees, one per parallel agent.
• MCP servers: a small handful I actually use, not one for every trend.
• Shell: bash or fish, nothing exotic.
• Package manager: pnpm, for parallel-install safety.
• Secrets: 1Password CLI or environment files, never pasted into chat.

That's it. Seven moving parts. The temptation is to add more; resist it.

The editor is not the center anymore

This is the big shift. In 2024 the editor was where you spent most of your time, and the AI was a panel inside it. In 2026 the agent is where you spend most of your time, and the editor is where you go to verify the agent's work.

I still use Neovim, but as a reviewer and occasional surgeon. The code gets written in Claude Code. I read the diff in my editor, run tests in my terminal, and go back to the agent for the next round. Cursor is fine for the same role; pick your taste.

The implication: your editor config matters less than it used to. Invest that time in your agent configs instead.

Grid terminal as the workspace root

My whole workflow lives in a grid terminal. Not tabs. Not a single pane. A grid where each pane has a dedicated CLI and cwd.

The 2x2 default: Driver (Claude Opus), Implementer A (Claude Sonnet, worktree), Implementer B (Codex, worktree), Shell. When I scale up, I go to 3x2: add a Qwen pane for test backfill and a second shell.

If this sounds specific, it is — I've converged on it after trying half a dozen alternatives. The reason I use SpaceSpider is that I want this layout to be declarative (define once, recreate instantly) rather than something I rebuild in tmux every morning. See the grid layouts docs for the presets.

CLI selection by role, not by fandom

Three CLIs, three roles. Don't assign them by which one you like best; assign them by which pane they're in.

Driver pane runs Claude Code because judgment quality matters most where I'm actually thinking. Implementer panes run whatever CLI is cheapest-per-quality-point for well-specced tasks — usually Claude Sonnet or Codex. Backfill pane runs Qwen or Kimi for mechanical work where cost dominates quality.

For the head-to-head, see Claude vs Codex vs Qwen. The parallel AI agents use case shows the full role assignment.

MCP servers, carefully chosen

MCP servers are tempting to collect. I collected too many, then pruned. My current set:

• A filesystem server for controlled file reads outside the repo.
• A GitHub server for issue/PR work.
• A database server for the one project where I want the agent to query staging data.
• A web-fetch server for when the agent needs to grab docs.

That's four. I'd deleted a dozen others. The ones I deleted were clever but I wasn't using them weekly. Rule: if an MCP server hasn't been invoked in two weeks, delete it. They cost cognitive overhead and startup time.

Worktrees as the isolation primitive

Every parallel agent lives in a git worktree, not a clone. Worktrees share .git and are cheap to spin up:

git worktree add ../myapp-feature-x feature-x

This is the single most under-used git feature in our community. Before I adopted worktrees I'd clone the repo three times or use a single working tree and suffer. Worktrees fix both.

When you combine worktrees with a grid terminal, each pane can point at a different worktree and run a different agent, with zero cross-contamination. Worktree plus grid is the atomic unit of the parallel workflow. For the full picture see the parallel AI coding workflow post.

Context files: CLAUDE.md, AGENTS.md, QWEN.md

Every repo gets a top-level context file, usually per CLI. Minimum contents:

• Stack overview (one paragraph).
• Layout diagram of the main directories.
• Build and test commands, exact strings.
• Style guardrails ("never run rm -rf", "always use pnpm", "don't modify dist/").
• Pointers to any project-specific skills or docs.

These files are underrated. They're the difference between "the agent fumbles around for three minutes before doing anything useful" and "the agent is productive in thirty seconds." Write them once, keep them short, commit them to the repo.

Secrets: zero pasting, ever

I have rules. The agent never sees:

• Production credentials.
• Customer data.
• API keys for paid third-party services.
• Anything covered by a contract I'd have to explain to legal.

Secrets live in 1Password and get injected into the shell via op run or similar. Environment files are .gitignore'd and not readable by the agent unless explicitly allowed. If the agent needs to hit a service, I'd rather it fail and ask than read the key.

This isn't paranoia. Pasted secrets end up in logs, transcripts, and occasionally in training data (depending on your provider and plan). The rule is cheap to follow.

Shell and package manager: boring on purpose

bash works. fish works. I don't use exotic shells because they occasionally break agent tool calls in surprising ways. Boring shell, maximum compatibility.

Package manager is pnpm, specifically because it's safe under concurrent installs. If two agents run pnpm install at the same time on the same project, they won't corrupt the store. npm will occasionally. yarn is fine but slower.

Example setup from scratch

If I were setting this up on a new machine today:

# install the CLIs
npm install -g @anthropic-ai/claude-code
npm install -g @openai/codex
npm install -g qwen-code

# install SpaceSpider (or your grid terminal of choice)
# for SpaceSpider, grab the installer from the releases page

# make a home for worktrees
mkdir ~/work
cd ~/work
git clone git@github.com:me/myapp
cd myapp
git worktree add ../myapp-a feature-a
git worktree add ../myapp-b feature-b

Then open SpaceSpider, create a space per project, and assign CLIs to panes. The getting-started docs walk through this in detail.

The stack I removed

Things I tried and dropped in the last year:

• A second agentic CLI for "a different perspective." Worth it for specific review tasks, not as a daily driver.
• Notebook-based agents. Cool demo, not my workflow.
• Voice-to-code. Briefly fun, shallow utility.
• Per-project Docker dev containers. Overhead exceeded benefit for my projects. Your team may differ.
• A local LLM for privacy. I now use Qwen pointed at an OpenAI-compatible endpoint instead. For the reasoning see Qwen and Kimi as a local-ish backup.

The common thread is that most additions felt clever for a week and then became friction. When in doubt, remove.

Key takeaways

The 2026 agentic stack is smaller than the marketing implies: three CLIs, a grid terminal, git worktrees, a thoughtful MCP set, boring shell and package manager, and strict secret discipline. Everything else is personal taste.

The power comes from how the pieces compose. Grid + worktrees + per-pane CLIs is the core loop; the rest is support. Invest in that loop before you invest in anything else, and you'll skip most of the "stack envy" trap entirely.