Also neovim + claude code + open terminal pane in tmux is the goated combo anyway. Especially more lately you need to understand the code you are writing if you want to do anything important in software, and the best way to do that is neovim :)

And wrote about my thoughts on the relevance of nvim here https://dlants.me/ai-whiplash.html

It's been many months, and I thoroughly prefer my harness inside of nvim as my day to day development environment. Using Claude code or cursor makes me feel very removed from the code.

Exploring code, gathering context and tweaking prompts/giving guidance to the agent are very much enhanced by neovim.

The biggest boon has been the fact that agents make customizing neovim a lot easier. Writing new bindings, config, and even building novel plugins.

Here's a few that I built that fit into my workflow:

- a tool for reviewing commits / branches / wip. https://github.com/dlants/glean

- an iterative grepper https://github.com/dlants/shuck

- a file picker that renders in your current window (like oil) and uses more intelligent signals for ranking (like frecency) https://github.com/dlants/needle

Exactly the same as I used it on the age of frameworks, the age of Java and .NET, the age of compilers, the age of ...: you take it by the helve and swing the business end towards the object.

I've had much more success with agents reviewing my code and offering inline autocomplete over LSP than I have with letting the agents write the code, which I then try to review. I end up with a much better mental model of the code and higher quality output than either I or the agent could do alone.

Neovim can already have all the agents running in different terminal buffers or there are plugins popping up every day to have deep integrations with your favorite or we even have some interesting harnesses that are unique to neovim like sidekick.

As always, the ability to compose small tools and edit any file allow neovim to stay relevant and more powerful than ever in my opinion while not forcing workflow changes like the others

AI + Prompting can get you there, but it's still fairly laggy. Honestly, VSCode (aka: Cursor) w/ the vim plugin, and `F2-rename` has been the sweet spot for me. Reviewing diffs with `git diff | view -` and browsing them with vim is another useful.

:wq

but i don't use ai to write code for me -- i use it as a companion thing where i ask questions and then, instead of asking for code, i implement everything myself.

it keeps me sharp and helps me understand the lastest ai stuff.

Most of all, Neovim is helping me keep an eye on the code I develop at all times, and helping me keep writing code manually as well. It think it's especially important to be mindful about what we're doing these days because we're at risk of all becoming vibe coders as the AI assistants improve.

In essence, this is how: hjkl, G, gg, $, 0, w, b, e, i, y, p, <leader>e, <leader>o, <leader>ff, <leader>fw, /, dd, dw, grr, ]b, [b, :w, :q, :wq, etc... :)

I can jump to one tab look at the code, jump back over and talk to claude for a little.

I can spread this all across several projects using herdrs workspaces.

I still write code when it makes sense.

Sometimes i annotate the code with comments, hop back over and ask the LLM to consume the annotations i just added and make changes.

Sometimes i ask the LLM to analyze lots of code, and come up with a plan of attack for me, then i go implement it myself.

For Personal projects I write much more of the code myself still, because i enjoy it. For work, i do whatever gets the best outcome most efficiently.

Right now I'm using TMUX with Claude Code and Vim side-by-side, but I mostly use vim to look at the code and make small changes, while I review the code changes directly on GitHub PRs.

And yes, I admit I look at the code less than before. For as much as I'd like to say it's untrue, I'm increasingly spending time in crafting skills to make sure they don't break the code, trusting the Coding Agent more and more, and consequently looking less at the code itself (which it doesn't mean I don't know how it works, I am in a sort of "reviewer mode" as a coworker writes it, with additional care and attention ofc).

So yeah I was wondering how did it change for you and if you think it still makes sense (it's my understanding that the agreement is "yes" apparently, with which I tend to agree!)

I've noticed that my preferences for tools and languages is shifting as well. I'm happy to work with stuff that I previously would have not touched now because it would take me too long to get up to speed with languages, frameworks, etc. That stuff no longer blocks me from being productive. I still care about code quality, good design, etc. but a lot of that stuff doesn't require me to micro manage a code base. In the rare case I want to open something in an editor, I use vs code. I've removed a lot of the plugins in that as I'm not really using them any more.

I actually do reach for vi on the command line sometimes. But I've never been very good with it. I know how to do simple edits and save the file. I just never really got into it. I memorized a handful of key bindings somewhere in the nineties and that's it. I know some people that live in this editor and swear by it but for me it's just something that's there by default that is vaguely useful in a pinch if there's nothing else.

I have neovim hooked up to a local llama.cpp (through lemonade) for completion, but I have not found a plugin that I’m happy with. Avante is probably the closest because you can give inline instructions, but it both got very very heavily and stopped working with small LLMs so I uninstalled it. I’m using minuet currently.

Quite satisfied with that, haven't opened vscode/zed in a while. Making something like that is easy with LLMs now.

https://github.com/martanne/vis

I've also customized Zed's UI to optimize for reading and reviewing code, and mostly adding notes or small focused edits, rather than writing entire files from scratch.

With Opus I still feel like I'm pair coding and want to get in there and make some changes myself, but working with Fable (even Fable managing Opus agents) had me in a completely different mindset, one where I realized I would just be getting in the way.

Granted, the language servers are getting dusted, but it's much nicer to write goals in markdown in vim and send it to LLM in a self-written harness CLI; and even look at the results in the same way. All unix. LLM is just the latest toolbox addition.

I'm writing less code, but I'm reviewing more code. And I use magit in Emacs for reviewing code.

And I run my agents inside my emacs. I use my emacs like most others use tmux -- my emacs session is persistent and I connect with emacsclient.

Furthermore, a lot of my workflow is now done on remote servers (i love exe.dev) where claude code is sandboxed to an extent (it can still cause damage, just not to my main computer's file system). When I'm configuring those, i have a setup script that installs all of my vim files just the way i like them, so vim behaves exactly the same on a remote server as it does locally. I can edit things as needed. I can also access claude code on those servers as well. So working on my remote machine feels a lot like workin locally [1].

[1] I'm aware that i can setup cursor or vs code to access SSH servers, but it's just not as easy and doesn't feel as natural, IMO. There's something i like about needing to call `ssh remote-server` first.

It really can be a fancy auto complete, but more agentic usage moved out of the editors (and I think that's a good thing).

Definitely not a vim power user though. I just like writing markdown spec-ish prompts and opencode simplistic input box isn’t ideal for that

"vimdiff" is a really great way to review code changes side-by-side.

1. /edit => opens in editor

2. /feedback => opens the last llm message in an editor so i can inline feedback. Think inline responses in email vs bottom posting.

3. /review => same as /feedback but opens up the diff so i do an inline review. Yes I still read the code it ships.

So basically in this flow vim becomes integral to doing anything involved.

I prefer commits to be granular to the extent that I manually edit the patch in git add -p, albeit rarely. So I have a pty plugin that my agent literally sends control codes to. This is also useful in general for LLMs driving any interactive terminal program. Long live text, I guess.