Ваш код знает о вашем бизнесе больше, чем вы думаете

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

Недавно исследовательская группа ServiceMatch выдвинула провокационную идею. Они утверждают, что зрелые программные системы — это не просто инструменты для ведения бизнеса. Это исполняемые носители всего, что организация узнала о своём деле за годы работы. Сложность в том, что эти знания скрывались у всех на виду, запертые в репозиториях, которые исторически читали только компиляторы и изредка — люди.

Миф о документации

Ситуация знакома каждому. Приходит новый разработчик в команду, и ему выдают стену страниц в Confluence, записи архитектурных решений и содержимое Wiki. «Это поможет тебе быстро влиться», — говорит кто-то с оптимизмом, которому сложно поверить.

Не поможет.

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

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

Но здесь начинается самое интересное.

ИИ меняет уравнение читателя

Аргумент Наура описывал два типа читателей: компиляторы, которые исполняют код без понимания, и люди, которые понимают медленно и дорого. Предполагалось, что другого вида читателей не существует.

Большие языковые модели — это третий тип читателя. И они удивительно хорошо реконструируют неявные теории, встроенные в код.

Система ServiceMatch предоставляет убедительные доказательства. Их CMDB-платформа кодирует знания об управлении конфигурациями предприятия, которые заняли бы целые тома, если бы были записаны прозой. Но загвоздка в том, что они уже записаны — просто не прозой, а кодом.

Возьмём их логику разрешения идентичности устройств. Вместо эссе консультанта о том, «как работает идентификация устройств», у них есть конфигурационный файл с весами: серийный номер (25), имя хоста (25), инвентарный номер (25), IP-адрес (20), MAC-адрес (15). Плюс пороги уверенности и правила разрешения конфликтов. Каждая цифра — это аргумент, который кто-то выиграл. Каждый тип конфликта — реальный инцидент, произошедший где-то в продакшене.

Это не описание политики. Это САМА политика, исполняемая каждую ночь против реальных корпоративных активов.

Что это значит для вашей команды

Для разработчиков и технических лидеров это исследование имеет практические следствия:

Ваш код — это документация, которую вы не поддерживали, и у этого есть свои преимущества. В отличие от устаревших wiki-страниц, код, работающий в продакшене, постоянно проверяется на реальных данных. Если документация противоречит коду — неправа документация.

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

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

Предупреждающий знак

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

Команда ServiceMatch обнаружила, что их тезис — «репозиторий достаточен» — перестаёт работать в предсказуемых случаях. Остаток Наура реален. Какие-то знания действительно живут только в головах людей.

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

Что с этим делать

Если вы стартап или растущая технологическая компания, вот фреймворк для осмысления:

1. Доверяйте коду больше, чем документам, когда они расходятся
2. Пишите код, который документирует свою логику — осмысленные имена переменных, понятные функции, комментарии, объясняющие ПОЧЕМУ, а не ЧТО
3. Относитесь к конфигурации как к институциональному знанию — эти веса и пороги являются решениями, которые стоит сохранять
4. Начните изучать AI-инструменты, способные опрашивать вашу кодовую базу как источник знаний

Код, который вы пишете сегодня, — это завтрашнее институциональное знание. Сделайте так, чтобы оно того стоило.