The Terminal Is My IDE Now, and I Do Not Miss the GUI

I want to be upfront that this is not a vim-elitism post. I spent the first decade of my career in IntelliJ and VS Code, and I think both are excellent pieces of software that make plenty of developers more productive than they would be otherwise. This is just an honest account of why I moved almost entirely into a terminal-based workflow over the last two years, and what specifically changed, because I think the reasons matter more than the conclusion.

It started with remote work friction, not ideology

The actual trigger was mundane. I started doing a meaningful chunk of my work over SSH into a beefier remote machine, partly for a GPU-heavy side project, and partly because my laptop's fan noise during long compile times was driving me slightly insane. Running a full GUI IDE over a remote connection, even with good remote development extensions, introduced enough latency and enough weird edge cases with file syncing that I started reaching for a plain terminal session with Neovim instead, purely because it was less friction for that specific use case. What surprised me was that I never really went back, even once I was working locally again.

What the setup actually looks like

I run tmux as the session manager, with a layout I have not meaningfully changed in over a year: one pane for Neovim, one pane for the dev server, one pane that toggles between test output and a scratch shell, and increasingly, a fourth pane running Claude Code for anything that benefits from a longer, more autonomous task description rather than line-by-line editing.

tmux new-session -s work \; \

send-keys 'nvim .' C-m \; \

split-window -h -p 30 \; \

send-keys 'npm run dev' C-m \; \

split-window -v \; \

send-keys 'npm run test:watch' C-m

That script alone gets me from a cold terminal to a fully populated working session in about two seconds, editor, dev server, and test watcher all running, all visible at once without switching windows. The equivalent in a GUI IDE, opening the project, waiting for indexing, opening an integrated terminal split for the dev server, opening another for tests, reliably takes me somewhere between fifteen and thirty seconds, and that gap, paid every single time I start a work session, adds up over a year in a way that is easy to underestimate.

The part that actually took real effort: Neovim as a real editor, not just a text editor

I want to be honest that getting Neovim to a place where it genuinely replaces a modern IDE, not just a syntax-highlighted notepad, took real investment. LSP support through nvim-lspconfig gives you the same go-to-definition, find references, and inline diagnostics you would expect from any modern IDE, but you are responsible for wiring it up yourself, which is either an interesting weekend project or a deeply annoying one depending on your temperament.

require('lspconfig').tsserver.setup({

on_attach = function(client, bufnr)

vim.keymap.set('n', 'gd', vim.lsp.buf.definition, { buffer = bufnr })

vim.keymap.set('n', 'gr', vim.lsp.buf.references, { buffer = bufnr })

end,

})

Telescope handles fuzzy file finding and project-wide search, which I would argue is actually faster than most GUI equivalents once you have the keybindings in muscle memory, because there is zero mouse movement involved and the fuzzy matching algorithm is genuinely excellent at surfacing the file you meant even from a rough, misspelled query. Git integration comes through a plugin, I use one that shows inline blame and hunks directly in the gutter, similar to what GitLens gives you in VS Code, just rendered as terminal text instead of a rich UI panel.

Where the terminal-first approach genuinely loses

I am not going to pretend this is strictly better in every dimension, because it is not. Debugging with breakpoints, watch expressions, and a visual call stack is meaningfully worse in a terminal setup. I use nvim-dap for this and it works, but it is not as pleasant as a graphical debugger, and for genuinely gnarly debugging sessions I will still open VS Code specifically for its debugger UI. Anything visual, working with images, designing a UI in a browser preview pane, reviewing a complex diff with side-by-side rendering, is also better served by a GUI, and I keep a plain VS Code install around specifically for PR reviews where I want to see a rendered diff rather than a terminal-based one.

Onboarding a new terminal-first setup onto a new machine also has real cost. My dotfiles repo, covering Neovim config, tmux config, shell aliases, and terminal emulator settings, is a genuine artifact I maintain, and getting a fresh machine to feel like home takes maybe twenty minutes of running a setup script versus just installing VS Code and signing into settings sync, which restores your entire environment in under a minute.

Why Claude Code specifically fits this workflow so well

The piece that made this whole setup click even harder over the last year is that agentic coding tools are inherently terminal-native. Claude Code lives in a terminal pane the same way my editor and my dev server do, which means it is not a separate application context switch, it is just another pane in the same tmux session, reading and writing the same files my editor has open, without any special integration needed to keep them in sync. That is a genuinely different feel than a GUI IDE's AI panel, which always feels slightly like a separate application bolted onto the side, even in the more deeply integrated tools.

The actual case, stripped of ideology

If your work is heavy on visual debugging, design collaboration, or you are frequently pairing with people who are not terminal-fluent, the GUI IDE ecosystem is going to serve you better and I would not push you off it. But if your daily loop is mostly editing text, running commands, and now increasingly delegating well-scoped tasks to an agent, a terminal-first setup removes a surprising number of small frictions you did not know you were paying, and it composes unusually well with exactly the kind of AI-assisted workflow that is becoming a bigger part of how all of us work regardless of which editor we are typing into.

I get asked fairly often whether I would recommend this setup to someone earlier in their career, and my honest answer has softened over time. When I first wrote about this workflow internally, I was fairly evangelical about it. Now I would say: learn the concepts, LSP-backed navigation, fuzzy search, terminal fluency, integrated version control, regardless of which specific tool you learn them in, because those concepts transfer completely whether you end up in Neovim, VS Code, or whatever comes next. The specific editor is genuinely less important than most of these debates make it sound. What matters is not accepting a slow, high-friction daily loop just because it is the default you started with, and being willing to periodically ask whether the tool you are using is actually the fastest path to doing the work, or just the most familiar one.

There is also a quieter benefit to this whole setup that took me longer to notice than the speed gains: working almost entirely in text, without a mouse pulling my attention toward panels and icons, changed how I think while coding, not just how fast I execute. There are fewer visual distractions competing for attention, no notification badge in a sidebar, no hover tooltip appearing uninvited, and I find I stay in a focused state for longer stretches than I did in a busier visual environment. I do not want to oversell this, it is a genuinely subjective effect and I know plenty of excellent engineers who find a rich visual IDE clarifying rather than distracting for exactly the same reasons I find it the opposite. But it is worth naming as part of the honest case for this setup, because the productivity story is not only about milliseconds saved on startup, it is also about the shape of attention over a full working day.