Кто теперь пишет ТЗ? Документация, которую читает машина
Раньше системный аналитик сидел между бизнесом и разработкой, перекладывая требования на язык use cases и user stories. В 2026 году к этому дуэту добавился третий участник — LLM. И тут выяснилось: нейросеть не переваривает размытые формулировки. Она хочет точных спецификаций, формальных схем и однозначных правил. Родился Spec-Driven Development (SDD) — подход, при котором документация пишется не для людей, а для машинного обучения.
Суть SDD: вы создаёте детализированную спецификацию (на JSON, YAML или в виде структурированного текста), которая становится единственным источником правды для LLM. Никаких лишних слов, одна грамматика.
Звучит как возвращение к водопаду? Наоборот — это эволюция. Аналитик больше не тратит недели на согласование ambiguous-фраз. Он проектирует контекст для LLM: описывает бизнес-правила, форматы данных, граничные случаи. Всё, что раньше уходило в «понимание на лету», теперь зашивается в machine-readable spec.
От UML-диаграмм к spec-файлам: что реально изменилось?
Главный сдвиг — объект документации. Вместо того чтобы описывать «система должна делать X» для человека, вы описываете «вход — выход — контекст — исключения» для LLM. Это требует совершенно другого мышления. Аналитик превращается в инженера промптов: он знает, как LLM интерпретирует неоднозначности, где срезает углы, какие формулировки провоцируют галлюцинации.
На практике это выглядит так. Проект по автоматизации анализа договорных рисков: раньше аналитик писал 50-страничный документ с таблицами рисков. Теперь он создаёт spec на YAML, где каждое правило привязано к конкретному типу clauses. LLM берет эту спецификацию и применяет её к тексту. Результат — не просто анализ, а документ, который уже прошёл валидацию по spec. Статья Автоматизация анализа договорных рисков на LLM показывает, как подобный подход ускоряет работу юристов в разы.
Но есть подвох: SDD требует от аналитика понимания, как работает context window и токенизация. Если spec слишком длинный, он просто не влезет в окно контекста. Да, модели 2026 года имеют уже десятки тысяч токенов, но для сложных систем всё равно приходится резать контекст.
Три кита SDD: структура, детерминизм, итеративность
Чтобы spec работал как надо, он должен удовлетворять трём требованиям. Во-первых, строгая структура: JSON schema, OpenAPI или собственный DSL. Никакого «свободного текста» — только поля, типы, обязательность. Во-вторых, детерминизм: одна и та же спецификация должна давать одинаковое поведение LLM на одном и том же входе. Это ломает стереотип о «креативности» нейросетей. В-третьих, итеративность: spec живёт, его правят по результатам тестов. Без обратной связи от LLM spec мертв.
На этом этапе анализатору приходится работать с тестами — ровно о том, как тестировать недетерминированные модели, рассказывает статья Тестируем недетерминированные LLM: как написать тесты для вызова функций и не сойти с ума. Без этого spec просто повиснет: вы не узнаете, выполняет ли LLM требования.
Кто такой аналитик 2026? Архитектор AI-взаимодействия
В классическом понимании системный аналитик собирает требования, пишет ТЗ и передаёт разработчикам. В SDD он создаёт спецификации для LLM, потом тестирует их, уточняет, и снова тестирует. Это больше похоже на DevOps-цикл, чем на каскад. Аналитик теперь отвечает за то, как LLM поймет бизнес-логику.
В итоге роль смещается: от «переводчика с бизнес-языка на технический» к «архитектору контекста». Аналитик проектирует не алгоритм, а пространство, в котором LLM принимает решения. Это требует понимания контекстной инженерии — как собрать релевантный контекст, отсечь шум и не потерять важное в окне токенов.
Проблемы, которые никто не хочет обсуждать
Во-первых, поддержка версий spec. Если вы обновили spec, LLM может «вспомнить» старую версию из контекста — и начать галлюцинировать. Тут выручает протокол SDX-S, который диагностирует дрейф контекста.
Во-вторых, переобучение. Когда spec становится слишком конкретным, LLM может выучить его наизусть и перестать обобщать. Нужен баланс между формальной точностью и способностью модели адаптироваться к новым данным. И тут уже без метрик, как в Lexometrica Ground Truth, не обойтись.
В-третьих, культура. Разработчики привыкли к agile-манифесту, где «working software over comprehensive documentation». А тут вдруг documentation становится главной частью софта, от которой зависит работа LLM. Это культурный шок, особенно в стартапах. Но индустрия, судя по всему, готова платить за predictable output, а не за креатив.
Прогноз: аналитик без SDD — как таксист без навигатора
К концу 2026 года spec-driven подход станет стандартом для любого AI-продукта. Те, кто не перестроится, останутся с «ручным» тестированием каждой гипотезы, в то время как SDD-аналитик будет просто обновлять два файла и запускать пайплайн. Это не футуризм — это новая реальность, в которой системный аналитик становится главным инженером по работе с LLM.
Совет? Не ждите, пока ваша компания придумает стандарты. Начните с простого: возьмите один процесс, опишите его в структурированном JSON, скормите LLM, и посмотрите, насколько точным будет вывод. Удивитесь, как быстро бизнес оценит предсказуемость.
