The Moment I Noticed
I’m reviewing Claude’s code in one tmux pane. Neovim is open in another, metals LSP quietly doing its thing on a Scala file. A third pane has a test runner watching for changes. Everything is fast, quiet, and exactly where I need it.
Then I see the email: “Your JetBrains All Products subscription is due for renewal.”
I try to remember the last time I opened IntelliJ. I genuinely can’t. It’s been weeks—maybe a month. The tool that defined my development workflow for years has been sitting untouched, and I didn’t even notice it was gone.
This is the story of how that happened.
The JetBrains Years
Let me be clear upfront: this isn’t a hit piece. JetBrains makes excellent software. IntelliJ IDEA is, by almost any measure, the most capable Scala IDE in existence. WebStorm understood TypeScript projects better than I did sometimes. The refactoring tools, the database client, the debugger UI—these are genuinely world-class.
I used IntelliJ for Scala work and WebStorm for TypeScript for years. They were the center of everything. Open the IDE, open the project, and the entire world of that codebase was at your fingertips. Intelligent code completion, instant navigation to definitions across modules, refactoring that actually worked across a 200-file project. For a long time, I couldn’t imagine working without it.
But JetBrains IDEs were built for a world where you write most of the code. Where the editor’s primary job is to help you type faster, catch your mistakes in real-time, and navigate a codebase you’re actively building character by character.
That world changed for me.
What Changed: Claude Code and Git Worktrees
The trigger wasn’t some Hacker News post about Vim superiority or a sudden desire to look cool in a terminal. It was practical friction that became unbearable.
Two things converged. First, I started using Claude Code heavily for day-to-day development. As I wrote about in my previous posts, I shifted from writing code directly to directing AI-assisted work—defining requirements, reviewing plans, checking implementations. My interaction with the editor changed fundamentally. I wasn’t writing code for hours anymore. I was reviewing it, tweaking it, navigating through it.
Second, I adopted git worktrees for parallel feature development. This is where JetBrains started to crack.
Git worktrees let you check out multiple branches simultaneously in separate directories:
git worktree add ../feature-auth feature/authentication
git worktree add ../feature-dashboard feature/dashboard-redesign
git worktree add ../bugfix-payments bugfix/payment-timeoutEach worktree gets its own Claude Code session. I’m directing three streams of work in parallel, switching between them throughout the day. This workflow is incredibly productive—but it’s also incredibly hostile to heavyweight IDEs.
Every new worktree means a new IntelliJ project window. Each window needs to:
- Index the entire codebase from scratch
- Download and resolve all dependencies
- Build its internal model of types, references, and symbols
- Load its plugins and configurations
- Allocate its own chunk of RAM
Three worktrees meant three IntelliJ windows. That’s 6-8 GB of RAM just for the IDE. My laptop fan would spin up like it was preparing for takeoff. Switching between windows was sluggish. Opening a new worktree for a quick bugfix meant waiting 2-3 minutes for indexing before I could do anything useful.
The friction compounded. The more I leaned into parallel work with Claude Code and worktrees, the more the IDE fought me. It was optimized for a single-project, deep-focus workflow. I was doing multi-project, high-frequency context switching.
The Role of the Editor Changed
Here’s the insight that made everything click: the editor’s job in my workflow had fundamentally changed, and I hadn’t updated my tools to match.
In the old workflow, the IDE was the center of creation. I spent 6-8 hours a day typing code, and IntelliJ’s intelligence—autocomplete, inline error checking, automated refactoring—directly accelerated that typing.
In the new workflow, Claude Code is the center of creation. The AI writes the first draft. I review, adjust, and approve. My editor interactions are:
- Navigate to a file Claude just modified
- Read through the changes, understand the approach
- Make small edits—rename a variable, adjust a condition, fix a style issue
- Search across the codebase to verify consistency
- Jump between files to trace a change across layers
None of these require a 2 GB IDE with a full semantic model of my codebase warming up in the background. They require a fast editor with good navigation, decent LSP support, and the ability to open and close instantly.
I needed a reviewer’s tool, not a writer’s tool.
Why LazyVim
I’d tried Neovim before and bounced off it hard. Configuring everything from scratch—key bindings, plugins, LSP servers, file explorers, color schemes—felt like building a house before you could start cooking dinner. I didn’t want a hobby. I wanted an editor.
LazyVim changed that equation. It’s a Neovim distribution with sensible defaults for everything:
- File navigation with Telescope (fuzzy finder that’s absurdly fast)
- LSP preconfigured for most languages
- Git integration via lazygit
- Tree-sitter for syntax highlighting
- Which-key for discoverability (press a key, see what’s available)
I installed LazyVim, added the Scala extras (metals LSP) and TypeScript extras, and had a working environment in about 20 minutes. Not a perfect one—I’ve been tweaking it since—but a functional one that let me start working immediately.
The key insight with LazyVim is that it covers 90% of what you need without the IDE weight. That remaining 10%? I’ll get to that honestly. But 90% of an instant editor beats 100% of one that takes three minutes to become useful.
The Terminal-Native Workflow
The real power isn’t Neovim in isolation—it’s Neovim as part of a terminal-native workflow where everything compounds.
My setup:
- tmux for session and window management
- Neovim (LazyVim) for editing
- Claude Code for AI-assisted development
- lazygit for git operations
- ripgrep for fast code search
Everything lives in the terminal. Switching from Claude Code’s output to the editor is a Ctrl-b + arrow key. Opening a file Claude just mentioned is :e path/to/file or a quick Telescope search. Checking git status, reviewing diffs, committing—all without leaving the terminal.
The workflow with worktrees looks like this:
# tmux session: feature-auth
# Pane 1: Claude Code (directing implementation)
# Pane 2: Neovim (reviewing/editing)
# Pane 3: Tests running
# tmux session: feature-dashboard
# Same layout
# tmux session: bugfix-payments
# Same layoutSwitching between features is Ctrl-b s to pick a tmux session. Neovim opens in under a second. There’s no indexing, no warming up, no “please wait while we build your project model.” It’s just there.
This speed difference sounds trivial until you’re switching between three active workstreams fifteen times a day. Those 2-3 minute IDE startup delays add up to 30-45 minutes of waiting. With Neovim, the switching cost is effectively zero.
What I Miss (Honestly)
I’ve been on Neovim for less than three months. I’m not going to pretend it’s all sunshine. Here’s what I genuinely miss:
The Debugger UI. IntelliJ’s visual debugger for Scala is unmatched. Setting breakpoints, inspecting variables, stepping through execution—all in a polished GUI with watches, conditional breakpoints, and inline value display. Neovim has DAP (Debug Adapter Protocol) support, and it works, but it’s nowhere near as smooth. For complex debugging sessions, I occasionally think about firing up IntelliJ. I haven’t yet, but the thought is there.
Rename Refactoring Across Projects. LSP handles basic renames fine, but IntelliJ’s refactoring was smarter—it understood string references, comments, configuration files. Metals and typescript-language-server do a good job for code references, but they don’t catch everything IntelliJ would.
Database Tools. IntelliJ’s database client was genuinely good. Connect to Postgres, browse schemas, write queries with autocomplete, see results in a nice table. I’ve replaced this with psql and DBeaver when I need a GUI, but it was convenient having it integrated.
The “Just Works” Factor. With JetBrains, I never thought about my editor. It was configured, it worked, updates were automatic. Neovim requires occasional maintenance—a plugin breaks after an update, a new language needs LSP configuration, something in the config needs adjusting. The maintenance cost is low, but it’s not zero.
These are real trade-offs, not minor inconveniences I’m glossing over for the narrative. If your workflow is single-project, deep-focus coding without heavy AI assistance, JetBrains IDEs are probably still the better choice.
Three Months In
I’m not going to tell you to switch editors. That’s a deeply personal choice, and the right answer depends entirely on how you work.
What I will say is this: the barrier to trying Neovim is lower than it’s ever been. LazyVim means you don’t need to spend weeks configuring an editor before you can use it. LSP means you get real intelligence—go-to-definition, find references, error checking—without an IDE. And if your workflow has shifted toward AI-assisted development, you might find that the heavyweight IDE is solving a problem you no longer have.
The editor you need depends on what you’re doing with it. I used to spend my days writing code, and IntelliJ was the best tool for that. Now I spend my days directing AI, reviewing its output, and making surgical edits. For that workflow, a fast, terminal-native editor that opens in a second and gets out of my way is exactly right.
My JetBrains subscription renewal email is still sitting there. I think I know what I’m going to do with it.
I’m less than three months into this switch, working primarily with Scala and TypeScript. My opinions will probably evolve. If you’ve made a similar transition—or decided against it—I’d be curious to hear how it went.