This is true - and a reason I'm not sure about this package. I'll still try it, but I don't think it's the right way forward.

Pretty much the only advantage is that you get access to logic available in the claude code CLI - which in large parts probably already exists in emacs or extensions. On the downside it'll bind you to claude code.

I'm generally using a generic LLM wrapper - emacs has two good ones, gptel and llm. I have both configured, as both are required by some of the extensions I'm using, but currently prefer gptel: It seems to be more advanced, especially when it comes to tool use.

Advantage of that approach is that when you're hitting a wall with one LLM being stupid with one specific issue you can just switch to a different one. Or you can use the same environment with locally hosted LLMs.

Disadvantage is that the IDE/project functionality is not tied up that nicely yet - there are a few attempts (like minuet or evedel), but nothing I really got into.

Currently I'm mostly doing a chat buffer, and the LLM has tools available to inspect and to some extend alter the current state, published here: https://github.com/aard-fi/gptel-tool-library - that works pretty well on a per file basis, and to some extend it can figure out project details, but overall it lacks project info - in part that's a context limitation thing, where that info should be provided as additional context for each instruction (which I assume the CLI is doing).

What this approach also nicely enables is fun experimentations:

- https://github.com/aard-fi/buffer-turtle implements simple turtle graphics in an emacs buffer, and has bindings for the LLM to control the turtle - https://github.com/aard-fi/arch-installer has the glue to have the LLM interact with a serial port, and some glue (like basic ANSI escape parsing) to make the result look somewhat reasonable in an emacs buffer. That allows it to do stuff like trying to install Arch linux in a VM

Both repos have links to youtube videos with some runs.