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 was the center of my workflow for years has been sitting untouched, and I didn’t notice it was gone.
This is how that happened.
The JetBrains years
This isn’t a hit piece. JetBrains makes very good software. IntelliJ is the most capable Scala IDE I’ve used. WebStorm understood TypeScript projects better than I did sometimes. The refactoring tools, the database client, the debugger UI — these are the parts I’ll still defend in any argument.
I used IntelliJ for Scala and WebStorm for TypeScript for years. Open the IDE, open the project, and the codebase was at your fingertips: completion across modules, navigation that actually worked, refactors that held up across hundreds of files. For a long time I couldn’t picture working without it.
But the IDE was built for a world where I write most of the code. Where the editor’s job is to help me type faster, catch my mistakes as I make them, and navigate a codebase I’m building character by character.
That’s not the world I’m working in anymore.
Claude Code and git worktrees
The trigger wasn’t ideology. I didn’t read a Hacker News post about Vim and have a moment. It was friction that kept getting worse.
Two things converged. First, Claude Code became the way I work. I’ve written about this — I shifted from typing code to directing it: writing requirements, reviewing plans, checking diffs, making the small edits the model didn’t quite get right. I wasn’t writing code for hours. I was reviewing it.
Second, I started using git worktrees for parallel work:
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. Three streams of work, switching between them through the day. Productive — and very hostile to a heavyweight IDE.
Every new worktree is a new IntelliJ window. Each one re-indexes the codebase, resolves dependencies, builds its semantic model, loads its plugins, takes its slice of RAM. Three worktrees meant three IntelliJ windows. The fan would spin up. Switching between them was sluggish. Opening a worktree for a quick bugfix meant waiting on indexing before I could do anything useful.
The more I leaned into parallel work, the harder the IDE pushed back. It was tuned for one project, deep focus, eight-hour stretches. I was doing the opposite.
The editor’s job changed
Here’s the thing that finally clicked: the editor’s role in my workflow had changed, and my tools hadn’t.
Old workflow: I typed code for most of the day, and the IDE’s intelligence — completion, inline errors, automated refactoring — directly accelerated that typing.
New workflow: Claude writes the first draft. I navigate to what it changed, read through, make small edits, search to verify consistency, jump between files to trace a change across layers. None of that needs a heavyweight semantic model warming up in the background. It needs a fast editor with decent LSP and the ability to open instantly.
I needed a reviewer’s tool. I’d been using a writer’s tool.
Why LazyVim
I’d tried Neovim before and bounced off it. Configuring everything — keybindings, plugins, LSP, file explorer, colorscheme — felt like building the kitchen before you could cook dinner. I didn’t want a hobby. I wanted an editor.
LazyVim solved that. It’s a Neovim distribution with sensible defaults already wired up: Telescope for fuzzy finding, LSP preconfigured for most languages, lazygit for git, tree-sitter for highlighting, which-key so you can discover bindings without memorising them. I installed it, added the Scala extras for metals and the TypeScript extras, and was working in an afternoon. Not a perfect setup — I’ve been tweaking it since — but a working one.
90% of an editor that’s there immediately beats 100% of one that takes minutes to become useful.
The terminal-native part
Neovim alone isn’t the point. Neovim inside the terminal is. Everything I need lives there: tmux for sessions and panes, Neovim for editing, Claude Code for the model, lazygit for git, ripgrep for search.
A worktree session looks like one tmux window with three panes — Claude in one, Neovim in another, tests in the third. Switching to a different feature is a tmux session jump. 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.
The speed difference sounds trivial until you’re switching between three workstreams all day. With IntelliJ those switches added up. With Neovim the switching cost is effectively zero.
What I miss
A few months in, and I’m not going to pretend it’s all upside.
The debugger. IntelliJ’s Scala debugger is the thing I miss most. Breakpoints, watches, conditional stops, inline values — all in one polished panel. Neovim’s DAP support works, but it’s not as smooth. For anything genuinely complicated I sometimes think about firing IntelliJ back up. I haven’t yet, but the thought is there.
Refactoring across the project. LSP handles symbol renames fine. IntelliJ’s refactoring was smarter — it would catch references in strings, comments, config files. Metals and typescript-language-server cover the code paths but not the long tail.
Database tools. IntelliJ’s database client was good — connect to Postgres, browse schemas, write queries with completion, see results in a table. I’m using psql and DBeaver now. It works, but it’s a separate tool to remember.
The “just works” factor. With JetBrains I never thought about my editor. Updates were automatic, things didn’t break. Neovim needs occasional maintenance — a plugin breaks, a new language needs LSP set up, the config drifts. The cost is low, but it’s not zero.
These are real trade-offs. If your work is single-project, deep-focus coding without much AI in the loop, IntelliJ is probably still the better tool.
A few months in
I’m not telling anyone to switch editors. That’s a personal choice that depends entirely on how you actually work.
What I’ll say is this: trying Neovim is easier than it’s ever been. LazyVim means you don’t spend a weekend configuring before you can edit a file. LSP gives you most of the IDE intelligence without the IDE. And if your day has shifted toward directing AI rather than typing code, the heavyweight IDE may be solving a problem you don’t have anymore.
The right editor depends on what you’re doing in 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 what it produces, and making surgical edits. For that, a fast terminal editor that opens in a second and gets out of the way is the right shape.
The renewal email is still sitting there. I think I know what I’m doing with it.
A few months in, mostly Scala and TypeScript. My take will probably evolve. If you’ve made the same switch — or tried it and gone back — I’d be curious how it landed.