nb: Bruce also did figwheel, a hot/live reloading tool for Clojurescript
right now the advice in the readme makes a lot of sense: use git (or similar) for checkpointing
a bit like climbing with ropes and anchors
More discipline than what is required when trying to keep track of all of that in your head? Personally I use a REPL because I'm lazy and dumb, and the REPL helps me keep track and makes sure I don't do stupid mistakes. If I wanna know what value a thing has, I just ask the REPL, instead of trying to retrace some logic by reading the code again.
I think an LLM could help with that. Ideally, I could say, "Please add the widget-muckle-frobnicate function from the current REPL session to the codebase. Fix or flag any shortcuts I took in its implementation, such as hardcoding configuration and naming functions 'foo' or 'bar', and add unit tests that include the examples I tried in the REPL as well as property-based tests to exercise edge cases."
I think this is your problem, those two things should be the same, not two different things. When I'm working with a Clojure REPL, I write down code in a .clj file, then evaluate that code via the REPL but without leaving my editor. "Moving" something from a REPL session to the codebase is a matter of saving the current file you're editing.
I wrote more about the exact process I typically use when going from "prototyping with a repl, to having a test case" (https://news.ycombinator.com/item?id=44106445) and it's essentially changing "comment" to "deftest" then saving the file again, now it's a unit test.
I do find value from LLMs in general, but I don't see much value in taking a process that takes a minute or less and trying to make LLMs do it.
I might type a "5" and evaluate it just to see if the REPL is busy or not, but otherwise, everything the REPL evaluates comes from an emacs source code buffer, sent via CIDER to the REPL. At most, it might be in a "Rich comment" and thus not evaluated next time I load that file, but those tend to be small, interactive tests and not defns.
Unless emacs crashes with the buffer unsaved, there's nothing the REPL has that the source file doesn't.
In general I wonder how to quickly set up mocks and such with chatbot integrations.
Usually it's a matter of renaming "comment" to "deftest", and move some things around. Not sure how/why it would be different when using a LLM compared to doing it manually.
This is all in the file as saved to your version control:
(defn greet [name]
(-> (str "Hello, " name "!")
println))
(comment
(greet "worldsayshi"))
When testing against an LLM you probably want to mock its responses for tests. Which is quite doable by copy-pasting its responses. I'm just curious what the "best" workflow is.
1. Write a function that returns a LLM response
2. Play around with this function in a `comment` block, highlighting what I'm testing
3. If I find a response I'd like to "cement"/save and use for testing, Conjure (what I use to connect to the REPL) has a command that is basically "evaluate what's highlighted in the editor with whatever that returns when evaluated", so that basically copy-pastes the return value into the editor
4. Move it into a test somewhere
Not sure there is a better or faster workflow, from deciding "Hmm I want to test against this in the future" to "make test checks this" takes something like 2 minutes with a workflow like this.
I’m not a Clojure user but I’ve set up the Jetbrains MCP server and Claude Desktop has been working really well with it. I added a system prompt telling Claude to inspect the CLAUDE.md (used with Claude Code normally) whenever using Jetbrains to get project context, which is also working out really well.
When working with Clojure, I've been using LLMs primarily for two use cases:
1. Search
2. Design feedback
The second case is more interesting. I believe the design of a system is more important than the language being used. I'd rather inherit a well-designed codebase in some other language over a poorly designed Clojure codebase any day. Due to the values of Clojure embedded in the language itself and the community that surrounds it, Clojure programmers are naturally encouraged to think first, code second.
The problem I've run into with the second case is that it often takes too much effort for me to get the context into the LLM for it to answer my questions in detail. As a result, I tend to reach for LLMs when I have a general design question that I can then translate into Clojure. Asking it specific questions about my existing Clojure code has felt like more effort than it's worth, so I've actually trained myself to make things more generic when I talk to the LLM.
This MCP with Claude Code seems like the tipping point where I can start asking questions about my code, not just asking for general design feedback. I hooked this up to a project of mine where I recently added multi-tenancy support (via an :app-id key), which required low-level changes across the codebase. I asked the following question with Claude Code and the Clojure MCP linked here:
> given that :app-id is required after setup, are there any places where :app-id should be checked that is missing?
It actually gave me some good feedback on specific files and locations in my code for about 10 seconds of effort. That said, it also cost me $0.48. This might be the thing that gets me to subscribe to a Claude Max plan...
It’s really powerful.
3. Agentic Coding (aka Vibe Coding)
You need to find a workflow to leverage it. There are two approaches.
1. Developer Guided
Then you start creating the namespaces you want, but you don't implement them, just create the `(ns ...)` with a doc-string that describes it. You can also start adding the public functions you want for it's API. Don't implement those either. Just add a signature and doc-string.
Then you create the test namespace for it. Creates a deftest for the functions you want to test, and add `(testing ...)` but don't add the body, just write the test description.
Now you tell the AI to fill in the implementation of the tests and namespace so that all described test cases pass and to run the test and iterate until it all does.
Then ask the AI to code review itself, and iterate on the code until it has no more comments.
Mention security, exception handling, logging, and so on as you see fit, if you explicitly call those concerns it'll work on them.
Rinse and repeat. You can add your own tests to be more sure, and also test things out and ask it to fix.
2. Product Guided
Then you ask AI to generate a design specification. You review that, and have it iterate on it until you like it.
Then you ask AI to break down a delivery plan, and a test plan to implement it. Review and iterate until you like it.
Then you ask AI to break up the delivery in milestones, and to create a break down of tasks for the first milestone. Review and iterate here.
Then you ask AI to implement the first task, with tests. Review and iterate. Then the next, and so on.
Off topic, but I have found Google Jules to be useful for Clojure development.
Bruce recommends/mentions Claude Desktop specifically because it makes it easy to try out Clojure MCP without having to worry about token cost.
The LLM agent will often write the code for a function and immediately follow that code up with several smoke testing expressions and the eval the whole thing in one go, function and tests.
It will creatively setup test harnesses to enable it to exercise code while it's being developed. (think html endpoints, starting and stopping servers, mocking)
And it goes on from there. Its an experience, and I submit to the reader that they experience it sooner than later bc its an extremely effective workflow and its AWESOME!
fjalahdbtnt•14h ago
If you need to run code locally, why bother paying google to run claude?
> I highly recommend using it with Claude Desktop to start. It's prettier and there are no api charges!
???? How does this make sense to anyone
didibus•13h ago
Say you have a Clojure project, it's in a folder on your computer where you likely cloned or initialized a git repo.
Now you want to leverage an agentic LLM that can connect to clojure-mcp so you can prompt the LLM to make real edits to your project source files, folder structure, resources, documentation, etc.
Your options are kind of limited: - Amazon Q CLI - Claude Code CLI - OpenAI Codex CLI
Those are the best. Then you have the IDE based ones, like Cursor, Windsurf, Copilot agent mode (in public preview currently), and so on.
What they are saying though is that Claude Desktop also support MCP, and can be used without incurring API charges.
Honestly, the in-IDE ones, for me, are not very good, you really don't need this stuff tied up inside an editor. I prefer the CLIs personally, but can see how you can also just as easily run Claude Desktop as a side-bar than need something inside your editor.
roenxi•13h ago
throwaway314155•12h ago
Out of curiosity, which option do you go for?
didibus•53m ago
The others I listed above come with a lot of tools baked in, and I'm not sure if they could interfere, like the LLM might prefer one that's bundled to using the clojure-mcp ones.
Otherwise I use Amazon Q CLI, because it is the cheapest of the bunch. I'd say Claude Code CLI is the other I'd use personally.
dotemacs•11h ago
Ampcode have a CLI, which is their agent using Claude 4.
Google also came out with Jules a few days ago.
There's aider, with which you can use whichever LLM you'd like.
I'm pretty sure that there are others...
didibus•56m ago
Ampcode I heard of, but I also heard it's very expensive, same for Devin. I also don't know if either of them support MCP.
I'm sure there are others, of varying quality, but realistically, the options you'd want to use are the ones I listed I think.
P.S.: I'd been looking for alternatives by the way, something that lets me use OpenAI models, I've yet to try it but heard good things about: https://block.github.io/goose/