Линус Торвальдс читает код иначе, чем десять лет назад. Изменений он смотрит меньше, чем описаний к ним. Объяснение патча разбирает внимательнее самого диффа — потому что объяснение показывает, понимает ли автор, что именно он сделал.
В разговоре про ИИ и качество кода он назвал вещь, которую почти никто не проговаривает вслух: самые опасные баги в ядре — не про память. Это логические ошибки. Инженер пишет код, исходя из неверной картины того, как система должна работать. Ни один язык такое не поймает. И ни одна модель.
Если вы ревьюите код или пишете его с ассистентом, для вас это про одно: патчей становится больше, чем вы способны осмысленно проверить. Узкое место переехало.
Где именно болит у мейнтейнера
ИИ приносит не только код. Он приносит поток. Мейнтейнер тратит силы на разбор ложных баг-репортов, на попытки понять чужую реализацию, на переписку с автором — «что вы, собственно, сделали?» — и на проверку обратной совместимости после этого. Внимание, которое должно было уйти на подсистему, уходит на переговоры.
Торвальдс назвал ИИ-патчи бездумными пластырями. Логика простая: модель может закрыть тот баг, который видно прямо сейчас, а следующий уже стоит в коридоре и ждёт своей очереди. Так бывает всегда, когда проблему глушат, не разобравшись в причине. Это свойство любого ремонта вслепую.
Про продуктивность он высказался сдержаннее, чем пресса. Смысл примерно такой:
ИИ, будем надеяться, создаёт больше пользы, чем разрушает.
Не «трансформирует». Не «меняет всё». Просто «надеемся, что в плюсе». Скромная формулировка, за которой тридцать пять лет ревью чужого кода.
Логика против памяти
Соблазн такой: перевести проект на Rust — и закрыть класс проблем. Часть ошибок, которые вы делаете на C, Rust действительно убирает. Логические — нет. Думать за вас он не станет. Напишете неверный по смыслу код — результат так же уедет от задуманного. Ошибочный результат? Точка.
Громкие баги ядра, о которых все слышали, не были проблемами безопасности памяти. Их внесли люди с неверной моделью того, что код должен делать. Сюда же примыкают споры «любит Торвальдс Rust или нет». Ни то, ни другое. Разговор про то, что язык не отвечает за смысл.
| Тип ошибки | Откуда берётся | Компилятор и линтер | ИИ-ассистент | На ком ответственность |
|---|---|---|---|---|
| Безопасность памяти | неверная работа с указателями и границами | в Rust ловит на этапе сборки, в C часто нет | нет | на языке и инструментах |
| Логическая ошибка | искажённое представление о том, как система должна работать | нет | нет — уверенным тоном повторит вашу же ошибку | только на человеке |
| Регресс из-за пластыря | баг заглушили, причину не искали | нет | нет | на авторе и ревьюере |
| Ложный баг-репорт | галлюцинация при разборе чужого кода | нет | сам же и породил | на мейнтейнере, который это отсеивает |
Что делать на практике
Тест Торвальдса простой: читайте объяснение, а не только дифф. Ниже — как превратить это в процесс.
В описании изменения
- Причина, а не пересказ диффа. Дифф вы и так видите. Нужна модель: как, по мнению автора, должна работать система и что именно было не так.
- Границы проверки. Что запускали, что нет, какие подсистемы затрагивает правка.
- Обратная совместимость — отдельным пунктом. Кто уже зависит от текущего поведения и что для него сломается.
На ревью
- Сначала объяснение. Если из текста не видно, что автор понимает свою правку, читать дифф дальше бессмысленно.
- Задайте один вопрос по причине бага. Ответ «так работают тесты» — это не ответ.
- ИИ-патч отправляйте назад, если автор не может в двух абзацах объяснить, откуда проблема бралась. Пластырь без диагноза обычно оставляет рядом ещё одну мину.
- Отдавайте правку тому, кто знает подсистему. Сам Торвальдс теперь присылает патчи как предложения и ждёт, что мейнтейнер вернёт исправление: локальное знание точнее.
И следите за ловушкой: если описание патча сгенерировал тот же ассистент, вы читаете связный текст, а не понимание. Выглядит прилично и не значит ничего.
Когда так делать не нужно
Опечатка в комментарии, форматирование, обновление версии зависимости — требовать тут эссе смешно. Дисциплина нужна там, где правка меняет поведение системы. Для одноразового скрипта или прототипа — тоже мимо.
Что в остатке
Генерация кода не накапливается. Каждая новая модель обнуляет преимущество, которое вы получили от знания предыдущей. Картина системы, причины принятых решений и их последствия через годы — накапливаются, потому что строятся в голове, а не в файлах.
Профессиональная разница теперь выглядит так: один умеет получить работающий код, второй понимает, почему он работает и что сломается завтра. Отличить их можно по объяснению. Читайте его.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.