The Linux networking subsystem is drowning in AI-generated patches — maintainers impose the three-second rule

August 6, 2026, Phoronix, Linux Networking, three-second rule. On August 6, 2026, the maintainer of the Linux WiFi subsystem formalized a new code review doctrine: the three-second rule. If a patch does not pass visual inspection in under three seconds — in other words, if it does not immediately jump out as a legitimate fix — it is rejected without further process. The reason? A flood of AI/LLM-generated patches that has been drowning networking maintainers’ inboxes since early 2026.

This announcement follows the August 4 decision by Greg Kroah-Hartman — Linux’s second-in-command — to systematically reject LLM-generated patches in the staging area, except for genuine security fixes. But the staging area is an onboarding zone for new contributors. The networking subsystem handles production code that powers routers, switches, firewalls, and entire clouds.

A networking subsystem under siege

Phoronix reports that the Linux Networking subsystem continues to be “bombarded” with AI patches. The problem is structural:

• AI coding agents (Devin, Copilot, Codex, Cursor, etc.) generate patches en masse from static analysis tool reports.
• These patches often fix false positives or cosmetic issues (typos, code style) without delivering functional value.
• Each submitted patch requires the maintainer to read, understand context, and decide — a process that takes 5 to 15 minutes per patch for an experienced human.

When an inbox receives 50 AI patches per week, the review time spent on slop (the term maintainers use for AI noise) exceeds the time available for real fixes — the ones that patch memory leaks, packet corruption, or CVEs.

Kalle Valo, maintainer of the ath12k driver (Qualcomm WiFi), was the first to publicly quantify the problem. On the linux-wireless mailing list, he reported that over 60% of patches received over a two-week period in July 2026 were identifiable as AI-generated — and none of them fixed an actual bug.

How to recognize an AI patch in three seconds

The three-second rule is not arbitrary. Networking maintainers have developed rapid recognition heuristics:

• Generic commit message: “Fix potential null pointer dereference” with no explanation of the actual execution path.
• Cosmetic patch without context: typo fix in a comment, variable rename with no functional impact.
• Static analyzer false positive: the patch “fixes” a Coverity or Sparse warning without understanding that the code is correct as-is.
• No human signature: the contributor has never submitted a patch before, the email address is disposable, and the patch arrives without prior discussion on the list.
• Too-clean patch structure: a real developer leaves iteration traces (v2, v3, changelog). An AI patch is often a perfectly formatted one-shot.

Kalle Valo summarized the doctrine: “If I can’t understand what the patch does in three seconds, I reject it. If the contributor is legitimate, they’ll come back with an explanation. The AI never comes back.”

The real cost of slop for network infrastructure

This is not an anecdotal problem. The Linux networking subsystem is the backbone of the Internet. Every line of code that enters it potentially affects millions of servers, BGP routers, load balancers, and cloud infrastructures. An incorrect patch in net/core or net/ipv4 can cause a global network outage — the memory of the 2019 TCP SACK regression is still fresh.

The risk is not that the AI produces a malicious patch — no one is accusing coding agents of sabotage. The risk is that it produces a plausible but incorrect patch, which passes a quick review on a Friday evening, and introduces silent corruption discovered six months later during a production incident.

David Miller, the long-time networking subsystem maintainer, has always enforced a strict review policy. But the additional workload imposed by AI patches threatens to slow down the integration of real fixes — including urgent security patches. This is the paradox: AI, designed to accelerate development, is actually slowing down the maintenance of critical code.

The community response: filtering and automation

Faced with this situation, several initiatives are emerging to protect the contribution process:

• Reputation-based filtering: maintainers are starting to ignore patches from email addresses with no contribution history. This discriminates against legitimate new contributors but is pragmatic.
• Pre-review bot: a bot that detects typical LLM patch signatures (commit message patterns, similarity with known patches) and marks them as NEEDS-HUMAN-REVIEW.
• Domain whitelisting: some mailing lists are considering only accepting patches from verified company or institution domains.
• patcheck-ai: a community-developed script to automatically detect suspicious patches before they reach maintainers.

None of these solutions is ideal. All impose additional friction on real contributors, which runs counter to the openness ethos of the Linux kernel. But the alternative — letting the networking subsystem get overwhelmed — is worse.

Why networking is more exposed than other subsystems

The networking subsystem is particularly vulnerable to AI slop for three structural reasons:

1. High visibility: static analysis tools (Coverity, Sparse, Coccinelle) scan networking code as a priority because it has a large attack surface. Every alert generates a potential AI patch.
2. Moderate complexity: unlike the scheduler or memory management, networking code is often self-contained (a driver, a protocol). AI can produce syntactically correct patches without understanding semantics.
3. Undersized maintainer pool: the maintainer-to-contributor ratio is lower in the networking subsystem than in other kernel areas. Each maintainer handles multiple drivers and protocols simultaneously.

Johannes Berg, co-maintainer of the WiFi subsystem, summed up the situation with disarming honesty on the linux-wireless list: “I now spend more time rejecting AI patches than writing code. That’s not what I volunteered for.”

Verdict

If you manage network infrastructure that depends on the Linux kernel — and that covers 99% of routers, switches, and network appliances worldwide — you need to integrate this reality into your risk management:

• Track stable branches (linux-stable) and apply updates within 48 hours. Security fixes still get through, but AI noise slows everything else down.
• Participate in funding networking maintainers. David Miller, Jakub Kicinski, Kalle Valo, and Johannes Berg are the last line of defense between your infrastructure and the slop — and they work as volunteers or with limited corporate support.
• Do not use AI agents to generate kernel patches without human review. If you do, apply the three-second rule yourself before submitting.

The Linux community has survived Microsoft, patent trolls, and supply chain attacks. It will survive AI patches — but only if networking maintainers receive the financial and human support they deserve. The three-second rule is a symptom, not a solution.

References

• Phoronix — Linux Wireless Maintainer Takes Firm Stance Against AI/LLM Generated Slop Patches, August 6, 2026
• Phoronix — Linux Networking Continues Being Bombarded With AI Patches, August 6, 2026
• Phoronix — Linux Staging Area To Now Reject LLM-Generated Patches, August 4, 2026
• linux-wireless mailing list archives, accessed August 6, 2026