LLM сделала код 2013 года читаемым — и нашла еще больше багов
Нильс Оллогге, усердный разработчик, недавно сообщил об ошибке в реализации assoc_array ядра Linux. Даже сам Linus Torvalds признал, что код был «слишком неясным» для понимания, — откровенное признание от создателя Linux. Сложность TN/A подготовила почву для неожиданного вмешательства ИИ.
Торвальдс, будучи прагматиком, обратился к современной LLM, чтобы распутать запутанный код. Он поручил ИИ разбить непрозрачные функции на читаемые и управляемые компоненты. Полученный уточненный результат прошел тщательное тестирование в среде user-space, доказав полезность LLM как мощного аналитического инструмента.
Процесс TN/A не только подтвердил исходную ошибку Оллогге, но и выявил три дополнительных дефекта, существовавших долгое время. Эти скрытые проблемы восходят непосредственно к первому коммиту библиотеки assoc_array в 2013 году. Таким образом, LLM выступила не как автономный «исправитель багов», а как партнер по расследованию, значительно расширив возможности Торвальдса по пониманию и аудиту сложного устаревшего кода.
Поток ИИ-патчей для ядра имеет человеческую цену
Однако вновь обретенная Торвальдсом признательность к ИИ-инструментам не распространяется на беспорядочный поток ИИ-сгенерированных заявок, которые в настоящее время переполняют ядро Linux. На недавнем саммите мейнтейнеров в Праге участники и сопровождающие столкнулись с растущей волной патчей, в частности, от почти 800 новых участников только в Linux 7.3. Приток TN/A указывает на растущую проблему: человеческую цену разработки с помощью ИИ.
Официальные данные показывают, что около 1800 из 18 500 изменений в Linux 7.3 имели тег Assisted-by, что составляет всего 10% от общего числа заявок. Тем не менее, мейнтейнеры оценивают реальное использование LLM как гораздо более высокое, возможно, 90%. Это оценки, а не точный аудит, но они подчеркивают значительный разрыв между прозрачностью и практикой.
Настоящая проблема заключается не в самом инструменте, а в его плохом применении. Низкокачественные или плохо понятые патчи отнимают дефицитное время рецензентов, отвлекая его от критически важной разработки. Принятие Торвальдсом ИИ для личного использования не означает одобрения стратегии подачи заявок в стиле спама. Как он прямо заявил, мейнтейнеры ожидают компетентности и понимания, независимо от используемых инструментов.
Почему Торвальдс называет запреты на инструменты «совершенно глупыми»
Предлагаемое удаление тега Assisted-by: вызвало жаркие дебаты, обнажив фундаментальные разногласия по поводу раскрытия информации и ответственности. Мейнтейнеры беспокоились о потере защитных механизмов, опасаясь наплыва непроверенного ИИ-кода. Тем не менее, реальность была суровой: только ~1800 из ~18 500 несли тег, в то время как оценки предполагали, что 90% участников использовали LLM.
Линус Торвальдс, как и ожидалось, назвал запреты на инструменты «совершенно глупыми». Он развенчал аргумент о раскрытии информации с помощью убедительных аналогий: «Вот вам новое правило: не используйте компиляторы для любых ваших заявок в ядро». Он распространил эту логику на текстовые редакторы, утверждая, что инструменты, будь то компиляторы или LLM, по своей сути не доказывают и не опровергают понимание участника.
Основная мысль Торвальдса ясна: выбор инструмента не имеет значения; ответственность имеет первостепенное значение. Участник все равно должен проверить свой код, ответить рецензентам и принять на себя полную ответственность в рамках процесса подачи заявок в ядро. Система требует компетентности и ответственности, а не декларации предпочтений в программном обеспечении. Для дальнейшего обсуждения управления ядром см. Саммит мейнтейнеров 2026 года.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Правило, которое по-прежнему важно: отвечайте за каждую строку
Отказ от сложного в обеспечении соблюдения тега раскрытия информации может сократить объем бумажной работы, но создает компромисс в управлении. Мейнтейнерам по-прежнему нужны эффективные процессы проверки и четкая подотчетность со стороны участников, даже если формальное требование «Assisted-by:» уходит в прошлое.
Критическое различие заключается не в том, использовался ли инструмент, а в том, как именно. Разработка с помощью ИИ, где автор-человек может объяснить, проверить и пересмотреть вклад, резко контрастирует со слепым копированием или автоматизированным спамом патчами. Использование самим Torvalds LLM для прояснения кода assoc_array с последующим прогоном через тестовую среду, что позволило обнаружить три скрытые ошибки, датируемые 2013 годом, является примером ответственной интеграции инструментов.
Это подводит нас к главному выводу для open source: оценивайте материалы по доказательствам, корректности и ответственности участника, а не по инструментарию. Хотя проекты могут по-разному оценивать риски происхождения и лицензирования, окончательным критерием остается ответственность автора-человека. За каждой представленной строкой кода по-прежнему должен стоять компетентный и подотчетный человек.
Часто задаваемые вопросы
Что помогла обнаружить LLM Линусу Торвальдсу?
После того как Торвальдс использовал LLM, чтобы сделать код assoc_array в Linux более понятным и удобным для тестирования, эта работа подтвердила наличие сообщенной ошибки и выявила три дополнительные ошибки, датируемые 2013 годом.
Запрещен ли код, созданный ИИ, в ядре Linux?
Обсуждение, описанное здесь, касается отмены обязательного тега раскрытия информации Assisted-by, а не запрета на использование ИИ. Участники по-прежнему несут ответственность за код, который они предоставляют.
Почему в Linux рассматривали возможность удаления тега Assisted-by?
Сторонники утверждали, что тег использовался редко и его было трудно контролировать, в то время как критики опасались, что отказ от него может ослабить меры защиты от непроверенных патчей, созданных ИИ.
В чем заключается главный аргумент Торвальдса относительно инструментов программирования на базе ИИ?
Он утверждает, что мейнтейнеры должны оценивать, понимает ли участник код и готов ли он за него отвечать, вместо того чтобы следить за тем, какие инструменты помогли его создать.

