I've filed PRs against the dev software toolchain in the past, but the toolchain is pretty complicated, (including tools written in multiple programming languages) and it's always been extremely difficult to wrap my head around it, so I usually didn't bother.

In 2026, it's been way, way easier for me to fix bugs in that toolchain using LLMs. LLMs have no problem switching between programming languages, adding debug tracing to trace the flow of a bug through each layer, generating automated tests to reproduce the bug, and then fixing the bug correctly.

Of course, the problem then is: how would I convince the team to merge a PR containing code that was entirely LLM generated, when that's explicitly against their policy?

The answer I've picked: I lie and say I wrote the code.

But, to sell the lie, I first ask the LLM to explain the bug fix in detail, then I review the generated code very carefully (making sure it's written exactly the way I would have written it, especially the comments), and then I write all commit messages and the PR description entirely by hand.

I've found this to be an tremendously educational approach. I've learned a lot about the programming languages in the toolchain, and about the inner workings of the open-source game-dev tools. In many cases, my deeper understanding has allowed me to truly review the LLM's code, finding problems in the generated code, which the LLM then fixes.

I'm certain that if I'd just clicked a button and had the LLM generate the commit message + PR description, I never would have found those issues. And I obviously would never have learned as much.

I can't write anything about this under my own name, but I now genuinely recommend using LLMs to file open-source PRs, but never using the LLM to generate commit messages or PR descriptions. Pretend as if you wrote the code yourself, even if the open-source project explicitly permits LLM-generated PRs.

If you don't understand the code well enough to write the commit message or the PR description, ask the LLM to generate one for you, but then rewrite it from scratch in your own terms. This is partly so the description doesn't have that smell of AI slop, but also to ensure you understand the code well enough to explain what it does and why this code is the right approach.

Pretending that the code is really my code forces me to learn the code well enough to own it. I'm ashamed of lying about what I've done, but I'm proud of what I've learned and accomplished by doing so.