SDD, оркестрация и разговоры о замене специалистов

Фрагмент лекции: «Все что нужно знать про ИИ айтишнику», 01:35:30 — отсюда взято содержание этой главы.

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

Почему разговор с агентом не превращается в проект

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

Договорённости живут в переписке. Вы двадцать минут объясняли, почему в этом проекте не используется ORM. Через неделю вы открываете новый чат — и объясняете заново. Ещё через месяц вы открываете код и не помните, было ли решение обдуманным или агент так решил сам.

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

Никто, кроме вас, не может продолжить. Знание о проекте лежит в вашей голове и в вашем чате. Коллега получает код без объяснения намерения.

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

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

Spec-Driven Development: цикл, в котором между этапами стоит человек

SDD (Spec-Driven Development, разработка через спецификации) — способ организовать работу с агентом так, чтобы вход каждого шага был письменным документом, а не репликой в чате.

Сама идея не новая и не про ИИ. Автор лекции приводит ряд аналогий: в TDD сначала пишут тесты, потом код; дом строят по проекту и смете, а не «как пойдёт»; работу для заказчика начинают с согласованного технического задания. Во всех случаях перед действием стоит документ, который можно прочитать, оспорить и утвердить. SDD переносит эту дисциплину на диалог с агентом.

Цикл выглядит так:

1. Намерение. Вы формулируете, что хотите получить и зачем. Это единственный шаг, который делает только человек.
2. Спецификация. Агент превращает намерение в документ: цель, границы, требования, критерии готовности. Не код — описание.
3. План. Из спецификации выводится последовательность шагов реализации с контрольными вехами. Полезно ограничивать план по объёму явно: «не больше пяти пунктов», «с позиции ведущего архитектора».
4. Задачи. План нарезается на отдельные задачи, каждая — самостоятельная единица работы с проверяемым результатом.
5. Реализация. Агент выполняет задачи по одной, сохраняя результат.

И главное, ради чего всё это затевается:

Между каждыми двумя этапами стоит проверка человеком. Именно она отличает SDD от «попросил и надеюсь». В лекции эта проверка названа «тождественным морфизмом» — образ из теории категорий, который здесь не обязателен. Скажем прямо: это контрольная точка, на которой артефакт либо принимается и идёт дальше, либо возвращается на доработку.

Что на самом деле делают в контрольной точке

Проверка — не «пробежать глазами и согласиться». У неё есть содержание, и оно разное на каждом этапе:

Ошибка, обнаруженная на спецификации, стоит одного абзаца. Та же ошибка, обнаруженная после реализации, стоит всей ветки.

Отдельный вопрос — самопроверка агента. В инструментах SDD обычно есть шаг вроде «проанализируй план на реалистичность и на соответствие спецификации». Это полезный черновик: он ловит явные противоречия и пропущенные пункты. Но заменить контрольную точку он не может по принципиальной причине — артефакт и его проверку порождает один и тот же механизм, поэтому их ошибки скоррелированы. Модель не видит того, чего не видела при генерации. Автор формулирует это резче: мы ему не доверяем, поэтому проверяем сами.

Артефакты версионируются

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

проект/
├── .specify/                  # служебные файлы инструмента
├── memory/
│   └── constitution.md        # принципы проекта
├── specs/
│   ├── 001-user-auth/
│   │   ├── spec.md            # что делаем и зачем
│   │   ├── plan.md            # как делаем
│   │   └── tasks.md           # чем это нарезано
│   ├── 002-billing-export/
│   └── 003-search-index/
└── src/

Что это даёт помимо порядка:

• История решений. Через полгода видно не только «что сделано», но и «почему именно так» — спецификация лежит в том же коммите, что и код.
• Ревью до работы, а не после. Коллега комментирует spec.md в пулл-реквесте, пока цена изменения — правка абзаца.
• Воспроизводимость входа. Вы не можете гарантировать одинаковый выход модели, но можете гарантировать одинаковый вход. Это ровно та часть системы, которая вам подконтрольна.
• Передаваемость. Новый человек читает specs/ и понимает проект без вас.

GitHub Spec Kit

Spec Kit — одна из реализаций подхода, выпущенная GitHub. Не единственная и не обязательная: подход можно вести и вручную, в обычных markdown-файлах. Но готовый набор экономит время на разметке процесса.

Что он даёт по сути две вещи:

Набор команд для агента. Инструмент устанавливает в проект slash-команды, каждая из которых соответствует шагу цикла: /constitution — записать принципы проекта, /specify — построить спецификацию из намерения, /clarify — задать уточняющие вопросы там, где формулировка допускает разные прочтения, /plan — составить план, /tasks — нарезать задачи, /analyze — сверить артефакты между собой, /implement — выполнять.

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

Установка идёт через Python-утилиту, которая добавляет команды в проект под конкретного агента — Claude Code, GitHub Copilot, Cursor, Codex и другие:

# uv ставит и запускает CLI одной командой, без глобальной установки
uvx --from git+https://github.com/github/spec-kit.git specify init мой-проект

# точный список поддерживаемых агентов и актуальные флаги — в README проекта,
# он меняется чаще, чем сам подход

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

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

Конституция проекта и банк памяти

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

Что туда пишут: язык интерфейса и комментариев, запрет или разрешение на конкретные зависимости, стиль тестов, соглашения об именовании, границы («в этот каталог не лезем»), формат коммитов. Что туда не пишут: всё, что можно проверить линтером, — линтер дешевле и надёжнее.

Механически это тот же приём, который мы разбирали в главе про RAG, MCP и агентов: нужные знания кладутся в контекст перед запросом, потому что в весах модели их нет и быть не может. Так же устроены и «навыки» агентов — заранее записанные в markdown последовательности шагов, которые агент подтягивает по имени. Разница только в том, что именно подкладывается: документы, инструкции или правила.

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

Живой пример: портал, который вы сейчас читаете

Этот сайт устроен именно так. В репозитории есть каталог docs/sdd/ со спецификациями — по одной на каждое заметное изменение. Трек, который вы сейчас проходите, описан отдельной спецификацией: в ней зафиксированы проблема (полтора часа видео не ищутся и не читаются), карта из шестнадцати глав, правила переноса устной речи в текст и список утверждений лекции, которые в текст не попадают. Спецификация была написана и принята до того, как появилась первая глава.

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

Роль инженера: оператор спецификаций

Формулировка автора, ради которой стоит прочитать этот раздел:

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

Формулировка точная, и именно поэтому её нужно дочитать до конца. Проверять чужую работу — отдельный навык, и он не легче, чем писать код. Три причины:

1. Чтение кода сложнее его написания. Когда вы пишете, вы держите модель решения в голове. Когда читаете — восстанавливаете её по тексту, причём чужую и, возможно, неправильную.
2. Правдоподобный артефакт усыпляет. Спецификация, написанная моделью, читается гладко: правильная структура, уверенный тон, знакомые формулировки. Ошибка в ней выглядит ровно так же, как всё остальное. Это то же свойство, о котором шла речь в главе про галлюцинации и «мышление», — правдоподобие и правильность для модели неразличимы.
3. Приёмка требует критерия, а не впечатления. «Выглядит нормально» — не приёмка. Приёмка — это заранее записанный признак готовности, по которому видно, выполнена задача или нет.

Так что смена роли — это не «стало проще». Это перенос усилия с производства на приёмку. Кому-то такой обмен подходит, кому-то нет, и это профессиональный выбор, а не вопрос прогрессивности.

Оркестрация: когда агентов больше одного

Следующий шаг напрашивается сам: если агент умеет писать спецификацию, пусть один агент готовит спецификацию, а другой — реализует. Дальше — агент-проверяющий, агент-тестировщик, и так далее.

Что при этом растёт — и растёт быстрее, чем польза:

• Расход токенов — кратно. Спецификация, написанная одним агентом, целиком читается вторым; ответ второго читает третий. Каждая передача — это полный перечитанный контекст, а не ссылка на него.
• Площадь отказа. Ошибка первого агента становится входными данными второго и выглядит для него как требование заказчика. Ошибки не гасятся, а наследуются.
• Сложность отладки. Когда результат неверен, вопрос «на каком шаге сломалось» требует полных трейсов всех участников. Без логов вы не отладите систему, поведение которой недетерминировано.

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

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

Универсальный приём: сведите задачу к тексту

Это самый практичный совет всей лекции, и он не требует ни агентов, ни спецификаций.

Языковая модель работает с текстом. Значит, вопрос «решается ли моя задача моделью» сводится к вопросу «можно ли её представить текстом». Аудио сводится к тексту. Видео сводится к тексту. PDF, презентация, таблица, скан — сводятся к тексту. И как только задача сведена, дальше работают все техники из этого трека.

Документы → markdown. MarkItDown от Microsoft конвертирует в markdown большинство офисных и проприетарных форматов: PDF, docx, pptx, xlsx, HTML, а также картинки и аудио через внешние движки.

pip install "markitdown[all]"
markitdown отчёт.pdf > отчёт.md

Оформление при этом теряется — и это правильно. Структура документа нужна человеку; модели нужен текст с заголовками, а рамки, шрифты и колонтитулы только съедают контекст.

Видео и аудио → текст. ffmpeg извлекает звуковую дорожку, Whisper её расшифровывает:

# 1. Видео -> моно 16 кГц: именно этот формат ждёт распознавание
ffmpeg -i созвон.mp4 -vn -ac 1 -ar 16000 -c:a pcm_s16le созвон.wav

# 2. Аудио -> текст. Модель medium — разумный компромисс качества и скорости;
#    на CPU расшифровка идёт заметно дольше реального времени записи
whisper созвон.wav --model medium --language ru --output_format txt

# 3. Дальше текст обрабатывается как обычный markdown:
#    суммаризация, извлечение решений, список задач

Одно уточнение к лекции: Whisper даёт сплошной текст с таймкодами, но не разделяет говорящих. Разметка «кто что сказал» — отдельная задача, диаризация; для неё берут отдельные инструменты поверх расшифровки. Ожидать этого от Whisper из коробки не стоит.

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

Критерий применимости

Сформулируем явно то, к чему сводится весь приём:

Если задачу можно свести к тексту и результат можно проверить дешевле, чем произвести, — модель уместна.

Обе половины обязательны. Первая отвечает на вопрос «примет ли модель вход». Вторая — на вопрос «что вы будете делать с выходом». Расшифровка созвона проверяется выборочным прослушиванием спорных мест. Сгенерированный SQL проверяется запуском на тестовой базе. Патч проверяется тестами. А медицинская рекомендация или юридическое заключение проверяются дороже, чем производятся, — там модель может быть подспорьем специалисту, но не заменой проверке.

Про конфиденциальность

Сведение к тексту почти всегда означает отправку этого текста наружу. Запись созвона с клиентом, внутренний договор, медицинская выписка, исходники под NDA — прежде чем прогонять такое через облачный сервис, посмотрите на условия обработки данных и на то, что вы вообще имеете право отправлять. Технический выход есть: расшифровка и обработка локальной моделью на своём железе. Что для этого нужно, сколько это стоит по памяти и во сколько раз медленнее — разобрано в статье Локальные модели.

Заменят ли специалистов

Раздел, в котором нужно максимально аккуратно разделить три разных вещи.

Позиция автора — это мнение. Он формулирует её прямо: не заменит, паника раздута, нагрузка на специалиста растёт не вширь, а вглубь. Раньше вы задавали вопрос на форуме и ждали ответа эксперта пару дней; теперь ответ приходит за секунды, но проверять его и встраивать в свою задачу должны вы сами. Инструментов автоматизации в отрасли хватало и раньше — конструкторы сайтов вроде uCoz, WordPress, Joomla, Tilda и Framer появлялись волнами, — и профессию они не отменили. Это рассуждение по аналогии: оно объясняет, почему прошлые волны не сбылись, но не доказывает, что не сбудется эта.

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

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

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

Чего мы не знаем. Дискуссия о влиянии языковых моделей на рынок труда ведётся всерьёз, и однозначного ответа у неё нет. Есть работы, оценивающие долю задач, потенциально затронутых автоматизацией; есть полевые измерения производительности, где выигрыш достаётся в основном менее опытным сотрудникам; есть аргументы про создание новых ролей и про исчезновение младших позиций. Методики и выводы расходятся. Ни оптимизм, ни пессимизм здесь не являются фактом, и подавать их как факт — значит выдавать позицию за знание. Ссылки на конкретные исследования — в источниках ниже.

Что можно сказать без спора: изменился состав работы. Доля рутины падает, доля проверки, постановки задачи и ответственности за результат растёт. Как это встраивается в жизненный цикл разработки — от требований и код-ревью до тестирования и эксплуатации — разобрано в статье ИИ в жизненном цикле разработки.

Что держит этот трек вместе

Трек начинался с вопроса, который выглядел не имеющим отношения к ИИ: почему компьютер не умеет в случайность. Дальше была первая работающая модель предсказания следующего слова, трансформер, токены и контекстное окно, неудобный ответ на вопрос про мышление, промптинг, диффузия, RAG, MCP и агенты, провайдеры и фрейминг — и вот агент правит репозиторий по спецификации, которую вы приняли.

Одна мысль держит всё это вместе:

Модель предсказывает правдоподобное продолжение текста. Всё остальное — инженерия вокруг этого факта.

Проверьте на любой главе. Модель уверенно выдумывает — потому что «правдоподобно» и «верно» для неё одно и то же. Диалог дорожает — потому что памяти нет и контекст пересылается заново. Промптинг работает — потому что сужает множество правдоподобных продолжений. RAG нужен — потому что ваших документов нет в весах. Агенту нужны лимиты — потому что цепочка правдоподобных шагов расходится тем сильнее, чем она длиннее. SDD нужен — потому что воспроизводимым можно сделать вход, но не выход.

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

Источники

• GitHub Spec Kit — реализация подхода: команды агента, структура каталогов, конституция проекта
• MarkItDown, Microsoft — конвертация офисных и проприетарных форматов в markdown
• Whisper, OpenAI, и статья Robust Speech Recognition via Large-Scale Weak Supervision — распознавание речи с открытыми весами
• ffmpeg — извлечение и преобразование аудиодорожки
• Anthropic, Building Effective Agents — почему простые композиции обычно выигрывают у многоагентных схем
• Eloundou et al., GPTs are GPTs: An Early Look at the Labor Market Impact Potential of LLMs, 2023 — оценка доли задач, потенциально затронутых автоматизацией
• Brynjolfsson, Li, Raymond, Generative AI at Work, 2023 — полевое измерение эффекта на производительность
• Model Context Protocol — стандарт подключения инструментов и данных к агентам

Мини-итог

• Диалог с агентом не воспроизводится и не передаётся: у модели нет памяти, поэтому договорённости должны жить в файлах репозитория, а не в истории чата.
• SDD — цикл «намерение → спецификация → план → задачи → реализация», в котором между каждыми двумя этапами стоит контрольная точка: артефакт принимается человеком или возвращается на доработку. Без контрольных точек это не SDD, а просто длинный промпт.
• Артефакты нумеруются и версионируются рядом с кодом; воспроизводимым вы делаете вход модели — выход воспроизводимым сделать нельзя. Spec Kit даёт готовые команды и структуру каталогов, конституция проекта задаёт правила, которые едут в контекст каждой задачи и потому должны быть короткими.
• Роль инженера смещается с производства на приёмку: он становится оператором спецификаций. Это не облегчение работы, а обмен одного навыка на другой — проверять правдоподобный чужой артефакт не легче, чем писать код.
• Оркестрация нескольких агентов умножает расход токенов, площадь отказа и сложность отладки; лимиты, изоляция и приёмка результата обязаны жить на стороне оркестратора.
• Практический критерий на все случаи: если задачу можно свести к тексту и результат можно проверить дешевле, чем произвести, — модель уместна. Инструменты сведения к тексту существуют и бесплатны; проверять конфиденциальность данных перед отправкой наружу нужно всегда.
• Про замену специалистов проверяемо ровно одно: модель не имеет доступа к контексту, которого нет в тексте. Остальное — открытая дискуссия, в которой ни оптимизм, ни пессимизм не являются фактом.
• И сквозная мысль всего трека: модель предсказывает правдоподобное продолжение, а всё остальное — инженерия вокруг этого факта.

Что дальше

Трек закончен. Дальше есть два разумных направления.

Если хочется практики — идите в ИИ-инженерию: прикладной трек. Там всё, что здесь дано обзорно, разобрано до продакшн-деталей: структурированный вывод и схемы, продакшн-RAG с чанкингом и реранжированием, агентный цикл с инструментами и лимитами, оценка качества и регрессионные прогоны, экономика запросов, локальные модели, безопасность и инъекции. Рекомендация из той статьи работает и здесь: ведите один сквозной проект через весь трек, а не читайте подряд.

Если хочется закрепить или перечитать отдельные темы — вернуться к карте трека и пройти главы, которые в первый раз проскочили. Минимальный маршрут для повторения — главы про предсказуемость, токены, мышление и промптинг: они объясняют больше всего наблюдаемых странностей моделей.

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