Clojurians Log v2

I think transparency is the key word here. It doesn't have to be a binary yes/no. I can put in a prompt, go for dinner, come back, ship it without looking at it, and announce a new library with great fanfare. The fact that that is possible now means that you can no longer take releases at face value, you have to get a sense of the process to be able to assess if you would want it in your stack. I think it's also important for the people who embrace it, we're still in a wild west phase where everyone is figuring stuff out. How do you engineer with AI? How do you test? How do you build up confidence in the result? If you have a workflow that you feel delivers high quality reliable results, then I think disclosing that is good for your project and good for the ecosystem. LLMs are not "just a tool", writing software with or without them are two distinct practices, with a gradient between them depending on how you use them. The output of either needs to be judged differently, from a trust and safety pov and from a copyright pov. That's why I think the responsible thing is to not try to pass one off as the other.

I understand the resistance to this, because there are a lot of kneejerk reactions and dog piling happening. Together with encouraging responsible disclosure we also as a community need to be absolutely clear that that kind of behavior is not welcome here, simply because it is counterproductive. People won't do any less AI coding, they will just be more secretive about it. That is not a good outcome.

Coming back to @weavejester's question, here is a longer answer ... I consider toolchains to be infected by AI at this point where AI is like micro plastics: impossible to avoid. I do my best to keep the toolchain clean of that but it's hard to say definitively that there was no AI in everything that I use, even if I have not enlisted it. My rule is that the deliberate enlisting of AI in any form is "using AI". Once you have crossed that rubicon, I am not here to say it's OK or to create a permission structure for further use. Anthony Moser has made this case better than I can https://anthonymoser.github.io/writing/ai/haterdom/2025/08/26/i-am-an-ai-hater.html and we have an interview with him https://politechs.dev/episodes/s02-hate/.

So there's obviously a range of opinions on how much AI is ok, from zero to unlimited, this is not that conversation. The point is that everyone benefits from an environment where disclosure of AI usage is encouraged and can be done safely. AI vegans know they can avoid those things, people in the middle with legitimate concerns can adequately assess, AI boosters can find their peers and learn from each other, and as a community and ecosystem we can have more open conversations around mitigating harms. It's like giving clean needles to drug addicts, you don't need to endorse heroin to agree that it reduces harm. For a much longer take on this see https://www.youtube.com/watch?v=y85nqc2zm7M

that's funny @blueberry but I'm not sure how it contributes to this conversation?

It seems to me that there's a lot of AI enthusiasts that try to weasel out of an, in essence, a simple thing. Look, no one cares whether a person/developer used AI to help them find a solution, or which class could do a certain task, etc., etc. Do anyone ask you whether you read 7 threads in stackoverflow, or whether you read a really good explanation in a book, as long as you appear to know what you're talking about. The main issue (to me) is whether the artifact (code, article, whateve) is a product of your mind and creativity in a sense that you understand it, and you stand behind it, or it's just a stream of some blabber that you re-routed to me to waste my time. Ultimately, you don't have to disclose that you used AI, but then I'll look at what you're sharing, almost certainly be apalled at how odd it is, and decide that you, the "author" is someone whose output I should avoid like a plague. In that sense, disclosing that it's the product of AI that you used is beneficial to you, because I won't judge you in the case something's off, but I'd judge AI.

@plexus please read the message after the joke.

In short, I would like the use of AI to be disclosed, but I accept reality and know that many times it isn't. But then, if AI use wasn't disclosed, I attach my valuations of the shared information solely to the author. If the author is, actually, an undisclosed AI, too bad for the human that had appropriated the ownership.

No, I'm not skeptical about that. It exists, quite demonstrably.

Er, it's about its use rather than its existence. Think biological weapons. Are you a fan? Like that…

I'm not trying to "weasel out" of anything, assuming that comment was directed at me. I wanted to know where people draw the line, because ultimately if someone is asking me to inform them about something, I need to understand what exactly it is they want to be informed of. I've found LLMs useful for tasks that are trivially verifiable. That is, if an LLM gives you an answer, you must be able to verify that answer is true with relatively little effort. For example, I've found LLMs to be relatively good at searching documentation; I can give it an explanation of a class I want, and it usually finds the right class better than a traditional keyword-based search engine. But it also hallucinated an answer in one case, so the verification step (in this case looking up the Javadoc) is absolutely necessary when dealing with anything returned by an LLM, and the time taken to verify should be taken as part of the cost of the query. Along the same lines, I've also found LLMs useful for explaining APIs or, recently, a type system. Again, this is trivially verifiable because I can just run the example code it gives and check the result, or reconfirm with the documentation once I know where to look. The final use-case I've found LLMs useful for is as a slightly better rubber duck. I find it useful to talk through designs in order to get them clearer in my head, and Claude has proved to be slightly better in this regard than an inanimate object. It's even managed to point out a mistake I made in a particularly thorny concurrency issue, which I was genuinely impressed by. Unfortunately not long after that it hallucinated a static field on a class, which rather encompasses my experience of modern AI - surprisingly brilliant at times, surprisingly stupid at others. I don't use AI generated code in my projects for practical reasons. I've experimented with getting it to generate test cases, but they were bad enough that I had to rewrite them, so I don't think that saved any time at all. Equally I've experimented with having them generate lookup maps from documentation, but the time spent verifying the maps were correct meant that it was probably easier to write it out myself. And that's ultimately the practical problem with using AI-generated code directly: even assuming it produces reasonable code (and often it doesn't), once you factor in the time to carefully read through and understand it, you lose any time that would have been saved.

Personally these are use cases I'm less concerned about, because you still write the code yourself. You understand it, you develop and test it, in that regard it's not that different from pre-AI code. The provenance of that code is a human. People might still find it helpful to understand how you used AI and how it fits into your workflow. My bigger point is that, yes, it's a gradient/spectrum, and so disclosure shouldn't be a binary yes/no either. Say you have a PROVENANCE.md, you can put in there whatever you think is useful to understand how the code came to be. I'd like to see an environment where this can be common practice. This is asking a lot, because it means asking the AI haters in the community to fight the instinct to hurl abuse at people. But I think it's the best we can aim for, assuming that we want to have space on here and in the Clojure FOSS community both for people who categorically reject AI, and people who use it enthusiastically, and everything in between. I think that's worth shooting for. Clojure has always been a big tent where not everyone shares the same values, but we have enough shared interest to come together and work on a shared ecosystem. Like I said in an earlier thread, this thing is so divisive, you either take some kind of stance, or a lot of people will simply disengage and leave, and I think we'll be a poorer community when that happens. I think too many people are bought in to AI for that stance to be to reject it. I think enough people have valid concerns for them to reject it, and I would like to bring those people along too. So I think the middle ground stance is to have a social expectation of disclosing the provenance of your code, so everyone can decide for themselves how to engage with it, but also a social expectation that that disclosure can be done without inviting abuse. We have to make space for that.

At en ethical level, I can see why some would like an "AI used" disclaimer, and I shall probably provide that when it is not obvious. However this seems to be not just about AI use, but about more general disclojure of the state of the project, the maintainer's commitment to the project and the standards that they are working to. How much of the burden of discovery of these is on the consumer rather than the maintainer? From personal experience as a consumer, I know that it can be hard to judge a project, and I am concluding I should put more effort into providing this information in the future. What would be the practical standard for this? As @plexus just said, it seems to be more than just "AI used".

@weavejester It seems to me that in your case you're the one who's producing the code, and you use AI to help you find information. I don't think such cases warrant disclosement any more than having to disclose whether you used stackoverflow or you know the docs by heart. (but I didn't write my message having you or anyone else in this thread specifically in mind)

@hugod As far as I remember, most open-source projects are shared on AS-IS, no guarantees base, for good reasons. 🙂 We all have different bars when we decide what software we will use - often for free - and the code is there in the open so we can make our own decisions. Forcing maintainers to do my own work for free is something that I don't like to do.

I don't think any maintainer statement would remove the necessity of making your own judgement, but it could provide some extra information to help with that.

As others have said, even for AI there seems to be a spectrum; "AI used", "Contains AI generated code", "Contains AI designed and generated code", etc.

It seems like most people are okay with AI being used for information. One interaction I had with Claude right now went something like: 1. I ask Claude to see if it has any ideas why a stress test very occasionally fails 2. Claude thinks for 2 minutes and gives me back a wrong answer 3. I correct it, and it thinks again for 10 minutes, and to my surprise this time it actually finds a race condition. It suggests a solution. 4. I verify the race condition exists, but I discard its solution for a much better one of my own. 5. I double-check my solution with Claude, and it points out an edge condition I hadn't considered. Once the edge condition is accounted for, the stress test seems now not to fail. I think this is indicative of both the value and danger of AI assistance when it comes to coding. Claude was wrong in its initial diagnosis, and in its poor solution, but it legitimately found the race condition in, I suspect, a faster time than I'd be able to, and also pointed out an edge condition I hadn't accounted for. Perhaps then AI-use can be categorised according to whether a human is in the loop: 1. No AI use at all 2. AI use for information gathering only 3. AI-generated code used only if verified by a human 4. AI-generated code used without human verification

I wonder if it makes sense for AI-enabled people to share the result of our investigations into libs. Which could then include indicators of whether AI was used. For example, I have it: • Generate security notes of Emacs ELPA packages I use. • Create indexes of larger codebases, to help me read them. • Opine about the basic problem a lib's solving, it's approach, and others in the problem/solution space. This amplifies me in the fundamentals: • Reading the code curiously. Which as a side-effect helps me understand the author's perspective on precision, imagination, concision, low-level platform/language semantics, etc. • Checking for minimal deps. • Playing with the lib. I wonder if this could be used in a post-hoc system of analysis rather than upfront disclosure. Now, some might not want to even look at the results of such a system, as AI was used to construct it. That's up to them. However, it'd cache results of AI queries, which could reduce AI use.

Somehow, as often is the case with AI, this is shifting to a discussion about how to better use AI. And designing libs to account for the cost of tokens is even now entering the picture. I feel like I'm in the wrong channel.

I'm leaving this thread anyways. Good luck with your bots.

On top of known LLM disclosure in release notes, perhaps it's also a good idea to start encouraging use of Co-authored-by whenever code is being produced by the LLM. Or maybe use comments to indicate code sections that are "vibe-experimental" or "LLM-speculative" in nature, eg. ;; XXX(Claude): I did this with 30% confidence. Also good to vet at the library level: if a lib has been fully vibecoded, I don't expect the code ever to be very accurate, I think I've already such disclaimers in #C06MAR553.