Помимо создания серьезного давления на мейнтейнеров ядра, код, генерируемый закрытыми инструментами ИИ, рискует загрязнить экосистему не поддерживаемым и юридически сомнительным раздуванием кода. — neowin.net
На этой неделе Линус Торвальдс поделился своими последними еженедельными соображениями о пятом релиз-кандидате ядра Linux 7.1. Уже некоторое время Торвальдс говорит нам, что подозревает, что инструменты ИИ приводят к увеличению размера патчей, и что он был не против этого, но за последние пару недель его отношение к людям, использующим эти инструменты, заметно испортилось.
С четвертым релиз-кандидатом Linux 7.1 он критиковал людей за использование этих инструментов для поиска ошибок, но затем не стал сам отправлять исправление кода для этой проблемы. Вместо этого они переложили проблему на других, по сути, завалив их работой. С пятым RC он заявил, что многие исправления ошибок, отправляемые так поздно в цикле, могут подождать до Linux 7.2. Он попросил контрибьюторов сосредоточиться только на исправлении реальных регрессий, учитывая, что до стабильного релиза осталось три недели.
Хотя натиск патчей, сгенерированных ИИ, вызывает головную боль у мейнтейнеров ядра Linux, на самом деле создается более глубокий кризис. Заменяя человеческое понимание проприетарными, закрытыми моделями ИИ, ядро рискует быть загрязненным не поддерживаемым, юридически сомнительным и непрозрачным раздуванием кода (bloat).
Использование искусственного интеллекта для помощи в кодировании может быть безмерно ценным инструментом; это варьируется от человека, выступающего в роли основного кодера, а ИИ предлагает действительно полезную помощь, до «вибрационного кодирования» (vibe coding), где человек руководит кодером ИИ, что именно строить. Это тоже может быть очень полезно; при вибрационном кодировании не так уж сложно создать функциональный продукт. Однако при вибрационном кодировании, особенно с такими инструментами, как Codex от OpenAI, который скрывает код от глаз, человек, инструктирующий бота, не так хорошо знаком с генерируемым кодом.
Хотя для людей, занимающихся побочными проектами, вибрационное кодирование, вероятно, не имеет значения, вы, вероятно, не хотите, чтобы такое происходило в чем-то столь же важном, как ядро Linux, которое используется для питания большинства серверов по всему миру и значительного числа настольных компьютеров.
К счастью, мейнтейнеры Linux не принимают любой код случайным образом; он сначала проверяется. Однако с помощью инструментов ИИ люди могут за секунды создавать тысячи поверхностных патчей или сложных на вид отчетов об ошибках, которые, если их отправить, попадают во входящие мейнтейнера, где им приходится тратить драгоценное время на их рассмотрение.
Помимо дополнительной нагрузки на мейнтейнеров, исправления кода, сгенерированные ИИ, могут выглядеть правильными, но им может не хватать структурного понимания ядра, что может привести к тонким регрессиям, избыточной логике и уязвимостям в крайних случаях. Это весь код, который мейнтейнеру придется просеивать в поисках проблем, и это может привести к тому, что в ядро просочится больше проблем.
По сути, мы наблюдаем атаку типа «распределенный отказ в обслуживании» (DDoS) на разработку ядра. Вместо кибератак на серверы — это похоже на атаку легко генерируемого кода на способность мейнтейнера просматривать такое большое количество представлений кода.
Ядро Linux считается свободным программным обеспечением в соответствии с определением Фонда свободного программного обеспечения (FSF). Это программное обеспечение предоставляет пользователям определенные свободы, одна из которых — «свобода изучать, как работает программа, и изменять ее так, чтобы она выполняла ваши вычисления так, как вы хотите». Используя модели ИИ для написания кода для ядра Linux, ситуация становится несколько запутанной с философской точки зрения, поскольку этот код может быть не до конца понят контрибьютором. Это, по сути, делает код в некоторых случаях нечитаемым.
Читаемость кода заключается не только в возможности понять синтаксис; она также включает понимание того, почему был выбран определенный архитектурный путь для решения проблемы. Когда человек пишет код, он оставляет след своего намерения по всему коду, например, контекстные имена и комментарии. Когда код пишется моделью ИИ, эти вещи могут отсутствовать, поскольку у нее нет намерения; она просто предсказывает следующий наиболее статистически вероятный токен на основе своих обучающих данных. Она может предоставить вам код, который исправляет ошибку, но у него нет лежащего в основе обоснования.
В будущем, если код сломается, первоначальный автор не сможет объяснить свое исправление, потому что он делегировал работу ИИ, который не кодировал с намерением.
Еще одна проблема с обращением к ИИ для исправления кода заключается в том, что это приведет к появлению поколения некомпетентных разработчиков. Должно происходить следующее: приходят новые контрибьюторы, отправляют код, получают обратную связь, улучшают свой код и так далее. Но, полагаясь на ИИ, они теряют это ценное развитие. По мере того как старшие контрибьюторы уходят из проекта, это может привести к появлению поколения разработчиков, неспособных фактически поддерживать ядро, потому что они никогда не развивали свои навыки.
Еще одним чрезвычайно важным соображением относительно вкладов ИИ является тот факт, что большинство, если не все, используемые сегодня модели ИИ являются проприетарными черными ящиками. Даже так называемые модели ИИ с открытым исходным кодом на самом деле не являются открытыми, потому что пользователи не могут увидеть реальный исходный код: данные, используемые для обучения ИИ.
Существует вероятность того, что защищенный авторским правом код, на котором производилось обучение, попадет в ядро Linux; это может вызвать юридические проблемы для ядра в какой-то момент. Кроме того, эти модели, безусловно, обучались на коде с лицензией GPLv3, и если вы используете этот код, ваш проект также должен использовать лицензию GPLv3. Linux лицензирован под GPLv2, поэтому, если в ядре появится код GPLv3, это также может стать проблемой для проекта.
В своем сообщении, сопровождающем Linux 7.1-rc5, Торвальдс заявил, что мейнтейнеры начнут быть более строгими в отношении того, какой код они будут принимать на данном этапе цикла выпуска, чтобы предотвратить раздувание. Возможно, было бы разумно распространить это отношение шире, чтобы мейнтейнеры могли легче отклонять непроверенные, сгенерированные ИИ, отправки.
В то время как Big Tech может быть одержима «повышением производительности» и высокими скоростями разработки, экосистеме свободного программного обеспечения, включая Linux, больше пошло бы на пользу глубоко понятный код, написанный человеком. Его написание может занять больше времени, но автор знает, почему он его написал, и его будет легче исправить в будущем.
Если ядро Linux собирается принять ИИ, возможно, разработчикам стоит рассмотреть возможность создания полностью прозрачной модели, обученной на условиях copyleft, где пользователи имеют доступ ко всему стеку, от обучающих данных до модели вывода, чтобы четыре свободы свободного ПО были по-настоящему сохранены. Несколько иронично, что в настоящее время разработчики полагаются на закрытые модели для написания открытого ядра.
В конечном счете, контрибьюторы Linux и любого другого проекта должны гарантировать, что они все еще могут создавать понятный для человека код. Если разработка будет передана проприетарным моделям ИИ, это подорвет цифровую автономию, уменьшит сотрудничество между людьми и даст слишком большую власть Big Tech.
Сообщите нам в комментариях, что вы думаете об использовании ИИ в ядре Linux, считаете ли вы, что это создаст юридические проблемы, и как отреагировал Линус Торвальдс на его использование?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Paul Hill