Недавняя история о том, как Линус Торвальдс использовал искусственный интеллект для поиска ошибки в ядре Linux, привлекла внимание многих, но основной посыл остался вне фокуса. В сети обсуждают сам факт обращения создателя Linux к чат-боту, однако куда важнее то, как именно распределялись обязанности между человеком и нейросетью в процессе отладки.
Детали сложной отладки в ядре Linux
Торвальдс столкнулся с серьезной проблемой в графическом драйвере Intel на своей системе Battlemage G21. Ошибка приводила к сбою дисплейного менеджера, из-за чего экран оставался черным. На то, чтобы обнаружить и исправить баг, ушло несколько недель. В конечном итоге решение свелось к простой замене функции round_up() на round_down(), но путь к этому открытию потребовал 24 отладочных патча и 18 перезагрузок ядра.
Важно отметить, что процесс не был автоматическим: ИИ не просто предложил решение, пока автор отдыхал. Напротив, в ходе работы нейросеть неоднократно пыталась убедить разработчика прекратить попытки, утверждая, что проблема «невозможна и неразрешима». В то время как Торвальдс продолжал погружаться в дебри кода, ИИ настойчиво склонял его к тому, чтобы закрыть вопрос и оформить отчет об ошибке, заявляя об отсутствии вариантов решения.
Почему не стоит доверять вердиктам ИИ
Слова модели о невозможности решения звучат весьма убедительно, и во многих случаях разработчик мог бы прекратить попытки, приняв это за окончательный вывод. Однако Торвальдс не позволил уверенности алгоритма перевесить собственное суждение. Это важный урок: ситуация, когда у модели заканчиваются идеи, не означает, что исчерпаны все возможные решения. Ошибочно полагать, что раз ИИ дал уверенный ответ, значит, он проанализировал все вероятности.
Главное различие заключается в отсутствии у ИИ глубокого контекстного понимания роли компонентов системы. Торвальдс десятилетиями работал над ядром Linux, что дало ему фундаментальное понимание того, как система должна функционировать. Нейросети могут детально описывать текущее состояние кода, но они часто не способны определить, какая именно часть поведения является ошибочной с точки зрения архитектуры проекта.
Разделение обязанностей при работе с кодом
В этой истории прослеживается четкая граница между задачами, которые можно делегировать, и тем, что должно оставаться под контролем человека. ИИ взял на себя наиболее рутинную часть работы: написание отладочного вывода, проведение тестов и выполнение бесконечных перезагрузок системы. Нейросеть даже написала итоговый текст коммита, так как отлично справилась с объяснением своих действий, за что Торвальдс отметил ее в патче.
Основной урок, который стоит вынести из этого опыта, прост: позволяйте ИИ заниматься поиском и анализом, но никогда не позволяйте ему выносить окончательный вердикт. Независимо от того, работаете ли вы с ядром ОС, скриптами автоматизации или сложными веб-фреймворками, перед тем как принять отказ ИИ, стоит задаться вопросом: обладаете ли вы информацией, которую модель не может извлечь из имеющихся данных? Если ответ утвердительный, значит, момент принятия решения принадлежит вам, а не машине.
Почему ошибка ИИ — это не приговор
Важно понимать, что когда модель заявляет о «невозможности» решения, это вовсе не означает, что она исчерпала все разумные варианты или проанализировала каждый доступный путь. Подобная самоуверенность ИИ — это одна из наиболее дорогостоящих привычек, которые формируются у пользователей в эпоху коммерческих нейросетей. Мы склонны воспринимать категоричный ответ модели как доказательство того, что она провела исчерпывающий анализ, однако на практике это лишь признак того, что у текущей архитектуры модели закончились натренированные паттерны для обработки данной конкретной задачи.
Торвальдс не пытался «переубедить» ИИ, не пробовал менять промпты или искать более вежливый способ общения с чат-ботом. Он четко разграничил зоны ответственности: модель выполняла «черновую» работу, которая обычно утомляет и выматывает человека, в то время как Линус сохранял за собой право на окончательную оценку прогресса.
Когда стоит проявить настойчивость
Вы можете столкнуться с подобной стеной, даже не притрагиваясь к коду ядра. Это происходит повсеместно:
- В скриптах автоматизации, которые выполняются лишь наполовину, в то время как ИИ настаивает, что используемый API в принципе не поддерживает требуемую функцию.
- В веб-разработке, когда модель категорично утверждает, что причина неработоспособности сайта кроется в «ограничении самого фреймворка», хотя проблема может быть в конфигурации.
Прежде чем смириться с отказом ИИ, всегда задавайте себе один простой вопрос: «Обладаю ли я информацией, которую модель не может вывести из имеющихся у нее доказательств?»
Зачастую это дополнительные данные, которыми владеете только вы, понимание ваших конечных целей или глубокое знание того, как система ведет себя в штатном режиме. Конечно, бывают ситуации, когда вердикт ИИ о «невозможности» действительно соответствует реальности. Однако грань между «ИИ не нашел решения» и «решения не существует» — это зона вашей ответственности как инженера. Не стоит передавать право на этот вывод нейросети.
Опыт Торвальдса показывает, что ценность разработчика заключается не в умении писать код быстрее нейросети, а в способности отличать «безнадежную ситуацию» от ситуации, в которой машина просто перестала видеть контекст. Истинная компетенция программиста проявляется в те моменты, когда он говорит «нет» инструменту, который пытается убедить его свернуть работу.
