Код стал дешёвым. Понимание — нет

Вместо вступления

Когда-то было проще верить, что код и есть правда о системе.

Ты открываешь репозиторий — и вроде бы всё перед тобой: логика, правила, зависимости, поведение. Если что-то непонятно, значит, надо просто внимательнее читать. Такой взгляд был удобен, привычен и во многом оправдан.

Но сейчас он всё хуже работает.

Потому что код сегодня можно генерировать очень быстро. Практически мгновенно. А вот понимать, что этот код реально делает, почему он устроен именно так и какие последствия у него будут в проде, по-прежнему долго и дорого.

И в этом — главная проблема.

Скорость изменилась, а понимание нет

Генерация кода стала дешёвой.

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

Но здесь есть ловушка: скорость создания кода не равна скорости понимания.

Потому что самые важные вопросы в разработке почти никогда не звучат как:

• как написать этот метод;

• как назвать переменную;

• как оформить цикл;

• как собрать endpoint.

Они звучат иначе:

• безопасно ли это;

• что сломается через неделю;

• что мы здесь не учли;

• откуда вообще взялось это правило;

• почему система должна вести себя именно так.

И вот на такие вопросы генерация кода отвечает плохо.

Она умеет производить форму.
Но не умеет автоматически производить смысл.

Код — это не вся истина

Мы до сих пор часто ведём себя так, будто репозиторий — это единственное место, где живёт правда о системе.

Но это не так.

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

• исходным кодом;

• логами;

• трассировками;

• метриками;

• инцидентами;

• postmortem-отчётами;

• code review;

• комментариями;

• Confluence;

• перепиской;

• памятью команды.

То есть truth уже давно не лежит в одном месте.

И всё же мы продолжаем почти автоматически считать код главным источником истины. Как будто всё остальное — это вспомогательные заметки. Как будто code review — это только место для проверки стиля. Как будто инциденты — это отдельная жизнь, не связанная с кодом.

Вот здесь и возникает разрыв.

GitLab хранит change, но не meaning

GitHub и GitLab очень хороши как single source of change.

Они показывают:

• что изменилось;

• кто это сделал;

• когда;

• в каком диффе;

• через какой merge request.

Но change — это не понимание.

Например, вызов player.move('up') или player.move([0, 1, 0, 0]) может быть абсолютно достаточен, чтобы показать изменение состояния. Видно направление, видно вызов, видно форму API.

Но этого всё равно недостаточно, чтобы понять:

• почему интерфейс устроен именно так;

• какие правила стоят за этим вызовом;

• почему выбрана именно такая модель;

• какие инциденты или ограничения привели к этому решению;

• что здесь должно быть явно выражено, а что скрыто недопустимо.

GitLab хранит дифф.
Но дифф — это ещё не смысл.

Мы уже давно работаем не только с кодом

На практике разработчики и так постоянно опираются на вещи, которые не сводятся к исходникам.

Мы обсуждаем инциденты на встречах.
Мы разбираем их в постмортемах.
Мы ищем причины в логах и трассировках.
Мы спорим о смысле решений на code review.
Мы пишем комментарии.
Мы добавляем страницы в Confluence.

То есть мы уже живём в мире, где код — не единственный носитель истины.

Но проблема в том, что доверие к нему распределено неравномерно. Код всё ещё считается более «настоящим», чем всё остальное. А documentation, comments, postmortems и обсуждения часто воспринимаются как вторичные слои, хотя на деле именно там и живёт большая часть инженерного знания.

И это старое допущение начинает мешать.

Почему code generation подсветила проблему

Кодогенерация не придумала новый дефект.

Она просто сделала старый дефект слишком заметным.

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

Теперь это не работает.

Код можно получить слишком быстро.
И сразу становится видно: быстрое изменение — это не то же самое, что понимание изменения.

Если мы всё ещё считаем код единственным источником правды, то AI просто ускоряет производство артефактов, смысл которых потом снова придётся собирать вручную.

И тогда code generation действительно превращается в дорогую игрушку.

Где на самом деле живёт понимание

Понимание системы не живёт только в репозитории.

Оно живёт в:

• инцидентах;

• объяснениях на ревью;

• логах и трассировках;

• решениях, зафиксированных в документации;

• правилах, которые команда знает неявно;

• обсуждениях, где люди пытаются восстановить причину.

И если мы хотим, чтобы AI был чем-то большим, чем быстрый генератор синтаксиса, надо признать: source of change и source of truth — это разные вещи.

GitHub и GitLab отлично хранят change.
Но truth должен быть шире, чем code tree.

Что это меняет

Если перестать считать код единственным источником истины, тогда меняется сама инженерная модель.

Тогда важно не только:

• как быстро сгенерировать код;

• как быстро его закоммитить;

• как быстро его смержить.

Становится важно:

• как восстановить смысл решения;

• как связать код с инцидентами;

• как хранить объяснение, а не только результат;

• как сделать знания доступными не только автору, но и всей команде.

И вот тогда code generation начинает работать не как игрушка, а как инструмент.

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

Вместо вывода

Раньше было удобно верить, что код всё объясняет сам.

Теперь это уже не так.

Код можно генерировать мгновенно.
Понимание — нет.

И если мы не перестанем считать код единственным источником истины, AI останется просто быстрым способом производить то, что мы всё равно не умеем объяснять до конца.

А значит, да — пока мы не решим этот разрыв, code generation будет не будущим разработки, а всего лишь дорогой игрушкой в руках корпораций.