Clojurians Log v2

Vibe coding never made sense to me for commercial projects. But I use LLM a lot to develop now in clojure, but I make sure I'm driving. So I'm always starting with a explanation of the problem and I ask LLM to map out all relevant code files, functions etc. To explain data flow and current architecture of that part. When I have that summary, I'm using LLM as a "rubber duck" so we first conceptually talk about possible solutions, figuring out how we can do it better, considering trade-offs, business requirements and validity of those etc. That's main part, than when we reach optimal solution, I ask LLM to prepare plan for it and execute. After that I analyze deeply the code changes, line by line very thorough review. And here are two ways, it could go, either it's shit and I will try to point AI a bit, and if I'm still not happy with it, I will go on my own explore it and try to make it fit. If it's pretty good I either do some manual updates to that or tell LLM what he got wrong to fix it. I've been very productive with this workflow, but I can't imagine this to work if I didn't had many years of experience, thinking, playing with code manually, inventing on principle and architectural/Domain driven design knowledge. And it's high cognitive task, because I have zero trust policy so I analyze each line and change itself and challenge it.

I think I have figured out a decent way to write CLAUDE.md. Simply tell it to LARP as Rich Hickey.

Haha, that's a good trick I use it often when I want code review. I tell it "Put yourself in a perspective of a senior software developer, think like Rich Hickey and Martin Fowler. Person who values both big picture and attention to small details as they make up the whole picture."

> What it couldn't do was figure out our own code at work around how to integrate this API wrapper. I can't blame it, I have a hard time figuring out that particularl part of our codebase 🙂 Definitely- if the AI can't give good recommendations or figure it out, it's a code smell.

@danielmartincraig Can you talk about your workflow? Specifically, the granularity of your specs and what they target. Like are you speccing one function at a time, one namespace at a time, one API at a time. one feature at a time, one infra resource at a time, one DB table at a time, etc.

I still love using AI coding assistants like Claude. But recently I have been taking a step back and making time to grind personal fluency. Jumping back into DS/Alg fundamentals just for fun, getting more time with my hands on the keyboard. There's a lot of pressure internally at work to use these tools and show value with them. Actually what brought me back to clojure recently was just the desire to have more fun actually writing code and iterating manually, which to me the REPL feeling was always the pinnacle of. I mostly view AI coding assistants as valuable for making progress on things I otherwise wouldn't have the time/energy to get to. Small ideas/projects I wanted to hack together. Little tools I don't have the time to spend energy on. I do think there's a ton of valid criticisms of LLM generated code, and of the ways people use them. Going forward we probably do have to put significant effort into keeping the mental sharp in terms of actual coding semantics separately, which is obviously valuable. My two cents. It's totally fine to be against AI coding tools, and the social/cognitive/political implications of LLMs, data centers, etc. I'd just avoid tribalism and logical fallacies. Quite a bit of "No True Scotsman", begging the question, and bad faith interpretation of the definitions of certain things throughout this thread.

Not entirely related but it's funny gradually going back to programming after months of abstaining, firing up a spec-guided workflow just for fun, to see what's what, and immediately hitting the feeling on the pic, where I know the LLM is wrong, I just can't quite prove it. Let alone explain it to the assistant. Too rusty, ugh.

Spec as in a markdown file specifying a design, or formal specification?

I am in the same situation as you are. Noticing the same things, asking the same questions. My current thinking is that the LLM is a great guide for when you don't want to dive into docs and instead learn incrementally. If it weren't for the LLM I might have not started this project and not learned the things that I have. The trap is when laziness kicks in even harder and I ask it to write the code for me. It is the antithesis of hammock-driven development and I hate that I do it, but it is so alluring.

> Spec driven development is where it's at. This is something I'm trying, and so far agree. > Spec as in a markdown file specifying a design, or formal specification? In my case, I started using Allium (by Juxt) to define behavior, then have Claude write the implementation. I still review all the code (with more or less attention to detail depending on blast radius) but focusing on the specs has changed the experience for me, from one of playing LLM lottery, to one of designing -> writing a spec -> writing code -> review, etc. There was a bonus with Allium: I used Claude to produce an audio script with a tour of the behaviors defined, and of the allium file itself. The resulting audio (by aws polly) is a nice guide that I can come back to if I step away from the project for longer than my memory holds. In 5 minutes I can get a refresher, which is backed by a spec. This process could help me both write code with less effort —my wrists are happy about that—, keep my understanding of the project sharp, and onboard contributors more easily.

I'm not able to quit it for now, but it hasn't been productive at all and make me want to quit everytime. Most of the time it takes longer to do the task with AI than by hand simply because it keep getting lost on easy stuff and thinking in code is faster/more familiar than in natural language. Nowadays i try to do all the information extracting and planning upfront, vertical slice the most i can and if it gets lost in something i just do it by hand and co-author Claude for the "help" I think the productivity promise may be delivered sometime in the future, but i dont see AI doing much more than "faster" in this decade. "good" and "with quality" are just far from what Claude Code/Copilot CLI are delivering today

Does it count when one has never even used vibe coding? :D Well, at least for anything "serious". Did some experiments and quickly realized that it's a dead end and dropped it. Had to review some vibe-coded stuff, not a fun thing to do.

Most (all?) people in this community picked up Clojure because they wanted their programming to be fun. Because they cared. Generating slop is not fun, even if it works, even if you can do it 1000x faster. It's just somebody else doing your work. You get the result, you don't care how you got there, you don't have any emotional attachment to it. And there is zero difference between slinging slop in Clojure or Python/JS/any?. It's against the spirit of tinkering, in my world.

> Most (all?) people in this community picked up Clojure because they wanted their programming to be fun I'd say it's definitely not all, far from it. :) Another motivator is for programming to be more bearable. And to someone who just wants a working product (whatever "working" means), going beyond "at least in Clojure it's bearable" is a win. There even people here who genuinely dislike Clojure but have to use it at work. > And there is zero difference between slinging slop in Clojure or Python/JS/any? There is some, both pros and cons.

@roboli You might get more useful feedback in, say, #ai-assisted-coding -- outside of the AI channels, you're just likely to attract anti-AI folks 😄

FWIW, outside of AI channels the subset of people who reply should be more representative, I think.

Outside of AI channels, would he find people who had actually vibe coded stuff? 😉

Why not?.. It's #off-topic, not #off-topic-no-ai-lovers-allowed.

Right, but he asked about people who have vibe coded and then stopped -- and got responses from two folks who are anti-AI and have never vibe coded...

As I mentioned - I have, just not in a production setting. And I'm not anti-AI by any means. But I am anti-vibe-coding, that's for sure. :)

got responses from two folksThe thread is 25 minutes old. If there is a ratio of, say, 10:1 of "dislike AI":"like AI", then 0 responses vs 2 responses seems quite alright. (10:1 because the aforementioned AI channel has just 1k people. And I'm a member, even though I don't use it.)

I just find it kind of funny how fast the AI-naysayers jump in on any questions about AI and say how crap it is 🙂

Sean, I jump fast into any thread where I can provide a hopefully useful answer right away, without experimenting.

If I were a staunch pro-vibe-coding user, I'd jump here just as fast.

Last year I tried vibe coding and quickly dropped it because it felt like it was slowing me down more often than not. This year I picked it up again with more process around it and have noticeable improvements in polish and speed. It excels at simple grunt-work tasks, but to get actually good results, I have to: Manually review code, drive up code + mutation testing coverage, have agents peer review each others work and constantly clean things up. It’s a lot of hand-holding, but overall I see an improvement.

> Manually review code > a lot of hand-holding I believe by at least some definitions it makes it stop being vibe coding.

in response to the OP: depends on what you mean by vibe coding I think. I generally define that as "having the AI build something without you reviewing the code" which I wouldn't do for an established project. But I've done that for getting an MVP of a side project up and in that context I think it was a good approach. Although even then next time I am planning to be more strict about the DB schemas instead of glancing at them and sayng "eh lgtm I guess"

At work I generally have the agent write all the code, then I review it carefully and usually have it do a bunch of refactoring. which is kind of interesting in how it shifts the allocation of time... initial working implementation goes really fast so I sometimes feel like "it's almost done!" but the majority of the work (restructuring the code) still needs to be done. And so yeah, I don't really consider that "vibe coding"

Regarding reviewing LLM-generated code - has anyone noticed that when you review such code, you're somewhat more likely to glance over things, review less carefully? I know that self-reporting is less reliable than a coin toss at a casino, but still curious.

hmm.... haven't noticed it personally but yeah it certainly could be happening. otoh I do think there is an opposite factor in play sometimes: since you come to the code with fresh eyes it can be easier to notice if something is unreadable/architected weirdly. Whereas when you implement it yourself you can end up with the curse of knowledge and such.

Good point about the definition of "vibe coding". Strict vibe coding means ignoring the generated code and using AI to do it all - treating the code as a true black box. Then there's the "sloppy" definition that has folks generating code via AI but then treating it like any other scaffolding system, and reviewing / extending the code, either themselves or using AI.

I think the rapid improvements in the models and the support for context engineering means that you kinda have to keep trying newer versions rather than just dismissing it as "it was crap last year so I'm not using AI ever again" 😁

Except in rare cases, I treat it more as a scaffolding tool than trying to fully vibe code stuff...

@foo Sorry, I mostly meant reviewing generated code vs. reviewing someone else's code. But good point either way.

you mean you were talking about reviewing generated code (that you generated)? that's also what I was talking about

I meant comparing "reviewing code that was generated by someone with an LLM" and "reviewing code that was written by someone manually". So the only variable is the reviewer knowing the provenance of the code.

ah got it I think that kinda depends on how thoroughly the other person reviewed their own generated code then?

you kinda have to keep trying newer versions rather than just dismissing it as "it was crap last year so I'm not using AI ever again"Unfortunately it's more than trivial to go the latter route when: • The same exact thing has been on repeat since the inception of LLMs • I hear the same thing from particular people, and then those very people ask me to review generated code that has deep issues within it (which prompted my question above - those people did not see any issues with their code, other reviewers did not see them) • I routinely use LLMs for stuff that's unimportant or trivial to check and I see them coming up with utter nonsense all the time. Just yesterday some latest LLM (at this point I don't even care what exact model I'm chatting with) tried to persuade me that a window that's 1.5 m tall and 1.3 m wide is too large for a PNLC film because current films go up to 1.45 m in width. And up to 3 m in length... It's still true with that meme with an upside-down glass labelled by an LLM as having "manufacture defects" • I work on some non-trivial issue and think for days, sometimes consult with other people. End up with an implementation that ticks all the boxes and out of curiosity poke an LLM to see what would happen if I were to go that route from the get go. Invariably the result has been crappy.

re: the second point, continuing the thread about reviewing code. I wonder if sometimes people are still operating under the "old way" where implementation takes most of the time and then they have a tendency to not review, test & refactor as rigorously as they should since they subconsciously think "it's basically done" when the feature works. Since IME the latter is where all the work is now.

That's definitely how it feels sometimes, yeah.

I never started. "Vibe coding" was the epitome of the hype, usually by people who had little experience of software engineering. Vibe was a name designed to get money out of people. Conversational coding was a far better term and around for many year before. These new tools and services when understood and used well can provide value. These tools can also involve a lot of learning and yak shaving, which can be can be fun, but is it adding value?

re: the 4th point--agreed I haven't found LLMs to be good for anything that requires hammock time. I just use them for implementation after I've done the design work. And with a feedback loop ("use the new feature with a playwright instance to make sure it works")

> "Vibe coding" was the epitome of the hype, usually by people who had little experience of software engineering. Vibe was a name designed to get money out of people. I think our own Gene Kim might disagree with you there 🙂

On programming being fun... yes and no. I think I gravitate to Clojure because I want programming to be beautiful. LLM's produce ugly. Not always, but often

I can attest to the "doesn't stick" point. I've read code wondering who had written it and why, then checking git blame only to find out it was myself two weeks earlier. But it shouldn't come as a surprise, really, at least for simple tasks where you haven't spent time on a design. The less time you spend with the information, the less it will stick.

I think it depends how much I care. At work, I honestly care less. The codebase is going to degrade anyway, whether it’s AI, dumb deadlines, contractors, or a junior getting thrown a task way beyond their scope with no support. In my experience, pushing hard on code quality mostly just delays the mess by a few months, maybe a year or two if you’re lucky. At some point, everything just becomes LGTM because I do not have the time to make sure every change is clean, readable, and bug free. And by the time something is in CR, it is often already too late. A lot of my real feedback would be, this is wrong starting from where you made the change and how you designed the abstraction. But that is not practical in review, so instead it becomes minor comments like, hey, you forgot a null check. So I focus much more on whether the interfaces are right, whether service boundaries and responsibilities make sense, whether API semantics and behavior are correct, and whether the DB schema is right. The code itself is almost the thing behind the curtain anyway. For prototypes, MVP demos, internal business-process UIs, dev-only tooling, debug surfaces, etc., full vibe coding is fine. A lot of that stuff simply would not get built at all otherwise. For production software, I will use AI-assisted coding, and sometimes vibe code parts of it, but only when the interface is already clear and I can test it well. In that case, I am vibe coding the implementation, not the design.

I started to vibe code a CI because I was tired on debugging problems on Circle and on GitLab. It was amazing... until it wasn't. Now the thing feels a lot like "go horse" - bugs that reappear, issues that were fixed that the LLM thinks it knows better and then undoes, and lots - LOTS - of tokens spent. Now the thing is essentially a mess. But it was good to test the idea, but I'll probably need to reorganize the code, and maybe even rewrite some parts.

I actually never believed that Vibe Coding would work. Now that I tried, I believe even less 😄

Haha, ya it doesn't scale. You can't expect to take your demo/prototype and progressively add more and more features and make it better. It has to live at the hackathon style level. But for example, I can have it make a UI to call one API where the input can be proper text boxes, drop downs and so on. And have it pretty display the result. Do this for every API and already it's pretty neat.

So... scaffolding, would you say @didibus?

I recently had a funny / interesting experience with a new API we needed to integrate at work. The documentation was a 200 page PDF. I pointed Copilot/Claude at the PDF and asked it to write a Clojure wrapper for the API and design a MySQL table to store the API responses in. Overall, it did a decent job, but it missed a couple of fields in the table schema, and it got a bit random about what parameters to pass to certain API calls -- but it handled the XML parsing logic (yes, it was that kind of API) and it mostly avoided duplication. The funny part was right at the start tho'. It decided that the PDF would not be amenable to searching / summarizing, so it set up a temporary Python env and wrote a Python script to extract all the text from the PDF so it could operate from a plain text description of the API. It started asking me to authorize bash and Python stuff and I was like "WTF?" but I was curious about where it was going with this... and I decided to keep the text files around for searchability within my editor 🙂 In terms of actual code quality, it was "okay" -- like, junior programmer okay -- and it wrote good tests for all the parsing stuff and the logic it wrapped around the API (including mocking various things out to test success/failure modes). It produced about 1,000 lines of Clojure of what would have been really tedious boilerplate to write, and as I've worked around the edges of that code, I've also dipped in and cleaned up some of the "unnecessary functions" it added, inlining the code instead. Aside from adding a couple more fields to the SQL migration to create the table, I haven't had to touch the schema -- it even added a couple of obvious index creations. What it couldn't do was figure out our own code at work around how to integrate this API wrapper. I can't blame it, I have a hard time figuring out that particularl part of our codebase 🙂 This was all with "stock" VS Code / Copilot set to "auto" mode for model selection, developing a plan first, that needed just one additional iteration as I recall, and then letting it implement its plan without further guidance. The context was all created by Microsoft's Agent-Forge tool, which writes repo-specific agents, skills, and instructions after analyzing your codebase -- and I've done that for several of my active OSS projects too. That "context engineering" has made a big improvement in what LLMs can do and how accurate they are. And Copilot also updates all that context as it makes changes, so it reflects the updated codebase. And it was kind of fun to just drive the AI for a while, as it built and tested all of that (using the REPL to run tests and try out functions). I deliberately didn't touch the code myself until I felt like it had reached the end of what it could usefully do.

One thing that Claude is doing quite well for me is to generate URLs for me to test stuff. We have a simplified database on our dev environments, and I can query Claude like "give me an URL for a product with these and these caracteristics where the owner of the product is not an admin and have this and these permissions" and it works quite well, actually 😄

But I'm actually feeling that Claude is somehow getting worse... it used to get things right about 90% of the time, although the actual quality was not that good. Now, the quality varies between medium to atrocious, and it gets things wrong all the time

Specific models of Claude? The Claude Code harness? Can you be more specific -- "Claude" is quite a big surface area these days.

Claude Code actually. Sonet and Opus are the ones I usually use, but recently it feels that both are not that good as they were...

Microsoft has put in a huge amount of effort, improving the Copilot Chat harness in VS Code, and I like the overall UX of that. It seems to be getting better and better all the time. I have model selection set to "auto" and it switches models as needed for different tasks, sometimes even dropping back to Haiku!

(and because it works on requests and premium requests, rather than token budgets, I haven't hit any limits, even on just the $19/month plan)

I would not call it scaffolding. It is a lot more than that. For pure feature level vibe coding, you have to think in terms of use cases you probably would not have touched before. Smaller, simpler, more throwaway software that is still genuinely useful. For example, a tool where you paste gzipped base64 encoded EDN and it decodes it, unzips it, and pretty prints it. We have a service where that is exactly what gets stored in S3, and when you are on-call it is genuinely useful to have a little tool that lists the files in the bucket and, when you click one, pulls it and does exactly that. Another example. I was modeling a JSON structure for configuring collection forms across different use cases, and I wanted to prove you could actually build a UI that renders dynamically from that structure. So I vibe coded a prototype. In doing that, I found limitations in the JSON shape and adjusted it until it actually worked. Otherwise I would have found those issues much later. And with AI assisted coding, you can do a lot more. One of my favorite uses is fixing broken tests after a refactor. And then there are all the non coding uses. It is great for interrogating a codebase, reverse engineering function flows, making diagrams, rubber ducking ideas, exploring designs, naming things, and going through logs and code to root cause an issue.

> One of my favorite uses is fixing broken tests after a refactor It is one of my least favorites. Because I've seen first-hand the quality of tests degrading because if this use-case. When fixing tests was a little more "expensive", let's say, it felt that people wrote tests checking for the feature. If it's a refactor, for example, the test should not break ever. Nowadays, I see tests full of internal state, full of weird stuff... recently a test broke on our CI, and I remembered it being broken before. Turns out that there was a mix of fixed and relative dates on the test. Then I looked at the history, and what was happening is that somebody was asking for the LLM to fix the tests, and the fix was always to update the fixed date to the present day facepalm

Ya, I guess I'm a little more careful with it. I only have it fix one test at a time, I give it the context of what changes broke it, and I validate quickly that it didn't do something stupid like that.

Spec driven development is where it's at. Pure vibe coding is extremely hit or miss, but when you spell out all the design, requirements, and itemize the tasks individually you can get amazingly good results