Hello, I have been getting into the controversial world of vibe coding. I am a biologist so I don't have a lot of time to learn programming, I just have some background in computer science (I once knew some java...). But anywho, it annoys me when I have unspent Claude usage and I don't take full advantage of my subscription so I set up a software factory of a sort to make crates to solve frequently discussed issues. I'd love to hear opinions. I'm trying to do something in my power for rust/oss but I know these are strange times.
You can find me on GitHub by this username and see some of them that I've put up so far.
In my opinion, this is a bad idea for everyone involved.
If someone finds a problem with your crate, they may try to contact you to fix it, and if you don't even have the time to make the crate in the first place, you also won't have time to periodically review PRs.
You're setting yourself up as a high-value target for supply chain attacks.
If you don't review the code, you could be uploading low-quality crates. A bad crate is worse than no crate: if I can't find a crate to solve my problem, I know I have to make it myself. If there is a crate, I have to figure out if it's useful to me. This means the average quality of crates on crates.io is important.
This uses up the namespace of crates.io. You could be sitting on a name that would be better used in another meaning by someone more experienced.
Most of the issues discussed here can't be solved by a crate.
I've been seeing a lot of this idea recently that if your AI agent isn't running 24/7, you're wasting time. I get where that idea comes from, but I don't run Spotify 24/7 even though it's paid for. I don't think this is worth worrying about.
As consumers of crates there are a few things that would make us happy:
The crate does what it says it does.
It does not do things it does not say it does.
There are tests in place to demonstrate the above.
It is efficient, in terms of performance code size etc.
It is supported. Reality is that bugs are found, new requirements pop up and things change so it's great if someone stands behind their creation to address that.
Following from 5) the code should be understandable and maintainable so that if the creator is no longer around someone else can step up.
The documentation is good.
Basically we would like "quality" in the crates we come to rely on. Failure in any of the points above can cause frustration and time wasting and of course failure in peoples projects.
If you check all of those boxes I'm not sure I care where the code comes from.
But I suspect setting up an AI slop factory to churn out crates is not going to do it. Especially w.r.t 5) and 6). Flooding the place with low quality create that end up wasting peoples time and making work would not be helping the Rust/OSS community.
btw, @Philamentous , you should spend on tools / crates that you really need or use, instead of one-shot crates that you didn't plan to use or mantain.
Or, you can use it for RND for your own cases, the credits doesn't need to be used to code. You can use it for research, planning, etc for your own current or future projects.
I have sympathy for your approach and goals. I casually browsed some of your GitHub projects and see that you are working on cargo commands intended to improve the health and security of the ecosystem. And I see also interesting ideas. The crates are each quite small and focused, with a few hundred lines of code and tests. You clearly state the objective in each and also how it was created, the documentation is clean and not "over-selling" as we often see. Regarding code quality I cannot comment yet, because that would require more time to read and have an opinion.
But what really struck me is the number of such crates produced per day. If you or others continue with producing many AI generated crates, we are going to see an explosion in the total number of crates. For example several of your new crates are about auditing dependencies for health and security, and I have seen very recently (even today !) other announcements posted here of crates on this exact topic.
And if we have such an explosion of crates, I am really worried about the health of open source in general. We have seen what this kind of explosion of generated contents did to the Internet in general, news, etc. Slop contents far outnumber good content, and we end up being overwhelmed, which makes it extremely difficult for any specific contribution to stand out, however good it may be.
Continuing after thinking a little more about this topic.
I agree with others that the bar of crate quality should be high for crates to be useful to the ecosystem. But I see no reason to not use a tool if it helps more efficiently writing software (except if this tool is wasteful of natural resources but that is another topic).
So my recommendations would be to really take ownership of the produced code, understand everything of it, thoroughly test, and in general strive to apply best practices that improve maintainability over the long term.
And in order to reduce entropy, I think it is preferable to have a few ambitious crates that provide substantial, well thought-out and consistent functionality, rather than many small crates. (Or if they are many small crates, have them under a similar name space, so as to avoid using too many names, and also so that when searching for a crate, we can understand that they are intended as being part of a whole).
It's hard for someone without a good expertise to spot suboptimal code patterns/slop. I have used GitHub Copilot to do some repetitive code tasks. The model I use (not Claude)[1] tends to forget my instructions file custom instructions for the model after the dialogue reaches a specific length, so I end up feeding it as an attachment. I think this kind of AI slop exists in other models as well, more or less, and will make it difficult to modify the crate if OP ever needs to do that.[2]
I think AI users should be responsible for checking AI output[3], so publishing fully AI-generated crates without the skill required to remove AI slop is not something I'm in favor of, especially if it takes a public resource (e.g. crates.io namespace[4], time taken to review the code etc)
I think there's nothing wrong here with vibe coding itself, and it can be a productive tool if you use it correctly. Like if you're confident in your Rust skills, you can let AI write almost everything for you, verify it, and commit. But I doubt if this is the case here. (This reminds me of Ghostty's AI policy)
As a final note, this is all only my personal opinion and I don't think I am eligible to speak for the "sentiment/consensus" if that's what OP is looking for.
I think that is a great way to put it. If you did not write and do not understand the code in what way can you be said to own it? If you cannot or are not prepared to nurture that code, maintain it, fix it, support users of it, etc, in what way do you own it. You have just thrown some trash out the window and said "Here world, this is for you".
Don't worry too much. Open source is reselient. It'll survive. Most likely by learning to ignore such new crates as much as possible, but oh, well… it'll survive.
Just look on Github: most projects there were absolutely ignored by everyone even before LLMs arrived. Only tiny percent ever had even one star. We would just have more of that. The majority of AI-generated crates would join all these “I finished this task for that course” repos.
The problem with LLMs is that they are producing low-quality code incredibly fast. That, essentially means that they couldn't create anything truly new, but can quickly create variations of things that one already have.
This is useful, sometimes, when you are creating something that someone else asked you to create, but why would you do that to a public code? Well… maybe to relicense it… but we don't even know if that works. Soon would find out, though.
I think it should be quote of the week. But yeah: when some company “throws the code over the wall” then it's usually some high-quality code that is no longer needed. Akin to the well-done thing that you could no longer interested in and thus sell at bargain prices in a garage sale.
But trash that's not even yet made into a good thing… no one sells that with physical goods, why code should be any different?
My question here is, what itch are you scratching? You're not "programming", because you're not writing code nor solving problems involved with doing so. I can't see how you derive satisfaction from that.
You're also not contributing to the state of Rust/OSS, as you would've realized had you stopped a moment to consider. If all it took to create good code was a Claude subscription, what would any of us need crates.io for? What would we need you creating myriads of tiny crates for if it's that easy?
I think the moral here is to remember that if you want to contribute to society in some way, you have to... contribute. You can't achieve goals by taking the lazy route. If you don't have time to do it any other way, then please stop to consider the consequences of flooding an ecosystem with low-effort, no-maintainer code.
drewtato ZiCog farhansyah bettertree threefold3 khimru (it wouldn't let me tag more than 2)
Thank you all for taking the time to give criticism. I do appreciate it and you've given me a lot to think about. I had not considered name spaces and that they are limited. Also, while I did figure that the maintenance of the crates could also just be delegated to Claude or something, I do see the issue with publishing things that I really can't verify myself. And, I will take the point on not having a personal stake in the crate for my own use.
I do wonder if the crates so far are actually functional. I did use some additional meta prompting project from GitHub so that it wasn't complete slop and some private projects have actually worked and saved me a ridiculous amount of time in job automation. That was the only thing that made me more confident in publishing small crates that wouldn't exceed current AI capabilities. If anyone has an interest in testing them (just for research/curiosity's sake) I would be glad to add anyone as a contributor and hand off? Maybe?
But overall as a result of this discussion, I will not continue to generate random crates. I'll probably leave the current ones up for a while as a test to see if they're any good and get used. I will stick with the advice of putting out only projects that are personal to me and actually something that I can test/maintain in a way through my own use. I appreciate the input from you all thanks.
I'd like to echo the sentiment of working on what you personally need/use.
In my mind, the advantage of using a crate or tool is that you're leveraging the experience of an expert. Whatever it is you do with programming, tools that you personally interact with make you (in some sense) an "expert" in your exact workflow. Focusing your effort on making tools you use helps solve/improve problems you're facing.
If you're working on solving problems that don't directly affect you, then there's a lot more effort involved in defining the problem and then verifying that your solution meets the problem that actual people are experiencing. If you post a crate/tool that solves "a problem", but not the exact version of the problem that other people actually face, then it does serve as a distraction in some sense for people who are facing similar but different problems. They might find your crate/tool, look over the readme or some code or try the tool, only to find that it isn't well aligned for their specific problem.
Someone's experimenting with new tools with the end goal of making something useful for other people? Hard to get angry at the intent.
It has a few bugs, or gets abandoned? Hardly new. Not all projects work out.
The part that bugs me about bringing LLMs into things is that I was using how good the README looks as a general quality heuristic. That's gone now.
So my first impressions aren't lining up with actual crate quality any more, and it's entirely in the direction of going from "This looks good!" to "Oh wait, it's actually pretty mid." These new disappointments are all from LLM-made projects, and I haven't recalibrated yet (it's a slow process).
80% of my code is vibe. GitHub or any other free repository is completely free and open to any type of code as long as it complies to the term of use. It isn't a problem to find a repository with a computer virus, or some hacking solutions. If your solutions are valuable for you, they can be valuable for someone else. Nobody will care how you get the code, doing yourself or getting help from some system. Say more : vibe code usually has good comments and fairly smart organized, so more likely it will have a better quality than you did it yourself. Nobody will ask you - prove that your understand your code and have a college degree. So just share your code, and ask us for reviving it (optionally). Good luck.
When I tried to think what can I say in response to this (because “good comment” is definitely not what you may find in vibe coded project and smart organization is even farther from it) I have realised that I couldn't describe it better than it was described 14 years ago:
Yes, original was talking about PHP so-called “design”… but it describes vibe coded projects so perfectly because of the exact same reason: PHP was created as hodge-podge of different ideas which nobody tried to harmonize and clean up… and vibe code suffers from the exact same problem.
There are no plan behind vibe code, there no design, no goal… just a pile of haphazardly thrown together pieces that kinda-sorta-work if you don't “knock on the front door”.
And, well, there are good news and bad news. The good news: vibe coding doesn't go away and people would definitely create some interesting things with it. The bad news: people would be forcibly rejecting vibe coded things more and more (like Redox recently did) — and this would lead to quite a lot of tension because it's harder to do that than reject PHP…
It's absolutely fabulous, because I resurrected PHP technology in my latest Rust project in a couple months ago, and I like it a lot. I also keep a vibe coded invoice management system as an example of absolutely perfect code. It's written in .ts, and I do not understand it, but how the code organized and how it works, I can conclude that it's perfect.
Many may ask, why vibe coding is so good if it produced by system without any understanding of it? It's simple, the vibe coding is based on a collection of best practices, so the code is tuned by the best human programmers and the machine just stitched the pieces in a complete system.
You need also to realize, the probably you are a programmer from the God, but thousands other programmers are very average, and a vibe coded code is much better than they programmed themselves.
Returning to the original poster, he is a very knowledgeable is his area but knows nothing about programming. It's probably explains why he selected Rust, because Rust is less relevant to solving his problem, but regardless of a language he selected, the vibe coding gives him a chance to share his work with others, and it's very good objectively.
I think the core problem is that vibe-coded code rapidly loses value because just regenerating it myself will probably work better next year -- when the models are that much better again -- than trying to figure out which of the 300 vibe-coded crates claiming to solve the problem are any good.
To me, the value is in finding something that you can make -- perhaps with AI help -- that takes advantage of what you specifically know that will make something come out better than I -- not a biologist -- would get running an AI myself.
What crate can you make where you can write the better book about how to use it than the AI can write itself?
It's fine if you find LLM generated code good enough for use in your own projects. I think it's great that it enables more people to solve their problems through programming. There's a huge amount of time of non-developers that can be saved with one-off scripts, where code quality and buggyness almost does not matter. Here, LLM generated code is great, because it enables people to help themselves.
But the code quality requirements for "proper apps" are much higher, because they have to be dependable and maintainable for many years.
For libraries, the quality requirements are even much more higher than for proper apps, because they are the foundation of the "proper apps". My app has a terrible bug? I am affected. Serde has a terrible bug? Millions are affected.
If you start uploading low-quality crates, people may come to depend on them, and the "blast radius" of the bugs is so much higher. It is also quite likely a net loss for the ecosystem, because now people have to spend even more time migrating off your crate. And once LLM-generated crates become widespread, everyone else has to spend time carefully reviewing a potential crate for signs of being generated. It's already time-consuming to find quality crates right now, we don't need the additional burden of identifying LLM-generated code.
Note that, of course, what we were preaching all along is now confirmed. Zero regressions 76% of time is not an achievement worthy of celebrating if you'll ask me. I wouldn't allow human who would destroy my codebase so often anywhere near it — and that's celebrated as some kid of breakthrough, hot new thing in 2026! Only achievable with the latest and greatest Opus 4.6 with others being much worse (and we don't even know if it would hit the typical “90-95%” barrier that plagues everything LLMs do).
Nah. People are not idiots. When they would find out that these crates are not reliable they would mark the author of these crates as culprit and would stop looking on what he produces.
You need to produce something truly unique and absolutely worth having for others to even consider using what you have created after they would be bitten once and would found out that the reason they were bitten was vibe code.
Just add some meta-information to cargo audit, no?
We don't really have any choice: there are more than enough people who are generating slop and trying to present it on Reddit and elsewhere. And they don't read this thread, they don't even know it exists.
Means moderators on Reddit and elsewhere would have to learn to weed out these crates, maybe https://libs.rs would get some automated scorer, etc.
The worst hit would be for people who are not, currently, Rust users and may find these things by accident and would be bitten badly — but then, by now they should know every popular language is affected, so knowledge about how to detect and avoid slop would be the #1 “soft skill” people would need to learn, in year 2026, anyway.
Objectively it all just makes the problem of crappy crates that we need to weed out and ensure they wouldn't ever be used by anyone only worse — but then, this issue existed before LLMs, too, LLMs just made it more acute.
thanks.