--- title: 'In the News: August 29, 2026' description: 'A read of 120 open source AI policies finds 37 outright bans, and a rule no agent can satisfy: only a human can sign the Developer Certificate of Origin.' canonical_url: 'https://darkfactory.dev/news/2026-08-29-evening' markdown_url: 'https://darkfactory.dev/news/2026-08-29-evening.md' collection: news date_published: '2026-08-29T19:15:00-04:00' date_modified: '2026-08-29T19:15:00-04:00' --- # In the News: August 29, 2026 No agent can sign the Developer Certificate of Origin. If your factory sends patches upstream, that single rule sets where the human has to stand, and a read of 120 written open source AI policies puts numbers behind it. Claude Code also shipped a hook that lets you block a model switch, and Warp published the shape of a feedback loop that rewrites its own agent's instructions. ## 1. Someone read 120 open source AI policies. 37 ban AI-assisted contributions outright **[I Read the AI Policies of 120 Open Source Projects. Here Is What They Actually Say.](https://medium.com/@yadavrakshit60/i-read-the-ai-policies-of-120-open-source-projects-here-is-what-they-actually-say-9a5ea6897893)** · Rakshit Yadav · Medium, August 22, 2026 Yadav counted every project with a written, published policy, working from the public catalogue at [melissawm/open-source-ai-contribution-policies](https://github.com/melissawm/open-source-ai-contribution-policies), and read them in August 2026. The split: 72 allow AI assistance with conditions, 37 ban it outright, 11 have live arguments and no settled policy. The permissive camp includes Python, NumPy, Django, Kubernetes, the Linux kernel, curl and PyTorch. The banning camp includes Zig, QEMU, GIMP, Gentoo, Servo, Alacritty, SDL, OpenJDK, Asahi Linux and Clojure. The bans are mostly about legal provenance, not taste. QEMU's [code provenance policy](https://www.qemu.org/docs/master/devel/code-provenance.html) states it plainly: "Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content." The reasoning Yadav reports is that the copyright status of generated output is unsettled, training data may include incompatibly licensed code, and a contributor therefore cannot honestly certify the DCO. The [kernel documentation](https://docs.kernel.org/process/coding-assistants.html) makes the same point as a hard rule: AI agents must not add `Signed-off-by` tags, because only humans can legally certify the DCO. Permission comes with a format, and the format is per project. Kubernetes wants `Assisted-by:` and specifically does not want `Co-developed-by:`. The kernel wants the model version, as `Assisted-by: AGENT_NAME:MODEL_VERSION`. Several projects reject naming the tool in `Co-authored-by:` at all. The per-project rules get more specific from there. LLVM and qutip forbid AI on "good first issue" tickets, because those exist as learning opportunities. Homebrew allows one AI-assisted pull request open at a time. NetBSD requires core team approval before generated code enters the tree. Django asks contributors not to point automated AI reviews at other people's pull requests. curl's line is the sharpest of them: "A basic rule of thumb is that if someone can spot that the contribution was made with the help of AI, you have more work to do." Two limits on this count. Yadav is a writer working from a public catalogue rather than a maintainer reporting his own project, though the catalogue is public and a skeptical reader can recount it. And the figures move: he places GCC among the projects still deciding, while [Otto Kekäläinen's essay](https://optimizedbyotto.com/post/why-open-source-projects-ban-ai/) six days later lists GCC among those rejecting all AI-assisted contributions. Yadav's own advice is to check the catalogue on the day you submit rather than trust any blog post, including his. **Why it matters:** The DCO rule is a hard constraint that does not change with model capability. A pipeline that generates a patch, opens the pull request and signs it off has no compliant form in the permissive majority, let alone the 37. Somebody has to read the patch and put their name on it, which means the last step of an upstream contribution loop cannot be unattended by policy, not merely by preference. Trailer formats add another cost: "disclose" is not one behavior, it is a per-project string, and getting it wrong is how a good patch gets closed. ## 2. Claude Code adds hooks that can block a model switch **[Claude Code changelog, version 2.1.251](https://code.claude.com/docs/en/changelog)** · Anthropic · August 28, 2026 Version 2.1.251 adds `PreModelSwitch` and `PostModelSwitch` hook events, which can block, confirm, or annotate a model switch. `SessionStart` resume hooks now receive session staleness and the estimated re-cache cost. The same release closes several holes in the permission boundary itself. File tools were following a symlink swapped inside the working directory after the permission check had run, which could read or write outside the approved location. Grep and Glob were not applying `Read(...)` deny rules to files reached through a symlinked search path. The Workflow tool could read a `scriptPath` outside what the session may read before the permission check ran, and Bash permission checks were auto-approving commands that assign an arithmetic expression to an integer shell variable. **Why it matters:** On August 26, Sebastien Guillemot, CTO of the Midnight Foundation, [posted an account](https://x.com/SebastienGllmt/status/2092634841863123047) of a safety classifier downgrading his coding agent from Opus 5 to Opus 4.8 mid-run, after which the downgraded model wrote the delete script that removed his home directory. Guillemot reported that the switch happened without warning. Claude Code users can now block one. The symlink fixes also affect upgrade decisions: if you run agents unattended and treat file-tool deny rules as the containment boundary, this release is telling you that boundary was passable before it. ## 3. Warp publishes the shape of a feedback-to-skill loop, without measuring it **[How Warp builds self-improving agents on Claude](https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude)** · Michael Segner, Anthropic · Claude blog, August 26, 2026 Warp's internal code review agent was producing comments engineers found unhelpful. Rewriting the prompt by hand worked but did not scale, and improving context files helped without fixing it. The architecture they landed on has two skills with a human between them. An inner skill holds the domain knowledge and does the work. An outer improver skill runs on a schedule, not per task: it pulls accumulated human feedback, compares what the agent suggested against how humans responded, and proposes one small edit to the inner skill. Because skills are plain files, that edit arrives as a pull request a human reviews, approves and merges. The worked example is their issue triage agent, published at [warpdotdev/warp-agents-demo-github-issue-triage](https://github.com/warpdotdev/warp-agents-demo-github-issue-triage). The triage agent missed a "ready to spec" label; a maintainer left feedback on the issue saying both what he expected and why; the improver pulled recent issues carrying feedback via a bundled Python script, summarized them to JSON, and opened a pull request teaching the inner skill that rule. Founder Zach Lloyd's guidance for writing these: "Construct the skill as though you're instructing a smart person, not like you're programming a computer," and on feedback capture, "Low friction is what keeps signal flowing." The piece reports no measurement. Warp's first-party figures are about the company, not the loop: 800K monthly developers, 10M Claude Code sessions run inside Warp to date, more than 400K per week. There is no before and after on review quality, so the architecture is documented and the improvement is asserted. **Why it matters:** Warp says the improver skill is largely the same across agents once you strip out the domain knowledge. The human gate is equally important: the loop edits a file and files a pull request, so a person approves every change to the agent's own instructions. Warp's guidance assumes some feedback will be wrong: "Assume it will be." It also says to build the harness first, then let the agent tune against it. Skip either and you have built a mechanism for writing one reviewer's preference into a permanent rule for everyone. --- ## Also this cycle - **[The growing divide between AI hype and software engineering reality](https://optimizedbyotto.com/post/why-open-source-projects-ban-ai/)** · Otto Kekäläinen, Debian developer · August 28, 2026 · The essay that carried the 120-project count to a wide audience. Its argument is that the conflict in open source is information asymmetry rather than hostility to tools: contributors who cannot judge the output flood maintainers who can, and the traditional ratio of high contributor effort to low maintainer effort inverts. It quotes Greg Kroah-Hartman on the kernel mailing list that "even with the best of the current and next generation tools, at least 1/3 of the results they generate are flat out wrong or harmful."