Last month six of my pull requests were merged into other people's projects: an Android keyboard, a Python OAuth library and a reverse-engineering toolkit. Seven more are in review in Hyperledger Besu, Qwen Code, ParadeDB and Ratatui. Rust, Java, TypeScript, Kotlin and Python.
I use AI heavily to get there. I also know how maintainers feel about drive-by AI pull requests, because I read their issue threads. So here's the workflow I've settled on: fast because of AI, and still something a maintainer is glad to review.
Every project I contribute to gets the same first pass: CONTRIBUTING.md, any AGENTS.md, the PR template, and the AI policy if there is one.
The policies vary a lot. Ratatui welcomes AI-assisted PRs and asks you to say so. pandas wants the human to open the PR and do the talking, and to say which tools were used. Some projects ban AI-generated contributions outright, and I don't contribute to those. Others need a signed CLA or a DCO sign-off on every commit.
I keep a small policy file per repo so I never have to rediscover this, and so I never send a PR the project said it doesn't want.
A fix isn't real until a test fails without it.
In Ratatui, Japanese halfwidth sound marks (ﾞ ﾟ) started taking two cells instead of one. Nothing in Ratatui had changed. The unicode-width crate's 0.2.3 release had corrected those characters from width 0 to width 1, and Ratatui had a workaround that added +1 for them. Both "fixes" were now applying at once.
I ran the existing test suite on both dependency versions: everything passed on 0.2.2, and eight tests failed on 0.2.3. That told me the bug was real, where it was, and which tests would prove the fix.
.filter(|c| {
matches!(*c, '\u{FF9E}' | '\u{FF9F}')
&& c.width() == Some(0) // only compensate when unicode-width doesn't
})
One condition. It's correct on both versions of the dependency, so nobody has to pin anything. I didn't bump the dependency floor, refactor the width code or "clean up" anything nearby. Maintainers review for free, and every extra line is a cost I'd be putting on them.
Not every bug has one right answer. In Qwen Code, a /loop that had been told to stop could still resume, because a wakeup that had already fired was sitting in a queue the cancel path couldn't reach. Fixing the queue properly changes behaviour for people who chat while a loop runs.
So instead of guessing and sending a large PR, I wrote up what I'd traced, offered three scoped options, and asked which semantics they wanted. A five-paragraph comment costs the maintainer two minutes. A 300-line PR in the wrong direction costs them an hour and a polite rejection.
Before anything is pushed I go through it as a reviewer would:
That last one matters more than it sounds. Two of my Besu PRs this week fix part of an issue and say so. Changing the rest would have broken existing API clients, and that's the maintainers' call to make.
AI makes the slow parts fast: searching big codebases, reading unfamiliar modules, drafting tests and first versions of a change, running checks, keeping track of a dozen open PRs. It's also good at finding the issues worth doing. Fresh bugs in popular repos get claimed within hours, so speed of triage matters.
What it doesn't do is decide. Which issue is worth my time, whether a fix belongs in the code or the docs, when to stop and ask, what not to change: that's still engineering, and it's still my name on the commit. Where a project asks contributors to disclose AI use, I disclose it.
I'm focusing on a few projects where I can become a regular contributor rather than a one-off: Qwen Code on the AI-tooling side, Besu on Ethereum infrastructure, and one more AI infrastructure project. Reviews, bug triage and docs count too. They're some of the most useful work you can give a maintainer.
If you maintain a project and have issues that need hands, I'd like to hear about them.
John Alexander Kamau, Senior AI & Full-Stack Engineer. github.com/Xander-AJ