Try Turborg Free → Open App →
← All posts

I Stopped Opening VS Code Six Months Ago. Here’s What My Terminal-Only Workflow Looks Like.

July 11, 2026 · 5 min read · The xShellz Team

I Stopped Opening VS Code Six Months Ago. Here’s What My Terminal-Only Workflow Looks Like.

I haven't opened a local GUI editor in over six months. Not because I'm nostalgic for the 1980s. My entire development workflow now lives inside a remote Linux shell: tmux, Neovim, a handful of CLI tools, and borg, an AI coding agent that responds in the same terminal window. The result is lower latency, less memory pressure, and a weird sense of flow I didn't expect.

The hidden tax of local IDEs

Modern IDEs are resource hogs. A single VS Code window with a few extensions and a TypeScript language server can easily consume 4 to 5 GB of RAM on a mid-sized project. Add a browser, Slack, and Docker, and your laptop starts swapping, the fan howls, and typing feels just a tick behind. Even on a desktop, the UI thread gets bogged down when the language server churns through a re-index. The editor was often the bottleneck, not me.

I hit a wall on a Rust project where rust-analyzer would occasionally freeze VS Code for seconds at a time. Lowering the analysis settings helped, but the root problem was that my development environment was fighting for local resources. I needed a different approach.

Moving the heavy lifting to a remote shell

The fix: I SSH into a remote Linux box that runs my editor, toolchain, and language servers. My local terminal (Kitty, iTerm, whatever) is just a dumb display. The remote machine has enough cores and RAM to handle everything without breaking a sweat. I use a shell from xShellz, but any VPS with decent specs works.

This alone solves the resource contention. Code navigation, linting, and incremental builds happen instantly because they aren't competing with my browser and messaging apps. The real kicker is persistence. I keep everything inside a tmux session. I disconnect, walk away, and reconnect hours later. The session never dies. All my buffers, running jobs, and shell history are right there. No need to re-open projects or re-run watches.

Low latency is the real superpower

A common objection is network latency: "Won't SSH lag?" Typing over SSH with a round-trip under 50 ms feels instantaneous. The latency that actually hurts development comes from the language server or compiler blocking the UI. Those heavy operations now run on a remote box with a fast CPU and NVMe storage. The keyboard-to-screen path stays clean because my local machine isn't the one doing the work.

This also fixes environment parity. My remote shell runs the same Linux distribution as CI, so there are no mysterious "works on my machine" moments. I install apt packages, run containers, and test network services directly on the box. It's as close to production as a dev environment gets without being production.

Where borg fits in

Terminal-native AI tools change the game. borg is an AI coding agent that lives inside your shell. You can ask it to write a function, refactor a block, or explain a cryptic error, and it responds right in a tmux pane. It can even insert the code directly into your editor. Because borg runs on the same remote host as my editor, it has full filesystem access and can read my project's git log, check linter output, and iteratively refine code.

No GUI, no context switch. I stay in the keyboard-driven flow. I can pipe borg's output into other commands, script it, or run it headlessly in a cron job to periodically check for broken imports. IDE-based assistants try to integrate into a heavy UI; borg just feels like another Unix tool.

The tie to xShellz is real: borg is included in their shell plans and runs natively in the same environment. But even if you aren't using that, the concept holds: a terminal-native agent eliminates the friction of bouncing between editor and an AI pop-up.

The workflow I actually use

I SSH into my remote shell and attach a tmux session. The layout is simple:

  • Pane 1: Neovim with a few plugins for language support.
  • Pane 2: A shell where I run tests, git, and one-off commands.
  • Pane 3: borg in interactive mode. I type something like "add request validation to the login handler and write a test," and watch the code appear.

All of this lives in tmux. I can detach, go to lunch, and reconnect from my phone's SSH client to check on a long build or tweak a config. The shell never sleeps. It also runs my IRC bouncer, so I never miss mentions without needing another app.

The unexpected side effects

Fewer context switches. I click less, I move the mouse almost never, and the muscle memory of keybindings deepens. The environment works from any device with an SSH client: a Chromebook, a tablet, even another borrowed laptop. No syncing dotfiles or installing language SDKs locally. My entire dev environment is an SSH config and a keypair.

The always-on nature means I can kick off a full test suite, detach, and check on it later. With a local IDE, I'd have to keep the GUI session alive. Now I can restart my laptop without thinking about it.

Is this the next generation of devs?

I'm seeing juniors learn tmux and Vim motions not as a retro flex, but because remote pairing and resource-constrained setups demand it. When you combine that with a terminal-native AI agent, the traditional IDE becomes an optional layer, not the default. The terminal-first mindset fits naturally with GitOps, infrastructure as code, and the rest of the modern stack where everything is a text stream in a shell.

Skipping the IDE isn't a nostalgia trip. It's a strategic choice. If you haven't tried moving your main development environment into a remote shell, give it a weekend experiment. You might find you don't miss the GUI.