Як повідомляє Linux.org, супровідники мережевої підсистеми ядра Linux зіткнулися з різким збільшенням кількості патчів, створених або виявлених за допомогою ШІ. Один із відповідальних розробників Якуб Кічинський визнав, що команда вже повністю перевантажена потоком змін, пише MigNews.
Проблема стала помітною під час підготовки Linux 7.3 і спричинила ширшу дискусію про контроль якості коду ядра. Розробникам доводиться перевіряти сотні виправлень, тоді як складність самого Linux продовжує зростати, зокрема через використання Rust та збільшення кількості автоматично згенерованих пропозицій.
Сотні патчів для Linux перевантажили супровідників мережевої підсистеми
Якуб Кічинський навів конкретні показники навантаження. За його приблизними підрахунками, він разом із Паоло об’єднав 632 патчі для гілки net та ще 648 для net-next.
Водночас ці цифри не повністю відображають масштаб роботи. Від третини до половини змін у net-next також можуть бути низькопріоритетними виправленнями, очищенням коду або уточненнями, виявленими за допомогою ШІ.
Ситуацію Кічинський описав так:
«Побіжний і приблизний підрахунок показує, що ми — Паоло і я — об’єднали майже однакову кількість патчів net — 632 і net-next — 648. Це не відображає всієї картини, оскільки від третини до половини патчів у net-next також виглядають як виправлення низького пріоритету, виявлені за допомогою ШІ, очищення коду та уточнення. Ми, звісно, повністю перевантажені».
На масштаб проблеми звернули увагу й оглядачі, які стежать за розробкою ядра Linux.
«Мережевий pull-запит для Linux 7.3 з’явився цього тижня, і найцікавішим у ньому був не BIG TCP і не нові драйвери бездротових мереж. Це був супровідний лист, у якому люди, що керують однією з найбільш навантажених підсистем ядра, вголос сказали те, про що ходили чутки місяцями».
Розробники залучають ШІ для перевірки створених ШІ патчів
Команда намагається впоратися з потоком змін за допомогою тих самих технологій, які частково спричинили проблему. Для перевірки кожного патча планують використовувати кілька провідних великих мовних моделей.
Кічинський пояснив, що необхідний бюджет і доступ до LLM уже вдалося забезпечити.
«Промінь надії полягає в тому, що ми забезпечили достатній бюджет і доступ до LLM, щоб проводити рев’ю з використанням кількох провідних моделей для кожного патча. Це усуває частину галюцинацій. Хоча в плані рев’ю самі LLM можуть зробити лише стільки».
За наведеними у матеріалі даними, бюджет на токени для такої роботи надала Meta. Однак автоматизована перевірка не усуває необхідності людського контролю та не розв’язує всі проблеми, які накопичувалися в коді роками.
Кічинський окремо вказав на дефекти, пов’язані з рідкісними системними подіями.
«Сумна правда полягає в тому, що наші API — особливо для рідкісних подій, таких як помилки PCIe або тайм-аути — завжди страждали від дефектів гонки станів, і тепер LLM просто не дозволяють нам це ігнорувати».
У спільноті Linux сперечаються про контроль якості коду
Ситуація з мережевою підсистемою вийшла за межі питання кількості патчів. У спільноті почали активніше обговорювати, хто фактично здатний контролювати весь код, який зрештою потрапляє до ядра.
Оглядач Рой Щестович висловив особливо критичну позицію щодо чинної моделі контролю та складності компонентів, написаних на Rust.
«Лінус Торвальдс не стежить за тим, що потрапляє в ядро, а будь-який код на Rust для нього більш-менш незрозумілий. Тому фактично ніхто за це не відповідає, а людей, які говорять про цю проблему, таврують і демонізують як “анти-ШІ”».
Це твердження є позицією автора колонки, а не офіційною оцінкою команди Linux. Водночас дискусія демонструє занепокоєння частини спільноти щодо того, як масштабування ШІ-генерації коду впливає на традиційну систему перевірки патчів.
Потік ШІ-патчів уже позначився на розробці ARM64
Наслідки збільшення кількості ШІ-змін помітили й в інших частинах ядра. Зокрема, під час циклу Linux 7.2 розробка для архітектури ARM64, за наведеними даними, постраждала через надмірний потік патчів, пов’язаних із AI та LLM.
Ситуацію з AArch64 описали так:
«Розробка для архітектури ARM64 нібито постраждала під час циклу 7.2 через “божевілля з патчами для AI/LLM” — жодних реальних нових функцій для AArch64 у тому циклі так і не з’явилося».
Таким чином, проблема полягає не лише у додатковому навантаженні на супровідників. Велика кількість дрібних виправлень і пропозицій може відбирати ресурси, які розробники могли б витрачати на нові функції та інші пріоритетні завдання.
LLM можуть отримати більше завдань під час розробки Linux
Наступним кроком команда розглядає ширше використання мовних моделей у рутинних процесах. LLM планують залучати до супроводу системи Patchwork, автоматичних відповідей на типові процедурні зауваження та редагування повідомлень комітів.
У перспективі автоматизація може поширитися й на застосування патчів, які вже отримали схвалення від довірених рецензентів. У такій моделі частина людського контролю фактично зміщується від повторної перевірки кожної технічної операції до визначення кола фахівців, чиїм рецензіям можна довіряти.
Водночас розробники не розглядають LLM як повноцінну заміну фахівцям. Навіть використання кількох моделей для одного патча лише скорочує частину помилок і галюцинацій, залишаючи остаточну відповідальність за якість коду за людьми.
Нагадаємо, раніше ми писали про обмеження Android 17 для ресурсомістких застосунків та керування оперативною пам’яттю.
