Generative AI has become deeply embedded in modern software development. Developers use it to explain unfamiliar code, generate functions, write tests, draft documentation and sometimes produce entire applications from a sequence of prompts.
Codeberg has now decided that some of those practices do not fit the kind of open-source community it wants to operate.
Members of the German non-profit Codeberg e.V., which runs the Codeberg software forge, have approved two proposals dealing directly with generative AI. The first formally prevents Codeberg from using hosted code or user data to train large language models. The second introduces restrictions on projects created largely through AI-generated code with limited human authorship or supervision—commonly described as "vibe coding."
The first decision strengthens a privacy position Codeberg had already expressed. The second is far more controversial because it could affect which projects are permitted to remain on the platform.
A Member-Led Decision Rather Than a Corporate Product Strategy
Codeberg operates differently from large commercial platforms such as GitHub and GitLab.
It is run by a non-profit association, with important policy proposals discussed during its annual assembly before members vote over a 14-day period.
That governance model means the new AI policies were not simply introduced by executives or product managers. They were debated and approved by the association's members.
Both AI-related motions passed after voting closed.
The result gives the decisions more institutional weight. They are no longer informal preferences or wording hidden inside a privacy notice. They now represent formal positions adopted through Codeberg's membership process.
Codeberg Will Not Train AI Models on Hosted Projects
The first proposal confirms that Codeberg will not use the code, content or data belonging to hosted projects and users to train generative AI systems.
This includes large language models designed to produce output based on patterns learned from training material.
Codeberg had already indicated through its privacy policy that it wanted to minimise the amount of personal information it collects and processes. The membership vote turns that broader principle into a specific commitment concerning generative AI.
For maintainers, the message is straightforward: hosting a repository on Codeberg does not give the platform permission to treat that repository as training material for an internal AI product.
That position may appeal to developers who are uncomfortable with public code being incorporated into commercial model-training datasets without clear consent, attribution or compensation.
Open Source Does Not Automatically Mean Open for AI Training
The debate reflects a wider disagreement within software development.
Publicly accessible source code can usually be viewed, downloaded and redistributed according to the terms of its licence. However, developers continue to disagree over whether those permissions automatically extend to machine-learning training.
Some argue that training a model on public code is another form of analysis. Others believe that model training creates a separate use that may not respect licence obligations, authorship or project intent.
Codeberg has chosen the more restrictive interpretation for its own services.
Its stance does not change the licence attached to an individual repository, nor can it completely prevent an external organisation from attempting to collect publicly available code. However, Codeberg itself is committing not to use hosted material to build generative AI systems.
The organisation has also described the current generative-AI model as difficult to reconcile with responsible free and open-source software stewardship.
That is a stronger position than simply saying it will not train a model for commercial reasons. It frames the issue as one involving community values, resource use and responsibility.
The "Vibe Coding" Restriction Is More Divisive
The second motion changes Codeberg's terms of use to restrict what it describes as vibe-coded projects.
The term generally refers to software produced largely through conversational prompting, where an AI model generates much of the code and the human operator provides relatively limited technical review or direct authorship.
This does not necessarily mean every project that uses an AI assistant will be prohibited.
A developer who uses an LLM to explain a function, draft a test or suggest a refactoring may still be exercising meaningful control over the project.
Codeberg's concern appears to focus on repositories generated substantially or almost entirely by AI, particularly when the maintainer may not fully understand, review or support the resulting code.
The distinction is important, but it may also be difficult to enforce consistently.
The Vote Passed, but Not Without Opposition
The vibe-coding proposal received 358 votes in favour, 144 against and 14 abstentions.
Nearly three-quarters of participating members supported the restriction, but the 144 opposing votes represent a substantial minority.
This was not a symbolic motion that passed without debate. It exposed a real disagreement within the Codeberg community.
Supporters may see the policy as necessary to protect limited infrastructure and maintain software quality. Opponents may view it as difficult to define, intrusive to enforce or unnecessarily hostile toward tools that are already widely used by developers.
The level of participation was also notable. Around half of Codeberg's active membership reportedly voted, which the organisation described as a high turnout.
The result gives Codeberg a mandate to proceed, but it does not eliminate the need for careful implementation.
AI Crawlers Have Become an Infrastructure Problem
Codeberg linked both votes to a practical problem: aggressive web crawlers operated for AI data collection.
Codeberg already allows public repositories to be accessed through ordinary Git operations. Anyone can clone a public project without loading every individual webpage on the platform.
According to the organisation, some AI crawlers do not behave that way.
Instead, they repeatedly request web pages representing repository files, issue views, filtered issue lists, commit histories and historical versions of files—even where the file contents have not changed.
This browsing pattern creates a very different load from cloning a Git repository.
A single repository may contain thousands of commits, issue combinations and navigable pages. When automated crawlers attempt to retrieve each variation individually, they can generate large numbers of database queries and application requests.
For a volunteer-supported non-profit platform, that activity can become expensive quickly.
Defending Against Crawlers Can Affect Everyone
Codeberg says its administrators have had to spend time building controls to reduce the load caused by aggressive crawlers.
Those controls may include rate limits, request filtering and access blocks.
The difficulty is that defensive systems do not always distinguish perfectly between a commercial crawler, a research tool and a legitimate user performing intensive work.
A rate limit designed to slow automated scraping may also affect developers browsing large project histories or using scripts against the platform.
As a result, the cost of AI crawling is not confined to extra server utilisation. It also includes engineering time, administrative attention and a potentially worse experience for ordinary users.
This is part of Codeberg's broader argument: the costs of generative AI are often pushed onto organisations and communities that did not choose to participate in model development.
The Hidden Costs Extend Beyond Model Providers
Much of the discussion around AI costs focuses on the companies operating data centres and the customers paying for subscriptions.
Codeberg argues that the wider burden also includes:
From Codeberg's perspective, a company training an AI model may benefit from publicly available code while leaving the hosting platform to absorb part of the collection cost.
That imbalance helps explain why the organisation is taking a stronger position than many commercial code forges.
Why AI-Generated Projects Can Strain a Volunteer-Run Platform
Codeberg's concerns about vibe coding are not limited to code quality or authorship.
The organisation has also raised questions about infrastructure consumption.
Maintainers say they have observed projects operated by a single developer that nevertheless run extensive CI/CD pipelines, publish frequent binary releases and claim support for many operating systems or hardware platforms.
Before generative AI, maintaining that level of output might have required a larger team and an established user community.
An individual using an LLM can now generate features, configuration files, tests and release workflows much faster. That may allow one person to create the appearance and infrastructure footprint of a much larger project.
From the maintainer's perspective, the problem is not simply that AI helped write the code. It is that automated generation may make it very easy to consume shared build minutes, storage, bandwidth and release infrastructure without a corresponding user base or contributor community.
Producing More Code Is Not the Same as Maintaining More Software
Generative AI can reduce the effort required to create a project, but it does not automatically provide the capacity to maintain it.
A repository may contain thousands of lines of code, support several platforms and publish frequent releases. Yet if one person prompted most of the implementation without deeply understanding it, that person may struggle to diagnose defects, review security issues or respond to user reports.
This creates a mismatch between visible project size and actual maintenance capacity.
The code may look active because commits and releases appear frequently. However, the project may lack experienced reviewers, a stable architecture or people capable of supporting it when something goes wrong.
For a hosting platform, this can result in resource-heavy projects with little sustainable community behind them.
Codeberg Has Not Published Data Showing the Scale of the Problem
Codeberg's concerns may be understandable, but the publicly described justification remains largely observational.
The organisation has not released detailed figures showing:
Without those figures, it is difficult to determine whether Codeberg is responding to a widespread operational problem or several highly visible examples.
That does not make the concern invalid, but it does mean the policy's proportionality will depend heavily on the evidence and enforcement process that follow.
Defining "Vibe-Coded" Will Be Difficult
The largest unresolved question is how Codeberg will decide whether a project falls under the new restriction.
There is no reliable technical test that can prove how much human authorship went into a source repository.
AI-code detectors are not sufficiently dependable for making serious enforcement decisions. Human-written code can resemble model output, while AI-generated code can be edited until its origin is impossible to determine.
Commit volume is also not proof. A highly productive developer may create frequent updates without using generative AI.
Extensive CI/CD pipelines are not proof either. A single maintainer can legitimately support many platforms through well-designed automation.
Even a maintainer's public admission that AI was used does not reveal whether the model generated one helper function or most of the application.
Codeberg will therefore need a definition based on behaviour, responsibility and project stewardship rather than unreliable attempts to identify AI-generated syntax.
AI Assistance Exists on a Spectrum
Software development rarely divides neatly into "human-written" and "AI-written."
A developer might use an LLM to:
These uses involve very different levels of human control and understanding.
A blanket restriction on any LLM involvement would be difficult to justify and nearly impossible to enforce.
Codeberg has indicated that ordinary AI assistance is not necessarily the target. The concern is software built largely through automated generation with minimal meaningful authorship or oversight.
That distinction makes sense conceptually. Turning it into fair and predictable platform rules will be much harder.
Human Responsibility May Be the More Useful Standard
A practical policy could focus less on whether AI contributed code and more on whether the project has an accountable maintainer.
Relevant questions might include:
These questions examine the consequences that concern Codeberg without requiring the platform to prove exactly how each line was created.
A project could use substantial AI assistance while still being carefully reviewed and responsibly maintained.
Conversely, entirely human-written software can be abandoned, insecure or wasteful.
Enforcement Details Are Still Missing
Codeberg has acknowledged that the initial announcement does not fully explain how the new terms will be enforced.
The organisation plans to publish additional guidance covering the practical impact.
That follow-up will be important because the vote establishes the policy but not its operational boundaries.
Maintainers need to know:
Without clear answers, developers may not know whether their current use of AI places a project at risk.
False Accusations Could Damage Legitimate Projects
Any enforcement process must account for mistakes.
A project maintained by one person may be highly automated because the developer has invested years in release engineering.
A large volume of commits may come from code generation tools that predate modern LLMs, such as compilers, schema generators or interface builders.
Support for many platforms may be legitimate for libraries designed to be portable.
If these signals are treated as evidence of vibe coding, maintainers could be wrongly targeted.
Codeberg will need transparent review procedures and a meaningful opportunity for maintainers to explain their work.
Otherwise, the policy could discourage legitimate developers who fear being judged based on superficial patterns.
The Policy Creates a Clear Contrast With GitHub
The vote makes Codeberg's identity increasingly distinct from GitHub's.
GitHub has integrated Copilot directly into its development experience and treats generative AI as a central product capability.
Codeberg is moving in the opposite direction.
It is rejecting the use of hosted projects for model training and limiting repositories that it considers predominantly AI-generated.
For developers choosing a hosting platform, the difference is no longer only about ownership, pricing, privacy or open-source governance. It is also about the role AI should play in software development.
Some maintainers may prefer GitHub's AI-assisted workflow and large ecosystem. Others may value Codeberg's privacy commitments and resistance to commercial model training.
The two platforms increasingly represent different philosophies.
This Could Attract Developers Who Want an AI-Resistant Space
Codeberg's position may appeal to open-source contributors who feel that generative AI companies have used public code without sufficient consent.
Maintainers who do not want their projects incorporated into platform-operated training pipelines may view Codeberg as a more aligned hosting environment.
The policy could also attract communities that want greater emphasis on human authorship, maintainability and smaller-scale collaboration.
However, the same stance could push away developers who use AI extensively but still believe they are maintaining their projects responsibly.
Codeberg may gain a clearer identity at the cost of narrowing the range of communities that feel welcome on the platform.
The Rules May Be Harder to Apply to Collaborative Projects
A further complication arises when projects have several contributors using AI in different ways.
One maintainer may write code manually. Another may use an assistant for testing. A third may contribute a model-generated module that receives extensive human review.
Would the project become vibe-coded because some contributions relied heavily on AI?
What if the initial version was generated through prompts but later rewritten and maintained by a community?
What if an organisation imports a project from another forge without knowing how it was originally produced?
These situations demonstrate why project-level bans can become difficult to apply in collaborative environments.
The enforcement framework will need to account for history, review practices and current maintenance rather than relying on a simple label.
Resource Governance May Be Easier Than Authorship Policing
Some of Codeberg's concerns could potentially be addressed through resource controls rather than content restrictions.
The platform might limit excessive CI/CD consumption, apply storage quotas, restrict high-frequency binary releases or require approval for resource-intensive workloads.
Those rules could apply equally regardless of whether the code was generated by AI.
A human-written project that consumes unreasonable infrastructure would face the same restrictions as an AI-assisted one.
This approach would directly target the operational problem while avoiding debates over authorship.
However, Codeberg's motion appears to express a broader ethical objection to projects produced with minimal human involvement, not merely their infrastructure footprint.
That means resource limits alone may not satisfy the association's goals.
Open-Source Communities Are Starting to Define Their AI Boundaries
Codeberg's vote is part of a wider shift across open-source communities.
Projects and platforms are being forced to decide:
There is unlikely to be one universal answer.
Different communities have different resources, licences and values. A commercial platform may see AI integration as a competitive advantage, while a volunteer-run forge may view the same activity as a burden or threat to community sustainability.
Codeberg has now made its own position unusually clear.
What Maintainers Should Do Now
Developers hosting AI-assisted projects on Codeberg should pay close attention to the promised enforcement guidance.
Until more detail is available, maintainers can reduce uncertainty by ensuring their projects demonstrate meaningful human oversight.
Documentation should explain the project's purpose and architecture. Releases should be tested. Generated code should be reviewed, and maintainers should be able to respond to defects and security reports.
Teams should also examine whether their CI/CD and release schedules are proportionate to actual demand.
Where AI plays a substantial role, transparent disclosure may help establish that the maintainer is not attempting to misrepresent the project's development process.
However, disclosure requirements have not yet been defined, so maintainers should avoid assuming that transparency alone will guarantee compliance.
Final Thoughts
Codeberg's members have chosen to draw one of the clearest boundaries against generative AI among major public software forges.
The decision not to use hosted code and user data for LLM training strengthens the platform's privacy-focused identity and responds directly to concerns about consent and aggressive AI crawling.
The restriction on vibe-coded projects is more complicated.
Codeberg has raised legitimate questions about infrastructure consumption, misleading project scale and software created faster than it can be responsibly maintained. Yet it has not yet provided enough evidence or enforcement detail to show how the policy will operate fairly.
The success of the rule will depend on whether Codeberg can distinguish irresponsible automation from legitimate AI-assisted development without relying on unreliable detection methods or vague assumptions.
For now, the vote sends a strong philosophical message: Codeberg wants to remain a platform centred on human stewardship, accountable maintenance and community-controlled infrastructure.
The next announcement will determine whether that principle can be translated into clear, practical and enforceable rules.
Comments