ИИ научился писать документацию. Что теперь делать техническому писателю?

Главная проблема: текст перестал быть дефицитом

Три года назад разговор об ИИ в технической документации обычно начинался с вопроса: «Сможет ли модель написать инструкцию не хуже человека?» В 2026 году этот вопрос уже почти неинтересен. Да, сможет. При нормальном входном материале модель быстро пишет справочные статьи, черновики руководств, release notes, API-примеры, FAQ, описания параметров и варианты формулировок.

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

Именно поэтому ИИ одновременно создаёт ощущение, что технический писатель больше не нужен, и делает качественную документацию сложнее. Сгенерировать сто страниц стало проще. Гарантировать, что этим ста страницам можно доверять, не стало проще вообще.

Что на самом деле изменилось за три года

С конца 2022 года модели прошли путь от любопытного генератора абзацев до рабочего инструмента, который можно встроить в документационный конвейер. Они умеют:

• превращать структурированные исходные данные в связный черновик;
• переписывать материал под другую аудиторию и уровень подготовки;
• приводить терминологию и стиль к заданным правилам;
• извлекать изменения из diff, issue или release description;
• генерировать варианты примеров и тестовых сценариев;
• переводить и локализовать большие объёмы текста;
• классифицировать и связывать существующие материалы;
• искать противоречия, пропуски и подозрительные места, если дать им достаточно контекста.

Это не небольшое ускорение набора текста. Это изменение экономики производства документации. Работа, на которую раньше уходили часы, иногда превращается в несколько минут подготовки входных данных и несколько минут ревью.

Поэтому исчезает привычное оправдание: «У нас нет времени написать документацию». Времени на написание действительно требуется всё меньше. Но остаются сбор фактов, принятие решений, проверка и сопровождение.

Я уже вижу компании, которые решили вопрос радикально

Я лично знаю уже несколько компаний, которые полностью отказались от технических писателей. Это не статистическое исследование и не доказательство того, что вся профессия исчезает. Но это важный сигнал: сценарий, который ещё недавно выглядел теоретическим, уже экономически возможен.

Обычно логика простая. Разработчик или product manager даёт модели исходные данные, ИИ делает текст, кто-то быстро просматривает результат — и материал публикуется. Если документация небольшая, продукт относительно простой, а цена ошибки невысока, такая схема может некоторое время работать вполне убедительно.

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

Поэтому вопрос для профессии теперь звучит жёстче: не «может ли ИИ заменить человека, который пишет абзацы?», а «есть ли у компании работа, для которой нужен специалист по документации, кроме написания абзацев?»

Если такой работы нет — часть вакансий действительно исчезнет.

Какие задачи автоматизируются первыми

Чем более механическая и проверяемая задача, тем легче передать её модели или генератору.

Задача	Насколько легко автоматизировать	Что всё равно нужно проверить
Первый черновик по спецификации	Высоко	Полнота входных данных и факты
Описание параметров API	Высоко	Семантика, ограничения, реальные примеры
Release notes по списку изменений	Высоко	Что действительно важно пользователю
Перевод и локализация	Высоко	Терминология, культурный контекст, интерфейс
Переписывание под style guide	Высоко	Смысл и техническая точность
FAQ по известным обращениям	Средне/высоко	Актуальность решений и безопасность советов
Архитектура большой документации	Средне	Модель задач пользователей и связи материалов
Определение реального поведения продукта	Низко	Нужен источник истины и эксперт
Решение, что вообще нужно документировать	Низко	Продуктовый контекст и приоритеты
Ответственность за опубликованный факт	Не автоматизируется	Нужен владелец решения

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

Как теперь выглядит документационный процесс

Старая схема часто была линейной: эксперт рассказал — технический писатель написал — эксперт проверил — опубликовали.

Сегодня рабочая схема становится похожа на инженерный конвейер:

Ключевой сдвиг здесь в том, что ИИ не стоит в конце как «автор». Он стоит внутри процесса между источниками и ответственным человеком.

Кто теперь за что отвечает

Самая опасная ошибка — написать в регламенте «текст проверяется ИИ». Модель может найти противоречие, но она не становится владельцем факта. Нужна явная граница ответственности.

Этап	ИИ	Технический писатель	Эксперт / команда продукта
Сбор исходных данных	Классифицирует, суммирует	Определяет, чего не хватает	Предоставляет источник истины
Структура	Предлагает варианты	Выбирает архитектуру и сценарий	Подтверждает продуктовые ограничения
Черновик	Генерирует	Задаёт правила и редактирует	Отвечает на неоднозначности
Примеры	Предлагает	Проверяет понятность и полноту	Проверяет или запускает технически
Факты	Ищет подозрительные утверждения	Связывает утверждение с источником	Подтверждает поведение продукта
Стиль	Проверяет автоматически	Принимает редакционные решения	Обычно не участвует
Публикация	Не принимает решение	Контролирует готовность	Утверждает критичные изменения
Актуализация	Находит кандидатов на устаревание	Управляет очередью обновлений	Подтверждает изменение продукта

Если эта таблица в вашей команде не заполняется конкретными ролями, значит ответственность просто размазана.

Как я бы строил работу технического писателя сейчас

1. Начинать не с промпта, а с источников

Перед генерацией должен появиться пакет фактов. Для API это может быть OpenAPI, реальные request/response, тестовые данные, список ошибок и ограничения авторизации. Для UI — acceptance criteria, актуальный интерфейс, сценарии и подтверждённые состояния. Для железа — спецификация, результаты испытаний и требования безопасности.

Плохой вход нельзя исправить хорошим промптом. Модель просто оформит неопределённость убедительнее.

2. Просить ИИ сначала разобрать материал

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

Так ИИ используется как аналитический слой, а не как автоматическая пишущая машинка.

3. Генерировать небольшими проверяемыми единицами

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

Чем меньше единица генерации, тем проще увидеть ошибку и источник изменения.

4. Ревьюить не красоту текста, а доказательства

Для каждого важного утверждения должно быть понятно, откуда оно взялось. В идеале ревьюер видит не только новый абзац, но и связанный diff, ticket, spec или тест.

Гладкий язык больше не является признаком качества. Модель одинаково уверенно может написать правильное и неправильное предложение.

5. Автоматизировать то, что проверяется детерминированно

Ссылки, сборка, терминология, обязательные разделы, структура metadata, форматы примеров, lint, дублирование, орфография, соответствие схемам — всё это должно уходить в автоматические проверки. Человека не надо тратить на то, что машина может проверить без предположений.

6. Оставлять человеку решения с ценой ошибки

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

Ревью теперь должно быть трёхслойным

Один человек, который «прочитал текст и вроде всё нормально», — слабая модель контроля.

ИИ можно использовать во всех трёх слоях как помощника, но он не должен подменять владельца слоя.

Почему «ИИ проверил ИИ» — не проверка фактов

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

Надёжная проверка выглядит так:

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

Что делать компании, которая уже убрала технических писателей

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

Минимальный набор:

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

Если никто этого не делает, компания не «автоматизировала технических писателей». Она просто отказалась от управления документацией.

Новая роль технического писателя

Я не думаю, что полезно спасать профессию аргументом «человек всё равно пишет красивее». Иногда пишет. Иногда модель пишет лучше. Это слишком слабая граница.

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

• проектирует структуру знаний;
• определяет источники истины;
• превращает изменения продукта в управляемый documentation backlog;
• строит правила генерации и ревью;
• проектирует автоматические проверки;
• проверяет примеры и сценарии;
• управляет терминологией и переиспользованием;
• связывает документацию с support, product, engineering и feedback;
• решает, когда страницу нужно обновить, объединить или удалить;
• отвечает не за количество написанных слов, а за надёжность опубликованной информации.

Название должности может остаться Technical Writer. Может появиться Documentation Engineer, Content Engineer, Knowledge Engineer или Docs Lead. Название менее важно, чем то, где находится ответственность.

Какие навыки теперь действительно дорожают

Понимание продукта

Чем легче написать текст, тем ценнее человек, который быстро понимает систему, задаёт правильные вопросы и замечает недокументированные состояния.

Информационная архитектура

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

API, данные и автоматизация

Структурированные источники — лучший материал для автоматизации. Писатель, который понимает API, схемы, Git, CI и автоматические проверки, может управлять конвейером, а не конкурировать с ним скоростью печати.

Редакторское решение

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

Проверка фактов

Это становится отдельной инженерной дисциплиной: происхождение утверждения, версия источника, тестируемость примера, traceability изменения.

Что измерять вместо количества страниц

Если ИИ увеличивает output в десять раз, количество опубликованных страниц становится ещё более бесполезной метрикой.

Смотрите на другое:

• сколько пользовательских задач закрыто без обращения в поддержку;
• сколько критичных примеров автоматически проверяется;
• сколько страниц имеют известного владельца;
• сколько материалов просрочено по review date;
• сколько ошибок нашли до публикации, а не пользователи;
• насколько быстро изменение продукта доходит до документации;
• какие страницы не используются и могут быть удалены;
• сколько утверждений можно связать с актуальным источником.

Как могла бы выглядеть небольшая команда в 2026 году

Для продукта, где раньше было несколько авторов, я бы скорее строил компактную систему вокруг сильного документационного специалиста, чем пытался сохранить старую фабрику ручного текста:

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

Что делать самому техническому писателю

Если ваша основная ценность сегодня — «мне дают задачу, и я хорошо пишу текст», риск действительно высокий. Не через десять лет, а уже сейчас.

Практический план гораздо конкретнее, чем «учите ИИ»:

1. Научитесь получать факты из продукта, а не только из интервью.
2. Освойте API, Git и хотя бы базовую автоматизацию.
3. Научитесь проектировать структуру большой документации.
4. Стройте процесс review и quality gates.
5. Используйте ИИ ежедневно и фиксируйте, где он ошибается.
6. Учитесь проверять происхождение утверждений.
7. Берите ответственность за результат пользователя, а не за текст как таковой.

Вывод: ИИ отменил не технического писателя, а монополию на производство текста

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

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

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

Главная задача теперь не написать быстрее ИИ. Это невозможно и не нужно. Главная задача — построить систему, в которой ИИ может писать быстро, а ошибка не может так же быстро попасть к пользователю.

Связанные материалы

• Как проверять документацию, написанную с ИИ, до публикации убедительных ошибок
• Используйте ИИ как редактора, а не как оракула
• Ограничители для LLM-конвейера, который публикует техническую документацию
• Документация в CI/CD: где автоматические проверки действительно помогают