Clojurians Log v2

Ok using AI to fight AI, I think I have my answers. I also read the CircleCI terms myself and was not convinced. And this is just what they say in the open, corporates can still act differently behind the scenes and pay relative low fines in the future

"we use your data to improve our products and services," a clause that has been nearly ubiquitous in platform terms of service for over a decade, has always struck me as broad enough to cover training AI models

I was still naively hoping for something else I guess. If we want to keep our edge as humans I think it is clear what we have to do. It's not that the machine will be smarter, it will just be faster to steal your work and take the credits. I hope this data collection stops somewhere. What about cloud providers? Will they start collecting data from your VPS at some point?

I think this might be one instance in which private companies' interest in protecting their (and their customers') data could actually help protect the privacy interests of individual users: lots of companies are very loudly insisting that their prompts and data are not to be used for future AI model training. I'd have to imagine that a cloud provider collecting data from a VPS would almost instantaneously be a GDPR violation (how would they know what's PII and what's not prior to collection?), so there's that at least that. In a previous regulatory environment, the US Federal Trade Commission was actually https://natlawreview.com/article/algorithmic-disgorgement-increasingly-important-part-ftcs-remedial-arsenal-ai models trained on data that was illegal to collect. Nowadays, if the EU actually tries to enforce any of their regulations they get https://www.theguardian.com/us-news/2026/jul/24/trump-european-union-tariffs.

I have also published one entirely vibe-coded project and clearly stated that in both the announcement of it and in its README. Regarding scenarios #1 and #2, this is likely to cover all projects that I work on since I accept some amount of auto-complete suggestions and some of those may come from Copilot. Up until I changed that setting, everything could be considered #2 at least.

And, to be concrete about my specific projects: • next.jdbc - category #1. • honeysql - categories #1, #3, #4. • deps-new - possibly category #2—I have no way to tell. • core.cache - category #4, when trying to solve the TTL cache stampede issue (which I'd had several manual attempts at before, unsuccessfully). • clj-watson - the core of the work to add support for checking dependencies based on a classpath (instead of deps.edn) was authored by GitHub Copilot from the GitHub website - category #4 • polylith-external-test-runner - some of the ClojureScript support for Shadow-cljs testing was authored by GitHub Copilot from the GitHub website - category #4 And, as noted, pretty much everything I've worked on since GitHub Copilot started contributing to VS Code auto-complete may include that level of co-authoring, even if the commits weren't showing it in the past.

(I'm assuming no one really cares about category #5—correct me if I'm wrong there!)

Personally; all except maybe #4 don’t qualify for a very big AI label. What I’m personally getting out of an AI label is a proxy for ‘how well are these thought through’. By your descriptions I trust that for all of them to the same degree that I trust you. I think its nice to cocredit Copilot tho; and explicitly state your ‘promise’ in READMEs: While code may be generated by LLMs, all code, line by line is vetted by you. But; even if it didn’t have such a disclaimer, I would still be very comfortable using these projects. (Does that help?)

For my taste, 3 and 4 could get a note that says "This project contains LLM-generated code". I'm actually not sure how LLM auto complete works though; is it similar to the sorta stuff you'd get from a typical language server, or does it generate more stuff?

I don't have super strong opinions about any of the labels, and if an LLM was used or not. I prefer to follow my internal reputation ranking of people in the community. This was always important, now just a little bit more. And you Sean, you have been a long time highly respected person in the Clojure community so I take most of what you say at face value. The labelling does help me to further judge what is less or more risky to use. If there is something that you used AI for and you have hard time explaining what it does then it is important to state this in order to not lose this reputation I think. Maybe this is partially a slippery slope when you are using a lot of LLM so we have to be honest enough with ourselves here. As an example, today I had chatgpt generate some Objective C code. It was not a lot and I've read the code, but I have no idea if it is good code. It looks innocent, but if it's good I don't know. I think it is important that I really seperate this part from other work that I feel really confident about.

> (I'm assuming no one really cares about category #5—correct me if I'm wrong there!) I wouldn't assume that no one would cares about #5 (no AI-generated code, but AI is still used for research, review, analysis, etc). Some of the primary negative consequences of AI usage aren't about what gets checked into version control.

@me1965 Part of why I turned on that co-author setting is because I had no idea which auto-complete suggestions were coming from VS Code and its language support (maybe via LSP, maybe via the language grammars, maybe via Calva/nREPL, maybe a combination of all of them?), vs the Copilot Chat extension. Certainly, some auto-complete suggestions are fairly extensive -- maybe up to four or five lines, rather than just a word or an expression. But the docs are pretty thin on how auto-complete works under the hood.

@smith.adriane Fair point. So, I guess some people would like to see that research etc declared on a project README...

@jeroenvandijk Thanks. But having mentioned here that one of my projects had some LLM-generated code, even given my "ranking" and history of OSS work, there was sentiment expressed that some folks would reconsider using my projects because of that...

It's hard to say what people want. I think trying to convey how you're using AI for folks that might care is admirable, but I feel like every person has different sentiments about what is considered acceptable

@seancorfield Yeah I've seen that and I find that a bit unreasonable, but everybody has the right to their opinions of course. I don't share this opinion and as far as I can tell the people that are the loudest on this Slack have not generated many open source libraries themselves since I have been around, and that's a pretty long time. If I am wrong about this than my apologies. So I find it hard to hear some people complain about it so much. I get the complaints and that you don't want your code to be copied by AI. I will also take steps now I've realized we are the products of Github and CircleCI, but I don't see yet why I should boycot the people that are trying to give something free to the world.

I don't think the main reasons people object to AI is primarily because they are worried about their code being copied by AI.

My code was copied verbatim, years back, by another member of the Clojure community. You don't need AI for copyright violation 🙂

Yeah I agree about that and we should all take action. But not by complaining with the opensource authors. I think they are the robinhoods if we have to find an analogy. I think everybody can move their code off from Github and similar platforms. Don't use any of the AI tools for your private projects if you don't want to share etc. Everybody can do their own share. If we get a better next.jdbc because of LLMs then that's a win for us 1-0 against AI. If my private project is copied through github, maybe even just the idea, then that's a win for AI and a loss for me. So this we need to fight, not the opensource stuff IMHO

There are many potential consequences of the long term use of AI. The fact that AI companies may be unfairly benefitting from the work of others is a small part.

Anyway, I feel like we're side-tracking the main discussion. We can move this to another thread if you want.

Yeah let's do that. And I don't disagree with you. I just don't know how much we can make genuine open source authors responsible for that

I have Copilot configured to not suggest or generate any code it finds "as-is" out there in the wild (since we have a business account). I know that works because when I asked Copilot to produce some examples for the next.jdbc documentation at one point, it refused because the only code it could come up with public -- in the next.jdbc repo on GitHub! But I think that setting is disabled for non-business accounts (and is disabled by default for business accounts). Just FYI.

For me I'd say it's: 1. Is there AI generated code or not (to understand the legal greyness/copyright risk) (maybe an approximate % of how much) 2. If there is, how much of that code you are still fully knowledgeable about, reviewed and steered to be how you like it? a. Every line of code b. Every function signature/doc-string but not their implementation body c. Only the public functions signature/doc-string, not the private helpers or the implementation bodies d. None of it, you only know the features provided and how the library can be used e. You didn't even try to use the library yourself or only partially used it 3. Do you have the expertise needed to assess the quality of the generated designs/code for this kind of library? 4. Do you intend to maintain and evolve the library actively and long term? Do you depend on it yourself in other projects or at work? Or is this more an experiment for fun and you might move on quickly?

@didibus Q re: 1. Do you consider "auto-complete" to be AI generated? (as noted above, sometimes auto-complete is flagged as AI-provided, sometimes it is not AI-provided)

Since the legality are so grey, so is my answer haha. But I think that's where a "indicator of how much" could help. So if you were to say, "only minor amounts of code are AI generated, mostly from auto-compete of simple function invocations and data access."

I feel it's not so much auto-complete or not, it's more if you're doing this: ;; A function that .... ;; and ... ;; ... <-- trigger auto-complete Now it means entire functions or complex logic is AI generated. Which is different from, my AI helps me auto-complete the keys in a map when I do (:foo m).

There's a bunch of open source projects with AI statements. maybe another approach is to try to copy an existing approach from a major project like gcc, openjdk, linux, or otherwise. Not sure how feasible that is in retrospect.

It's such a subjective minefield... some of the objections are artisanal, some ethical. From the ethical perspective, should there be different disclaimers for commits assisted by Big AI and those assisted by local LLM? Or maybe local LLM is building on Big AI and doesn't get an ethical pass? From an artisanal perspective I'm OK personally having LLMs iterate on disposable/dev tooling/general yak-shaving, freeing up my focus time to write production code I care about by hand. It's a bit like weddings -- no matter what you do or who you invite, you're going to piss somebody off. So stop worrying -- document your own usage policy / comfort level in the repo readme and let people decide for themselves whether they want to use it or not. OSS library users who aren't paying you shouldn't get to dictate how you use your discretionary time 😉

You missed the one that's about quality and reliability. That's the one I care more about personally 😅

The various combinations of GenAI vs human contributions can be explosive. To that end I'm wondering if, instead of a scale enumerating all possible ways GenAI can contribute (search and investigation, code completion, PR and commits, testing, etc.), it would not be better to size GenAI output and how much of it is reviewed by humans. The idea is to focus on what's perceived as more valuable (the human contribution and role in the dev process), and to reduce the combinatorics effect of all possible variations. Allowing for tooling and automation in capturing and handling the metadata should also be considered. For example: a/ software is written entirely by humans b/ some code no larger than a functional unit is contributed/inspired by GenAI, AND reviewed by humans, c/ some functional unit is written by GenAI AND reviewed by humans d/ some code is entirely written by GenAI AND NOT reviewed by humans e/ most or all code is written by GenAI AND NOT reviewed by humans The concept of functional unit is certainly vague but should be considered equivalent to an issue or ticket, which depending on the process may represent a user story, use case, feature, etc. Also there must be some distinction between production code and lifecycle code (testing and CI), as expectations and GenAI use are often different for both. Finally the history and actual status of a software has an importance as well: is it in active development or mainly in maintenance mode? Is there any active human maintainer? Was it first written entirely by human before GenAI got involved?

I guess what I'm saying is we need a scale that can work with different development methodology and can ultimately be supported by tooling and automation. Terms such as PR or story are rather specific to tooling and dev process. Functional unit may not even be the better term to describe a development methodology unit, but in the absence of a well-defined methodology (e.g. POC and very tactical/ponctual software) the term functional unit still makes sense.

Or maybe a VCS commit as unit could be better, as it's a term that makes sense for all VCS, the use of the latter being almost a certain assumption we can make.

So maybe the better scale would be: a/ all commits are written entirely by humans b/ some commits are contributed/inspired by GenAI, AND reviewed by humans, c/ some commits are entirely written by GenAI AND NOT reviewed by humans d/ most or all commits are written by GenAI AND NOT reviewed by humans

So the answer to the original scenarios would be this mapping from Sean's categories to the above: 1. Some projects show a Copilot co-author credit based solely on auto-complete suggestions. => B 2. Some projects do not show such co-author credits but may well include Copilot auto-complete suggestions accepted before I changed that setting. I simply cannot tell. => B 3. Some projects have accepted PRs that were clearly AI-assisted, but were reviewed line-by-line by me, and deemed satisfactory in terms of code, tests, and documentation. => B 4. Some projects contain code that I specifically prompted Copilot to generate, again all reviewed and tested by me. Some of these have credits in the commit, some do not. I sort of assumed they'd get automatic co-author credits but not all such commits did. => B 5. Some projects contain no AI-generated code (as far as I know—see the auto-complete caveat in #2 above), but I've used AI to analyze the code and find bugs, or to review changes, or to research problems and provide an analysis of potential trade offs in solutions. => A It kinds of erase the various distinctions (not the goal) to focus on the human part (the goal) which in your case is always involved, with GenAI not being a major contributor. This makes me think of an intermediate step between b/ and c/ to describe projects where a good chunk of the code is contributed by AI but always reviewed by humans. This also makes me reflect on the size of the commits, as an initial one could be entirely from GenAI but subsequent ones aren't or always involve humans... Maybe commit isn't a proper measure alone, LOC could enter the picture too. That intermediate category between b/ and c/ could be characterized by a number of LOC (not) touched by GenAI and how much of that is reviewed properly by humans..

I hope the reputation ranking thing doesn't play out, which is why I would prefer that all vibe-coded projects or features/commits are voluntarily disclosed, and it doesn't become acceptable for well known oss contributors to publish fully vibecoded projects or features without any notice. 1. First of all, this can kind of create two classes of OSS contributors. Those with contributions pre ~2025, and those after, the tainted ones. 2. The well known contributors are just as susceptible to the "lgtm" syndrome

I think that openJDK doc worded it nicely: "Generative AI tools, by their nature, make it easy to create large quantities of plausible-looking code, with plausible-looking tests, which is nonetheless incorrect or, even if it is correct, is poorly designed and therefore difficult to maintain."

If one uses it for small quantities of code, they mitigate some of the risks and especially for those with a reputation you might assume they can keep poor design decisions out. Otherwise all the other points remain, and with larger quantities of code, I think even with reputable authors it is safe to assume poor design decisions will seep through.

At this point, I'm thinking about writing up my usage and thoughts on AI/LLMs as a blog post, and then just adding a link to that near the top of the README of all my projects. Thank you, everyone, for your insights on this! gratitude

I'm surprised as well. I read it a while back. Great breadth.

For some reason it was blocked in the uk, " Unavailable Due to the UK Online Safety Act" makes me wonder what's on the site, perhaps it the same for others ?

It's unavailable not due to some direct action by the UK government, by due to a direct action of Kyle himself: > A few months back I wound up concluding, https://blog.woof.group/announcements/updates-on-the-osa, that http://aphyr.com might be illegal in the UK due to the https://en.wikipedia.org/wiki/Online_Safety_Act_2023. I wrote https://aphyr.com/posts/379-geoblocking-the-uk-with-debian-nginx on geoblocking a single country using Nginx on Debian.

Ah I see I was surprised it's the first time I have hit a site with a restricted message