Codeberg has decided to exclude projects whose code is predominantly written by generative AI. The members voted 358 to 144, and the terms of use will be updated accordingly. Tools such as Claude and OpenAI Codex are explicitly named. The reasons given are the unresolved copyright situation, the lack of safeguards against malicious code, and the burden placed on the small number of people who keep a project running.
The decision is understandable. It falls entirely within the responsibility of the association that operates the platform and protects its resources. Even so, the actual technical question remains unanswered: What exactly does “predominantly” mean in a mature repository with hundreds of commits, multiple authors, and years of history? And more fundamentally: Is the origin of the code really the measure by which its health can be judged?
For me, the interesting question is therefore not whether code comes from a human or from AI. What interests me is whether the architecture is healthy enough to deal with faulty code—regardless of where it came from.
Origin Is Not a Quality Check
Code written by humans can be poor. Insecure, difficult to maintain, lacking tests, lacking documentation. This is nothing new. Anyone who has spent enough time working in other people’s repositories has seen examples. AI-generated code can have the same characteristics—and just as easily the opposite: clean, reviewed, understandable, and clearly structured.
The label “written by a human” or “generated by a model” says very little on its own about how code behaves in production. Its origin may provide clues, but it is no substitute for a technical evaluation. In many projects, even determining the percentage of human or machine authorship is hardly possible in any meaningful way. Does an autocomplete suggestion count? What about an entire generated function body that was then revised line by line?
The Concern Behind It Is Legitimate
That does not mean Codeberg’s concern is unfounded. Autonomous agents generating repositories on a massive scale. Generated pull requests submitted without any understanding of the project they target. Maintainers forced to review someone else’s mistakes without anyone taking responsibility for them. Unclear accountability when something breaks. Resources consumed by code that nobody in the project can explain or maintain.
These problems do not arise because a language model was involved. They arise when nobody takes responsibility for the result. The true opposite of healthy code is not AI-generated code. It is code that nobody stands behind.
A Different Question
Perhaps, then, we are discussing this on the wrong level.
This is where what we are working on in Biocodie comes into play. Biocodie views a program not as a collection of files and functions, but as a community of autonomous cells, each with its own state, its own responsibility, and the ability to explain its own actions.
From this perspective, the question shifts.
Not: Who wrote this code?
But rather: How does a cell remain capable of acting when a neighbor provides faulty, contradictory, or unreliable information?
The Cell Model already includes self-diagnosis and the ability to request help—a cell should recognize when it can no longer fulfill its own responsibility reliably. What remains unresolved is this: How does it recognize unreliable neighbors? How does trust change through repeated experience? When does it request a second opinion, when does it isolate a relationship, and when does it accept a single error for what it is—a single error? And how does it prevent a local problem from damaging the entire playground? These are open questions, not solved ones.
Perfection Was Never the Foundation
An organism does not remain healthy because every cell functions flawlessly at every moment. Health also arises through recognizing deviations, limiting damage, redundancy, repair, temporary isolation, and adaptation. Software is often designed as though every participant must behave correctly. Nature follows a different path. A cell might observe: This neighbor’s answers contradict one another. It can then respond by reducing trust, verifying results more carefully, requesting a second capability, or temporarily limiting the relationship.
In doing so, the cell does not judge the moral quality of its neighbor. It observes behavior.
And an unreliable neighbor is not a special case of AI. It could be human-written code, an external library, a network service, an outdated configuration, or a cell with obsolete knowledge. An architecture that assumes perfect neighbors can only deal with real-world development to a limited extent—regardless of who or what ultimately wrote the faulty code.
Responsibility Instead of Authorship
This brings into focus what has always been a core principle of Biocodie: responsibility instead of functions. What matters is not who produced the first version, how many lines came from a model, or whether the code was typed manually or suggested automatically. What matters is whether someone can explain why the code exists. Whether it has been reviewed. Whether its limitations are understood. Whether the unit executing it can detect errors and request support. Whether it can be replaced if it fails.
A language model can generate code. It cannot take responsibility for a project.
That is precisely why Biocodie deliberately shifts responsibility away from the history of how code came into existence and toward the observable behavior of a unit. This is not an accidental analogy to biology. It describes a different way of looking at software.
Codeberg Answers a Social Question
Codeberg has every right to decide which development practices fit its own community. That is a legitimate social and political decision by an association about its own platform. It simply should not be confused with a technical definition of quality. The rule answers who is welcome. It does not answer how healthy software involving AI is actually created.
Perhaps the defining line does not run between human-written and generated code, but between code for which someone accepts responsibility and code that nobody understands, reviews, or maintains.
Perhaps that will become one of the questions we continue to explore in Biocodie.
Healthy software does not emerge from perfect neighbors. It emerges from the ability to deal responsibly with imperfect ones.
