Hey Tim,

Another developer here, I mostly lurk on the mailing list. I'm certainly curious if WineHQ has any formal precedent on this but I'm going to offer my two cents here.

Firstly, WineHQ has placed strong emphasis on following clean-room guidelines https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines, meaning that code pulled into Wine must be legally trustworthy regarding its separation. Given the immense amount of training data present in Claude Code, ChatGPT, and really all usable LLMs on the market, I would find it legally risky to trust how that code was sourced and generated. There's a quote on that clean room page that seems apt here, 

> "For what it's worth, the policy I've personally been using has been to simply avoid unnecessary risk.",  Henri Verbeet.

Additionally this question has been asked previously, with no answer: https://list.winehq.org/hyperkitty/list/wine-devel@list.winehq.org/message/GG7SBBPDE6K2JHGPTFZXRQ5T5Q5KOWAI/

Secondly, from a noise and effectiveness perspective, AI generated code carries risks. I personally appreciate your honesty about not fully understanding regarding the how's and the why's of what your code is doing, I wish more developers were honest about that in general. However, what you're functionally asking is for someone to spend their time working on a patch that the core contributor cannot reliably maintain, refactor, or truly own the underlying logic.

Open source is largely built on the establishment of trust and a lot of commitment of time from those who frankly don't have much of it; it's often rather thankless work and every line of code has to be owned by someone.

I think it's awesome whenenver anyone wants to work in a territory they don't understand, learning should always be celebrated (we're in an industry where so many derive joy out of belittling others and making them feel stupid or inferior, it's really frustrating!). but at the same time, I would only contribute things I understood, could explain, and am providing in good-faith (which in regards to good-faith I believe you have, hence these many words), we owe that much to the communities from which we gain so much and to which we want to give back.

All that being said, perhaps the Wine team could correct me, or maybe this will just wind up being more noise on an email thread I was pretty sure I unsubscribed from multiple times, I dunno.

But I figured I'd air my thoughts,

May. 

On Wed, Apr 8, 2026 at 9:18 PM tim--- via Wine-Devel <wine-devel@list.winehq.org> wrote:
Oh man, yeah it is. :) I'd likely never have tried to fix a FIXME in a beast of a project like Wine without these newer models/CLI-based tools. Totally wild. And Claude Code/Codex have been working fantastic in SRE/Ops contexts as well.

The actual fixing patches don't seem to have many LOC changing. It's mostly the tests I worked through defining/generating that theoretically prove it works which take up the most of that repo.

The patches for the flocking fixes are at:

https://github.com/livingstaccato/space-wine/blob/main/patches/comctl32-fix-edit-BuildLineDefs.patch
https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-fix-UnlockFileEx.patch
https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-fix-UnlockFileEx.patch
https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-NtLockFile-FIXMEs.patch
https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-edit-BuildLineDefs.patch
https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-fix-lock-fd-leak.patch
https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OEM_CHARSET.patch

And I also had it fix a font fixme:
https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OEM_CHARSET.patch

Then had it go overboard making tests:
https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-tests-expand-lockfile.patch
https://github.com/livingstaccato/space-wine/tree/main/tests

Hopefully the actual patches are high enough quality that it's helpful. Or maybe the testing tools would be a handy addition to the Wine toolchain.

--Tim