But "freshly generated by a hallucinating language model" mischaracterizes what actually happened here. The code was tested on real hardware. NVIDIA passthrough on bhyve works — repeatedly, across reboots, with actual guest OS execution. That is empirical validation, not a claim about the model's infallibility. Plenty of upstream contributions have never seen hardware before review.
Do all LLMs hallucinate? Absolutely. Was the code generated by an LLM? Yes, it was. Does it work? Maybe. How well? You can't tell unless you can actually read it and understand what's going on, and until then it's 'freshly generated' in a sense that no one has analyzed it yet. I don't see any mischaracterization here.
The framing of "a real qualified human behind it" treats human authorship as a proxy for code quality. Sometimes it correlates. Sometimes it doesn't. The code exists, it can be read, and it ran. That's what review is for — evaluating the artifact, not the credentials of whoever produced it.
No, I was talking about the difference. What I wanted to say is that, from a maintainer's point of view, those things cannot be compared. I'd be far more likely to look at real work because it tells me that:
- some effort was already put into the code;
- the lower the level, the greater the chance that the person is actually qualified;
- I can talk directly to them and without worrying about the context window;
- we can learn together throughout the process and build trust.
Neither is true for a 100% generated "artifact". I'd personally look at such code only if I was ready to start almost from scratch.
On the IP/consensus point: agreed, Anthropic's statements are irrelevant to what the community decides. That's exactly why I said the community needs to answer this question. I'm raising it explicitly because I think pretending it doesn't exist is worse than naming it.
What question? I thought you were pretty clear:
I can use the code written by Claude freely. Anthropic explicitly transfers output rights to the user in its Terms of Use. The code produced during my sessions belongs to me.
And I was referring to the public in a broader sense, not the FreeBSD community.
The LLM is not a contractor who has gone silent. Anyone — including reviewers — can open a conversation, paste the code, and ask exactly why a specific implementation choice was made, what edge cases were considered, what happens under condition X. That capability doesn't disappear after submission. In that sense, the code comes with a permanently available interlocutor, which is more than you get with most human contributors who have moved on to other projects.
This whole paragraph is marketing nonsense. You can only say that to someone who knows nothing about how LLMs work.
I can answer for what this code is supposed to do: the architectural goals, the design decisions, the reasons why certain components were chosen over others. Those were my decisions.
I cannot answer for how the C achieves it at the implementation level. I am not a programmer.
I don't think that can work, it should be the other way around. In software engineering, you start as a mere coder, not as an architect. How and why are you trying to contribute the code you can't even read? The motivation behind this is the reason why I've joined this conversation.
What I can tell you is that the code ran on real hardware and produced the expected result. That doesn't prove the implementation is correct — it proves it works in the conditions I tested. Those are different things, and a reviewer with C kernel expertise might find problems I would never catch on my own.
Sure, it's all understandable. In that case, I'd try to find someone who is at least (a) interested in the project and (b) willing to work at the code level, so you don't have to feel your way through your journey alone.
I am a domain-level contributor who validated a result, not a C programmer who can defend every line. If that disqualifies the contribution entirely, I accept that judgment. But if the question is whether the code deserves to be read on its own merits by someone qualified to evaluate it — I think it does.
Maybe it does, maybe not. Either way, I don't think it's the kind of contribution FreeBSD needs, and that's not just my opinion:
Do NOT submit a Pull Request for:
[...]
Works in progress.
Changes that require design discussion, or are likely to be controversial. (Start a mailing list thread to discuss the change first.)
[...]
Changes generated by AI tools without substantial human review and validation.
The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src
github.com
Clearly, such code can be submitted, but someone has to validate it first.
On plagiarism: that concern exists independently of AI. The code can be scanned with the same tools used for any other contribution. It's a real concern worth addressing, but it's not unique to this case.
On the contrary, I think it's rather unique, but much ink has already been spilled over this topic elsewhere.
The reviewer burden is real. The question is whether that burden is categorically different from other contributions where the author is unavailable, underqualified, or working at the edge of their own understanding — which is not rare in open source.
This is a self-incriminating statement, don't you see? Those are poor contributions by definition (except for the last one, of course, there is nothing wrong with that). If you want to make another one - sure, go for it, nobody would blame you. I just don't think this is something to be proud of, especially when you can make a good one simply by getting the right people involved beforehand.
P. S. Even if those are really your thoughts, the more symbols I typed the harder it became for me to justify the time I had spent replying to a generated post. Sorry, but I can't be sure how much of it is genuine, so I'd rather not do this again, it just doesn't feel right.
summerofcode.withgoogle.com
legal, BSD is permissive
illegal, GPL is copyleft