October brought a run of decisions in free-software projects that all come back to the same thing: more and more code, review and bug reports are being produced with language models. Sometimes that means serious bugs get caught before they reach users. Other times it means maintainers spend hours reading patches that nobody fully understands. Here are five cases, told from what the projects themselves wrote in commits, mailing lists and release notes.
Linux already had rules, and in October it simplified them
Since January the kernel has documented how to handle tool-generated content in Documentation/process/generated-content.rst, alongside a second document, coding-assistants.rst, aimed at AI assistants. The core idea is that responsibility can’t be handed off: “You are expected to understand and to be able to defend everything you submit”, and if you can’t, maintainers “are entitled to reject your series without detailed review.” It asks for transparency about which tools were used and with what prompts, and it’s explicit that an AI agent must not add a Signed-off-by line, because only a human can certify the Developer Certificate of Origin. Anyone using an assistant to hunt for bugs is expected to try to reproduce them, write and test the fix, and say plainly what couldn’t be verified, because “maintainers currently waste too much time analyzing unverified reports and untested fixes.”
On 14 October a change from Sasha Levin landed in the documentation tree that drops the Assisted-by tag, the one that asked people to mark LLM-assisted patches. The commit lays out why: only around 10% of the 18,533 non-merge commits in Linux 7.3 (up to rc7) carried it, while actual use is far more widespread, so its absence said nothing. At the 2026 Maintainers Summit there was “a strong, though not unanimous, consensus” to remove it. Maintainers still want to know how a patch was made, but that now belongs in the cover letter. The change is already in Linux 7.4-rc1, released on 1 November.
OverlayFS: twenty fixes, many from an AI review
The clearest example of the useful side is OverlayFS, the layered filesystem that containers rely on. On 31 October Linus Torvalds merged the fixes sent by one of its maintainers, Amir Goldstein: 20 commits, and the first line of the summary reads “Fixes for bugs found by Chris Mason’s AI review, several of them reachable by unprivileged users”. They include an information leak, use-after-free and NULL dereference bugs, an RCU path-walk stall with remote layers, and data loss with the nfs_export option.
The same pull also carries fixes from elsewhere: copy-up failing on files with an empty security.capability xattr, which any user could set to block copy-up; a regression in the override_creds mount option dating back to Linux 6.16; and two casefold fixes. All of it is in 7.4-rc1.
A taint flag against junk reports that lasted a month
The kernel’s other October story shows the opposite problem. In September Greg Kroah-Hartman added TAINT_FORCED_BIND, a flag (the letter Y) the kernel sets on itself as soon as someone writes to the sysfs bind and unbind files, which let you attach a device to a driver by hand. According to the commit, fuzzing tools such as syzbot were binding random drivers to any device, producing “loads of unneeded errors and pointless kernel patches” written by unsuspecting new developers. With the flag set, whoever receives a crash report can see it was triggered by forcing that binding.
It went in during the 7.4 merge window and came out again before rc1. VFIO, which is used to pass PCI devices through to virtual machines, depends on exactly those bind/unbind files, so perfectly normal workflows ended up with a tainted kernel. Kroah-Hartman reverted it on 28 October and Danilo Krummrich sent it to Torvalds on the 30th, with the plan to revisit the idea after 7.4. In the revert, Kroah-Hartman notes that syzbot no longer does random binding and hopes nobody else starts again, “but in this madness of LLMs these days, you can’t be sure.”
RADV writes its position down
Over in Mesa, Samuel Pitoiset proposed on 27 October adding an LLM contribution policy to the documentation for RADV, the Vulkan driver for AMD GPUs, and it was merged on 2 November. In the merge request he explained that they were “starting to get slightly more LLM MRs by external contributors” and that it seemed better to state a position “before getting flooded.”
The text is short. LLM-assisted merge requests “require a good understanding of the codebase, and reviewing them has a real cost”; reviewers may close them at their discretion. If you find a bug you can’t fix yourself, file an issue. LLM-written issues are discouraged because “they tend to be verbose and hard to read”, so people are asked to describe the problem in their own words. LLM-generated reproducers, on the other hand, are fine as long as the sender has reviewed them and they actually show the bug.
PostgreSQL 19, later than planned
PostgreSQL usually ships its major release in September. Not this year. On 10 October, Jonathan Katz told pgsql-hackers that the final release of PostgreSQL 19 was moving to 19 November, with a second release candidate on the 12th, because “given the volume of fixes” that had gone into the branches, the release team wanted those included first. He called it “an atypical major release cycle”. RC1 came out on 15 October.
The announcement doesn’t mention AI, but the development list had been arguing about it for weeks. In late August Robert Haas asked a language model to rank the version 19 patches by how many bugs they had needed fixed after feature freeze, which started a discussion about reverting some of them. Melanie Plageman wondered whether the ease with which LLMs let people “pressure test features” means bugs are being found sooner; Amit Kapila saw that as good for long-term stability even if it means more clean-up patches in the short term; Daniel Gustafsson pointed out that the big features in 19 were written and reviewed before these tools were anywhere near as good. Bruce Momjian added another factor: “a huge amount of security/CVE fixes” was pulling many people away from other work. More bugs found, in other words, but someone still has to review and fix them.
FreeRDP 3.33: WebAssembly and a flood of pull requests
FreeRDP 3.33.0, the free implementation of Microsoft’s Remote Desktop Protocol, came out on 2 November. The headline feature is WebAssembly support, so the client can now run inside a browser. There’s also experimental UDP support for direct connections without a gateway, the Windows shadow server is back (experimentally), macOS file clipboard support no longer needs FUSE, and message translation has started. The release fixes 13 security advisories.
The notes say “the influx of pull requests and feedback for bugs/regressions/… was huge”, enough that a patch release with the remaining backlog will follow soon. They don’t say why. GitHub’s search gives a sense of the jump: 255 pull requests were opened in the repository between 12 October and 2 November, against 91 in the first three weeks of August, and this release’s changelog lists 20 new contributors.
What they have in common
None of these projects bans AI. What keeps coming up is that whoever sends a patch has to understand it and stand behind it, and that review time is the scarcest resource. Some projects go further, such as AlpineBSD, which keeps packages containing AI-generated code in a separate repository. On the security side, Canonical has explained how it handles the wave of vulnerabilities found by AI models and how it uses its own tool, Redhound, to hunt logic flaws. Kernel versions and dates are on the Linux page, and what 7.4 brings for RISC-V is in this article.
Sources: Documentation/process/generated-content.rst and coding-assistants.rst; commit “docs: remove Assisted-by references”; merge “ovl-fixes-7.3”; commits TAINT_FORCED_BIND and its revert; RADV policy commit and MR !45668; “Updated PostgreSQL RC / GA dates”, PostgreSQL 19 RC 1 announcement and the “scary patch contest” thread on pgsql-hackers; FreeRDP 3.33.0 release notes.