In the networking pull request for Linux 7.3, Jakub Kicinski describes maintainers under heavy review pressure. The useful evidence is his account of patch volume and current review assistance, not a proven classification of every contribution as AI-written.
Read the estimate as an estimate
The August 18 pull request gives a rough count of 632 net and 648 net-next patches handled by Kicinski and Paolo Abeni. Kicinski estimates that one third to one half of net-next looks like AI-driven low-priority fixes, cleanups or clarifications. That is a qualified impression of one subset, not an audited AI label on all 1,280 patches.
He also describes access to multiple frontier models for review, with a credit to Meta. The account says this removes some hallucinations while acknowledging limits. It does not establish that agreement between models proves a finding or that a concern raised by only one model is usually false.
Why correct patches can still consume scarce capacity
An original queue example makes the constraint concrete. Suppose 30 patches arrive each hour and each takes five minutes of human attention. Two reviewers supply 120 reviewer-minutes per hour, enough for 24 patches. Even if every patch is valid, the backlog grows by six per hour, or 48 over an eight-hour period with the same rates.
These are fictional planning numbers, not a measurement of netdev staffing or review times. The example shows that patch correctness and sustainable arrival rate are separate questions. Shorter review time, fewer low-value submissions or more available reviewers change the arithmetic; a label on the authoring tool does not by itself resolve it.
Keep a model finding attached to verifiable evidence
A useful proposed review note identifies the affected path, the triggering condition and what observation would distinguish a real defect from an impossible path. For a race claim, merely naming two functions does not show that their operations can overlap in the relevant state.
Two models can repeat the same mistaken assumption. Conversely, one reviewer can find a real issue others missed. A reproducer, a state argument and a relevant regression test carry more information than a vote among generated answers. This is a review method, not a claim that every concurrency defect is easily reproducible.
Planned process automation is not autonomous acceptance
Kicinski discusses possible next-cycle work such as managing Patchwork, handling common process feedback and editing commit messages. Applying changes already reviewed by trusted people is presented as a possibility. The pull request does not announce unrestricted automatic acceptance of model-generated patches.
The networking changes themselves include BIG TCP in VXLAN/Geneve UDP tunnels and improved MPTCP behavior under severe memory pressure. The review-pressure discussion accompanies actual subsystem work; it should not be rewritten as a claim that Linux has handed its networking decisions to an agent.
Treat the AI share as a maintainer estimate, distinguish current review assistance from contemplated automation, and remove unsupported model-agreement and legal claims.