Some good questions in the comments:
What does “written by” mean? Who defines authorship? What does “mostly” mean? Who defines ratio? Is this going to be enforced in practice? Who is going to enforce it? Based on which reporting?
Hot take: I don’t like this. It states a rule, but the line is vague.
How is vibe coding detected? How much is too much? How does this apply to my personal vibe coded util™? Does this apply to private repos?The rule feels ill defined while the consequences are quite extreme.
I think in practice they are saying that any shit that happens cant be blamed on anything but the submitter.
You can already make a project out of copypasted bits of code. So long as you understand what they do, vetted and vouch for it…it’s fine, no?
Yeah, this makes sense. They won’t be able to kick every vibecoded project off, but it gives them a rule to point to when they do find and remove slop.
Some of the commenters on the Codeberg issue are expressing concerns about copyright status, but my main concern is security issues with these projects, which I have expressed before. Somebody vibecoded a script to sort files? I don’t really care.
Someone vibecoded a network facing application, shipping a docker container, and is trying to encourage people to deploy it? If I investigate, and see the bad security practices common to vibecoding, I wouldn’t want to be providing that for people to download. Even though I’m technically not responsible for it, it just doesn’t feel right to host something that could explode later. I would want to be able to take it down, and having a rule to point to prevents complaints when Codeberg does so.
I’m perfectly happy with this.
Why?
Because at the end of the day, the users of the code forge can be broken up into three categories:
- Traditional coders with human made projects
- Vibe-coders who slop out 100 throw away projects, each of which is a dead project as soon as that user moves onto the next project
- Vibe-coders who focus work on only a single project.
Category 1:
- Code forges were already valuable before LLMs, so we already have a proof of value/utility/whatever for hosting projects from users in category 1.
Category 2:
- Projects from the users in category 2 have a half life of a couple of weeks.
- They’re so quickly made that most of their contents is going to be rehashes of previous existing content, so there’s a reduced value holding on to them as reference when the original sources exist.
- Since they were generated so quickly, a more up-to-date version can be generated in the future if they’re ever needed again.
- Since the projects aren’t going to be used by others, they don’t actually use the features of a code forge, so it’s not a great idea to allocate so many resources that aren’t going to be utilised to host them on a community code forge. A better place for them would be cloud storage (dropbox, google drive, etc…). Most cloud storage services have a free tier. Anyone with a crazy amount of projects and assets that would exceed free tiers and who just wants to hold onto the projects for the future can use something like S3’s glacial deep archive which is about $1.20USD a year to hold onto 100GB of zipped up projects.
Category 3:
- These projects may actually get used by people
- Since they’re developed with LLMs, there’s so much churn that there’s no actual point of reading the code since it’s quickly out of date. That means there’s no use for using the code forge’s source file features
- Issues that reference code will go out of date as soon as the code goes out of date which is far more likely than with category 1 users.
- These projects tend to have so much code churn that their builds are more inefficient than hand coded projects. This means that they’ll tend to want more powerful hardware to run their CI/CD pipelines than a community code forge can provide. So from their perspective, they’re better off running their own code forge anyway.
Keeping category 1 users on community code forges, saving the code forge’s resources from being used by community 2 users, and letting community 3 users tailor their own code forges for their own needs seems like a win for everyone actually using the community code forge, and not those treating it as a file dump.
Let’s discourage user transparency and AI disclosure
OMG that’s a great move.
deleted by creator
Seems reasonable but good fucking luck enforcing that.
IMO they should instead simply charge cost price for hosting. It can’t be much surely?
I don’t think the cost of hosting the repositories itself is the issue, more the legal problems and the fact that real projects get drowned out by the noise
While there are cases, when the garbage nature of genAI code wouldn’t cause that much of an issue, the issue will be that these projects ultimately will drive attention away from human-made code, which can have devastating effects on said projects.
I don’t really understand that line of reasoning. By definition if genai code is garbage, a human made competitor would be better. Why can’t it stand on its own qualities rather than rely on blanket banning the alternative?
I think it’s a matter of volume, it’s extremely easy and quick to publish large amounts of generated code, and by far most people won’t go searching your codebase in depth to see if the code is decent, if it works as advertised they don’t have a reason to look into it further. If you add a third party to vet all code then you’re still giving massive amounts of work to whoever has to review the mountains of slop.
It’s not like we didn’t have an issue like this before, about people copy pasting without understanding anything, but these tools made it more accessible and streamlined, and the worst part is that vibe coders believe sharing their slop is of value.
