В защиту непонимания кодовой базы

Sean Goedecke (см. sean-goedecke-blog) делит инженеров на два лагеря в зависимости от типа кодовой базы. В небольших проектах с низкой текучкой в команде - Redis, игра вроде The Witness - проект можно целиком держать в голове. Люди оттуда обычно утверждают, что полное понимание обязательно. В огромных кодовых базах с высокой текучкой - поиск Google, GitHub - никто не удерживает систему целиком. Разработчики там смирились с тем, что работать приходится локально и с неполной картиной. Первый лагерь формирует большую часть инженерного дискурса в сети, поэтому его планку воспринимают как общепринятый стандарт. Goedecke защищает второй лагерь: частичное понимание - это не провал, а наилучшее доступное состояние в крупной системе.

Его главная мишень - статья Питера Наура Programming as Theory Building. Goedecke согласен с основным тезисом Наура: главный продукт инженера - это ментальная теория программы, а код - лишь побочный результат этой теории, зафиксированный с потерями. Но с практическими выводами Наура он спорит. Наур утверждал, что теорию нельзя восстановить только по коду и документации, поэтому команда, потерявшая понимание, должна выбросить программу и переписать её с нуля, а не пытаться реанимировать. Goedecke считает этот совет абсолютно неверным для крупных систем по двум причинам. Во-первых, большую систему невозможно переписать с нуля: она хранит тысячи нюансов и краевых случаев, которые никто не сможет восстановить по памяти. Реальные переписывания идут через распил существующей системы на куски и их постепенную замену, что само по себе требует длинной череды правок старого кода. Во-вторых, заброшенные кодовые базы оживляют постоянно. Он сам неоднократно брал чужие заброшенные системы, разбирался в одном сквозном сценарии и отталкивался от него, пока не начинал безопасно вносить правки. Восстановить теорию по коду долго, но возможно - вопреки утверждению Наура.

Самая резкая мысль Goedecke: в достаточно большой кодовой базе у каждого ментальная теория программы ошибочна. Ждать человека с исчерпывающим знанием бессмысленно - такого человека не существует. Приходится строить наиболее обоснованное предположение, действовать на его основе и отвечать за последствия. Он также выдвигает аргумент о масштабе: в 1985 году "большая программа" насчитывала сотни тысяч строк - достаточно мало, чтобы переписать её с нуля и прогнать старые тесты. GCC вырос со ста тысяч строк в 1987 году до четырнадцати миллионов к 2015-му. Совет о "построении теории", возможно, просто устарел из-за изменившихся масштабов.

Общая рамка такова: поддержание теории кодовой базы - лишь одна из инженерных ценностей, а не святыня. Полноту ментальной модели постоянно разрушают обыденные вещи: чужие коммиты в тот же код, обязательные задачи по доступности или защите данных, переходы коллег в другие команды, обновления безопасности, новые зависимости. И ничто из этого не считается ошибкой. Теорию программы разменивают на скорость, соответствие закону или политику компании ровно так же, как ради дедлайна выпускают заведомо медленный код. Инженеры-"пуристы" предпочитают полную ментальную модель, потому что так приятнее и это больше похоже на "настоящую разработку". Goedecke считает это отличным поводом завести небольшой пет-проект, но на работе вам платят за разделение ценностей работодателя, и абсолютное понимание кода в этом списке далеко не всегда на первом месте.

При чём здесь LLM

LLM появляются лишь в одном абзаце ближе к концу, почти мимоходом - и всё же именно из-за них статья звучит актуально для эпохи агентов. Распространённая претензия к LLM состоит в том, что они мешают выстраиванию ментальной теории. Goedecke считает это упрощением: это палка о двух концах. Инструмент действительно усложняет формирование глубокой ментальной модели, но позволяет быстро собрать рабочую частичную теорию и начать действовать. Сам он всё ещё оценивает этот баланс. Показательно, что он отказался ставить тег AI этому посту в своём блоге и был раздосадован тем, что на Lobsters посту присвоили тег vibecoding на основании единственного абзаца - за этот момент сразу зацепились комментаторы (см. ниже). Это вполне укладывается в его подход к текстам об LLM (например, steering-vectors-interesting-again), где фокус направлен на конкретные механизмы, а не на общий шум вокруг ИИ.

Аргумент Goedecke находится в продуктивном противоречии со скептицизмом, собранным на других страницах этой базы. skill-atrophy-supervision-paradox и agentic-coding-is-a-trap предупреждают: активное использование агентов атрофирует навыки чтения кода и критического мышления, необходимые для контроля над ними, так что привычка опираться на частичное понимание ведёт к деградации. На самом деле Goedecke этому не противоречит. Его тезис дескриптивен - частичное понимание на масштабе неизбежно. Опасения же насчёт атрофии навыков касаются вектора развития: частичное понимание, выстроенное через вдумчивый анализ системы, отличается от частичного понимания, принятого из-за того, что агент сгенерировал код, который вы даже не читали. Его собственные примеры реанимации проектов противоречат слепому делегированию: он изучает заброшенную кодовую базу, прослеживая один сценарий от начала до конца, прежде чем что-то менять, - это именно то осознанное развитие навыков, за которое ратуют критики. Честный синтез звучит так: "не нужно понимать всё" и "нужно понимать достаточно, чтобы рассуждать локально и ловить ошибки агента" - оба тезиса верны, а главный вопрос в том, где проходит нижняя граница. clean-code-coding-agents развивает смежную мысль: структура кода с приходом агентов становится важнее, а не наоборот, потому что частичная теория работает лишь тогда, когда код позволяет рассуждать локально. 1password-agentic-refactoring даёт наглядный пример: устойчивый выигрыш был достигнут за счёт детерминированных инструментов анализа, написанных агентами, и поэтапной декомпозиции, а не за счёт генерации кода, который никто не понимает (тот самый метод распила, который Goedecke описывает для переписываний). writing-code-vs-building-software занимает противоположную позицию, определяя ответственность через полное понимание и валидацию каждой части и запрещая выпускать что-либо меньшее, хотя там критика направлена на непрочитанный сгенерированный код, а не на систему, логику которой инженер уже отследил.

Интересное из обсуждения

В ветке на Lobsters аргументацию рассмотрели с нескольких сторон.

В топовом комментарии (typesanitizer) замечено, что заголовок чересчур вызывающий для довольно умеренной мысли: "в больших кодовых базах нужно уметь двигаться вперёд с частичным пониманием". Построение теории не противоречит этому подходу, если разделить широту теории (о скольких частях системы вы можете ответить на вопросы) и её глубину (насколько сложное изменение вы можете внести в одну часть без потери корректности). Переписывание модуля - это выстраивание узкой, но глубокой теории этого модуля. Автор комментария также отметил: Наур исходит из того, что "поставленная задача" всё ещё существует в виде спецификации, тогда как в реальных больших системах ближе всего к ней подобрался разве что набор тестов. Кроме того, continuous delivery и дежурства с пейджером на живых сервисах меняют логику переписывания кода так, как в 1985 году никто и представить не мог.

mcherm связал публикацию с локальным рассуждением (local reasoning) - способностью менять одну часть, не понимая систему целиком. По его мнению, computer science стремилась к этому с самого начала: структурное программирование, отказ от глобальных переменных, устранение побочных эффектов в функциональном программировании и ООП появились во многом ради локального рассуждения. Это превращает тезис Goedecke в старую истину, переодетую в контекст эпохи агентов: частичное понимание работает потому, что десятилетия развития языков были направлены именно на это.

jmillikin добавил аргумент о мобильности инженеров: даже эксперта по кодовой базе на 300 000 строк на следующей неделе могут перебросить на другую систему такого же размера. В таких условиях выживают за счёт общих идиом, инструментов, которые громко падают при неверном вызове API, и интуиции относительно структуры крупных программ - и нет смысла удерживать в голове понимание систем, из которых ты ушёл. Он провёл полезную границу между экспертными знаниями (как работает парсер, как написать его без уязвимостей) и тривиальными фактами (в каком именно файле лежит build_huffman_tables()). mxey возразил: это принижает ценность специализированного опыта, а главная проблема с LLM - не в том, держит ли один человек всю систему в голове, а в том, написан ли код так, чтобы человек вообще мог с ним работать (когда тысячи непроверенных AI-коммитов становятся катастрофой).

andyc согласился с аргументом, но предостерёг от нигилизма: частичное понимание неизбежно на масштабе, но организациям всё равно нужно стремиться к большему пониманию. Позиция "мне платят за работу" не должна прикрывать деградацию продукта из-за монопольного положения (в качестве примеров систем, страдающих от накопленной сложности, были названы Windows и macOS). alurm возразил: принцип "всегда стремись к большему пониманию" легко превращается в инструмент саботажа, когда релизы блокируются, потому что планка "достаточно хорошо" объявляется неприемлемой. coxley описал эксплуатационную сторону проблемы: разрыв между предполагаемой и реальной теорией растёт сам по себе по мере роста кодовой базы. Типичная цена этого - "ложные эксперименты": команда пробует X, получает сбой, потому что система ещё не была готова к X, и делает неверный вывод, что X в принципе не работает.

Большая ветка обсуждения ушла в чистое мета: уместен ли тег vibecoding для поста, где LLM упоминаются всего один раз. Реплика simonw о том, что этот тег воспринимается скорее как предупреждение о триггере, чем как тематическая метка, набрала больше всего голосов, что наглядно показывает текущее отношение аудитории Lobsters к материалам об LLM.