We are in an age where someone’s one-sentence prompt to an AI coding tool can generate enough code to overwhelm a reviewer. I plan to focus my code review on people who actually use the open source systems I help maintain rather than an endless stream of low quality AI-generated PRs. Such PRs do not add value, and I think they actually harm the open source communities I care about.

Open Source: Still a Good Idea

I help maintain Apache DataFusion, arrow-rs, and Apache Parquet, and I have reviewed A LOT of code and PRs in my 20+ years as a professional software engineer. Open source development is most effective when users band together to create and maintain software that is bigger and better than they could create themselves. Historically, it also helped students and hobbyists learn the craft of software engineering and new languages and frameworks by contributing code and receiving feedback from experienced maintainers.

While I still think there is huge value in collective maintenance, open source as a way to learn software engineering and new technology stacks is much less valuable. It has never been easier to learn using one of the amazing AI tools out there (Codex, Claude, Copilot, etc.), and feedback from overworked open source maintainers is likely less helpful and takes longer to arrive.

Some people have predicted that open source is obsolete now that you can turn an agent loose and wake up the next morning to marvel at 50,000 lines of new code. This may turn out to be true, but my thesis is that we will continue to build systems by assembling libraries that embody our collective wisdom and experience, and those libraries will still be built and maintained by open source communities. I am not ready to rage-quit open source, but I am changing how I spend my time.

Low-Quality PRs: Harming Open Source Communities

I used to enjoy reviewing proposed contributions (PRs) because it helped my projects and taught me new techniques. However, over the last 12 months, I have become overwhelmed by the number and size of PRs. Many come from new contributors, with lengthy descriptions and substantial code and test changes but little context about the problem being solved (despite detailed descriptions of the code being changed). Instead of researching and refining the request, many contributors submit a raw (perhaps unreviewed) PR and effectively ask the maintainers to sort through their agent’s output. We have seen contributors submit 10+ PRs in a single day, prompting us to introduce open PR limits.

Even more demotivating, my review comments often get what appear to be unedited AI-generated responses within minutes. I learn little from these exchanges, and I doubt the contributors do either. As stated in the DataFusion AI guidelines, I can iterate on AI-generated code myself; doing so through a “meat proxy” simply adds work without value.

I used to prioritize new contributors because we needed coding capacity, and helping people learn was an investment in the community. Now code generation far exceeds our capacity to review it. Even worse, I feel prioritizing new contributors hurts longtime (and thus likely more valuable) contributors. The never-ending stream of new PRs sucks so much of my time that it often takes me weeks to review PRs and get back to existing community members. While I fully admit that part of this delay is due to my own penchant for starting too many things in parallel, the sheer volume of new PRs makes it easier than ever for me to get distracted. Frittering away review time also means larger, more important projects like Join Ordering and Parquet Pushdown aren’t making as much progress as I would like.

Going Forward

Therefore, going forward, I no longer plan to spend much time driving someone else’s LLM for uncertain reasons and low-value changes. Instead, I plan to prioritize PRs:

1. From actual users: They have the context to identify useful changes and evaluate their agent’s output, and the motivation to iterate on it until it is correct and merged.

2. Authored by prior contributors: My past interactions give me confidence in their work and their willingness to iterate on feedback.

3. Approved by other contributors (especially other committers): A few rounds of review put PRs in much better shape than raw LLM output.

4. From established GitHub accounts: Contributors with accounts over a year old and a reasonable history of contributions to other projects are less likely to be experimenting with an LLM.

To be clear, I believe most contributors are well-meaning, and there is nothing wrong with submitting PRs as a newcomer, but prioritizing them for review at the same level as other contributors is starving the projects of the time and attention needed to make progress. I realize this creates a chicken-and-egg problem for new contributors trying to establish a track record, but I am confident that motivated contributors will find a way.