Vim vs IntelliJ when you pair: what actually works when two people share one session
Tom Reeves
September 23, 2026
The fight is almost never about which editor is “better.” It’s about whose hands are on the keyboard while the other person is trying to think out loud. One of you lives in Vim motions. The other lives in IntelliJ’s project model, run configurations, and a debugger that actually attaches. You open a pairing session, share a screen, and suddenly every jump-to-definition becomes a tiny culture war.
I have sat on both sides of that desk. I have watched a Vim driver type ci" while the IntelliJ navigator said “wait, what just happened.” I have watched an IntelliJ driver click through a refactoring wizard while the Vim navigator muttered that we could have done that in three keystrokes and already be in the test. Neither complaint was wrong. Both were useless mid-ticket.
This is not a vote for modal editing or for JetBrains. It is what we kept after we stopped trying to convert each other during a shared session.
Name the actual problem
Pairing fails across editor tribes for three boring reasons.
First, latency of intention. The navigator speaks in goals (“extract that validation,” “find who calls this,” “run the failing test”). The driver translates into muscle memory. When those muscle memories are different languages, every sentence costs a second of translation. Those seconds add up into impatience that looks like ideology.
Second, asymmetric visibility. IntelliJ surfaces structure: project tree, inspections, breadcrumbs, a run panel that means something. Vim surfaces text and motion: buffers, splits, a quickfix list if you configured one. The IntelliJ person keeps pointing at panels the Vim person does not have. The Vim person keeps doing jumps the IntelliJ person cannot preview. Both feel gaslit by the same screen.
Third, identity leakage. Editors become personality. “I can’t work in your tool” often means “I feel slow and slightly stupid in your tool.” That feeling is real. Treating it as a product review is how you burn forty minutes before a single test runs.
Once we named those three, the conversation got smaller and kinder. We were not defending careers. We were reducing translation cost.
Pick a host machine, not a winner
The first decision that actually mattered was whose machine drives the session — and we stopped pretending that was a compliment.
If the work is JVM-heavy, or the bug only reproduces under a particular run configuration, the IntelliJ machine hosts. The Vim person joins as navigator, or as a second brain on a shared call, and accepts that their fingers are not the product for the next hour. If the work is a small, known change on a remote box, or a script-shaped fix, the Vim machine hosts. The IntelliJ person stops insisting on importing the whole world first.
We write that choice down in the first two minutes: “Your box for the debugger. Your box for the remote edit.” Saying it out loud kills the silent competition about whose setup is more professional.
Remote pairing tools change the shape but not the rule. JetBrains Code With Me, a shared desktop, a tmux session over SSH — pick the one that matches the host. Do not invent a third stack mid-session because someone saw a blog post. The host tool is the session tool.
Driver and navigator are roles, not religions
We rotate driver on a timer or at natural seams (test green, PR opened, “I need coffee”). What we stopped doing is rotating editors every time we rotate people. Switching both the human and the keymap every fifteen minutes is how you get motion sickness.
When the Vim person drives IntelliJ, we enable the IdeaVim plugin or a minimal Vim keymap — not a full recreation of their Neovim config. Enough to move: hjkl, basic operators, search. Not forty custom leader maps. The point is to lower panic, not to smuggle a second IDE into the first.
When the IntelliJ person drives Vim, we do not demand they learn modal editing in real time. They stay in insert more than they would like. The navigator narrates motions when they help (“delete inside the parentheses,” “jump to the other end of this function”) and otherwise speaks in outcomes. Teaching Vim mid-incident is a different activity from pairing on a bug.
That asymmetry is fine. Pairing is a temporary contract. Solo muscle memory can wait.
Speak goals, not chords
The highest-leverage habit we kept: navigators talk in intent, not key sequences.
Bad: “Hit shift-command-F and type the class name.”
Better: “Find every caller of authorizePayment.”
Bad: “Do ciw on the variable.”
Better: “Rename this local so it matches the field.”
The driver then picks the gesture that exists in their editor. IntelliJ might use refactor rename. Vim might use an LSP rename or a carefully scoped substitute. The navigator cares that the name changed and the tests still make sense. They do not care which shortcut did it.
When the navigator does not know how the host editor does a thing, they ask once: “What’s your rename?” They do not lecture about the superior chord from home. If the driver hesitates, the navigator offers the goal again, slower. Silence is better than a tutorial.
Agree on a tiny shared vocabulary
We kept a short glossary taped above the monitor — not because we love process, but because we hated repeating the same argument.
- Jump — go to definition / declaration.
- Find uses — callers, references, usages.
- Rename — symbol rename that respects scope, not a blind find-replace unless we say so.
- Run that — the failing test or the nearest meaningful suite, not the entire monorepo.
- Show me the tree — project structure or file finder; we do not argue which panel.
- Park it — stash the half-thought as a comment or a failing test and move; do not polish mid-exploration.
Five or six phrases. Enough to navigate. Not enough to become a manifesto.
We also agreed on one escape hatch: either person can say “solo five” and take the keyboard for a short burst when the other is thrashing. Pairing is a tool. It is not a morality play about never typing alone.
What IntelliJ people need from Vim drivers
If you are the modal driver, slow down the magic. Narrate the expensive jumps. “I’m grepping for the interface, then hopping to the implementation.” Your partner cannot see your intention in a status line the way they can see an IntelliJ gutter.
Keep a visible file list. A tree plugin, a picker, even a second split with the project root — something that answers “where are we.” Pure buffer chaos makes IntelliJ folks feel lost even when you are not.
Prefer LSP renames and jumps over clever macros during the session. Clever is for solo time. Shared time wants predictable edits someone else can undo with their eyes open.
If you need a terminal for a host-only task, say so: “I’m dropping to the shell for the migration.” Do not vanish into a tmux pane without a sentence. Your partner’s brain is still on the Java type hierarchy you just left.
What Vim people need from IntelliJ drivers
If you are the IDE driver, resist the tour. Do not open every tool window “in case.” Pairing is not an IntelliJ product demo. Keep the layout boring: editor, one useful side panel, run/debug when needed.
Map a few Vim-ish motions if your partner is driving later, but do not spend the first twenty minutes installing plugins. IdeaVim defaults are enough for a session. Config fishing is a different ticket.
When you refactor with a wizard, say the outcome before you click Apply: “This will move the method and update callers in this module.” Wizards that mutate twelve files feel like a jump scare to someone who edits one buffer at a time.
Let the navigator see the failing test output. Do not hide it in a collapsed panel while you “just try one more thing.” Shared attention is the whole point.
Remote vs same desk changes the protocol, not the politics
Same desk: one keyboard, voice in the room, finger pointing still works. The host machine rule still applies. Pass the keyboard deliberately; do not hover-fight.
Remote: video of faces helps more than people admit. Watching someone frown at a stack trace is information. Screen share the host editor full-bleed. A second camera on a paper sketch is optional; a second editor open “just so I can follow along” is how you get two sources of truth and a merge conflict of attention.
If latency is bad, reduce motion. Prefer larger, slower edits. Prefer talking more and jumping less. A laggy Vim session with frantic C-o history is a special kind of hell for the person watching.
When the “which editor” question sneaks back in
It will. Someone will say, after a rough hour, “Maybe we should just standardize.” Sometimes that is a team decision worth having — on Thursday, with coffee, not mid-incident.
If the question is really “what should I use when I’m alone,” that is a different article from this one. Daily-driver choice and pairing etiquette share keywords and almost none of the failure modes. For the solo decision — modal editor versus a full IDE when nobody else is watching — we already wrote through when the modal editor is enough and when it isn’t. Bring that debate back to the room only if the team is picking a default for onboarding, not because today’s pair felt awkward.
Awkward pairs get better protocols. They do not get converted at gunpoint.
A session checklist that fits on a sticky note
- Who hosts, and why (debugger, remote box, language).
- Who drives first, and when we swap.
- Goals language on; chord lectures off.
- One shared glossary if we keep tripping.
- IdeaVim or insert-mode mercy, not a config transplant.
- “Solo five” allowed without apology.
- Editor religion postponed until after the PR.
We run that list in under a minute. It sounds managerial. It saves the managerial meeting later where everyone is still mad about keybindings.
What we stopped fighting about
We stopped fighting about which tool is objectively faster. Speed is contextual, and pairing speed is social.
We stopped fighting about whose config is cleaner. Clean configs are a solo hobby with a git repo. Shared sessions need a lowest common denominator that both brains can track.
We stopped fighting about whether real engineers use mice. Some of the best debugging I have seen involved a careful click on a breakpoint gutter. Some of the best refactors I have seen were a Vim visual block that never touched a menu. The ticket does not grade your purity.
We kept fighting — productively — about the design: naming, boundaries, test shape, whether the bug is in the code or in the assumption. That fight belongs in a pair. The editor fight does not.
The boring ending that ships
Two people can share a session with Vim and IntelliJ in the room if they treat the session as a temporary system with a host, roles, and a spoken vocabulary. Convert each other on your own time if you must. During the pair, optimize for mutual comprehension and a green test.
The tools will keep evolving. Agents will sit in both sidebars. Motions will stay weird to outsiders. None of that excuses spending the first half of a pairing block arguing about docks and leader keys.
Pick a host. Speak goals. Rotate drivers, not religions. Ship the change. Then, if you still care, open your own editor alone and be as extreme as you like.
