AI-gut gescriptete Fixes in Open-Source-Projekten
AI hilft dabei, Pull Requests in Open-Source-Projekten zu schreiben und einzubinden
Im vergangenen Monat wurden sechs meiner Pull Requests in Projekte anderer Personen übernommen: eine Android-Tastatur, eine Python-OAuth-Bibliothek und ein Reverse-Engineering-Toolkit. Sieben weitere befinden sich in Review in Hyperledger Besu, Qwen Code, ParadeDB und Ratatui. Rust, Java, TypeScript, Kotlin und Python.
Ich nutze KI intensiv, um das zu erreichen. Ich weiß auch, wie Maintainer über beiläufig eingereichte KI-Pull-Requests denken, denn ich lese ihre Issue-Diskussionen. Hier ist der Workflow, den ich dafür entwickelt habe: schnell dank KI, und dennoch etwas, das ein Maintainer gern reviewt.
Jedes Projekt, zu dem ich beitrage, bekommt dieselbe erste Runde: CONTRIBUTING.md, eventuell vorhandene AGENTS.md, die PR-Vorlage und die KI-Richtlinien, falls es welche gibt.
Die Richtlinien unterscheiden sich stark. Ratatui begrüßt KI-unterstützte PRs und bittet darum, dies zu erwähnen. pandas möchte, dass der Mensch den PR eröffnet und die Kommunikation führt und angibt, welche Tools verwendet wurden. Manche Projekte verbieten KI-generierte Beiträge komplett, und zu denen trage ich nichts bei. Andere verlangen eine signierte CLA oder eine DCO-Signatur auf jedem Commit.
Ich lege pro Repository eine kleine Richtliniendatei an, damit ich das nie wieder herausfinden muss und nie einen PR sende, den das Projekt ausdrücklich nicht haben möchte.
Ein Fix ist erst echt, wenn ein Test ohne ihn fehlschlägt.
In Ratatui begannen japanische Halbbreiten-Lautungszeichen (ﾞ ﾟ), zwei Zellen statt einer zu belegen. An Ratatui selbst hatte sich nichts geändert. Das Release 0.2.3 der Crate unicode-width hatte diese Zeichen von Breite 0 auf Breite 1 korrigiert, und Ratatui hatte einen Workaround, der dafür +1 addierte. Beide "Fixes" griffen nun gleichzeitig.
Ich ließ die bestehende Testsuite mit beiden Abhängigkeitsversionen laufen: Auf 0.2.2 bestand alles, auf 0.2.3 schlugen acht Tests fehl. Das zeigte mir, dass der Bug echt war, wo er steckte und welche Tests den Fix beweisen würden.
.filter (| c | { matches! ( * c, '\u{FF9E}' | '\u{FF9F}' ) && c.width () == Some ( 0 ) // only compensate when unicode-width doesn't }) Enter fullscreen mode Exit fullscreen mode Eine einzige Bedingung. Sie ist auf beiden Versionen der Abhängigkeit korrekt, also muss niemand etwas pinnen. Ich habe die Mindestversion der Abhängigkeit nicht angehoben, den Breiten-Code nicht refaktoriert und nichts in der Nähe "aufgeräumt". Maintainer reviewen kostenlos, und jede zusätzliche Zeile wäre ein Kostenfaktor, den ich ihnen aufbürden würde.
Nicht jeder Bug hat eine einzige richtige Antwort. In Qwen Code konnte ein /loop, dem mitgeteilt worden war, anzuhalten, dennoch weiterlaufen, weil ein bereits ausgelöstes Wakeup in einer Queue lag, die der Abbruchpfad nicht erreichen konnte. Die Queue richtig zu fixieren, würde das Verhalten für Personen ändern, die chatten, während ein Loop läuft.
Also riet ich nicht ins Blaue hinein und schickte keinen großen PR, sondern hielt schriftlich fest, was ich nachverfolgt hatte, bot drei abgegrenzte Optionen an und fragte, welche Semantik gewünscht war. Ein Kommentar mit fünf Absätzen kostet den Maintainer zwei Minuten. Ein 300-Zeilen-PR in die falsche Richtung kostet ihn eine Stunde und eine höfliche Ablehnung.
Bevor irgendetwas gepusht wird, gehe ich es so durch, wie es ein Reviewer tun würde:
Der letzte Punkt ist wichtiger, als er klingt. Zwei meiner Besu-PRs in dieser Woche beheben einen Teil eines Issues und sagen das auch. Den Rest zu ändern hätte bestehende API-Clients beschädigt, und das ist eine Entscheidung der Maintainer.
Die KI macht die langsamen Teile schnell: große Codebasen durchsuchen, unbekannte Module lesen, Tests und erste Versionen einer Änderung entwerfen, Checks ausführen, ein Dutzend offener PRs im Blick behalten. Sie ist auch gut darin, lohnende Issues zu finden. Frische Bugs in populären Repositories werden innerhalb von Stunden beansprucht, daher zählt Tempo beim Triage.
Was sie nicht tut, ist entscheiden. Welches Issue meine Zeit wert ist, ob ein Fix in den Code oder in die Dokumentation gehört, wann ich innehalten und nachfragen sollte, was ich nicht ändern darf: Das ist weiterhin Engineering, und weiterhin steht mein Name auf dem Commit. Wo ein Projekt die Offenlegung der KI-Nutzung verlangt, lege ich sie offen.
Ich konzentriere mich auf einige wenige Projekte, in denen ich statt eines einmaligen Beitrags eine regelmäßige Mitwirkende oder ein regelmäßiger Mitwirkender werden kann: Qwen Code im Bereich KI-Tooling, Besu bei der Ethereum-Infrastruktur und ein weiteres KI-Infrastrukturprojekt. Auch Reviews, Bug-Triage und Dokumentation zählen. Sie gehören zu den nützlichsten Arbeiten, die man einem Maintainer abnehmen kann.
Wenn Sie ein Projekt betreuen und Issues haben, die Hände brauchen, würde ich gern davon hören.
John Alexander Kamau, Senior AI & Full-Stack Engineer. github.com/Xander-AJ
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
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 }) Enter fullscreen mode Exit fullscreen mode 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