This week the FOSS world has seen (at least) two bold discussions about AI: Codeberg banned code written (mostly) by LLMs, while the Debian community is hosting a very similar decision-making process (with unknown outcomes at this point).

Reading some articles commenting about the Codeberg case, I started to find words for something that really bugs me in this debate: people are using written by AI as a proxy to assume quality in software.

And that is a terrible proxy for that. I had that feeling for months now, but I found the words for it today.

A story from late 2025

I was reading this particular blog when it clicked. I enjoyed the reading (even if I disagree with a lot of the opinions expressed there). That piece reminded me of something I wrote over half a year ago when someone submitted a really low quality vibecoded PR to a project I maintain, a project with over 1,000 stars on GitHub.

That particular PR had all the red flags. The description looked like slop: different language from all the contributions in the project, full of sub-headers, hyper verbose pitch about the contribution itself. I am not sure right now — and GitHub is not loading — but probably it was full of emojis and em-dashes. But I love em-dashes, let's be clear about it.

Anyway, I took a look at the code and I could bet it wouldn't work. It was suggesting to fix an issue that had been broken down into 5 sub-issues. And the code was probably too short to take all that into account — not that lines of code mean a lot, but I could see it was missing some abstractions I was expecting, so my feeling was that there were important bits missing, maybe a naïve implementation? I wasn't sure. So, I decided to run the code. Surely it was broken.

That was my response to that PR, to that poor attempt to load millions of records to a database (the core of the issue it was arguably addressing):

I will be frank with you: this PR gives me the vibecoding air, and not in a good way. There are parts of the description and of the code that are definitely not part of the implementation suggested in these commits. I was not surprised to see that running your branch does not load a single record to the database (console logs below, at the end of my message). The way I understand it makes me afraid the situation might be as follows:

The code and description might be something no human bothered to write, and, on top of that, no human might have even read them before opening the PR here. And that is really harmful.

Maintaining open source is as tough as it is demanding, and I like to think that if the idea is not to help, at least try not to get in the way of people maintaining it. Vibecoding is potentially harmful because it gets in the way. Let's suppose one does not write or read a contribution before sending it to someone else. In that case, this person is demanding time from the maintainers to do the labour they refused to do, the labour they are completely delegating to LLMs.

I will not let this happen in this project. Therefore, let’s talk and see how I can help you contribute to this community with your interest in the project.

I am delighted you showed up. Before we move forward and I review this PR, please go over the description and the code one more time to ensure they are consistent and accurately describe what these commits implement. Also, there is a lot of this work already in another PR, and it would be wonderful if those efforts were aligned, or if we could discuss the different approaches suggested there and here to consider which would work better in the short- and long-term.

I am more than happy to support you and answer any questions you might have. But I want to make sure we are on the same page: let’s not allow LLMs to steal our time.

Here I slightly modified the text above to omit unnecessary details (and eliminate some typos). But the core of this argument came back today.

Enough of 2025, let's get back to today's trending topics

I understand Codeberg's efforts to “protect” the community, and I am really excited that one of the proposals on the table for the Debian community touches on that very same argument because we are humans — we must be accountable for the FOSS contributions we make:

Contributors assume full responsibility for their contributions, including vouching for the technical merit, security, license compliance, and utility of their submissions. The contributor remains solely accountable for the entirety of these contributions. Contributors should fully understand the proposed changes and be prepared to justify them.

On the project from the PR I used as an example, later on, I added a guideline to the contribution guide based on Fedora's contribution policy: the code you submit must be something you tested, fully comprehend, and are fully capable of engaging in a productive discussion about the implementation, abstractions and tests suggested there.

In my opinion, and based on my experience, that mindset really changes things. I worked at companies where people were excited opening PRs without even reading the code (maybe not even understanding it) and obviously the result was: bugs. Bugs all over the place.

Once things were broken, it was chaos, mainly because often the system paying the price of a bad implementation was not where the problematic PR was shipped. The LLM cannot know the context where it is shipping code, so not a huge surprise, right? For example, a bug in a consumer might cause a bottleneck blocking a producer; then the team working on the producer was paged, but they had little to no context on what was just shipped on the consumer.

In places like that, usually code reviews were also problematic: thousands of lines of code changed, and if I had a question, people would just answer with I am not sure, AI wrote it that way. That was terrible. But that is not an AI problem; that is a human, a culture problem, mostly an accountability and a communication issue.

That is why I truly believe that targeting LLMs is not effective in enhancing software quality. Software quality comes from collaboration among humans, and not only collaboration between software engineers. It involves the whole culture in which this person is coding, with or without AI: how success is measured (if it is), what are the pressure and incentives to write that software, what are the pain points for delivery, etc. And how everybody involved negotiate all those tensions.

AI has tons of problems, and I do appreciate Codeberg's blog because it touches on so many of them: from ecology to morality, including hardware and service prices. It is crazy! But I still refuse to use written by AI as a proxy for quality. I prefer to criticize AI in the ways it can be potentially harmful, and that is a socio-technical construct, not a software quality issue. It requires a complex, social, and cultural perspective a simple let's ban AI cannot tackle. It is about how we make decisions about software in our society, not about how we mechanically write code.

As Evan Czaplicki said (in a completely different context, let me be honest about it), code is the easy part — the challenge is to understand how we organize ourselves and our values around it.