It'll even suggest it
You want a single RPC websocket go for it
2. There absolutely are cases where modifying code "manually" is unquestionably faster than prompting an LLM. There are trivial examples for this - eg only an insane person would ask an LLM to rename a variable rather than using an LSP for that. It would provably and consistently take more keystrokes. There are less trivial examples as well, like, you know, having an understanding of your codebase and using good abstractions/libraries within it that let you make large changes to the program's behavior with little boilerplate code.
One can argue that producing a lot of complex changes through an LLM is faster, which I would agree with, but then see point #1. Sustainable software development has up to this point relied on iterative discovery of the right small components that together form a complete, functional, stable system (see "Programming as Theory Building").
There's zero indication so far that LLMs are capable of speeding up the process of creating complete, functional, stable systems. What every org within my career and friend circle is seeing (and research into productivity impacts of LLMs on software development is showing) is the same story - fast prototypes that either turn into abandonware, personal tools, or maintenance nightmares.
2. Yes, true, but the point is to move up the abstraction hierarchy, so instead of asking the LLM to rename a variable you describe the concrete business goal you're trying to achieve.
It is true that coding agents cannot build fully complete stable systems completely unguided yet. That's why we still have jobs. But it's wrong to suggest that they don't deliver value or that they're destined to produce trash every time. It is a matter of oversight and guidance and setting your codebase up for success. That does require work, but it is not impossible, just a different skillset from the ones we've been used to.