CiderGPT

[vemv]

A clojure-specific "gpt mode" would seem nice / better than context-switching to chat.openai.com. For instance, one could send the buffer's ns form as part of the prompt, so that GPT produces a new one that is a merge of your stuff + suggested stuff.

(Otherwise, having to adapt top-level (require '[,,,]) calls into the ns form is fairly cumbersome)

The response could be the whole new contents of your .clj file: existing + suggested contents. i.e. the buffer contents are replaced, you only hit save if you're happy.

Other bits of context that could be sent would be project.clj/deps.edn (so that it knows which libraries are preferred) or, who knows, maybe all your .clj files (with obvious IP concerns - I'd only do this if there was something like a .gpt-allow empty file at the project root)

Here's a POC session:

https://chat.openai.com/share/31edefae-845c-4ceb-abe9-64dcd95b473f

The way I thought of implementing this was at cider-nrepl level. Doing stuff with a Clojure backend seems better than a pure-elisp impl since:

• we can build "context" directly by inspecting files in PWD / the classpath
• we can build advanced HTTP requests (including sending/receiving files)
• overall greater ease/testability for intrincate features like dynamic prompt generation.

As mentioned, client-side, the impl could be as simple as replacing the whole buffer. But an agnostic backend can leave the choice open for more detailed clients.

Thoughts?

[expez]

Having played around with the various AI tooling a bit, I think this is a great idea.

I've been doing mainly two things:

1. Chatting, e.g asking questions like 'what is the best algorithm to X'. 'Why is foo used here instead of bar?'
2. Requesting code / edits of code

For both of these I find the Copilot Chat interface the best. Getting incremental inline completions to write substantial amounts of code is not the way to go, but that was how the original copilot worked.

The problem I have with copilot chat is:

1. It can be cumbersome to get the changes from the chat into the buffer
2. It can be quite hard to see what the AI agent actually changed, when it returns hundreds of lines. New code is often obvious but did it edit stuff that should've been left unchanged?
3. The context being sent is a complete black box (I picked a javascript react project to test the AI for this reason, assuming it would be optimized for this use-case)
4. It only does one round. Ideally the code goes through a few iterations before I'm asked to inspect it. E.g it could've tried to compile it and sent any errors back to the AI for fixes, linted it or even executed all, or a subset of the unit tests. I'm not sure what the roundtrips would be like, but I'd rather wait 10 seconds than have to go multiple rounds manually.

Aider does a few things that I really like:

1. It uses the ChatGPT API instead of ChatGPT (faster, not rate limited, can change the system message). AFAIU, ChatGPT is also (more) heavily 'aligned' which seems to be a detriment to performance.
2. It gets diffs from the API (GPT4 is apparently much better at this than 3.5). With the API costing money per token, and the length of the output being limited, this can make a big difference.
3. It uses ctags to concisely transmit context to the AI system. Since we pay for tokens on this end too, and the context window is severely limited in size, this looks like a big win to me.

[vemv]

Thanks much! I'll eye Aider again soon