Документация пишется после кода, а после кода всегда есть следующий код. Поэтому README устаревает на два релиза, описание API живёт в голове бэкендера, а ТЗ для заказчика — в переписке. Нейросеть меняет порядок: она читает код и собирает из него документ — README по разделам, эндпоинты с примерами из роутеров и схем, докстринги, таблицу переменных окружения, ТЗ на доработку с критериями приёмки, changelog из коммитов. Человеку остаётся то, чего в коде нет: актуальность, обещания заказчику и проверка быстрого старта на чистой машине. Работает из России без VPN, документы можно забрать в .md и .docx.
Код — лучший источник документации
Роутеры содержат эндпоинты, схемы — параметры и ответы, settings — настройки, обработчики — коды ошибок, TODO — известные ограничения. Это и есть документация, только разбросанная по файлам. Модель собирает её в один документ за минуты, и он точнее написанного по памяти, потому что взят из того, что реально выполняется.
Читатель определяет документ
README для разработчика начинается с трёх команд запуска; описание API для фронтенда — с примеров запросов; ТЗ для заказчика — с цели и границ, без слова «эндпоинт». Один и тот же код даёт три разных документа, и разница — в одной фразе запроса о том, кто будет читать.
Список несогласованностей — побочный продукт, который стоит дороже документа
Собирая README, модель замечает настройку, которую никто не читает, роут с другим форматом ошибки, функцию без вызовов. Попросите вынести это отдельно — получите список для чистки перед релизом, который иначе никто бы не составил.
ТЗ на доработку — документ, который экономит споры
«Сделать, чтобы заявки падали в CRM» — это не задача, а пожелание. ТЗ превращает его в границы, поля, сценарии с ошибками, критерии приёмки и список того, что не входит. Написанное от существующего кода, оно содержит реальные вопросы заказчику — доступы, дубли, ответственность за вторую систему — и их лучше задать до старта, чем после.
Где модель опасна
В актуальности и обещаниях. Мёртвый код попадёт в документ как живой — пройдите по таблицам и уберите. Быстрый старт проверяется на чистой машине, а не чтением. Сроки, объём и «не входит» в ТЗ — решения, которые подписываете вы; модель их формулирует, а не принимает. Всё остальное — структура, извлечение из кода, примеры, язык под читателя — она делает стабильно.
