New user- Question about AI-discovered issues

Off-Topic
1

Hi guys, new Haiku user here, but having a lot of fun so far. I’ve gotten Haiku installed on my 2010 MacBook Pro, and am currently using Claude Code to get iPhone hotspot tethering on it, due to the lack of WiFi drivers. While in the course of doing this I’ve discovered an bug in Haiku’s usb_raw kernel driver that has been the source of some issues for my project.

I understand many in the community take a dim view of AI, and I respect people’s opinion on such. I don’t want to join here and slop it up immediately. Given that, what’s the best way to get this upstreamed/to developers? CC is making a patch for my machine and has written up a bug report, but again, don’t want to just blindly commit AI-generated code, or send a wall of AI text on the forum. I’m not much of a software engineer besides a tiny bit of hobby ASM, or I’d love to do it myself haha

1 Like
2

Hi there!

Yes, AI generated code is not accepted; You can however report a bug fine even if you discovered it with automated tools (or llms), as long as you understand the bug yourself and can put it in your own words :slight_smile:

You can also submit a patch yourself if you wrote it yourself

5 Likes
3

LLM-generated or assisted patches are currently not accepted by the Haiku developers. To be precise here is what the policies document states:

The Haiku project cannot accept contributions (e.g. code, documentation, translations, etc.) which are under ambiguous or incompatible licenses. (This includes most content produced with the use of LLMs.)

Your best option is to ask CC to summarize the changes it did in order to do a clean room implementation by a human, and then find someone who would be willing to implement it.

4

Thanks, I’ve gotten a surface level understanding of the bug so far, I’ll do a deep dive and report back with a human-written bug report :saluting_face:

9 Likes
5

I was thinking of creating my own post on how AI findings can make their way into Haiku, as I have managed with some help to get about 10% of my bug findings and a few I borrowed from AI projects by atomzero and rations.

The first bug I was able to get fixed came about it in comments I made on Trac #6300 for a 16 year old kernel bug. It is a good example of what not to do, and offers some pointers on how to handle the Trac route. First, unaware of the Trac rules and being in a rush to fix a kernel issue that I could not package myself, I copied an AI generated description as a comment to the bug. They were quick to ridicule me for the faux pas, and I admit I didn’t understand the issue 100% to be able to put it into my own words. But after returning the next morning with a brief human written explanation of the issue and fix, it was merged within 24 hours and made it into Beta 6. It was also suggested to open your own ticket rather than as a comment to an open ticket, as we might not be able to identify the bug appropriately, apparently, which could further waste their time. Instead, maybe just include bugs that you believe it may apply to in your report.

I can abide by not posting AI generated content in these forums or in the bug tracker. But it also makes submitting bug requests that much harder for the people finding them. A bug here or there is no big deal, but when you are sitting on dozens of fixed bugs, as I am, it is quite a burden. The disdain for AI from the top of the Haiku dev team obvious. Where an experienced developer, like @waddlespash, could read my AI generated upstream notes in 20 minutes, review the code and have his own bug fixes written in a few hours, with my severe ADHD it would literally take me well over 100 hours to fully understand each issue and write explanations for them. Should I be doing it any ways? Probably. But I have a lot of motivation to find and fix bugs, and very little motivation for doing paper work.

Luckily one Haiku developer, @phoudoin, did take interest in my Media-OS project early on and has helped me write bug fixes from several of my UPSTREAM.md item notes.

CR Subject Row Landed commit Merged
11697 usb bus manager: set_pipe_policy() used IsSet() to deref pipe object 18 78624f18e8 2026-09-06
11698 usb: xhci leaked USB IDs when deviceObject failed to init 24 3ccd9a7ef7 2026-09-06
11699 usb: control-pipe request timeout 2s → 5s 34 cd5be02529 2026-09-07
11751 deskbar: don’t loop forever if replicant is larger than the row 32 fcdee3a787 2026-09-15
11772 ntfs: fix vnode leak on mkdir 33 e9ade57f61 2026-09-17
11829 usb_midi: let a signal interrupt reading on an idle device none 565edc14fe 2026-09-22
11830 usb_midi: release write semaphore on failure in usb_midi_write() none 2db348d3f1 2026-09-22
11844 usb_midi: stop queueing IN transfers after too many continuous read errors 12 1adb39bc8b 2026-09-24

@phoudoin has encouraged me to make my own Gerrit CRs. How you say? From AI generated code? Sort of, but not quite. First of all, a lot of bug fixes come down to just a few lines of code. Even when the code is fixed by a human from notes, once you remove notes and whitespace, it is often byte identical to what AI generated. As long as I understand the bug and the code behind the change, there is no reason I should not be able to submit my own CRs. So I did. My UPSTREAM row 36 became CR 11790 usb_audio: GPFs when you attach a different device from the same vendor, merged 2026-09-18 (e4fed155b7). I gave Claude strict rules not to edit anything in my local Gerrit repo. I made the code change by hand, literally 2 characters, as it was the use of a wrong logical operator. I wrote the commit message myself. It was also quickly merged.
So, it can be done. This was a very small change. I will likely submit a few more smaller ones. And @phoudoin will likely help me submit some of the mid-size ones. But I am afraid that some of the larger fixes may never see the light of day within Haiku proper, unless the rules relax a little bit. At the end of the day, you have a human signing off on what they produce, AI help or not. If they produce poorly, do not thoroughly test their product, or do not have the capacity to maintain their own code, that should become clear pretty quickly, whether they use AI or not. The hurdles for participation seem a little higher than they need to be when submitting information for fixed bugs.

3 Likes
6

It seems to me that the rules are effective given our relative small developer workforce. Explaining the reason for a change, how it has been tested, whether it could affect other hardware is a difficult task, but nothing inaccessible. It’s like for the Haiku code style guide, it’s mostly useful for humans reading the code in the end.

7 Likes
7

It’s a bit a ckicken and egg situation:

  1. AI clearly boost discovering issues in open source code
  2. this increase the rate of bug fix CRs being submitted by new contributors
  3. this increase the workload on existing pool of reviewers
  4. those still needs to understand why the change make sense
  5. which requires submitter being able to both explain the change rational and to adjust it if necessary
  6. which takes time and effort from both sides, reviewer(s) like submitter
  7. it’s only that way, shared effort, that workflow of next CRs from same submitter would be more fluid (people have to learn working together)
  8. and eventually that submitter to becomes part of the reviewers pool too one day, contributing to reduce point 3 main bottleneck in that whole process.

I think it’s in best interest of everyone that both sides make effort here:

  • submitters to accept that they needs to put effort to submit bug fixes they actually understand and can explain and defend themselves, in their own words.
  • reviewers to accept that AI being used or not by a submitter in bug discovery doesn’t matter, what’s matter is that a least two humans will understood it and will agree on the what, the why and the how to fix it correctly: the submitter and the reviewer.

I’m not talking on new feature submission here, only bug fixes.
And, no, “it’s not a bug it’s a feature” joke won’t play great here :wink:

8 Likes
8

I’m not a code reviewer on Haiku, but for what it’s worth I agree this is the correct approach. The provenance of the code, and the degree of understanding by the submitter and reviewer are what matters.