theo de raadt eschews vibe coding for copyright reasons https://lwn.net/SubscriberLink/1064541/1a399d572a046fb9/
Vibe-coded ext4 for OpenBSD

A number of projects have been struggling with the question of which submissions created by lar [...]

LWN.net
@davidgerard Okay so if I understood correctly, that means NetBSD and OpenBSD remain slop-free while FreeBSD and Linux won't. Didn't have "Run BSD" on my bucket list, but here we go I guess 🙃
@lu_leipzig @davidgerard Linux, I think I've heard enough about, but FreeBSD? Is the guy who submitted the slop a contributor or something? Has something been moving there? Or is this simply an inference from current discourse over there?
@HaTetsu @davidgerard That was based on FreeBSD's GitHub repo showing the infamous "Claude was here" banner:
@lu_leipzig @HaTetsu @davidgerard that banner appears even if claude contributed to one PR that was accidentally accepted and then promptly reverted, as happened with Godot for example. Manual audit is still necessary, unfortunately.
@lu_leipzig @HaTetsu @davidgerard In this case, claude does not (yet?) have contributions on the main branch.

@ratsnakegames @HaTetsu @davidgerard Found this commit on main from a couple of weeks back: https://github.com/freebsd/freebsd-src/commit/6495dafd58b94a44fc9bc966ef47d6bc6916f5b9

It's only a trivial change and it seems to originally come from this PR at openzfs: https://github.com/openzfs/zfs/pull/18255

So yes, technically there's a Claude commit in FreeBSD's main branch, but this particular one is probably too trivial to directly affect FreeBSD's quality or legal situation. It would have been great if they still rejected it as a matter of principle though.

range_tree: use zfs_panic_recover() for partial-overlap remove · freebsd/freebsd-src@6495daf

zfs_range_tree_remove_impl() used a bare panic() when a segment to be removed was not completely overlapped by an existing tree entry. Every other consistency check in range_tree.c uses zfs_panic_...

GitHub

@lu_leipzig @ratsnakegames @HaTetsu @davidgerard And here's a similar situation with OpenBSD

https://github.com/openbsd/src/commit/9c2b8e445a0bdfafdd6148b1760f00aa5429627b

It's more involved, but also from a 3rd party project.

Add support for applications to use synchronized output mode (DECSET · openbsd/src@9c2b8e4

2026) to prevent screen tearing during rapid updates. When an application sends SM ?2026, tmux buffers output until RM ?2026 is received or a 1-second timeout expires. From Chris Lloyd with the as...

GitHub