Docs-as-Code 2.0: готовим документацию к эпохе ИИ в 2026

Дата публикации: 29 мая 2026 года.

Представьте: в прошлом году вы начали писать документацию на Docs-as-Code. Вы используете Git, Markdown, CI — всё по заветам YouTube-экспертов. Вдруг выясняется: в 2026 году этого мало. Появились ИИ-агенты, без которых сегодня никуда, вот только они не в состоянии прочитать ваши труды. Всё потому, что инструменты Docs-as-Code 1.0 создавали сайты для людей, а не для алгоритмов. И тут на сцене появляется Docs-as-Code 2.0. Он возводит спасительный мост между вашим текстом и большими языковыми моделями (LLM).

Откуда взялся Docs-as-Code 2.0?

Первая волна Docs-as-Code зародилась в середине 2010-х. Технологию распространили разработчики, уставшие от Wiki и MS Word. Они хотели писать документацию в Markdown, хранить ее рядом с кодом, версионировать через Git и собирать через CI.

К 2020 году такой подход стал стандартом для многих opensource-проектов и IT-компаний. Сайты на Docusaurus, MkDocs, Hugo — типичные плоды Docs-as-Code 1.0.

Однако в 2025–2026 годах произошли серьезные изменения. В повседневную практику вошли ИИ-ассистенты: разработчики внедряют GitHub Copilot, пользователи ищут ответы через ChatGPT, Claude, Perplexity, а техписатели пробуют автогенерацию документации через большие языковые модели.

И тут возникла проблема: традиционные сайты документации созданы для человека. Для нейросети это просто HTML или Markdown, в котором структура не отделена от представления: нейросеть не отличает текст инструкции от кнопок навигации, не понимает, где описание функциональности, где предупреждение, где пример кода.

Docs-as-Code 2.0 — это ответ на новый технологический вызов. К счастью, следующая версия технологии не отменяет Git и Markdown, а добавляет к ним машинно-читаемые слои: файлы llms.txt, схемы JSON-LD, MCP-серверы, метаописания для ИИ-агентов.

Статус и востребованность технологии в 2026 году

К началу 2026 года llms.txt стал неформальным стандартом. Спецификацию предложил в сентябре 2024 года Джереми Ховард и его команда из Answer.ai. Через год её поддержали почти все популярные генераторы статических сайтов: Docusaurus, MkDocs с плагинами, Hugo. А Mintlify поддерживает llms.txt и MCP-сервер из коробки.

Что это за файл? Это ваш_сайт.com/llms.txt, написанный в Markdown. Он играет роль карты: перечисляет ключевые разделы документации, кратко описывает их и подсказывает большим языковым моделям (LLM), с чего начать анализ. В чем-то он похож на файл robots.txt.

Как выглядит llms.txt на практике? Ниже — пример из документации Claude AI от компании Anthropic (доступен по адресу platform.claude.com/llms.txt). Файл написан в Markdown и перечисляет ключевые разделы, которые ИИ-агент может использовать для навигации.

# Anthropic Docs 
    

   / → Overview of the docs 
    

   /claude-api → Reference docs for the Messages API, model info, etc. 
    

   /claude-api/get-started → Build a Claude-powered app 
    

   /claude-api/rate-limits → Information on rate limits 
    

   /claude-api/migration-guide → Migrate from Text Completions API 
    

   /build-with-claude → Tutorials, guides, and examples 
    

   /legal → Legal and policy information

Такой файл помогает LLM сразу "увидеть" структуру документации и не блуждать по навигационным меню. Вы можете посмотреть этот пример вживую, перейдя по указанному адресу. Для больших проектов можно создать llms-full.txt — плоскую версию всех страниц подряд.

К сожалению, в открытом доступе на середину 2026 года нет крупных исследований от серьёзных аналитических агентств (Gartner, Forrester, W3Techs) по llms.txt. Поэтому лучше цифр не давать вовсе, чем ссылаться на сомнительные. По оценкам независимых наблюдателей, на май 2026 года доля популярных сайтов, поддерживающих llms.txt, выросла до нескольких процентов, что сопоставимо с ранними этапами внедрения robots.txt в 1990-х. В число ранних последователей входят Cloudflare, Microsoft (Azure, GitHub), Adobe, PayPal, Stripe, Slack, Zendesk и WordPress.org.

Примеры из индустрии:

• Vercel добавил автоматическую генерацию llms.txt для всех проектов. Обсуждение внедрения этой функции в Next.js доступно в официальном репозитории на GitHub (Discussion #81215). Теперь ИИ-агенты могут читать документацию Next.js в структурированном виде. Вся документация AI SDK от Vercel доступна в формате llms.txt по адресу ai-sdk.dev/llms.txt — это подтверждает официальная документация AI SDK.
• Mintlify генерирует llms.txt, llms-full.txt и MCP-сервер "из коробки".
• Anthropic (Claude) и OpenAI используют структурированные форматы данных для повышения точности RAG-ответов. Если документация сайта не структурирована для ИИ, качество падает, так как модели не могут эффективно извлекать нужную информацию из шумного HTML.

Хотя конкретная статистика о поиске ответов в технической документации (34% и 62%) в доступных отчетах не обнаружена, сам тренд активного использования ИИ разработчиками подтверждается индустрией. Опросы показывают, что всё больше инженеров обращаются к ChatGPT, Claude и GitHub Copilot для решения повседневных задач, и это повышает спрос на машиночитаемую документацию. Это делает структурирование контента для машинного чтения критически важной задачей для технических писателей.

Спрос на Docs-as-Code 2.0 растёт среди компаний, которые внедряют ИИ-ассистентов в поддержку, и среди проектов с большой документацией, которую потребляют через LLM.

Docs-as-Code 1.0 vs 2.0: что принципиально изменилось?

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

Ключевой сдвиг: документация перестаёт быть просто статичным сайтом. Она становится сырьём для ИИ. Теперь вы строите базу знаний, которую нейросети смогут использовать без искажений. О том, что это могут быть за искажения (галлюцинации) мы писали в статье "Как стать экспертом по нейросетям в 2026 году".

Почему Docs-as-Code 2.0 появляется именно сейчас?

В мае 2026 года вышло интервью Naval Ravikant (Наваля Равиканта) — известного инвестора и предпринимателя. Статья на русском называется "Apple труп, SaaS следующий" (перевод vc.ru). Главная мысль: классический SaaS доживает последние месяцы. Ему на смену идут компании из одного человека, которых ИИ превращает в команду из пятидесяти специалистов.

В этом леденящем душу айтишника предсказании — ключ к пониманию необходимости Docs-as-Code 2.0. Если компания становится крошечной, то и документацию не будут писать десятки техписов. Её будут создавать фаундеры-одиночки и малые команды. Но их проблема в другом: у них нет времени переписывать одно предупреждение в пяти руководствах. Им нужна документация, которая собирается автоматически и сразу готова для ИИ-агентов, которые будут её анализировать.

Обычный Docs-as-Code (Markdown + Git + генератор сайта) решает половину задачи — автоматизацию сборки. Но не решает вторую половину: как сделать документацию понятной для нейросетей. Если через год ИИ-агенты будут поддерживать пользователей вместо живых саппортов, то эти агенты должны уметь читать документацию без искажений. А для этого нужны llms.txt, структурированные метаданные и MCP-серверы — то есть Docs-as-Code 2.0.

Как агент использует llms.txt в реальном диалоге? Представьте, что пользователь спрашивает в чате поддержки: "Как настроить уведомления о наличии?". ИИ-агент, у которого есть доступ к вашему llms.txt, действует так:

1. Читает файл llms.txt и видит раздел /guides/notifications с описанием "Настройка уведомлений для склада".
2. Запрашивает этот раздел (через HTTP или MCP).
3. Извлекает точную инструкцию и возвращает её пользователю, при необходимости уточняя версию продукта.

Без llms.txt агент был бы вынужден скачать всю главную страницу, распарсить HTML, отфильтровать кнопки и баннеры — и всё равно мог пропустить нужный раздел. А с картой-llms.txt он находит ответ за долю секунды, без лишних вычислений.

Более продвинутые агенты (с MCP) могут сразу запросить: "Дай инструкцию по настройке уведомлений для версии 3.2" — и сервер вернёт только релевантный фрагмент.

Ravikant даёт индустрии 18 месяцев до перестройки. Для технических писателей это означает: переход на Docs-as-Code 2.0 — не хайп, а подготовка к новой реальности, где документацию будут потреблять в основном машины. И делать это придётся быстро, без огромных команд, с помощью ИИ-инструментов. Те, кто начнёт сейчас, получат фору. Однако не спешите перелопачивать свою справочную систему и переходить на новые рельсы, дочитайте статью до конца — возможно, следующий Docs-as-Code вам не подходит.

Гибридные подходы и инструменты

Переход на Docs-as-Code 2.0 не требует ломать нажитую непосильным трудом инфраструктуру. Вы можете оставить свой Docusaurus или MkDocs и добавить к нему генерацию llms.txt через плагины.

• Docusaurus → плагин docusaurus-plugin-llmstxt.
• MkDocs → плагин mkdocs-llmstxt.
• Hugo → модуль hugo-llms-txt.
• Mintlify — уже поддерживает "из коробки".

Гибридная схема: старый сайт для людей + отдельный /llms.txt и MCP-сервер для ИИ-агентов. Это работает уже сегодня и не заставляет отказываться от привычного стека.

Model Context Protocol — это способ для LLM получать доступ к документации через единый интерфейс, аналогично файловой системе или веб-API. Вместо того чтобы скачивать llms.txt и потом самостоятельно обходить ссылки, агент может через MCP-сервер сразу запросить нужный раздел, указать версию продукта или получить только изменения с определённой даты. MCP-сервер работает как прослойка: он понимает структуру вашей документации и отвечает на запросы LLM уже структурированными данными (JSON или Markdown). Это сокращает число вызовов и уменьшает риск галлюцинаций.

А что такое JSON-LD и зачем он нужен? Если llms.txt — это общая карта всей документации, то JSON-LD — это навигационные указатели на каждой отдельной странице. Это небольшой блок кода, который встраивается в HTML и на понятном машинам языке описывает содержимое страницы: к какому продукту она относится, какая у неё версия, кто автор, является ли она руководством или справочником API. Такой подход помогает ИИ-агентам мгновенно понимать контекст страницы, даже если они попали на неё напрямую из поисковой выдачи, а не через главный файл llms.txt. Вместе эти два инструмента создают полную картину: карта всего города (llms.txt) и указатели на каждом здании (JSON-LD).

Стоит ли "прыгать в поезд"?

Внедрение любой новой технологии похоже на выбор вагона: можно сесть в купе с повышенными удобствами, а можно в целях экномии выбрать тамбур. Docs-as-Code 2.0 не исключение. Он щедр на преимущества и жаден до ресурсов. Давайте посмотрим, кому стоит потратить бюджет на путешествие первым кассом, а кому пока достаточно и плацкарта.

Для кого это актуально в 2026:

• Компании, которые внедряют ИИ-чаты для поддержки (на базе их документации).
• Проекты с очень большим объёмом документации (более 1000 страниц).
• Техписатели и команды, которые разрабатывают документацию как продукт, а не как приложение.
• Open-source проекты, желающие, чтобы их документацию хорошо индексировали ИИ-поисковики (Perplexity, Phind).

Для кого не подходит:

• Небольшие проекты (до 50 страниц), где документацию пишет и поддерживает вручную один человек.
• Команды без ИИ-специалистов. Без понимания RAG, эмбеддингов и MCP вы получите файл llms.txt, который никто не использует. О том, что такое RAG и эмбеддинги мы писали в упомянутой выше статье.
• Задачи, где документация строго конфиденциальна, и вы не можете передавать её LLM (даже через локальную модель — это отдельная инфраструктура).

Внедрение Docs-as-Code 2.0 требует не столько технических знаний, сколько смены подхода: вы начинаете проектировать документацию как структурированный набор данных для разных потребителей. Для человека — удобный сайт. Для ИИ — машиночитаемые слои.

Скрытые сложности

Поиск и аналитика. Даже если вы сгенерируете llms.txt, не факт, что ИИ-агенты вашей компании сразу его используют. Нужно настроить RAG-пайплайн, добавить эмбеддинги, связать с вашими тикетами и чатами (ох уж эти англицизмы). Это работа не техписа, а ML-инженера.

Поддержка. Документация живёт, меняется. llms.txt и MCP-сервер тоже нужно обновлять. Если вы пишете сложные редиректы или размечаете версии, то рискуете получить рассинхронизацию между сайтом и ИИ-доступом.

Совокупная стоимость владения (TCO). Бесплатно вы получите только генерацию файлов. Платное — это интеграция с LLM, хостинг эмбеддингов, поддержка MCP, работа специалиста, который разбирается в этом. Для крупной компании расходы оправданы. Для стартапа — вряд ли.

Заключение

Docs-as-Code 2.0 — не маркетинговый шум. Это закономерный ответ на вторжение ИИ в нашу работу. Git и Markdown остаются. К ним добавляются llms.txt, JSON-LD, MCP-серверы.

Если вашу документацию уже сейчас пытаются читать нейросети (через Copilot или поиск), то переход на версию 2.0 — вопрос ближайшего года.

Если вы пишете мануалы для узкой группы профессионалов и не планируете внедрять ИИ-чаты, то можете спокойно оставаться на 1.0.

Главный признак, что пора задуматься: вы заметили, что пользователи всё чаще приходят с ответами, которые сгенерировал ChatGPT, но эти ответы неверны. Скорее всего, ИИ "споткнулся" о вашу вёрстку. Сделайте доброе дело, дайте ему понятную карту — llms.txt.

Итак, инструменты уже есть, примеры компаний — тоже. В 2026 году Docs-as-Code 2.0 — это выбор для тех, кто хочет, чтобы их документацию использовали не только люди, но и нейросети. Если верить мрачному прогнозу Наваля Равиканта, до часа X осталось каких-то полтора года. И время пошло.