Vim vs a full IDE in 2026: when the modal editor is enough and when it isn’t

I have spent most of the last decade in some flavor of Vim bindings and some flavor of an IDE I complained about. In 2026 the argument is louder because the IDE grew an agent pane and the modal editor grew an LSP that almost feels like a product. Neither side won. The work split, and the split is more useful than a religion.

I used to be a cloud engineer. I still write and I still ship. This is when I open a terminal and stay there, and when I stop pretending a terminal is a Java shop.

What “enough” means now

Enough is not “I can edit text.” Enough is: I can jump to a definition without a prayer, rename across a module without a sed incident, run the test under the cursor, see the type of the thing I am staring at, and not lose the buffer when the language server sulks. Neovim plus a maintained LSP config does that for Go, Rust, TypeScript, Python, and a lot of the languages I actually touch. It did not do that reliably in 2018. People who last opened Vim in 2018 are arguing with a ghost.

Enough is also: I can live on a small laptop, over SSH, on a jump box, in a container, on a train. A full IDE wants a project import and a JDK and a UI thread. Modal editors want a file and a tty. If your week is a lot of remote boxes, the IDE is the guest. If your week is one fat monorepo with a debugger that must attach to a running JVM, the terminal is the guest.

The agent year confused the comparison. VS Code and JetBrains now ship a chat that can edit. Neovim has plugins that do a version of the same. I do not pick an editor because of the chat. I pick it because of the day the chat is wrong and I still have to move. Modal editing is still the fastest way I know to change text I already understand. An IDE is still the fastest way I know to understand a system I do not.

When the modal editor is enough

You already know the shape of the code. A service you wrote, a config you own, a script, a Terraform stack, a Go worker, a Rust crate you can hold in your head. LSP gives you the jump. Grep gives you the rest. You do not need a project model that indexes the universe. You need motions and a quickfix list.

The unit of work is a file or a small graph. Dotfiles. A CLI. A single package. A blog of HTML, if we are being honest. Opening IntelliJ for that is how you wait for Gradle to decide you exist.

You are on the far side of a pipe. Production box, customer VPN, a codespace that is really SSH, a review on a server that will not install a GUI. I will not fight that. I will open Vim and do the three-line fix. The IDE can have the follow-up on my desk.

The language server is a first-class citizen in your stack. TypeScript, Go, rust-analyzer, basedpyright — these are good enough in 2026 that “Vim cannot refactor” is a take from a person who did not install the server. The rename works. The import works. The inlay hints work if you want them. What does not work is pretending this is a substitute for a Java debugger that understands your application server.

You like a config you can diff. My editor is a git repo. When it breaks, I know which plugin I added. When I get a new laptop, I clone. An IDE is a profile, a set of synced settings, and a surprise after an update. I can live with that for a day job. I do not want it for the editor I use to fix the editor.

When it is not enough

You are lost in a monorepo you did not plant. Polyglot, generated code, three build tools, a service mesh, a test that only runs through an IDE run configuration someone left in a wiki. I have wasted afternoons recreating that configuration in a terminal. The IDE already had it. Pride is a latency budget.

You need a real debugger more than twice a week. I can drive dlv and lldb from a terminal. I do not want to, not when the bug is a breakpoint in a framework method with a watch on a collection that only misbehaves after the 40th request. JetBrains and VS Code still win that afternoon. Winning the afternoon is the job.

The project is Java, C#, or a heavy frontend design system with a preview that is part of the work. People will tell you Neovim can do this. People can also cook a state dinner on a camp stove. I will open IntelliJ for Java and I will not write a blog post about my purity. The same is true for a lot of Android and a lot of Unity. Modal bindings inside the IDE are a compromise I accept. Modal-only is a hobby I do not bring to those codebases.

Onboarding is the product. A new hire should not spend week one fighting Mason and a Mason fork. A team standard that is “install VS Code, open the folder, trust the workspace” is a gift. I can keep Vim for myself and still review in the tool the team shares. Editor wars that cost a new person two days are not craft. They are a tax on people who have not yet earned an opinion.

The agent needs the project, not the buffer. Some of the useful agent features in 2026 are “see the test run, see the failing assertion, apply the patch, show me the diff in context of the run configuration.” That loop is tighter in an IDE that already owns the run. I still do a lot of agent work from a terminal. When the loop is “run this JUnit with these env files,” I stop being brave.

The hybrid I actually run

I do not pick one. I pick a default and a rescue. Default, for me, is Neovim for anything I already understand and anything remote. Rescue is JetBrains or VS Code when I am lost, when I am debugging a runtime I do not want to memorize, or when I am pairing with someone whose muscle memory is not mine.

Vim bindings in the IDE are how I keep my hands from becoming two people. I am not a purist about hjkl in a JetBrains window. I am a purist about not relearning a third set of keys every time the stack changes. If you only learn the IDE mouse, you will be slow on a box. If you only learn Vim and refuse the debugger, you will be slow in a meeting. Both slownesses are optional.

Plugins are the hidden IDE. A Neovim config that is 200 plugins is not “lightweight.” It is an IDE you assembled without a QA department. I keep the list short: LSP, completion, treesitter, a picker, a git gutter, a terminal. When the config takes longer to fix than the bug, I have become the person I used to mock in the IDE camp.

What 2026 changed, and what it did not

Language servers made the modal editor honest for typed languages. Agents made both sides louder and did not settle the file-versus-project question. Remote dev is still a tty problem. Java is still an IDE problem. Pairing is still a social problem: use the thing the other person can see.

What did not change is the lie that the editor is the craft. I have watched people spend a quarter ricing a status line and ship nothing. I have watched people live in an IDE they hate and ship every week. The tool should disappear into the gesture. If your editor is the identity, you are optimizing the wrong loop.

How I would choose this quarter

Write down the three tasks you did most last month. If two of them are “edit a thing I know on a box I SSH to,” stay modal. If two of them are “find out why this test fails in a framework I do not own,” take the IDE and map your Vim keys. If they are split, split the tools and stop asking the internet to pick a spouse.

If you are learning, learn the motions either way. They travel. Do not learn 80 plugins. Learn jump-to-definition, rename, test-under-cursor, and a debugger you will actually launch. Those four are the job. The rest is taste, and taste is a weekend, not a personality.

Modal is enough when the problem is text you understand. It is not enough when the problem is a system that has not introduced itself. I like my terminal. I like shipping more. In 2026 I let the second preference win the days it has to.