The FreeBSD project's status team has published FreeBSD's third status report of 2026, showing plenty of ambitious work underway and a community still undecided on how to treat code from AI coding assistants. 

The FreeBSD Status Report Third Quarter 2026 is a substantial document, with 51 entries from five teams covering 16 projects, plus six other sections with more detailed reports.

There are updates on the progress of the Sylve project, which is an attempt to bring a smooth polished GUI for managing FreeBSD virtualization hosts – something akin to Proxmox for FreeBSD. We mentioned this when we looked at the new Daemonarchy project last month. Another covers the new AppJail effort – a containerized app distribution system for FreeBSD, including for GUI apps, which aims for something broadly comparable to Snap, Flatpak and AppImage on Linux.

In other words, interesting and quite radical stuff is happening in the FreeBSD space.

What this particular LLM-skeptical vulture was most interested to see, though, was an update on the internal discussion about how to handle code generated by AI coding assistants in the project. We first reported on this vexed subject back in September 2025 and no final answer has yet been published.

NetBSD banned AI-generated code in 2024 and although the bot-boosters say this will doom it to irrelevance, as we reported last month, the project is thriving. Also back in October, we looked at OpenBSD 8.0, whose launch materials are full of mockery for AI users.

Under the FreeBSD Core Team section, there is a subsection headed "FreeBSD Developer AI survey." The survey was created by Baptiste Daroussin, and received 140 responses. Although the percentages show that there is some resistance to AI, there are hints here as to why it’s taking so long. Some project committers are against it, yet many more are proponents. Since there are only seven bullet points, we thought we would quote them in full:

• Policy: 88 percent want the Project to adopt a policy, either a formal, written policy (49 ) or light guidance and best practices (39 ). Six  said that AI should be explicitly discouraged, and three percent that the existing contribution rules are sufficient.

• that it must be reviewed more strictly than human code, 22  that it should be treated like any other contribution, and 16  that it should be rejected outright.

• Safeguards: mandatory human review (78 ) were requested most often, followed by provenance or licensing documentation (47 ).

• want AI use disclosed, either always (48 ) or when its involvement is significant (36 ). 79 want AI-assisted commits marked in the commit log, and 56 prefer a tag that names the tool.

• Concerns: the main concerns about quality are correctness and subtle bugs (39 ). 75 are somewhat or very concerned about copyright and licensing.

• Principles: accountability, meaning that a human remains responsible (91 ) were selected most often, and preserving code quality was the top-ranked goal for a policy.

• Other uses: 65 would allow AI-generated documentation with human review. 54 would allow AI tools on Project infrastructure, most of them with restrictions, and 29 would not.

Only six percent for explicit discouragement, 16 percent for outright rejection,  and 35 percent against LLM-generated documentation. This plus the usual sort of calls for responsible use and disclosure, concerns about copyright issues, and so on.

is strongly reminded of the Debian developer poll we reported on in August. This had no fewer than four slightly different AI-refusal options out of eight, and despite the Condorcet voting method it uses, the result was giving permission to use bots.

With such relatively weak opposition, we suspect that FreeBSD will go the same way as Debian: tell developers to be careful, but allow bot usage, resulting in LLM-extruded code being committed into the project. ®