If you attended FOSDEM 2026, you probably noticed discussions on how AI impacts FOSS, mostly in detrimental ways. Two of the three keynotes in Janson mentioned this, and I assume other speakers mentioned the topic too. Moreover, it was a very popular topic in the “hallway track.” I myself chatted about it with multiple people, both from the Postgres community and outside of it. And the experience does not seem great …

People try to use AI tools during development, with varying levels of success (often with so much hand-holding it doesn’t save any time in the end). But that’s not what this post is about. Let’s talk about how AI tools affect the functioning of the developer community, raising new contributors, and so on.

My main impression from all the discussions was that almost no one thought AI is a net benefit for their OSS project. It may help individuals (especially senior/experienced developers), but it changes the fundamental “economics” of the development in a way that increases the pressure on existing maintainers. It also disrupts the “funnel” of new contributors and (eventually) maintainers.

This is not a new issue, of course. OSS maintainers have always been spread very thin (obligatory xkcd), and for many projects it was getting worse over time. But the AI seems to amplify the issue.

What this post is not about

There’s no shortage of posts on various aspects of AI. This post is focusing on challenges AI is causing or amplifying for OSS projects. I’m not going to discuss the ethics of training/using AI, foundations, technology, or likelihood that it delivers on the many promises.

There’s a lot of great posts and talks about these topics. You can go to HN any day, and almost certainly there’s an interesting post about AI on the frontpage. There’s also a bunch of talks about AI from recent conferences, be it 39C3 or FOSDEM:

• FOSDEM - Open Source Security in spite of AI / Daniel Stenberg
• FOSDEM - FOSS in times of war, scarcity and (adversarial) AI / Michiel Leenaars
• 39C3 - AI Agent, AI Spy / Meredith Whittaker, Udbhav Tiwari
• 39C3 - Agentic ProbLLMs: Exploiting AI Computer-Use and Coding Agents / Johann Rehberger
• 39C3 - AI-generated content in Wikipedia - a tale of caution / Mathias Schindler

I may not agree with some of the claims presented in these talks. I’m sure there are many interesting talks from various other conferences.

This post is merely about the impact I see (or expect to see) in our project, and what I think we might do about it. These are my personal opinions. There’s an ongoing discussion, but it may take a while to figure out what to do (if anything).

The project economy

Every open source project relies on a healthy community, and Postgres is no exception. What does “healthy” mean, though? You might say it’s about being nice to each other, diversity, etc. And that is important, no argument here. But I think the overarching goal is sustainability. If a project dies for whatever reason, the community disappears.

Therefore, a healthy community has to be able to raise new contributors. People will move to work on other projects, retire or leave for some other reason. That is expected and natural. The community needs to grow enough experienced contributors to make up for the departures.

If the total number of contributors and maintainers grows over time, that is even better, of course! It allows either doing more work or spreading the work a bit more. Postgres is doing well in this regard, with a steady growth in number of active committers and contributors.

Raising experienced contributors takes time and effort, on both sides.

For new contributors it takes time to learn how the code works, details of the development process, thinking about new trade offs, etc. It also takes time to learn how to best communicate with other contributors on the mailing list.

It requires a fair amount of time from experienced contributors too, who need to help new contributors in various ways. It may mean reviewing a patch, responding to a review or discussing patch ideas off-list. Or something else, as long as it helps the new contributor.

And that is perfectly fine. I don’t know a single maintainer or senior contributor who would not recognize how important this is for the survival of the project. This is why we have community efforts like the semi-formal mentoring program, monthly hacking workshop, or the discord server.

The AI inversion

The AI seems to change the balance in a way that fundamentally breaks the process of growing new contributors.

There have always been more new contributors than senior ones, but there was also a little bit of friction. Writing a patch or submitting a review required investing a substantial amount of effort to understand how the modified part of the code works, what trade offs it requires, think about the use cases, testing, etc. And then you had to write a message presenting a coherent opinion.

This “proof of work” naturally restricted the amount of work required on the side of senior contributors. It also (probably?) selected for motivated contributors, willing to learn about the code and the development process.

It was not perfect, of course. A number of patches did not get any substantial feedback for far too long, for example. There’s always the possibility and ambition to do better.

Unfortunately, AI shifts this in exactly the wrong direction. It makes it much easier to produce plausible-looking patches, with all the issues expected from a junior contributor (and hallucinations). At the same time it does very little for maintainers who are expected to review those patches.

I’m afraid it disrupts the process of learning too. If most of the code was written by the AI, how much does the contributor learn? Does that mean he/she can ignore the “simple” code and focus on the big issues?

I’m not sure it works like that. For me the tedious “legwork” is a fundamental part of coding. It allows me to explore the trade offs and clarify what problem I’m even trying to solve. Offloading this part to some AI agent completely misses the point of how coding works.

This is not an entirely new problem. We’ve always had people reporting “bugs” identified by their favorite static analyzer, without spending enough time to investigate and verify the issue is real. Reports from static analyzers are certainly worth looking at, but the “signal to noise” ratio is relatively low.

AI makes this massively worse. It makes it much “cheaper” to generate the patch/review, and it also makes it much harder to realize this is happening. With static analyzers it was usually fairly obvious that’s where the report comes from (due to the formatting, wording, and so on). Generative AI usually mimics an organic report (just see the curl AI slop reports). No wonder curl decided to close their bug bounty program.

How serious is this?

There is no reliable way to identify code and/or reviews written by AI (entirely or partially), so it’s tricky to quantify how widespread this issue already is. But there are hints it’s becoming a serious issue.

A fellow contributor described how this affects his patches. She’s trying to “polish” the patches as much as possible before posting them to the mailing list, so she’s using AI tools to do a round of reviews.

The results are usually rather underwhelming. Most of the issues found by the tools are superficial or irrelevant issues (or hallucinations). Relevant issues get addressed, irrelevant ones get dismissed, and the patch gets posted to the mailing list for reviews by other.

Recently more and more “organic” reviews posted to the mailing list started to raise exactly the irrelevant (and thus dismissed) points from the AI review. Which is quite painful, because the custom is to respond to all reviews. And so the contributor is forced to spend a substantial amount of time explaining why it’s irrelevant.

It’s possible someone raises exactly the same review points as an AI tool. AI is trained on human reviews, after all. But if it happens repeatedly, it’s a hint.

This is more damaging than patches written by AI. You can choose not to review a patch, but for reviews you don’t have that choice. What’s worse, if the review really is written mostly by AI, your response is unlikely to stop the AI from making similar reviews again.

I occasionally try using AI for reviews too, with very limited success. The AI reviews seem to go directly against the “hierarchy of needs” from Robert’s An Exercise in Paranoia pgconf.dev talk.

Initial reviews need to focus on architecture / design, layering and other high-level aspects of the patch. Details like typos or naming can wait for later reviews. However, AI tools are good in finding these cosmetic issues, forcing everyone to resolve the unimportant stuff way too early.

Conclusions

I have no reason to think any of this is malicious, not in the sense that anyone is trying to cause harm. But even if the intentions are good and everyone is trying to help, the negative consequences can be real.

Without the AI the hope was the contributor would (quickly) learn what (not) to do, and in the end it’d be worth it. I’m not sure this approach still works. With AI it’s tempting to churn out more and more patches or reviews, and hope something sticks.

I’m not sure how big of a problem this will turn out to be, or what to do about it. I suspect personal connections will become more important. Not in the sense “you have to be friends with a maintainer” but in the sense that people will pay much more attention to patches and reviews from people they already know.

I’m concerned this will make it harder for new contributors to join the community. I wish new contributors had the same opportunities I had ~20 years ago. For now, the best thing I can offer is being available for off-list discussions, either by email or office hours.

Unfortunately, things are likely to get worse - not just in Postgres, but in the FOSS world in general. The curl AI slop story is widely known, but it’s unlikely the only OSS project having such an issue. There will be surprises. For example, last week we witnessed this bizarre story, and there will be more such “great” ideas.