❝ — Значит, Ричард написал код?
— Ричард написал, но источник вдохновения очевиден. ❞© Кремниевая долина
Я работаю более 6 лет системным аналитиком и порядка трёх лет на продуктах по внедрению LLM в бизнес. И меня категорически не устраивает AI-зрелость большинства моих коллег в этих ИИ-проектах!
Есть мысль, что часть проблемы в отсутствии у системных аналитиков общепризнанного подхода к AI‑усилению, подобного тому, что уже сформировался у разработчиков. Но при этом я часто встречаю в вакансиях требования «опыт написания документации AI‑native», «AI‑центричная аналитика». И я согласен с таким запросом рынка — давайте уже подстраивать пайплайн под эксперта! А эксперты в процессе написания кода — это наш разработчик + AI. Очевидным и логичным решением будет писать аналитику сразу в текстовом формате, постепенно уходя от Miro и Draw.io.
Первое время я даже считал, что придумал новый фреймворк, и даже придумал ему красивое название — Analysis‑as‑Code, но оказалось, что существует Spec‑Driven Development — подход, в котором «спецификация» становится центральным документом, а ИИ использует её в реализации задачи.
В этой статье я хочу разобрать Spec‑Driven Development (SDD) с оглядкой на роль системных аналитиков в России и СНГ и понять, как их меняется их роль при таком подходе.
Что такое Spec‑Driven Development и какие я в этом вижу плюсы
Spec‑Driven Development (SDD) — это подход, при котором спецификация предметной области выступает первичным источником истины, описывается md файлах, а код порождаются из неё, в том числе с помощью LLM и агентов. Подробнее уже писали на Habr тут и тут.
SDD даёт несколько практических преимуществ:
1. Спецификация снижает семантический дрейф LLM: модель получает чётко сформулированную и конечную цель.
2. Изменение бизнес‑требований через вайбкодинг происходит менее травматично для связки разработчик — аналитик. Agile, agile, agile! We’re pivoting.
3. Текстовые артефакты проще хранить в Git и проверять через diff и в следствии этого изменения видны на уровне строк, а не «где‑то на схеме».
4. Архитектура и требования жёстко фиксируются в спецификации совсем рядом с кодом, разработчику не нужно переключаться между IDE и корпоративной WIKI.
5. Обновление документации для разработчика по результатам работы над задачей происходит одной командой агенту.
Минусы SDD
Во-первых, важно не впадать в догматизм и не отказываться от Miro, draw.io, Figma и прочего, например когда команда ищет форму решения, обсуждает варианты и быстро рисует гипотезы. Для воркшопа, discovery‑сессии или грубой продуктовой схемы визуальный формат часто быстрее и удобнее. Но как только решение начинает стабилизироваться, полезно переводить его в текстовый, версионируемый вид.
Во-вторых, можно увлечься и сгрузить всю документацию в проект, забив контекст модели старыми легаси‑решениями и митинг‑репортами. Тут уж нужно понимать, что важно для модели, что нет и насколько артефакт из wiki нужно учитывать при разработке — или эти данные не важны, или задублированы в других артефактах.
Например, BPMN‑схемы — это большой и тяжёлый XML. Его нужно предварительно конвертировать и разбивать, упрощать. Связи между нодами, условные переходы, параллельные ветки — всё это либо теряется, либо интерпретируется неверно и при этом требует большого контекстного окна модели.
Ограничения по внедрению в Enterpise подхода SDD
1. Security и риск потенциальных утечек
Первым делом выясните, что говорят ваши внутренние политики об отправке запросов в облачные LLM. Скорее всего, вам это запрещено явно или неявно. Классно, если вам предоставят корпоративные LLM в корпоративном контуре. Если не повезло — разворачиваете локальные LLM и работаете с персональной машины. Хотя...
Ваши границы пустая формальность, считайте меня гражданином мира
(© Кремниевая долина)
2. Confluence содержит графические вставки, ссылки на внешние спецификации
Для миграции, конечно, мы поиспользуем приложение Confluence Markdown Exporter или даже ставим браузерный плагин (например, Confluence to Markdown Exporter), если админы не дали прав на API. Но постепенно переводить графику в текст BPMN - так лениво, а возможно и не нужно. Это задача, которая так же будет где-то в техдолге. Ведь перевести многолетние записи конфлюенса в md - это огромный труд. Примем риски, коллеги )
3. Команда (не)хочет работать в привычных инструментах и ничего не хочет менять
Из-за того, что нет нативной поддержки MD в Confluence не все диаграммы и спецификации будут рендериться корректно, плюс прокомментировать конкретный кусок аналитики не получится. Но без единого источника истины и механизма синхронизации документация быстро расходится с реальностью, нужно идти договариваться с бизнесом, поддержкой и перенастраивать процессы.
Что делать уже сейчас?
Руководителю
Признать реальность: команда уже на 100% использует LLM. Слухи, что даже подрядчики «министерства, где все носят погоны», оставляли в документах артефакты ChatGPT, — показательный сигнал: лиду пора легализовать эту практику и возглавить работу с ИИ.
Инициировать изменение рабочих процессов, переходя от атомарных документов к исполняемым спецификациям, которые эволюционируют вместе с проектом.
Продумать процессы по внедрению AI-подходов, оценить их и выбить ресурсы на внедрение.
Cистемному аналитику
Принять, что разработчики всё меньше читают вашу аналитику.
Принять, что нагрузка на аналитика не снижается, а скорее увеличивается при текущем подходе.
Выяснить, в каком IDE, с какой моделью работают разработчики, и готовить спецификацию с учётом этого. Если команда сидит в Cursor с Claude 3.5 Sonnet, ваши .md должны быть структурированы так, чтобы модель максимально эффективно их инжектила.
Не позволять ИИ генерировать спецификации для самой себя без проверки человеком. Семантический дрейф никто не отменял.
Готовить и формировать ADR, BRD, PostMortem’ы, C4, ER в Markdown для переиспользования на проекте в отдельном Git‑репозитории по, например как тут https://github.com/github/spec-kit
Обновлять скиллы агента и промты по мере работы над проектом. Например, случился инцидент — значит, обновляем спецификацию, чтобы в будущем он учитывал этот кейс.
Освежить матрицу выбора нотаций. Для меня это ключевой навык: понимать, какую нотацию и инструмент выбрать для конкретного слоя системы, чтобы артефакт был и для человека читаем, и для LLM. Помимо PantUML, C4 и Mermind есть еще D2, Graphviz, Gherkin.
Вывод
В SDD‑мире аналитик, который владеет текстовыми нотациями и понимает, как дополнять контекст LLM, в разы ценнее коллеги, который ждёт, пока «роботы заменят рутину. Именно поэтому во внедрении подхода Spec‑Driven Development должны быть в первую очередь заинтересованы сами аналитики, а не организации, их нанимающие.
Коллеги, ❝У нас может быть все хорошо. У нас может быть все просто отлично. Но, возможно, что мы также в полной заднице.❞ (© Кремниевая долина)
Список использованных источников
Den Delimarsky September 15th, 2025 Diving Into Spec-Driven Development With GitHub Spec Kit https://developer.microsoft.com/blog/spec-driven-development-spec-kit
8 Best AI Tools for Spec-Driven Development https://www.augmentcode.com/tools/best-ai-tools-for-spec-driven-development
AI Dev Podcast #1 / Проектирование систем в эпоху ИИ, Максим Смирнов, Руслан Сафин, Андрей Бураков, YouTube, 2026. URL: https://youtu.be/IQ6zFeYDXd8
«What is Spec‑Driven Development?», 2024 – введение в SDD: https://www.itential.com/resource/guide/spec-driven-development/
«SDD Flow: Spec‑Driven Development», MCP Market – описание инструмента для SDD‑воркфлоу: https://mcpmarket.com/tools/skills/sdd-flow-spec-driven-development
Артеев, Д., «Spec‑Driven Development: контроль AI‑кодогенерации», Habr, 2025 – практический разбор SDD. URL: https://habr.com/ru/articles/985498/
«Как ИИ меняет работу системного аналитика», Нетология, Habr, 2026 – обзор возможностей моделей для аналитиков. URL: https://habr.com/ru/companies/netologyru/articles/980386/
«AI‑Disrupt PDLC: разбор для тех, кто пишет код», Whitepaper Сбера, обсуждение на Habr, 2026. URL: https://habr.com/ru/companies/oleg-bunin/articles/1038588/
Цитаты из сериалов: Кремниевая долина (Silicon Valley) https://citaty.info/series/kremnievaya-dolina-silicon-valley?page=1
