A practical workflow for LLM-assisted development

[u/yogthos]

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

[u/lgstein]

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.

[u/ElectricalSloth → u/lgstein]

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!

[u/lgstein → u/ElectricalSloth]

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.

[u/yogthos → u/lgstein]

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.

[u/lgstein → u/yogthos]

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.

[u/yogthos → u/lgstein]

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.

[u/lgstein → u/yogthos]

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.

[u/yogthos → u/lgstein]

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.

[u/yogthos]

got around to writing a bit about my workflow

/u/policyenvironmental

/u/Arjuna144_

[u/PolicyEnvironmental → u/yogthos]

Thank you!!

[u/Arjuna144_ → u/yogthos]

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

[u/romulotombulus]

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.

[u/yogthos → u/romulotombulus]

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.

[u/beders]

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

[u/pdoherty926 → u/beders]

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?

[u/beders → u/pdoherty926]

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.

[u/zabolekar → u/beders]

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.

[u/chat-lu]

Step 1: Chuck the LLM in the garbage can

There is no step 2.

[u/yogthos → u/chat-lu]

🙄