AI Code Is Cheap. Open Source Maintainers Pay the Bill

An AI coding agent can do work and generate a respectable pull request before you finish your first cup of coffee.

It can read an issue, find the relevant files, write the code, add tests, and draft a polished description.

That sounds like progress.

And inside your own codebase, it often is.

But an open source pull request crosses a boundary. The code may have taken you five minutes to generate, but someone else now has to figure out whether it belongs in the project. They have to check your assumptions, reproduce the bug, review the implementation, run the tests, and live with the change after you disappear to vibe your next pursuit.

And personally, this puts me in an awkward spot.

I teach people how to code with AI, and I use coding agents every day. Thus, I have no interest in telling developers to stop using them.

But we need to be honest here: AI has made code cheap.

Review, context, and maintenance still cost real time.

If you use AI to contribute to open source, your job is to pay those costs, and do the work, before you click Open pull request.

Why open source maintainers are closing the gates

And this is no longer a hypothetical problem.

In January, tldraw began automatically closing external pull requests. Maintainer Steve Ruiz said many of the new PRs looked formally correct but lacked context, misunderstood the codebase, and received little follow-up from their authors.

Ghostty now requires first-time contributors to get vouched before opening a PR. Its AI policy also requires disclosure and says contributors must understand every change without leaning on an AI tool to explain it for them.

The curl project had a similar problem with security reports. Its bug bounty once produced 87 confirmed vulnerabilities and paid more than $100,000 in rewards. In 2025, however, the percentage of submissions that became confirmed vulnerabilities fell below 5 percent. The team ended the bounty to remove the financial incentive for speculative reports.

That change worked. Curl later returned to HackerOne without restoring cash rewards, and Daniel Stenberg reported that the slop problem had subsided even as report volume increased. Removing the reward changed what people dumped on maintainers without shutting out useful AI security research.

A July 2026 study of 294 open source repositories put numbers behind the frustration. The researchers analyzed more than two million pull requests and issues. PR volume increased during 2025, while one-time contributors saw an estimated 18.18 percent decline in merge rates compared with the study’s counterfactual.

More code entered the queue. Less of it was useful.

A pull request is a request for attention

We tend to talk about a PR as if it were a gift. You wrote free code. Why wouldn’t a project want it?

Well, because code is only one part of the contribution.

When you open a PR, you are asking a maintainer to spend attention on your idea. Bring enough evidence and context that they can make a decision. Otherwise you have handed them all of your uncertainty along with the code.

AI makes that transfer dangerously easy. You can paste an issue into an agent, let it work for ten minutes, and submit the result without ever deciding whether the issue was valid or the solution fit the project. The diff might look great. The checks might even pass. That polished wrapper can make unfinished work feel finished.

The missing part is judgment.

Confirm that the work is wanted

Do this before asking an agent to write code.

Read CONTRIBUTING.md, the pull request template, and any AI policy in the repository. Search the issues and pull requests for earlier attempts. Some projects only accept work tied to approved issues. Some want a design discussion before implementation, and a few are not accepting outside code at all.

If the policy is unclear, ask:

I can reproduce this issue on version X with the steps below. I would like to work on a small fix. Is this approach wanted before I start?

That short comment can save everyone hours. Silence is not approval, and an open issue is not always an invitation to implement the first solution an agent invents.

Reproduce the problem yourself

Do not submit a fix for a bug you have never seen.

Before touching the code, write down:

• The exact version or commit you tested
• The smallest set of steps that triggers the problem
• What you expected to happen
• What happened instead
• A minimal example, log, screenshot, or failing test

If an agent discovered the bug, verify it without relying on the agent’s explanation. Security reports deserve an even higher bar. Curl’s current reporting guidance asks for a self-contained reproducer because a report without one pushes that work onto the security team.

Your reproduction is proof that you investigated a real problem rather than forwarding a plausible story.

Pass the understanding test

Ghostty’s central rule is a useful rule for every project: you must understand your code.

Close the chat window and answer these questions in your own words:

1. Why does the bug happen?
2. Why does this change fix it?
3. Which behavior could this change accidentally break?
4. Why is this approach consistent with the surrounding code?
5. What would you inspect first if a maintainer reported a regression?

If you cannot answer one of them, keep investigating. Ask the agent to point you to the relevant call path, documentation, and existing tests. Then verify what it tells you in the codebase.

You should reach the point where you can continue the conversation if the tool disappears. Memorizing the agent’s explanation does not count.

Keep the diff boring

Agents like to be helpful. Ask for a one-line bug fix and you may also get renamed variables, reformatted files, a new helper, and extra documentation.

Cut all of that unless the project asked for it.

A focused change is easier to review and easier to revert. Avoid new dependencies unless they are necessary. Do not combine cleanup with behavior changes. Do not let the agent “improve” nearby code just because it noticed something.

I use the same small-task rule when agents work in my own repositories. My guide to using AI coding agents safely covers branches, worktrees, permissions, and diff review in more detail.

Before committing, inspect exactly what changed:

git diff --stat
git diff
git status --short

If the diff is larger than you expected, stop and find out why.

Test the change, not the agent’s confidence

“The tests should pass” is not a test result.

Run the project’s documented commands yourself. Record the commands and results in the PR description. Add a focused test that fails before your fix and passes after it when the repository supports that kind of test.

Also check whether the agent weakened an assertion, deleted a failing test, or mocked away the behavior it was supposed to verify. Green CI tells you that the configured checks passed. It does not prove the solution is correct.

A useful PR testing section is plain and specific:

## Testing

- Reproduced on macOS 26.0 with commit `abc1234`
- Added a regression test that fails on `main`
- Ran `npm test -- path/to/regression.test.ts`
- Ran `npm run lint`
- Manually verified the original reproduction no longer fails

Do not claim a test you did not run.

Disclose how you used AI

If the project has a disclosure format, follow it. If it does not, one or two sentences are enough:

AI disclosure: I used Claude Code to locate related code and draft the initial implementation. I reviewed and edited the full diff, wrote the reproduction steps, and ran the tests listed above myself.

Be accurate. “AI assisted” is too vague if the agent produced the entire first draft. You do not need to paste a novel about every prompt, but the maintainer should not have to guess how much of the work you personally verified.

Disclosure does not rescue work you do not understand. It simply lets the project apply its policy with the right context.

Stay after you submit

The work continues after you submit the PR.

Watch for review comments. Answer questions yourself. Make requested changes promptly or tell the maintainer when you cannot. If the change is merged and later causes a regression, help investigate it.

This is where many drive-by AI contributions fall apart. The author was interested in producing a PR, not in getting the right change into the project.

If you are unwilling to maintain the conversation, do not ask someone to begin it.

Add an open source preflight to AGENTS.md

You can teach your coding agent to stop before it creates a mess. Add this to the repository-level AGENTS.md, CLAUDE.md, or equivalent instructions used for contribution work:

## External contribution preflight

Before editing code for an external open source project:

- Read CONTRIBUTING.md, the pull request template, and any AI policy.
- Confirm the project accepts external pull requests.
- Find an approved issue or explicit maintainer request for the work.
- Reproduce the problem and save the exact steps before proposing a fix.
- Stop and ask me before writing code if any of the above is missing.

Before suggesting that I open a pull request:

- Keep the diff limited to the approved problem.
- Show me every changed file and explain why it changed.
- List the exact test commands you ran and their results.
- Identify likely regressions or edge cases.
- Draft an accurate AI disclosure.
- Never open or submit the pull request without my confirmation.

These instructions give the agent a chance to interrupt you before speed takes over. You still have to make the call. If you use both Claude Code and agents that read AGENTS.md, you can share the instructions without maintaining two copies.

The five-question check before submitting

Before opening an AI-assisted pull request, ask yourself:

1. Did a maintainer indicate that this work is wanted?
2. Can I reproduce the problem without asking the AI?
3. Can I explain every meaningful line in the diff?
4. Did I personally run and inspect the relevant tests?
5. Will I stay involved until the maintainer is done with the contribution?

If one answer is no, do not submit yet.

AI can help you become a better open source contributor. It can search unfamiliar code, explain history, draft tests, and save hours of mechanical work. But speed only helps when you keep ownership of the result.

The maintainer does not owe your agent a code review. Make the contribution worth a human’s time.