← Back to Explore seedling

CLI-First Development

Why terminals beat GUIs for actual work

My 16GB laptop outperforms colleagues' 32GB machines because they're running VS Code, Docker Desktop, Slack, and a browser with forty tabs. I'm running a terminal. Same work gets done. Half the hardware.

That's not an ideology. That's a measurement.

What CLI-first actually means

Not terminal purism. I still use a browser. I still look at things with my eyes sometimes. CLI-first means the terminal is where work starts, and GUI tools earn their place by doing something the terminal can't.

The filter: can I script it? Can I pipe it? Can I run it on a machine I SSH into? If yes, it belongs in the terminal. If not, it might still belong in the terminal — I just haven't found the tool yet.

The payoff isn't speed (though it's faster). It's that every workflow I build is composable, repeatable, and works on any machine I can get a shell on. My development environment is a dotfiles repo. Yours is a 200GB IDE installation and a prayer.

The actual stack

Zellij for session management. Chose it over tmux because it works out of the box and I'd rather write code than configure a multiplexer. Sessions survive disconnects, layouts persist between restarts, and the keybinding hints mean I don't have to memorize another set of shortcuts.

Neovim for editing. kickstart.nvim as a base, telescope for fuzzy finding, harpoon for jumping between files I'm actively working on. Language servers give me the same code intelligence VS Code has, at a fraction of the resource cost.

Claude Code in the terminal for AI. aider with local models via Ollama when I want privacy or I'm offline. The AI tools live in the same environment as everything else — no context switch, no copy-paste between windows.

Git from the command line. Always. GUIs hide what git is actually doing, which is fine until something goes wrong and you need to understand the reflog.

What you give up

The learning curve is real. Neovim took weeks to feel natural. I still reach for the mouse sometimes and nothing happens.

Visual debugging is worse. Command-line debuggers are more powerful but less intuitive. For stepping through unfamiliar code, a GUI debugger with variable inspection is genuinely better. I use one when I need it.

It looks weird to other people. Pair programming on a terminal scares some collaborators. This is a real social cost and I don't pretend otherwise.

Why it compounds

Everything I learn about shell scripting, pipes, and text processing transfers. Between projects, between languages, between decades. The vim keybindings I learned work in every tool that supports them. The shell scripts I wrote five years ago still run.

Try running your VS Code extensions from 2019.

The sailboat test applies here directly. Will this development environment still work on a boat with a solar panel? The terminal will. Docker Desktop won't.