Разбор: почему Торвальдс читает объяснения, а не диффы — и что это меняет в ревью кода с ИИ

Линус Торвальдс читает код иначе, чем десять лет назад. Изменений он смотрит меньше, чем описаний к ним. Объяснение патча разбирает внимательнее самого диффа — потому что объяснение показывает, понимает ли автор, что именно он сделал.

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

Если вы ревьюите код или пишете его с ассистентом, для вас это про одно: патчей становится больше, чем вы способны осмысленно проверить. Узкое место переехало.

Где именно болит у мейнтейнера

ИИ приносит не только код. Он приносит поток. Мейнтейнер тратит силы на разбор ложных баг-репортов, на попытки понять чужую реализацию, на переписку с автором — «что вы, собственно, сделали?» — и на проверку обратной совместимости после этого. Внимание, которое должно было уйти на подсистему, уходит на переговоры.

Торвальдс назвал ИИ-патчи бездумными пластырями. Логика простая: модель может закрыть тот баг, который видно прямо сейчас, а следующий уже стоит в коридоре и ждёт своей очереди. Так бывает всегда, когда проблему глушат, не разобравшись в причине. Это свойство любого ремонта вслепую.

Про продуктивность он высказался сдержаннее, чем пресса. Смысл примерно такой:

ИИ, будем надеяться, создаёт больше пользы, чем разрушает.

Не «трансформирует». Не «меняет всё». Просто «надеемся, что в плюсе». Скромная формулировка, за которой тридцать пять лет ревью чужого кода.

Логика против памяти

Соблазн такой: перевести проект на Rust — и закрыть класс проблем. Часть ошибок, которые вы делаете на C, Rust действительно убирает. Логические — нет. Думать за вас он не станет. Напишете неверный по смыслу код — результат так же уедет от задуманного. Ошибочный результат? Точка.

Громкие баги ядра, о которых все слышали, не были проблемами безопасности памяти. Их внесли люди с неверной моделью того, что код должен делать. Сюда же примыкают споры «любит Торвальдс Rust или нет». Ни то, ни другое. Разговор про то, что язык не отвечает за смысл.

Что делать на практике

Тест Торвальдса простой: читайте объяснение, а не только дифф. Ниже — как превратить это в процесс.

В описании изменения

1. Причина, а не пересказ диффа. Дифф вы и так видите. Нужна модель: как, по мнению автора, должна работать система и что именно было не так.
2. Границы проверки. Что запускали, что нет, какие подсистемы затрагивает правка.
3. Обратная совместимость — отдельным пунктом. Кто уже зависит от текущего поведения и что для него сломается.

На ревью

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

И следите за ловушкой: если описание патча сгенерировал тот же ассистент, вы читаете связный текст, а не понимание. Выглядит прилично и не значит ничего.

Когда так делать не нужно

Опечатка в комментарии, форматирование, обновление версии зависимости — требовать тут эссе смешно. Дисциплина нужна там, где правка меняет поведение системы. Для одноразового скрипта или прототипа — тоже мимо.

Что в остатке

Генерация кода не накапливается. Каждая новая модель обнуляет преимущество, которое вы получили от знания предыдущей. Картина системы, причины принятых решений и их последствия через годы — накапливаются, потому что строятся в голове, а не в файлах.

Профессиональная разница теперь выглядит так: один умеет получить работающий код, второй понимает, почему он работает и что сломается завтра. Отличить их можно по объяснению. Читайте его.