Що сталося
15 липня 2026 року Лінус Торвальдс, творець і головний супровідник (мейнтейнер) ядра Linux, написав у поштову розсилку розробників ядра (LKML) різку відповідь тим, хто вимагає заборонити ШІ-інструменти в розробці. Він заявив: «Linux — не з тих анти-ШІ проєктів, і якщо в когось із цим проблема — можете зробити класичну опенсорсну річ: зробити форк». Окремо додав, що буде «дуже голосно ігнорувати» тих, хто намагається заборонити іншим користуватися ШІ під час написання коду для ядра.
Деталі
Суперечка в спільноті триває давно, але загострилася навколо зростання ШІ-інструментів рев’ю патчів — зокрема, Sashiko, відкритого з березня 2026 року інструмента від інженерів Google, який автоматично перевіряє вхідні патчі та, за заявленими даними, знаходить близько 53% багів у тестових наборах коду. Торвальдс визнав: ШІ-код додає мейнтейнерам роботи і «місцями боляче» — розкриває чимало багів, які інакше пройшли б рев’ю. Але його висновок інший: рішення — у кращих інструментах перевірки, а не в забороні самого ШІ. Критикам якості відповів ще різкіше: «ШІ не ідеальний. Але, чорт забирай, тим, хто тицяє пальцем у проблеми ШІ, варто спершу подивитися в дзеркало».
Що це означає
Формально позиція Торвальдса — це думка однієї людини, хай і з вирішальним голосом у найвпливовішому опенсорс-проєкті на планеті. Але вона позначає, куди реально зсувається межа допустимого: не «ШІ-код заборонено», а «ШІ-код дозволено, якщо він проходить той самий контроль якості, що й людський» — відповідальність за баг усе одно несе людина, яка підписала патч своїм ім’ям.
Кого це стосується. Насамперед — розробників, які вже пишуть код з асистентами на кшталт Cursor, Claude Code чи GitHub Copilot і колись захочуть запропонувати патч у чужий опенсорс-проєкт (не тільки Linux). Позиція мейнтейнера з такою вагою знижує спокусу в інших проєктів вводити формальну заборону «на вході» — але не скасовує їхнє право вимагати жорсткішого рев’ю саме для ШІ-коду.
Ризик чи можливість — з конкретикою. У критиків є два реальні, не надумані аргументи: провенанс і ліцензії (якщо модель навчена на коді з несумісною ліцензією, юридичний ризик лягає на проєкт-отримувача патча, а не на автора моделі) і навантаження на людину-рев’юера, яка фізично не може перевірити обсяг коду, який ШІ здатний згенерувати. Аргумент «за» — не абстрактний: ШІ вже реально допомагав саме в роботі з ядром Linux. Наприклад, ШІ-агент Claude Code знайшов причину багаторічного зависання дисплеїв на відеокартах AMD Radeon — баг, який роками не могли локалізувати вручну. Це конкретний прецедент, а не загальна обіцянка продуктивності.
Горизонт. Зміна — не завтрашня і не разова: це довгий процес притирання процесів рев’ю (інструменти на кшталт Sashiko розвиватимуться далі), а не разове рішення «увімкнули/вимкнули ШІ». Для тих, хто пише код зі ШІ вже зараз, практичний висновок один: якість і прозорість походження патча важливіші за сам факт «писав ШІ чи людина» — і саме за цим критерієм проєкти судитимуть, приймати код чи ні.
Контекст
Позиція Торвальдса — не розворот на порожньому місці: ще в жовтні 2024 року він називав 90% ШІ-маркетингу «хайпом», лишаючись при цьому прагматиком в оцінці конкретних інструментів. До середини 2026 року його тон став більш однозначним — не тому що ШІ став ідеальним, а тому що суперечка всередині спільноти ядра дійшла до спроб формально заборонити інструмент, а не просто критикувати його якість.
