Using AI on an open-source contribution

AI tools can help you read a codebase, draft a test, or explain an error message. They can also produce a pull request you couldn't explain if someone asked. Maintainers are seeing a lot of the second kind right now, and it has made some of them wary of newcomers. This guide covers how to use AI on a contribution without adding to that pile.

Why maintainers are cautious

In an October 2026 Linux Foundation survey, maintainers estimated that about a quarter of incoming pull requests are low-quality AI output, and more than half disagreed that AI had improved trust in their communities. Reviewing a pull request still takes a person's time, however fast the code was written. When a maintainer can't tell whether you understand your change, closing it is the safe choice for them. Read the Linux Foundation survey summary.

Check the project's AI policy first

Look in CONTRIBUTING, the pull request template, and the README for anything about AI tools. Some projects ask you to disclose AI use, some limit it, and some don't allow it. Many have no policy at all: the same survey found only about a third of projects had one. If you can't find a policy, ask on the issue before you start. In a Devprentice program, the AI policy is written into the program before you join.

Talk before you code

Comment on the issue, say how you plan to approach it, and wait for a maintainer to agree or assign it to you. A two-line plan costs a maintainer a minute to correct. A finished pull request that went the wrong way costs them much more, and costs you the work.

Keep it small

One problem per pull request. If the tool changed files you didn't ask it to touch, take those changes out. A small diff is easier to review, and easier for you to defend line by line.

Make sure you can explain every line

Before you open the pull request, close the AI tool and read the diff yourself. For each change, you should be able to answer these questions:

• What does this line do, and why is it needed?
• What else in the project calls this code?
• If this change were wrong, what would break, and which test would catch it?
• Why this approach and not the obvious alternative?

If you can't answer one, keep working until you can, or ask about it in the pull request description. An honest question reads much better than a confident guess.

Say how you used AI

If the project asks for disclosure, follow its format. If it doesn't, one plain sentence in the description is enough. For example: "I used an AI assistant to draft the test cases, then checked them against the existing tests and rewrote two." When maintainers know, they can review with the right amount of care.

Show your evidence

Run the tests and linters the project uses, and say what you ran in the description. If the change is visible, add a screenshot. If you tested by hand, list the steps.

Answer review in your own words

Review is where most of the learning happens, so don't hand it to a tool. Read each comment, make the change or ask a question, and reply yourself. Pasting a reviewer's comment into a chatbot and pasting the answer back is easy to spot, and maintainers run out of patience with it quickly.

Go deep, not wide

Opening pull requests across dozens of repositories is exactly the pattern maintainers have learned to distrust. Pick one project and stay with it, taking on related work over several weeks. A maintainer who has watched you follow through three times will read your fourth pull request very differently. Your first pull request, step by step.