Neovim in 2026: rebuilt with an agent

I type less code by hand now than at any point since I was thirteen. Most days it’s close to none. I read a lot of code, I review diffs, I write specs and instructions in Markdown, and the agents do the typing. So it’s a little ridiculous that the first week of March went into rebuilding my editor configuration from an empty directory. I’ve had three months with it, which is long enough to write about it honestly.

Why start over

In my 2024 editor post the config was a few hundred lines of Lua that started from kickstart.nvim and then grew the way configs grow. By this year it had plugins I couldn’t explain, two ways of doing a couple of things, and an LSP setup written against an API Neovim had since replaced. I’d been fixing it in place for two years, and each fix made the next one harder.

The thing that made me actually do it was realizing I wanted the agent for the reading, more than for the writing. A Neovim config is mostly decisions about other people’s plugins, and the work is knowing which plugin is current, what its options are this year, and how it interacts with the others. That’s the part an agent is good at and I’m slow at.

One change at a time

The rule I set was that nothing went into the config unless I’d picked it. I started a Claude Code session in an empty nvim directory, described what I use the editor for, and asked it to start with the minimum: a plugin manager and nothing else. After that, every round worked the same way. It proposed the next few changes as a numbered list, each with a sentence of reasoning, and I replied with the numbers I wanted. It applied only those, I restarted Neovim and tried them, and we went again.

The numbered list was what made it work. When an agent proposes a batch, the easy thing is to accept the batch, and then you’ve got a config you didn’t choose, which was exactly the problem with the old one. Picking by number meant I said no to a lot. I said no to a dashboard plugin, two different statusline themes, an AI completion plugin (the agents are in the terminal, not the editor) and, more than once, to a plugin that would do something I’d never once wanted to do. By my rough count I accepted a bit over half of what it proposed, and the rejections taught it something, because by the third day it had mostly stopped proposing things I’d want to reject.

Before we started I’d written down what I think of as the four moving parts, and we built them in order. Tree-sitter for parsing and highlighting. Language servers for the things an IDE does. Formatters, which are separate from the language servers even when they’re installed the same way. And completion, which sits on top of the language servers. Getting each one working before starting the next was slower than asking for everything at once and much easier to debug.

What’s in it

lazy.nvim for plugins, the same as before. fzf-lua instead of Telescope for finding files and grepping, which was the agent’s suggestion, and it’s noticeably faster on our larger repos. blink.cmp for completion. The language servers are configured with Neovim’s newer built-in vim.lsp.config and vim.lsp.enable, with no mason-lspconfig layer in between, and one list in mason-tool-installer installs both the servers and the formatters (stylua and prettierd; csharpier stays a dotnet global tool, outside Mason). conform.nvim formats on save, with a 500ms timeout so a slow formatter can’t hold up a write.

The biggest change is C#. In 2024 I used OmniSharp in Neovim for small changes and VS Code for anything serious. Now it’s roslyn.nvim, talking to the same Roslyn language server that VS Code’s C# tooling uses, and for the kind of work I do in our .NET services now, which is mostly reading and reviewing, it’s good enough that I’ve stopped switching. React and TypeScript got a small plugin that closes and renames JSX tags. I kept the Tree-sitter text objects, since daf deleting a whole function is still the best argument I know for modal editing.

The keymaps follow LazyVim’s conventions without using LazyVim: <leader>f for files, <leader>s for search, <leader>g for git and so on. LazyVim’s key layout is well thought out, and I wanted the layout without the distribution on top of it. There’s also nvim-spider, which makes w and b stop at the humps in camelCase names and is the one plugin I’d now find it hard to live without. The colorscheme is tokyonight, which means my editor and my terminal are different palettes, and it turns out I don’t care.

Three editors, one set of keys

Neovim isn’t the only editor I use. VS Code is still there for some debugging, and I have a JetBrains IDE open more days than I’d like to admit. The part of the rebuild I’m happiest with is that all three use the same keys.

The config checks whether it’s running inside VS Code, through the VS Code Neovim extension, which runs real Neovim behind the editor instead of emulating Vim the way the old extension did. If it is, it loads a minimal set of plugins and a keymap file that maps the same leader keys onto VS Code’s own commands. JetBrains gets an IdeaVim config with the same layout. The README in the config directory has a table of every keymap and what it does in each environment, and that table is the only place the three are reconciled, so it’s what I update first.

The whole thing lives in my dotfiles and goes out to the other Mac and the Windows laptop through chezmoi, as it has since 2023.

The ridiculous part

So I have the best editor setup I’ve ever had, built in a week, and I barely write code in it. I’ve thought about that a bit. Part of the answer is that reading is now most of the job, and a good editor is a much better reading tool than a diff in a browser. Jumping to a definition and finding every caller is what I do all day while reviewing what the agents wrote.

The other part is less rational. I like it. I spent thirty-odd years getting fast at typing code, and I’m a little sad that it doesn’t matter much any more. Keeping a good editor is a way of keeping a hand in, and the week I spent rebuilding it, picking every change by number, was the most I’ve enjoyed working on anything with an agent this year.