Those open legal issues are definitely concerns. But I want to stress that the focus of any policies for packages in the General registry is not legal. We’re not trying to apply some set of rules blindly, but rather act on a broad consensus of guidelines intended to foster a healthy and cohesive ecosystem. “Liability” is not a community concern – that’s something that package authors have to work out for themselves.
None of the “rules” regarding package registrations are absolutely 100% hard (although some might be pretty close). We try to engage with every package author in good faith.
For LLMs usage in particular, the concern is that it makes generating large quantities of low-quality code so easy, and we have to find way to mitigate that, and to address
I actually have some hope that as people gain experience with agentic coding (and maybe come to the realization that there are no short-cuts: you still have to put in effort to get high-quality results), and the agents also get better at not producing quite as much garbage, that “wave” will still be manageable in the end.
Another important aspect is the “good-faith engagement”: We can’t engage with an LLM, so there has to be a human author standing behind the design of a package, and engaging with discussion, as @kahliburke is doing here. If that author wants to incorporate LLMs into their workflow, that’s neither a problem nor even something to discourage.
Your comment is a splendid example of the application of judgment, brains and maturity as a superior alternative to a rules based regime of software governance. The example given was in the style of a protective legal disclosure intended to show how uninformative slapping a label on a contribution can be.
If you ask the LLM to implement an algorithm that was invented a few years ago and only ever implemented by one or two public repos, there’s a real concern that someone else’s code may be reproduced verbatim, and you need to do the due diligence to make sure no copyright was infringed. But if you ask the LLM to implement quicksort or linked lists, it would be laughable for someone to allege infringement.
I agree with you that you must put in effort to get good results. The higher the quality of effort, the higher quality of the results, as a rule.
I disagree with you that there are no shortcuts. There are absolutely huge shortcuts, in the sense of accelerating the pace of development by an order of magnitude or more. If I can choose between “by hand” or “using AI tools” and the difference is between 20 weeks or 2 weeks to implement, that is literally a shortcut in the truest sense of the definition of the term:
But would you be willing to scold them a bit, publicly, tell them that their behavior is questionable and that they should change their development practices? That’s all I’m asking for.
The volume of version changes on the General registry is simply too high to do this. Folks like Michael do an incredible job keeping the General registry clean (even with some false negatives) on the new package registration side of things, but the volume of new versions to new packages is at least 100x from a cursory look at the registry commits.
Unfortunately this means that new packages are the only real quality check or protection we have for the registry, and this naturally means that new packages will generate some discussion and scrutiny here and there.
There is typically at least a little consternation about semantic versioning issues if a package is a dependency of other packages in the ecosystem.
Given @goerz’s involvement with package registration, I would argue that anyone that attempts to register a package, or even anyone that thinks they might one day register a package, does ask for their opinion—package authors need to know what will be accepted into the registry!
No, people do not need to ask my opinions before submitting a registration. The guidelines for the General registry are based on a broad consensus of all registry maintainers, and usually a discussion with the larger community. We try to have those guidelines written out in the README of the General registry, even if their application is still subject to common-sense and individual considerations. My “opinion” is not a law of what can and cannot be registered… and actually, any community members should feel free to monitor the feed of package registration and voice concerns by leaving blocking comments on a registration to start a discussion that has be be resolved before a registration can be merged.
My other opinions, like to what extent exactly one should use agent-based coding, are just that: my (potentially evolving) opinions
I did read the guidelines. Nowhere does the word ‘opinion’ appear nor is there any recommendation to ask @goerz or anyone else about their opinions. So I didn’t do that.
I did follow the recommendations that were present, submitted my package through the official mechanism using Registrator and TagBot, passed all of the automated checks on the first try (due to my careful preparation of this package prior to my decision to release it), and posted my announcement in the correct manner; introducing the community to the features it offered. I immediately began responding to any issues created on GitHub, here is a breakdown of time to first response:
Average: 5.7 hours
Median: 3.8 hours
Fastest: 49 minutes (#6)
Slowest: 23 hours (#16)
I also fixed small bugs that were reported and implemented new features, some of them requested in the announcement threads, with a rapid turnaround.
After the 3 day mandatory waiting period, the registration request was granted. I’ve created 8 releases including some major feature enhancements since the initial push 3 weeks ago, and I’ll be releasing 1.1.3 very soon.
I’m happy that many have found this project to be useful and would encourage anyone who runs into any bugs or issues to file a report in GitHub and/or reach out to me through the Discourse chat.
So what was this discussion (split from my announcement topic) supposed to be about again? Something something … used AI tools … something … vibe coding is bad … something registry … ?
This discussion was split off precisely because it is not about your package. Your package is fine, in line with the guidelines, and thus was merged in the usual three-day period without comment.
This thread is an updated discussion on what our expectations are for registered packages. As LLMs rapidly evolve and agentic coding is on the rise, it makes sense to periodically talk about this… not that anything in this thread seems like it will lead to any revisions of the guidelines. Specifically, I don’t think we will require disclosure of the level of LLM usage for registered packages, as was suggested at the origin of this thread
I’ve half vibe-half manual coded a linear equation parser and a string to optic (from Accessors.jl) parser for linear constraint generation and hyperparameter search. That took a couple of hours of manually trying + asking Chad Gippity/Claude to try it out themselves.
All the LLMs did was show me subtly wrong ways of doing things, often annoyingly so. To be fair, those subtly wrong ways showed me what I shouldn’t do.
So now i’ve relegated them to writing my API docs, which they are half competent in, but they often add irrelevant sections like usage examples for abstract types, hallucinate references, links, or more annoyingly slightly change the wording of standardised phrases or quantities.
When it comes to API docs they get 80 to 90% of where I’d like them to be. Maybe 60%–70% on the limited and highly focused code i’ve managed to get them to generate.
It’s so far been a net positive for my use cases, but I’ve never got anywhere close to being satisfied or impressed, just pleasantly surprised. At most it removes some of the tedium, but I still have to go back and correct things and it’s so annoying when it’s just half a phrase that is repeated 30 times before (for example when describing an argument which is the same data used in many different functions) that it decides to suddenly change for no reason. It’s got so annoying that I defined a few glossary dictionaries whose entries I’m interpolating into my docs where appropriate to make sure the docs use standardised names and descriptions.
Actually to me it seems too strict for many projects, i.e. I used LLMs to find bugs in Ark.jl and it worked pretty well, finding around 8 bugs some of which not straightforward. In the many attempts, I also had a lot of false positives, but I would say that, without that help, I couldn’t have been able to proofread some of the implementations to this extent. To me the disclaimer of @kellertuer seems more appropriate to be added to the projects they want to “defend” from sloppy contributions.
In general, my main concerns about AI is the current level of control by big entities, and that who is using these tools is probably inadvertently make this worse. I would say we have lots of evidence that these tools are powerful, though on this aspect, I think that…With great powers comes great responsibility. And that not depending too much on these tools for everything is a good idea in the long run.
I think that “finding bugs” use case is the single one use of LLM that shouldn’t be
subject to any additional rules, so long as the fixes for those bugs are produced
by humans.
I agree that this is a major issue, if a code base becomes increasingly slopified,
that creates a vulnerability in the project – human developers may become
increasingly unwiling or even unable to contribute, so the whole project
tutns out to be fully controlled by a corporation.
