Дьявол кроется в документации
«Да-да, продолжайте двигаться с черепашьей скоростью». — Миранда Пристли, «Дьявол носит Prada»
В фильме «Дьявол носит Prada» есть ещё одна сцена, о которой я думаю чаще, чем об этой. Если вы его ещё не видели, постараюсь обойтись без спойлеров. Миранда поворачивается к Энди (своей ассистентке) и с нескрываемым нетерпением объясняет, что небесно-голубой цвет её «мешковатого свитера» взялся не из ниоткуда — за ним стоит цепочка осознанных решений в мире моды, принятых за несколько лет до этого людьми, которые тщательно обдумывали каждый выбор. Свитер, который Энди купила в магазине, стал конечным результатом долгой цепочки осознанного отбора, тщательно скрытой ради иллюзии, будто он появился сам собой.
Именно так я бы описала документацию, особенно в эпоху ИИ. Пользователь — разработчик, аналитик, инженер данных или технический писатель 😜 — задаёт вопрос ИИ-инструменту и получает ответ. Ему необязательно видеть каждое решение в стоящей за ним цепочке: что включить, как выстроить структуру, где есть пробелы, что нужно обновить. Но эти решения формируют каждый получаемый им ответ. Где-то в начале этой цепочки команда документации делает тщательно продуманный, осознанный выбор, последствия которого доходят до самого момента, когда ответ появляется в редакторе пользователя.
В этой статье мы расскажем, как команды документации стараются приблизить эти решения к пользователям — и почему в эпоху ИИ такая архитектура важна как никогда.
Начните с руководства по быстрому старту с dbt MCP или загляните в справочник инструментов для документации продукта, если вы уже подключились.