В октябре 2026 года в рабочей переписке разработчиков ядра Linux произошёл показательный обмен репликами. Один из участников предложил ограничить использование ИИ в работе над ядром. Линус Торвальдс ответил резко и саркастически: если не доверяете ИИ, откажитесь заодно и от компиляторов. Этот эпизод быстро разлетелся по профильным ресурсам, но обсуждают его чаще с эмоциональной стороны, а не с практической. А зря: спор поднимает важный вопрос о том, как разработчику вообще относиться к инструментам, которые генерируют код.

Суть претензии и суть ответа

Позиция автора предложения понятна: ИИ-ассистенты могут предлагать код, который выглядит корректно, но содержит скрытые ошибки, а в ядре цена такой ошибки высока. Ответ Торвальдса сводится к простой мысли: компилятор тоже преобразует исходный код в машинный, и никто не требует писать на ассемблере, чтобы «контролировать каждый байт». Инструмент не отменяет ответственности — он лишь меняет её форму. Компилятору доверяют не потому, что он безошибочен, а потому, что его поведение предсказуемо и проверяемо.

Для рядового разработчика этот спор полезен не как повод занять сторону, а как напоминание: любой инструмент в цепочке производства кода нужно уметь проверять. Если вы не можете объяснить, что делает сгенерированный фрагмент, и не можете его протестировать — проблема не в ИИ, а в процессе.

Как выстроить работу с ИИ-ассистентом без иллюзий

Практический вывод из дискуссии простой: не делите инструменты на «чистые» и «нечистые». Делите задачи по степени риска и выстраивайте проверку под них. Вот конкретные шаги.

  • Определите границы. Составьте список задач, где ИИ допустим (черновики, шаблонный код, тесты, документация), и где недопустим без полной ручной проверки (критичные участки, безопасность, работа с данными пользователей).
  • Требуйте объяснений. Если ассистент предлагает фрагмент, попросите его разобрать логику по шагам. Если объяснение противоречиво — код не берём.
  • Проверяйте тестами, а не глазами. Сгенерированный код должен проходить те же проверки, что и написанный вручную. Отсутствие тестов — причина не принимать фрагмент, а не повод довериться.
  • Фиксируйте происхождение. В командной работе полезно отмечать, какие участки кода созданы с помощью ИИ, чтобы при инциденте было проще провести разбор.

Эти шаги не гарантируют отсутствия ошибок, но делают их обнаружение частью нормального процесса, а не сюрпризом на проде.

Типичные ошибки разработчиков

Споры вроде торвальдсовского вспыхивают потому, что обе стороны часто допускают крайности. Вот что встречается чаще всего.

  • Слепое доверие. Разработчик вставляет сгенерированный код, не читая его полностью, потому что «выглядит логично». Это самая дорогая ошибка: она экономит минуты и стоит часов отладки.
  • Полное отрицание. Другая крайность — запретить ИИ на уровне команды. Запрет не решает проблему качества, но заставляет людей пользоваться инструментом тайно, без обсуждения и проверок.
  • Подмена понимания. Когда ассистент пишет код быстрее, чем разработчик успевает вникнуть, возникает иллюзия компетенции. Через месяц такой специалист не может объяснить, как работает его собственный проект.
  • Игнорирование контекста. ИИ не знает вашу кодовую базу, соглашения и ограничения. Фрагмент, идеальный в вакууме, может нарушать архитектуру проекта.

Пример из практики: команда подключила ассистента для генерации миграций базы данных. Первые несколько миграций прошли проверку, и процесс перестали контролировать. На одной из миграций сгенерированный код удалил индекс, который использовался в тяжёлом запросе, — нагрузка выросла в разы. Проблема была не в ИИ, а в том, что проверку заменили доверием.

Что делать, если вы только начинаете

Начинающим разработчикам стоит воспринимать ИИ-ассистента как тренажёр, а не как замену учебнику. Полезная практика: сначала попробуйте написать фрагмент сами, затем сравните с вариантом ассистента и разберите расхождения. Это развивает навык чтения кода и снижает риск слепого копирования. Ещё один приём — вести короткий журнал: какие задачи вы решали с ИИ, что пришлось исправлять и почему. Через несколько недель такой журнал покажет ваши реальные слабые места лучше любого курса.

Для команд полезно договориться о минимальных правилах: код от ИИ проходит ревью наравне с любым другим, в описании пул-реквеста указывается, использовался ли ассистент, а на критичных участках требуется дополнительная проверка. Такие правила не бюрократизируют процесс, а снимают неопределённость.

Спор вокруг ядра Linux — хороший повод перестать обсуждать ИИ в терминах веры и начать обсуждать его в терминах процесса. Инструмент не бывает доверенным или недоверенным сам по себе: доверие возникает из проверяемости. Если вы можете объяснить, протестировать и откатить сгенерированный код, — вы контролируете ситуацию. Если нет — неважно, пишете вы на ассемблере или пользуетесь генератором: риск остаётся вашим.