This was my first thought after they disallowed LLM contributions.
They may not use AI to check for vulnerabilities but attackers are going to which puts themselves at the disadvantage.
They may not use AI to check for vulnerabilities but attackers are going to which puts themselves at the disadvantage.
https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...
Forgejo disallows LLM contributions, including using a "general AI" (they include LLMs under "general AI") for reviews[0]:
> 5. Using general AI for review is forbidden. If the change contains changes to the UX it has to be approved by a human reviewer.
[0] https://codeberg.org/forgejo/governance/src/branch/main/AIAg...
The rule you quoted is about code reviews, they don't want you using an LLM to write reviews or leave comments.
This is a pretty poorly written policy to be honest, so I understand if you interpret it to mean "no LLMs in any capacity", but I think if that's what they meant they would have said that. In fact they explicitly allow content "made with the help of AI", you just have to disclose it.
>Vibe coding is the practice where AI creates a code change (feature, bug fix, tests, refactor) with a human that describes what needs to be implemented.
So if you let an AI prompt another AI without human input, that's not vibe coding? Meanwhile if you prompt the model with pseudo code you've written or code written in another programming language to translate into the target language, that's vibe coding?
>It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo.
They used the word "in", meaning it could refer to organizational membership, their repo or theoretically any instance of Forgejo, including self hosted ones. They failed to specify what part of Forgejo or the definition of Forgejo they meant.
Overall this is a pretty poorly written document and when you think about it, it doesn't really matter how poorly written it is when they are basically 100% against AI.
You're misreading the rule.
>> 5. Using general AI for review is forbidden.
The second sentence makes it even clearer, as it would have been unnecessary under a blanket ban scenario
>> ... If the change contains changes to the UX it has to be approved by a human reviewer.
> Forgejo does not accept works of authorship (code, documentation, etc.) either partially or completely generated by AI due to legal uncertainties.Would that not imply that a change that does not effect the UX does not have to be approved by a human reviewer? Otherwise, why specifically call out "changes to the UX" and not say "all changes"?
You are implying that just by allowing LLM contributions your product is free of bugs, and the LLM won't introduce new bugs. Of course, if the LLM introduces bugs, the solution is to add another layer of LLM looking for bugs, ad infinitum.
Another post from today from Shopify, praising LLM to code their frontend, also stated that their LLM generated code is not ready to deploy, and needs to be reviewed:
> It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped. [...] each [build] must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts.
you didn't read the comment, did you?
That... is not the implication of the comment you're replying to.
You don't need to make it all fundamentalist.
>6. It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo. This also applies when someone engages in 'vibe coding' or uses so-called 'agent mode'.
Go back and read the threads. On this forum, or on mastodon, or on the vote. It was pretty vociferously ... shall we say ... "principled"
It was never stated to be about "low quality" but about use in "large part" or "majority", and when pressed people refused to define what that meant, and in fact got angry and defensive and said things like "you'll know if you've crossed the line" and "stop trying to force consent" and similar pearls of wisdom.
The post-facto rationalization did in fact leave them room to judge "quality" on a purely subjective basis. I didn't stick around to find out how that would shake out.
There's no team of lawyers verifying the provenance of all code/projects submitted to codeberg. THe policy is just something they can point to as a general guidelines of what kind of shit they want to support.
Everyone knows exactly what kind of projects they're talking about. The people trying to nitpick definitions are those annoying ass people at the board game night that spend half the time combing through the rule book trying to figure out why whatever they didn't like was against the rules.
Ordinarily that's a bad way to run a rule. But not this time!
That's fine for new projects. Their sandbox and they can decide who plays in it. But the people who were using codeberg for months or even years and relying on it, and had to move... deserved better treatment.
Fomr my eyes the questions about what defines "majority" were well-intention-ed queries with the motive of trying to ferret out what the criterion for was in the eyes of the people who proposed the vote. That they refused to answer, and cast aspersions on the people who asked... is both a damning judgement on their personal character but also their community management.
What we have is a community defining an in-group and an out-group. And just like middle school, "you'll just know" if you're in one or the other.,
Good grief. What a bizarre cultish echo chamber. The tools make you dirty. Don't touch the tools.
And now you're literally saying that a "no vibecoded projects" rule is a slippery slope to actual fascism. Good grief! What nonsense!
I might be wrong but I doubt that people on Codeberg are against use of LLMs that make the projects better. Like finding security leaks. What these rules are aimed at are hosting of endless vibe coded projects that are just copy of each other.
Instead a vaguely worded policy was put in around the tools used to write code so that vibe-based judgement could sit and decide without the potential judged having recourse to any appeal. And requests for specificity were not just turned down but mocked. Because the intent was to leave it open so that a process of bullying could be put in place.
Basically, anti-democratic practices masquerading as community/democracy. I used to see this a lot back when I was involved more heavily in left wing activist groups and it was the sign of a declining and degraded community. Sad to see it here.
As for "I assume you are implying that LLM generated projects don't mean bad quality. That's true." I'm specifically saying LLM assisted/generated doesn't mean one way or the other. They're tools.
big hugs.