От документации к исполняемому контексту

Несколько дней назад я размышлял об артефактах агентов и сжатии контекста. Разговор быстро перешел к синтаксису. Если агенты начнут использовать более структурированные артефакты, получим ли мы гигантские YAML-файлы, которые никто не хочет читать? Изобретем ли заново языки программирования? Превратится ли работа со знаниями в еще одну разновидность конфигурационного ада?

Это справедливые опасения, но за ними скрывается более глубокий вопрос: кто должен читать эти артефакты?

Десятилетиями документация объясняла системы людям. Требования, спецификации, wiki-страницы, вводные материалы, дизайн-документы, записи решений и истории проектов решали одну проблему: сохраняли смысл, чтобы люди понимали происходящее. Слабость в том, что документация обычно существует вне исполнения.

Система продолжает работать, даже если документ ошибочен. Команда выпускает код, пока wiki устаревает. Продукт меняется, а спецификация остается в прошлом. Большинство команд игнорируют документацию не из-за ненависти к чтению. Они игнорируют ее, потому что у документации часто нет прямой связи с реальностью. Если документ неверен, ничего обязательно не ломается.

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

Это меняет и вопрос читаемости. Сегодня мы считаем, что артефакты знаний нужно оптимизировать для людей, потому что люди являются основными читателями. Но если главными потребителями части артефактов станут агенты, критерии могут измениться. Форму хранения придется оптимизировать под структуру, связи, ограничения, плотность и исполнение, а не под красоту, прозу или традиционную читаемость.

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

В программном обеспечении мы давно это принимаем. Большинство людей не читают машинный код. Многие не читают схемы баз данных напрямую. Разные пользователи видят разные интерфейсы, дашборды, отчеты и объяснения, созданные из базовых структур. Агентные системы могут направить работу со знаниями по тому же пути.

Интересный вопрос уже не в том, будут ли будущие артефакты выглядеть как Markdown, YAML, JSON, диаграммы или DSL. Вопрос в том, останутся ли они пассивной документацией.

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

Это меняет роль документации. Документ, объясняющий систему, можно проигнорировать. Исполняемый контекст нельзя игнорировать таким же образом, потому что он участвует в системе и влияет на поведение.

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

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

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