Коли алокатор почав використовувати область CCS як звичайну відеопам’ять, нові виділення могли перекривати та перезаписувати метадані, потрібні GPU. Це спричиняло пошкодження даних, пов’язаних із таблицями сторінок, збої композитора, артефакти на екрані та нескінченні перезапуски дисплейного менеджера GDM на графіці Battlemage G21.
Отже, першопричиною була не просто неправильна арифметична операція. Код поводився з величиною так, наче вона позначала адресу початку, хоча фактично це була межа — точка, за якою доступна пам’ять закінчується. Саме через цю семантичну помилку однорядковий патч виявилося так складно знайти.
Торвальдс разом із ШІ додавав і змінював точкове інструментування, простежував розрахунки пам’яті в драйвері та порівнював позицію CCS, яку повідомляло обладнання, з межею, переданою алокатору VRAM. Після 24 варіантів діагностичних патчів і 18 циклів «перезавантаження — тест» стало зрозуміло, що напрямок округлення неправильний.
Ці перезапуски були важливими: проблема проявлялася не лише як підозрілий рядок у вихідному коді, а й на рівні GPU та всієї графічної підсистеми. Кожен експеримент допомагав відокремити помилку розподілу пам’яті від інших можливих причин збоїв.
Торвальдс використовував асистента як інтерактивного партнера з налагодження. ШІ пропонував варіанти інструментування, допомагав проходити ланцюжками викликів у драйвері та аналізувати результати чергових експериментів. Це скоротило обсяг механічної роботи під час перевірки гіпотез.
Водночас асистент не був надійним джерелом остаточних висновків. За словами Торвальдса, він неодноразово заявляв, що проблему неможливо розв’язати, і пропонував просто написати звіт. Інженер продовжував пошук, обирав наступний експеримент, відкидав хибні трактування та розумів, що саме означає зміщення в моделі пам’яті алокатора.
У цьому і полягає головний урок історії: ШІ генерував можливості й виконував механічну роботу, а фахівець забезпечував контекст, наполегливість, перевірювані експерименти та остаточне рішення.
Торвальдс особисто підготував і закомітив виправлення драйвера Intel Xe до основного дерева ядра Linux. Очікувалося, що підтримувані стабільні гілки отримають його через звичайний процес перенесення виправлень, однак наявні джерела не дають змоги надійно назвати конкретні стабільні версії чи дати їхніх релізів.
Тому користувачам варто перевіряти оголошення своїх дистрибутивів або супровідників ядра, перш ніж робити висновок, що певна збірка вже містить виправлення.
Ця історія не є безумовним схваленням коду, згенерованого штучним інтелектом. Вона демонструє значно вужчий і практичніший сценарій: експерт використовує ШІ, щоб пришвидшити складний цикл налагодження, але сам формулює гіпотези, планує тести, перевіряє зміни й відповідає за результат.
Це принципово відрізняється від надсилання супровідникам неперевірених патчів або автоматично згенерованих звітів про вразливості. Розробники ядра описували «навалу» машинно створених внесків, а супровідники підсистем staging і networking говорили про зростання кількості малокорисних або погано зрозумілих патчів.
Поширену цифру про зростання кількості подань на 2700% слід сприймати обережно: наведені джерела не пояснюють методику вимірювання, період або точну категорію, якої вона стосується. Надійніше підтверджено загальніший висновок: ШІ здешевив створення коду та звітів, але їхня перевірка й сортування досі потребують часу людей і лягають на плечі супровідників.
Торвальдс також заявляв, що Linux не є категорично анти-ШІ проєктом, зокрема коли йдеться про такі інструменти, як допомога в перевірці коду. Налагодження Intel Xe добре показує межу: ШІ може бути корисним усередині дисциплінованого інженерного процесу, але не замінює знання підсистеми, відтворюваних тестів і людської відповідальності.
Фінальний патч складався з одного рядка. Справжнім досягненням було зрозуміти, який саме рядок потрібно змінити, і не зупинитися, коли асистент вирішив, що відповіді не існує.