AI Policy#

DataFusion has the following policy for AI-assisted PRs:

  • We welcome AI-assisted PRs from anyone. We do not welcome unreviewed “AI dumps” (defined below).

  • The PR author should have personally read the entire PR they submit and understand the core ideas end-to-end. Authors should be ready to justify and help reviewers understand the design and code during review.

  • Call out unknowns and assumptions. It’s okay to not fully understand some bits of AI-generated code. Please point these cases out so we can work together to clear up any concerns.

  • Follow ASF Generative Tooling Guidance. Among other things, the author must ensure the PR does not include undisclosed third-party code or copyrighted material.

While “understand the core ideas” is partly subjective, it means more than being able to follow the diff textually. We expect the PR author to take an active role in responding to feedback and crafting the PR to make sure it fits well into the project as a whole. The worst situation is one where the reviewer ends up simply driving the contributor’s LLM, for the reasons described in the next section.

What is an “AI dump” and why it is not helpful#

An “AI dump” is a PR, or a series of PRs, consisting largely of AI-generated code and descriptions that the author has not reviewed and does not understand. The code may even be correct. The problem is that all the work of understanding falls on the reviewer.

Code review serves two purposes:

  1. Finishing the intended task.

  2. Sharing knowledge between authors and reviewers, as a long-term investment in the project. For this reason, even if someone familiar with the codebase could finish a task more quickly by themselves, we are still happy to help a new contributor work on it.

An AI dump meets neither purpose. Maintainers could finish the task faster by running the AI tool themselves, and an author who acts only as a pass-through proxy for the tool learns little from the review.

Reviewing capacity for the project is very limited, so PRs that appear to be AI dumps may not get reviewed, and may eventually be closed.

Multiple PRs created in a short amount of time, especially by a first-time contributor, that in our judgment show a lack of understanding or author engagement may be treated as spam and closed. One high-quality PR that you work with maintainers to merge is far more valuable to you and the project than ten PRs you have your agent generate and submit for you.

Responding to review comments#

The same policy applies to review discussion as to the code itself: reviewers want to talk to you, not to your AI tool. Please do not respond to reviewer comments with unreviewed, fully AI-generated responses, as this again puts all the burden on the reviewer and you learn nothing. We expect your responses to be in your own words, though it is fine to use AI to help prepare your response (for example to understand the comment, or help translate your response to English). Examples of unreviewed AI-generated replies:

  • Summarizes the diff rather than answering the question that was asked.

  • Lists the commands run locally (e.g. cargo fmt, cargo test) and whether they passed. This is not useful to reviewers because CI already runs these checks.

  • Contains statements that don’t make sense in context, such as claiming tests could not be run because cargo is not installed.

For example, see this review thread in arrow-rs where the reviewer asked a design question, and received several replies that described what had changed and which commands had been run, rather than an answer to the question.

Again, the point of code review is to help the project and to help you grow as an engineer, so please read each comment, make sure you understand it, and reply in your own words.

AI-assisted reviews#

The same standard applies to AI-generated reviews as to AI-generated code: you should have read and understood anything you post. Raw AI review output is often verbose with unnecessary details, and it can take substantial effort to figure out what is actually being asked.

If you review PRs with the help of an AI tool, read all comments first, remove detail that is unnecessary or you don’t understand, and explain the rest in your own words so that each comment makes a clear, specific request.

Better ways to contribute than an “AI dump”#

It’s recommended to write a high-quality issue with a clear problem statement and a minimal, reproducible example. The reproducer should focus on the end-user-visible behavior rather than explaining the details of some code defect.

This will make it easier for others to contribute and for reviewers to understand the problem being addressed.