Post

If you say refactoring, do you type those changes by hand or give instructions to the LLM?

I'm always astonished that LLMs don't (can't?) use the LSP itself for refactorings. Typescript has lots of great built in refactorings. The LLMs are decent at refactoring without it, but there's something very funny about the magic computer from the future using grep like it's the year 2000

I imagine you probably could wire them up, I know opencode have an LSP integration but I’ve not tried it myself.

It can be either. Sometimes there’s structural changes that I know I want to make and I’m confident it’ll be quicker to do it by hand, so I do. Sometimes I just have a sense that something could be simpler so I let the LLM have a go and see if I like the result.

That makes sense to me and is also roughly where I landed when experimenting — manual intervention ofc seems hard to square with the hype b/c it means you still need a lot of skilled software developers to get sth done in the end

Have you used Codex for the 'steering' angle? It reads your message while continuing, whereas claude you have to explicitly stop it, or it waits for some kind of gap to actually read your message. The message queueing in claude code just feels bad in general now

I too also went a bit over the deep end, with the point at which I first read the code being a (draft) PR, and honestly it was kinda cool at first but I'm now back to either babysitting or heavily scrutinising and iterating on a plan before starting to execute.

This is on Monzo's big and complex systems though, very different approach when doing something for a personal project.

And I like this workflow a lot. If I have an idea that’s a big departure from the current state it’s very cheap to try it. I’m iterating with the LLM, I’m using the components I’m building constantly, tweaking small things that feel wrong. I can bring ideas to life I may have skipped on before.

And because I can talk to the LLM with my voice, it can interpret my words very well, it reduces the typing I do and thus the pain I get from tennis elbow. Hopefully those days will be soon behind me, but in the meantime this is a huge win for me.

And this has all made it very clear to me that whenever I see slop in the wild, it has little to do with the LLM. If you aren’t spending the time to make sure what you’ve built meets the quality bar, that’s a you problem. A skill issue, the kids might say. You can build great software with LLMs.

This aligns completely with where I’m at too. Code may never have been the hard part, but it’s still an important part.

I think it’s going to follow a similar cycle to the discourse around dynamic languages. - “Developer time is the expensive bit, write in a more expressive language like Ruby or Python.” - “Actually this is really slow and annoying, let’s make it faster.” - “Maybe we actually rewrite in Rust.”

“Speed is a feature, actually.” And that’s not to say dynamic languages have no place, I love Python and write a lot of it. But the answer was never to completely eschew performance for ease of writing. The answer will never be Gas Town.

I saw a phrase somewhere that really resonated: “you need to know what’s there to prompt what’s next”. I find myself learning a lot and being inspired from just reading the LLM code. It’s also fun to ask LLMs to write ast-grep rules to never write try-catch again

They’re so good at using the CLI, I posted about it a while back. bsky.app/profile/samw...