Giving up X for at least a couple of weeks I might check once a day to see if I have an interesting notification, like an interesting reply to something I said Prior to summer 2025, I had avoided X for about three years. Maybe I should do that again!

While I've been using nvim + opencode for a while now (thanks to a post by @Egge IIRC), I only just this evening integrated git into it properly, in order to make it easy to view the changes made the AI and then challenge the AI about specific changes I'm using three nvim plugins: gitsigns, telescope, and I've configured 'diffview.nvim' but haven't really used it much yet

I first read this YouTube preview as saying: "Stop trying to make Luke's Consensus change happen" I guess I'm spending too much time on X arguing about the fork

Now, I sometimes use 'Gemini Flash 3' for planning and 'GPT-5.2 Codex' for building. This is only because, in Opencode, I've noticed that Gemini kinda crashes in build mode; it's works for some time and then just stops in the middle of the task. Maybe just a funny detail in how Opencode is integrated Anyway, in practice, I'm still mostly using my Claude subscription inside Opencode, but that's cheap. But I like the ideas Gemini has for improving the codebase

Asking AI the important questions: (inspired by seeing this game in 'Hackers', the 1995 movie)

LLMs duplicate code too much. I got it to reorganize a bunch of code for the client-side of my system (the cashu channels). It liked and understood the changes I made, both for security reasons and maintainability. I immediately asked it to apply the same thing to the server side. It immediately understood and saw the great similarities between the client side and server side It did it, but didn't realize it has duplicated lots of code until I asked it to check. This isn't really a complaint. I'm actually glad that it (Opus 4.6) makes this mistakes as it means I'm still relevant as the architect and designer 😀

LLMs still (I basing this mostly on Opus4.6) don't appreciate how to order items in their todo list If we're working on component A, where A depends on B, and then we realize that B needs to be updated before A can be updated, then the priority should (depending on the precise circumstances) be to get B correct before updating A. It's too keen to do major refactorings, redesigning everything in one step. That's still too likely to result in everything breaking. I often have to intervene to help it identify the best (least likely to break) order in which to change things. Get the interfaces right between your components, starting with the lower levels, before working your way up Of course, as the LLMs are getting better, I'm allowing them to be more 'ambituous' and to try to do bigger changes at once. But, as of now, their level of ambition in complex protocols/systems doesn't quite match their ability, and I have to intervene regularly: "Yes, we want to change X,Y,Z, but don't you think that we can change Y first and ensure that all tests keep passing before we proceed to X and/or Z?"