I think you missed my point. Yes I can work on a library with an LLM, but I can’t work on the LLM itself, which is the interface I’m corresponding with now, where previously it was the library. Previously, the thing I was interacting with was malleable in a highly well-defined way. Now it isn’t.
Yeah: in a world where I am coding, I can put in the effort to make the software work the way I think... to use an LLM, I largely have to think the way it wants to work / converse.
I get it but not every editor/IDE was vim/emacs. Some tools were more or less rigid and today you still can have malleable workflows through custom workflows and harnesses.
It's not like you need to limit yourself to Anthropic and Claude Code. I myself developed "rik" a harness that can modify only a single file and hook up blazingly fast models for it to be like wide-context autocompletion.
1) I really wasn't talking about an editor at all: I was talking about the libraries and frameworks you use to program, so that the way you interact with the problem space is the way you think. I mean, even as someone who has almost exclusively used vim for the past 25 years of coding, if I went back to the prior 10 years before THAT of using Visual Studio, I'd have described this no differently.
2) In fact I have never used off-the-shelf coding assistants (Claude Code, etc.) and have only used my own harness; yet to me the issue is that the model itself often likes to think about problems in ways I find frustrating and unhelpful. The issue isn't at the level of how diffs are applied (that's commodity) or how context is managed (I can fix that) but in how problems are described, how abstractions are managed, and the language used to discuss them.
