Just to be clear: I haven’t made up my mind yet either :) that’s why I asked a question and avoided delivering truths or anything
Everything you said are all doubts I have, and especially the “it works until it doesn’t” is my biggest fear.
I’m probably less afraid of the “once it stops you’re screwed” part, I have been working in places where taking up codebases and products full of tech debt and renewing them was the norm, so I believe in the worst case that’s still doable.
So I’m not saying it’s an easy and straightforward revolution, yet I’m not so negative about it :)
Fair point on the QA, I might have some strong take there but it’s a chapter I’d rather not open now, but I guess the point of my post is on the last sentence of yours: is looking at the code really necessary to prevent headaches?
I have started delegating chunks of code without looking, and many times when I do look for one reason or another (I still want to know the big picture!) they looked good to me. So my idea it’s just that it could work, but I’m still experimenting as most of us :)
Yes I meant delivering value ofc, and I love the framing you propose, so my question is: are we already at the point where we could go safely faster, if we didn’t look at the code?
I think it’s a maturity model question, and an individual ability question. And maybe an industry tooling question.
Individual ability? Newer engineers should read and write more code than experienced engineers.
Maturity model? Teams with better access to objective specifications can read less code than teams without it. Teams with more experience with building loops and validation frameworks the same.
Industry tooling? I think we need more work on the spec driven development front. Some set of standards as to how we define contracts that LLMs can operate against that are more deterministic.
You mention in the original post having more bugs. When I use something for the first time and it has a bunch of bugs that prevent me from using it, I never bother using it again. That loss of trust is hard to win back and it erases the potential value. I want to deliver a good experience to the user, first and foremost, so they actually come back.
As a user, I’d rather the developers release later with a solid product/feature.
As a developer, I’d rather release something that won’t be a support nightmare.
“More bugs” is different from “a bunch of bugs”, and I agree on the support nightmare. My statement was implying that without looking at the code we might still be able to release something good quality that doesn’t fire back :)
neovim + claude code + open terminal is exactly my setup! But all the heavy lifting I used to do simply I’m not doing it anymore. I spend most of the time creating new worktrees and reviewing code, and I guess I’m just not interested about the implementation details that much (not that I don’t look at the code, but minor styling things I just ignore them right now)
I’m transitioning to this new way of work btw, so I still haven’t made up my mind. That’s why I asked for someone else opinion here :)
I see a lot of valid points, so let me specify better: now that the way we write code drastically changed, did you change anything in your vim setup? Like plugins, habits, anything?
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 still look at the files I want to change so that it doesn't go off and grep the entire project unnecessarily, burning tokens or getting the wrong idea.
So I still use a ton of fzf.lua to find the files to change and I have just added some keybinds to copy the open file path to the clipboard so that I can paste the path of the file to change it into opencode.
Code diffs I definitely look at locally with delta via lazygit or jjui. codediff.nvim is also good for resolving conflicts.
The main thing I've changed is just using JJ so merge conflicts can be resolved later by me manually without it blocking bringing in new changes.
If I just hand over the thinking entirely and don't know what has changed until I'm looking at it in GitHub I feel that removes the need for me entirely as by that point I'll be biased and will be less likely to change things to how I'd like them to be.
I removed most of the the autocompletion plugins from my Vim setup. (I had YouCompleteMe set up for intelligent suggestions, I've rolled it back to a simpler LSP-driven setup).
Also, I no longer update plugins without first manually reading the source diff to see if they've been infected by malware.
What you’re saying is super interesting, I’ve been using my setup for so long I might have missed some of the latest updates.
I spend most of my time on TMUX with Claude Code and vim side by side btw, but I’m using it just to search some specific code and making small changes.
I mostly review on GitHub PRs tbh
Yea by having claude code in a terminal window within neovim rather than tmux you can leverage neovim commands to traverse, copy, paste and otherwise interact with the terminal window like any other buffer.
There are also plugins with more specific workflows but I like really seeing how much vanilla neovim can get done
