"The AI flood continues."
That is how Takashi Iwai, the SUSE engineer who maintains the Linux kernel's sound subsystem, opened the pull request sending ALSA changes into the Linux 7.4 merge window — a four-word assessment that has quickly become a shorthand for a debate already playing out across kernel mailing lists.
According to Phoronix, which covered the pull request, Iwai noted that the flow of new patches arriving from AI and LLM agents has not slowed, and that those agents are turning up new kernel bugs alongside their own code contributions.
The remark landed as a wry observation rather than a complaint, but it captures something structural: machine-authored patches have moved from novelty to routine traffic in at least one core subsystem, and the maintainer responsible for vetting them is now treating the volume as a defining feature of the job.
Two streams, two problems
Iwai's comment appears to cover two distinct streams of AI-generated activity, each with its own set of difficulties for reviewers.
The first is straightforward volume. Patches proposed by coding agents arrive in numbers that must be read, tested, and either merged or rejected — work that falls on maintainers whose review capacity is already the kernel's perennial bottleneck. The second is verification. AI agents that report bugs are contributing something maintainers genuinely want, but bug reports produced by language models carry an obvious risk of false positives or mischaracterised root causes, each of which consumes triage time to confirm or dismiss.
Distinguishing these two streams matters. A contributor flooding the list with low-signal patches is a different editorial and community problem from one surfacing real defects wrapped in unverified diagnoses, even if both show up in the same pull request note.
Why it matters to the community
The sound subsystem is a plausible place for this to surface first: it is large and self-contained, with an active maintainer and a steady patch flow, which makes it an attractive target for automated contribution pipelines — though nothing in the pull request indicates ALSA is uniquely affected. That is analysis rather than anything Iwai stated, and it helps explain why the pattern he describes is visible here.
For downstream integrators and for anyone tracking open-source sustainability, the more important point is upstream of any single patch. Kernel development has always depended on a small number of experienced reviewers standing between proposed changes and the mainline tree. When a meaningful portion of incoming patches requires the reviewer to establish not only that code is correct, but that it was understood by whoever or whatever submitted it, that trust relationship is under strain — regardless of whether the underlying patch turns out to be good.
Linux 7.4's sound changes themselves proceeded normally: Iwai sent the pull, and the subsystem's usual fixes and feature work moved with it. What drew attention was the maintainer commentary that prefaced it.
Whether "the AI flood continues" reads as a warning or simply as the new baseline may depend on what the next merge windows show. For now, it stands as a maintainer's field report from the front line of machine-assisted kernel development — and, notably, one written without rancour.
Source: Phoronix, "Linux 7.4 Sound Changes Merged: 'The AI Flood Continues'" — phoronix.com
「The AI flood continues.」（AI 洪流持續湧入。）
這正是負責維護 Linux kernel 聲音子系統的 SUSE 工程師岩井隆丈（Takashi Iwai），在將 ALSA 變更送入 Linux 7.4 merge window 的 pull request 中的開場白——這四字評語迅速成為一場已在各 kernel mailing lists 上展開的辯論的簡稱。
據報導該 pull request 的 Phoronix 指出，岩井提到來自 AI 及 LLM agents 的新 patch 流量並未放緩，而這些 agents 在提交自身代碼之餘，亦不斷發掘出新的 kernel bugs。
此言與其說是投訴，不如說是一番帶有自嘲意味的觀察，然而它捕捉到某種結構性的現象：由機器撰寫的 patches 在至少一個核心子系統中，已由新奇事物變成常態流量，而負責審核它們的維護者，如今已將其數量視為這份工作的一項標誌性特徵。
兩股流向，兩類問題
岩井的評論似乎涵蓋了兩種截然不同的 AI 生成活動，各自為審核者帶來不同難題。
其一是單純的數量問題。由 coding agents 提出的 patches 數量龐大，必須逐一閱讀、測試，並決定合併或拒絕——這些工作落在審核能力早已是 kernel 長期瓶頸的維護者身上。其二是驗證問題。報告 bugs 的 AI agents 確實在貢獻維護者真正需要的東西，但由語言模型產生的 bug 報告，顯然存在誤報（false positives）或錯誤定性根本原因的風險，每一宗都需耗費 triage 時間去確認或排除。
區分這兩股流向十分重要。向 mailing lists 大量傾倒低資訊量 patches 的貢獻者，與以未經驗證的診斷包裝真實缺陷者，是兩種不同的編輯與社區問題，即使兩者同樣出現在同一份 pull request 說明中。
為何值得社區關注
聲音子系統是此現象最先浮現的合理場所：它規模龐大且相對自成一體，有活躍的維護者和穩定的 patch 流量，使其成為自動化貢獻 pipeline 的理想目標——不過 pull request 中並無任何跡象顯示 ALSA 受影響尤為嚴重。這是分析而非岩井本人的陳述，但有助解釋為何他所描述的模式在此處清晰可見。
對下游整合者以及任何關注 open source 可持續發展的人而言，更重要的一點在於任何單一 patch 的上游。Kernel 開發一直依賴少數經驗豐富的 reviewers 站在建議變更與 mainline tree 之間。當相當一部分 incoming patches 要求 reviewer 不單要確認代碼正確，還要確認提交它的「人或機器」確實理解其內容時，這層信任關係便承受壓力——無論底層 patch 本身是否良好。
Linux 7.4 的聲音變更本身進展順暢：岩井發出了 pull，子系統慣常的修復與功能開發一併推進。引起關注的，是排在 pull 之前的維護者評語。
「The AI flood continues」究竟應讀作警告還是新的基準線，可能要視乎接下來幾個 merge window 的情況而定。目前而言，它是一名維護者來自機器輔助 kernel 開發前線的現場報告——值得一提的是，這份報告並無怨懟之意。
來源：Phoronix，"Linux 7.4 Sound Changes Merged: 'The AI Flood Continues'" — phoronix.com