r/Clojure • u/yogthos • 17d ago

A practical workflow for LLM-assisted development

https://yogthos.net/posts/2026-08-17-llm-workflow.html
40 Upvotes

83% Upvoted

21 comments sorted by

8

u/lgstein 16d ago

To those afraid of missing out I can say that while there are certainly somewhat time/cost efficient ways to generate software through LLM subscriptions, I can assure you that I write Clojure code professionally day by day and don't have any LLM CLI installed or API hooked into Emacs, I don't ship any LLM generated line of code, I don't have any PRs "reviewed" by LLMs, and neither do my esteemed colleagues care about any of that. None of us don't worry or even care about it, beyond it having replaced and improved upon a Google / Stackoverflow search.

5

u/ElectricalSloth 16d ago

Happy for you! Professionally I'd be wondering why my team wouldn't want the speed boost, but if the person shelling out the checks is happy then great!

4

u/lgstein 15d ago

In Clojure typical domains such as health or finance, reliability is often more critical than speed. Also there are codebases which need to be maintainable without depending on a subsidized third party subscription service.

From what I have seen in JS world so far, the speed boost only holds for the first month or so anyways, after that its all fixing and patching the epistemic mess.

2

u/yogthos 14d ago

I don't see how reliability is affected when you use these tools properly. You still do design, you spend the time to understand the problem, and you review the code whether it's generated by hand or an LLM. Nothing changes in that regard in my experience.

Also, the whole notion that you need a subsidized subscription is misinformed. Local models like Qwen 3.8 can already do comparable work to frontier models from just a few months ago. And the local story will only get better going forward.

Finally, Js world was exactly like this long before LLMs were a thing. On the other hand, I've been working on Jolt for over three months now, and I'm not fixing and patching any epistemic mess there. But if you want to point out specific problems in the codebase that you think would've been avoided by not using LLMs, I'd be happy to talk about that.

4

u/lgstein 14d ago

Reliability is affected everytime you trust LLM output. It was not written by a human who can be held accountable, or somebody with even a mental model of the program, and due to nature of language models its optimized for plausibility rather than correctness. If reviewing this takes you less time than properly writing it yourself, you are risking reliability. If not, it is a trivial program that could have been copy pasted or generated via template. If it takes you the same or.more time, LLM is just solving a motivational problem you might have.

The benchmark for something like Jolt will be whether people trust it with lifes and bank accounts, not what I think about it.

3

u/yogthos 14d ago

Why would you trust LLM output though? It's just code that you can read and understand like any other code. It's not a magic black box you have to take on faith. LLM is a tool used by a human who can absolutely be held responsible for the code they produce. Literally nothing changes here from how regular PRs and code reviews work.

And the reality is that most code in any given application is, in fact, trivial. I've been doing software development for for at least a couple of decades now, and the amount of truly novel and interesting code I see in any given project is rather slim. Most of it is making yet another web service end point, writing a db query, creating a UI component. If you work on projects where majority of the code is novel and interesting, I'd really love to hear more about that.

Meanwhile, trust comes from amount of usage a project has, how much testing it does, and the the demonstrated ability to produce working software of the authors. Just because code was written artisanally doesn't make it automatically more trustworthy. We've all seen plenty of terrible code written by humans. What actually matters is the development process.

And in the short term nobody has to trust Jolt with their lives or bank accounts either. Most software out there isn't mission critical. And somebody making a fun game using Jolt will be just fine if they find a bug or two, as they would with any new piece of software.

1

u/lgstein 13d ago

My experience is that I can author program text in the same time or less than what I need to properly read and adjust LLM output. The generator has no coherent style, it sets wrong expectations in comments and naming, it claims authors intention where there is no author with intention, it offsets reading intuitions. It also misleads one to sink time into non issues. This paper on the fundamental differences between human authored and machine generated output captures many of these differences https://arxiv.org/abs/2512.19466

Trivial code like you mention should be generated by templates, macros, DSL, declarative solutions - not approximated by GPU clusters with a different outcome every time. Closing the semantic mismatch between human intent and general purpose programming should be treated as a design and abstraction challenge, it can't be solved satisfactory by outsourcing to a guessing machine. As an oversimplified example, you'd rather declare a RBAC configuration in data instead of English with an LLM writing a different function for every access check.

I don't believe that development processes matter that much for trust or quality. In almost all projects I have seen, no matter whether a small startup or big corporate, leadership places immense trust in one or two highly highly committed (and paid) lead devs. For arts and prototypes, of course, everything goes.

3

u/yogthos 13d ago

My experience is that there was no way I could build anything on the scale or quality of Jolt in three months by hand. If you can, then you're a far better programmer than I am.

The idea that the generator has no coherent style or that it sets wrong expectations in comments and naming does not match my experience at all. The models are, in fact, quite good at adopting existing style of the project. I also don't know what you mean by it claiming intention. The intention always comes from the human, and the model merely executes it.

I've seen this paper, and I'd argue that the authors build their entire conclusion about Epistemia on a wildly idealized version of human cognition. The glaring problem with arguing that LLMs are uniquely dangerous because they replace genuine truth evaluation with mere linguistic plausibility is that human minds run on linguistic plausibility and heuristic shortcuts rather than rigorous epistemic loops. Human judgment is often flawed, and even people who have many years of training in the scientific method fall prey to biases they know about. That's the whole reason we have the concept of peer review. Humans fail the exact same test the authors apply to LLMs.

Somebody still has to write templates, macros, and DSLs in practice. If this was a solved problem then Clojure projects wouldn't have repetitive code in them. Yet, majority of the code in any given project is boring. Meanwhile, the human mind is the very definition of a guessing machine. You don't write the Platonic shape of the code on a first try. What happens in practice is that you do a first approximation, then iterate on it. That's precisely why REPL driven development is such a pleasant experience.

And we fundamentally disagree on how quality of code is evaluate because I see the development process as the only thing that matters in tangible terms. Every successful project I've worked on had clear specifications, well defined tests, good project architecture and so on. It was never dependent on a single genius writing perfect code.

8

u/yogthos 17d ago

got around to writing a bit about my workflow

/u/policyenvironmental

/u/Arjuna144_

2

u/Arjuna144_ 9d ago

Thank you a whole lot!! This is really appreciated. Much love! <3

2

u/romulotombulus 16d ago

Thanks for sharing this. Some questions:

Do you still write code at all? Do you read all the code generated by the LLM?

Are you running your harness inside a sandbox (Docker etc)? If not are you at all concerned about the security implications?

What is your primary interface for sending prompts to the LLM? Do you type right into the Dirge UI? Do you write specification docs that you pass to the LLM?

Do you get the same enjoyment out of this that you did when you were writing all of the code? This is maybe my biggest hangup about LLM-assisted development. I like writing code. Higher-level design is fun and good, but it pains me to give up the lower-level stuff that I also enjoy. I feel like the bargain we're making is we can be 20+ times more productive, but we can't have fun anymore.

7

u/yogthos 16d ago

I don't really write a lot of code by hand at this point, but I do generally review the PRs generated by the LLM. I find that tends to work pretty well when you split tasks up front.

I tried doing sandboxing, and it works for some things, but I found most of the time it was more trouble than its worth. So, a lot of the time I don't bother.

And yeah, I just have terminals open and drive the agent using the TUI. Sometimes I'll put stuff in a markdown file and then tell the agent to look at it. But most of the time, I use the built in issue tracker for everything. It's basically a kanban board with epics and tasks associated with them. It seems to work pretty well for keeping stuff organized.

In terms of enjoyment, I actually find I have more fun now. I enjoy writing code, but in very specific cases. Like if I'm making a small visualization demo or something where it's just a few hundred lines of code, and I can keep the whole thing in my head. These kinds of projects can be really fun, and you can really think about how to write a perfect program that does a specific thing really well.

But I find most code isn't like that. Real world projects always get messy where you end up having to make compromises, and a lot of the code isn't really novel or interesting. Once you've written a bunch of service end points, database queries, UI components, to me it just feels like doing the same thing over and over. The details might be different, but conceptually you're generally solving very similar problems from one project to another.

The real fun for me is being able to go from an idea in my head to something I can play with and see how the idea works in practice. One recent example is the glimmer reactive library I made for Jolt. I had this idea for a long time that you could build something like Reagent but without needing a VDOM since the data in reactive atoms becomes the source of truth. So, I made a version of that, then I build a bunch of [GTK bindings](github.com/jolt-lang/glimmer-gtk) for it. There was nothing really interesting in mapping out the FFI for GTK, but the end result was really exciting to me cause I could start making native UIs the same way I do with Reagent apps, connect nREPL to the app and tweak the UI live. So, the LLM did a bunch of boring plumbing for me, and I got exactly what I had in mind in just a few hours. Then I went ahead and added a TUI backend on top of ncurses, and realized this approach could work with datastar, so I got that working here. Each of these projects would've been weeks of work before, but now I can go from having an idea to trying it in a day or so. And I've accumulated a ton of different project ideas over the years that I can now try out.

2

u/daver 12h ago

Yea, so I’ve been an AI skeptic for a while. I tried Aider 18 or so months ago with Claude and Gemini and the results were mixed. Sometimes it seemed like magic and sometimes it would just break things and mess up the codebase (git reset hard level stuff). I’ve been using some of the newer models this year, however, and things have really gotten a LOT better. Even if you don’t choose to use the model to write your code, there are a lot of support roles that the model can fulfill. For instance, I’ve used a model to inspect a library that wasn’t documented fully and asked the model to create an architecture-level manual for it. I’ve had a model review tests and suggest missing test cases to increase coverage. I’ve had a model write throw-away scripts to interrogate a git repo to extract non-trivial statistics from it. The model wrote the script in bash. I didn’t care because it was a throwaway. Anyway, I still like to write code because I like to write code, but I’m increasingly turning to a model for chores that would have taken a long time. So, thanks for the tips, @yogthos. It’s always nice to look over someone else’s shoulder and see how they do it.

1

u/yogthos 10h ago

No prob, do hope sharing experience will help with your workflow. And the rate of progress on this tech is really astounding. I used to be somewhat skeptical of how useful it would really be about a year ago myself. I'd play around with Cursor, and it felt like a better auto complete where I could get inline help figuring out APIs, or doing small chores. Then about half a year ago, I paired with a friend using claude code, and it was really eye opening for me to see how much the agent could do on its own.

What I'm really excited about though is the progress on local models. Lately, I've also been using Qwen 3.6 and now 3.8 locally for a lot of tasks, and it feels generally comparable to Claude 4.6. It's absolutely mind blowing that you can now have a model running on your computer that has similar capabilities to what used to be a frontier model just a little while ago. Granted I have a beefy macbook with 64 gb ram on it, but that's still consumer grade hardware and not even top of the line.

I'm very optimistic that in a year or two these models will get optimized enough that you'd be able to do most tasks locally and at that point you own the whole tool chain that runs entirely on your machine.

-1

u/beders 17d ago

I just had Claude start up 2 instances of our backend, connect to both REPLs and run some checks on the distributed task thingie I asked it to write earlier.

Another moment where things felt like magic.

OTOH, I’ve also spent a lot of tokens/credits to fix stuff an LLM hallucinated.
Mixing models by guessing what the cheapest one is for a specific task (or using Copilots Auto mode) can cost you more time compared to re-writing the whole thing.

I haven’t written a line of Clojure in a long time. Opus 4.8 is amazing

5

u/pdoherty926 16d ago

I haven’t written a line of Clojure in a long time.

I'm not criticizing you but this would bum me out. If I was lucky enough to be paid to write Clojure professionally (I have been but always under the radar) then I'd want to bask in the full experience.

To zoom out a bit, though, why even use Clojure at that point? Are you or your org still using it for greenfield projects?

8

u/beders 16d ago

Oh, I'm reading a lot of Clojure. Basically I'm in code review mode all the time.

(btw, we are obligated to use AI wherever possible - across the very large firm - in all areas)

Claude is really great at both: Greenfield stuff - where we cranked out ClojureScript for a brand new product offering in record time.

And extending our existing Clojure codebase. Claude excels at understanding and reproducing patterns you used elsewhere in your code.

Clojure is a prime language for LLMs: it is not only cost-effective (Clojure code is quite dense), but the fact that 90% of code is data transformation, makes it quite easy for an LLM to crank out correct code, spit out unit tests etc. And it can run the code immediately through a connected REPL.

I guess the big surprise was that readability is not suffering when using LLMs and we get better documentation for free.

We use Clojure because to us it is the best language to tackle thorny data problems in the enterprise, B2B and B2C.

3

u/zabolekar 16d ago

I haven’t written a line of Clojure in a long time.

I know you mean it in a good way, but it sounds sad even with context.

-9

u/chat-lu 17d ago

Step 1: Chuck the LLM in the garbage can

There is no step 2.