Линус Торвальдс отправил в ветку разработки Linux 7.3 патч длиной в одну строку, который исправляет неприятную ошибка Linux: на части машин система зависала в момент перехода к графическому экрану входа. Самое интересное не в размере фикса, а в маршруте до него: по словам Торвальдса, проблему удалось локализовать после 24 отладочных патчей и 18 загрузок ядра при активной помощи ИИ-бота.
Для русскоязычных разработчиков здесь важен не очередной сюжет про «ИИ пишет код», а куда более приземленная история: бот оказался полезен как выносливый помощник в отладке, но не как инженер, который сам доведет расследование до конца. Как пишет The Register, даже в этом кейсе ИИ несколько раз объявлял задачу почти безнадежной и предлагал просто оформить отчет о баге. Торвальдс, как и положено Торвальдсу, продолжил копать.
Сама ошибка Linux жила в драйвере Intel Xe для графики. Из-за сбоя машина могла намертво зависнуть ровно в тот момент, когда операционная система переключалась в графический режим и показывала экран логина. Это как раз тот тип поломки, который особенно неприятен в диагностике: логов немного, воспроизводимость капризная, а пользователь видит только замершую картинку в самый неудачный момент. Проблема упиралась в то, как драйвер резервировал память для Intel Compute Command Streamer, или CCS. Документация драйвера Intel i915 описывает CCS как движок, имеющий доступ к media- и GPGPU-конвейерам, но не к 3D-пайплайну. Дальше начинается типичный low-level сюжет: драйвер вычисляет нужную область памяти, берет пространство ниже нее, проводит еще несколько операций и округляет результат до кратности 128 КБ, после чего считает этот объем доступной видеопамятью.
Сломалось все на одном, казалось бы, невинном действии. Вместо округления вниз использовалось округление вверх. В результате драйвер в некоторых сценариях помечал как свободную память, которая уже была занята. Итогом и становился фриз в ходе загрузки. Финальный патч меняет round_up() на round_down() — буквально одна строка. Но эта история в очередной раз напоминает старую инженерную истину: размер исправления почти никогда не отражает стоимость поиска причины. Особенно когда баг сидит в управлении памятью на стыке ядра, драйвера и графического стека.
Торвальдс отдельно описал сам процесс отладки и, для него необычно, сделал это довольно разговорно. Он назвал разбор «сеансом отладки из ада» и признал, что ИИ сильно помогал с рутинной частью работы: добавлял диагностический код и анализировал результаты, когда его подталкивали в нужную сторону. При этом бот, по словам Торвальдса, несколько раз прямо заявлял, что проблема неразрешима. В итоге именно ИИ подготовил текст commit message, а человек оставил за собой то, что пока все еще плохо автоматизируется: упрямство, инженерную интуицию и готовность прогонять новые гипотезы до тех пор, пока одна из них не выстрелит.
Этот эпизод хорошо попадает в текущий тренд вокруг coding assistants. Самая трезвая модель их применения выглядит не как «заменить разработчика», а как «снять с него механическую нагрузку». В истории с Linux бот не написал красивую архитектуру, не вывел закономерность из воздуха и не спас релиз одной кнопкой. Зато он помог пережить десятки итераций отладки без потери темпа. Для команд, которые поддерживают сложные системы, драйверы, инфраструктурный код или высоконагруженные сервисы, это, пожалуй, более полезный сценарий, чем бесконечные демо в стиле “собери CRUD по промпту”. Когда нужно быстро плодить проверяемые гипотезы, вставлять временный instrumentation-код и разбирать шумные результаты, такой помощник действительно окупается.
Есть и второй слой, уже не про ИИ, а про железо. Источник обращает внимание, что современные ПК с дискретной или сложно устроенной графикой продолжают приносить проблемы из-за разделенной памяти CPU и GPU. На этом фоне все чаще всплывают идеи использовать ресурсы гибче: например, задействовать свободную видеопамять под быстрый swap или, наоборот, оптимизировать работу слабых GPU, которым не хватает собственного VRAM. The Register связывает это и с более широким трендом на более тесную интеграцию компонентов и общую память, как на некоторых Arm64-системах, включая Apple Silicon. Это не прогноз о скорой победе одной архитектуры, а скорее напоминание: память снова стала дорогим и дефицитным ресурсом, а значит, цена ошибок в ее разметке и распределении будет только расти.
Для бизнеса и продуктовых команд здесь сигнал тоже вполне практический. Если ваш стек включает системное ПО, графические подсистемы, ML-инфраструктуру, драйверы или любые компоненты, где ошибка проявляется лишь после длинной цепочки условий, не стоит ждать от ИИ магии. Но и списывать его в категорию игрушек уже поздно. Кейс Торвальдса показывает рабочий компромисс: бот полезен там, где нужен не авторитетный ответ, а терпеливый, дешевый и быстрый перебор технических шагов под контролем сильного инженера. И, возможно, именно эта модель окажется для индустрии важнее громких обещаний о полном автокодинге: ИИ не заменяет человека в критическом расследовании, но заметно расширяет его выносливость.