Оркестратор для кодинг-агентов: от отдельных сессий — к единому процессу

Сегодня coding-агенты неплохо справляются не только с небольшими правками, но и с достаточно крупными инженерными задачами: могут написать код, тесты для нескольких модулей и подготовить запрос на слияние (pull request).

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

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

В этой статье разберём, как мы попробовали реализовать этот подход в нашем решении — оркестраторе HG SDLC (Human Guided SDLC). Расскажем, почему разрозненные сессии с агентом не дают масштаба и что становится связующим звеном между этапами разработки. Разберём, что из себя представляет оркестратор на практике, результаты за первые месяцы работы и куда планируем развиваться дальше.

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

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

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

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

Построение ИИ-процесса для человека и ИИ

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

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

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

То есть целевой путь от намерения до результата не должен распадаться на организационные передачи, очереди и восстановление контекста. В руководстве AI-Disrupt PDLC для этого представлен отдельный термин — Zero Friction: опыт разработки без каких-либо трений и сопротивления. Устранение ручной пересборки задачи для агента — один из шагов в эту сторону.

SDD как способ связать этапы ИИ-процесса

Подход Specification-Driven Development (SDD) помогает начать работу по связыванию соседних этапов в единый ИИ-процесс. Сама идея — сначала описать требования, а затем писать код, — конечно же не нова. Меняется роль спецификации: она становится не просто документом для человека, а рабочим контрактом, по которому агент планирует изменение, выполняет его и предъявляет результат на проверку.

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

Построение своего SDD-процесса можно не начинать с нуля. На практике отправной точкой могут быть готовые SDD-фреймворки. GitHub Spec Kit связывает спецификацию, план, задачи и реализацию. OpenSpec организует работу вокруг пакета изменения и обновления спецификации системы. BMAD Method предлагает более широкий набор агентных рабочих процессов — от анализа и планирования до реализации и проверок.

Из приведённых выше SDD-фреймворков BMAD гораздо ближе к сквозному процессу. Но какой бы фреймворк вы ни взяли за основу, «из коробки» он не будет учитывать особенностей конкретной организации. Как и предметное и практическое знание инженеров, работающих над проектом. В обогащении SDD-фреймворка этими знаниями (в том числе и знаниями регуляторов — надёжности, безопасности, рисков) и заключается сложность перехода организации на SDD. То есть уточнения и ручная передача контекста между этапами постепенно должны стать исключением, а не штатным механизмом запуска каждого этапа производственного процесса.

Требования к сквозному процессу

Контролируемость: трассируемость и точки участия человека

Предположим, что мы создали свой SDD-процесс. Артефакты уже связаны, нужный контекст доступен, а повторяющиеся знания вынесены в инструкции и навыки. Для управляемого процесса этого всё ещё недостаточно.

Во-первых, нужна трассируемость. Между намерением, гипотезой, архитектурным решением, спецификацией, реализацией и проверками должна сохраняться связь. Если проверка закончилась ошибкой, важно понять не только «что упало», но и какое требование проверялось, на каком решении оно основано и в какую точку процесса нужно вернуть работу. Для OpenSpec, например, можно воспользоваться OpenFastTrace.

Во-вторых, нужно задать явные точки участия человека. Кто и когда проверяет результат? По каким критериям? Какое действие блокируется до решения? Кому передать вопрос при разногласии? В AI-Disrupt PDLC это раскрывается в концепции Human-in-the-loop Decision Map — карте участия человека.

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

От описания процесса к его исполнению

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

В части контроля и наблюдения за процессом самый простой вариант — это сохранить привычный набор инструментов. Задачи вести в трекере задач, спецификации — в wiki или Confluence, а код — в Git. Описание самого процесса можно представить в виде инструкций для человека — что и на каком этапе нужно проверить, принять или отклонить — и набора промптов, навыков, правил и субагентов для coding-агента. Все перечисленные артефакты тоже можно хранить и версионировать в Git, например, в виде Markdown-файлов, как это и делают SDD-фреймворки.

Состояние одного ИИ-процесса оказывается распределено между несколькими системами: Git, сессиями coding-агентов на разных машинах, трекером задач, базой знаний (wiki) и так далее. Чтобы ответить, на каком шаге находится работа, почему она остановилась и сколько раз возвращалась на доработку, придётся собрать историю из разных мест. То есть, чем больше систем, между которыми распределено состояние процесса, тем сложнее его наблюдать, восстанавливать и улучшать. Тем не менее, ту или иную разновидность этого подхода за 2026 год попробовали многие организации (и мы здесь не исключение).

В качестве альтернативы мы предлагаем переосмыслить рабочее место инженера: собрать состояние задачи, артефакты, вопросы и решения в одном интерфейсе. Это не обязательно замена IDE, это, скорее, отдельное представление процесса для человека, который принимает решения и наблюдает за несколькими задачами. Такая логика перекликается с децентрализацией IDE в AI-Disrupt PDLC: рабочая поверхность может меняться, но состояние и правила исполнения не должны зависеть от неё.

Остаётся второй вопрос: как исполнять описанный процесс? Существует несколько вариантов: поручить агенту самому следовать текстовому описанию процесса или разделить исполнение работы и управление переходами. Первый вариант прост и понятен: передали описание ИИ-процесса (Markdown-файлы) coding-агенту и попросили чётко ему следовать. Второй — агенту оставили свободу внутри конкретного этапа, а последовательность шагов, переходы, проверки и контроль над местами участия человека вынесли в отдельное приложение-оркестратор. В этом случае агент становится исполнителем работы, человек — в основном, источником намерения и содержательных решений, а оркестратор отвечает за то, чтобы сам процесс не потерялся между ними: хранит его состояние, определяет следующий разрешённый переход и фиксирует историю выполнения.

Давайте посмотрим, как такой оркестратор мог бы выглядеть на практике.

HG SDLC — оркестратор ИИ-процесса

HG SDLC (Human Guided SDLC) — наша реализация системы для запуска и отладки управляемого процесса разработки «поверх» ACP-совместимого coding-агента. Систему разработали несколько команд для себя, и она не позиционируется как готовая корпоративная платформа, закрывающая весь PDLC. Цель, которую мы перед собой ставили, — проверить саму модель организации разработки, где человек всё меньше выступает непосредственным исполнителем и всё больше сосредотачивается на содержательных решениях, контроле и проверке результатов. А часть его взаимодействия с агентом переносится из привычной IDE в общее командное пространство.

Проще всего объяснить, что собой представляет HG SDLC, через аналогию с BPM-движком. Представьте процесс в виде набора узлов: часть из них выполняет система, часть требует участия человека. Движок создаёт экземпляр такого процесса, исполняет его, хранит состояние, фиксирует ход выполнения и управляет переходами.

HG SDLC делает примерно то же самое применительно к разработке ПО: процесс представлен как версионированный циклический граф (в системе он называется «сценарий»), в котором заданы этапы, допустимые переходы, обязательные проверки и циклы возврата для доработки.

На текущем этапе развития больших языковых моделей собрать сценарий, который одинаково хорошо решает любую задачу, невозможно. Если в сценарий подключить SDD‑фреймворк, политики организации, систему работы с контекстом, CI/CD, обязательные проверки разработанного решения и правила публикации, то максимум получится полноценный Paved Road(«проторенный путь») для конкретного класса задач.

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

Состав сценария в HG SDLC: узлы графа

При создании сценария (описании процесса в виде графа) пользователь может воспользоваться следующими типами узлов:

Полученный граф хранится в виде YAML-файла. Упрощённый пример:

nodes:
-	id: ai-review title: AI-ревью type: ai instruction: |
Проведи ревью с помощью подключённых skill и subagent.
Подготовь краткий результат и сохрани его в файл review-result.md. skill_refs:
-	hgdlc-code-review@1.0 subagent_refs:
-	aidlc-qwen-review-edge-case-hunter@1.0 produced_artifacts:
-	path: review-result.md required: true
on_success:
transition: approval-gate

-	id: approval-gate
title: Проверка результата type: human_approval instruction: |
Проверь результат AI в файле review-result.md. Если результат корректен — нажми Approve.
Если его нужно исправить — выбери Rework и опиши замечания. execution_context:
-	type: artifact_ref node_id: ai-review path: review-result.md
on_approve: transition: terminal
on_rework:
transition: ai-review

-	id: terminal
title: Завершение флоу type: terminal

Узел графа не равен целому этапу производственного процесса. Например, «Разработка» может включать в себя несколько ИИ-узлов, команды проверки и согласование.

Почему мы не использовали существующий BPM-движок? Универсальный workflow-движок — например, Camunda или Temporal — вполне мог бы стать частью такого решения. Но вокруг него всё равно пришлось бы строить масштабную предметную модель: рабочее пространство агента, контекст, артефакты, согласования, возвраты, аудит и публикацию. Понимая объём этой обвязки, мы решили, что эффективнее разработать собственное ядро оркестрации под наши специфичные задачи. Однако это сугубо наш инженерный пример, и он не означает, что вам нужно выбирать такой же путь.

Жизненный цикл задачи в ИИ-процессе

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

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

Рассмотрим условную задачу: добавить новую кнопку «Версия». При решении этой задачи человек и агент пройдут следующие шаги:

1. Подготовка спецификации. Агент изучает доступные требования и кодовую базу, определяет затронутые части системы и готовит описание изменения. В описании должно быть отражено место кнопки, изменяемые контракты API, изменения SDK, условия совместимости и критерии проверки.

2. Согласование спецификации. На первом Human Gate человек проверяет границы задачи, выбранные решения и критерии приёмки. Если чего-то не хватает, он возвращает спецификацию с конкретным замечанием. Если всё согласовано, то процесс переходит к реализации.

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

4. Автоматические проверки. Командные узлы запускают сборку, тесты и настроенные проверки безопасности. Для неуспешных результатов в процессе должен быть предусмотрен понятный маршрут: исправление — повторная проверка (Ralph loop с условием выхода).

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

6. Публикация. После принятия результата изменения публикуют в выбранном режиме — например, в рабочей ветке, или делают pull request.

Два способа скорректировать результат работы агента: Rework и Human Takeover

В системе предусмотрено два способа корректировки результатов работы кодинг-агента: возврат на доработку и временный перехват управления.

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

Вернуться можно как из Human Gate, так и из AI Node. Если возвращаться из AI Node, то точек возврата может быть несколько: если проблема в реализации, то возвращаемся к ней; если обнаружено неверное предположение в требованиях, то уточняем спецификацию, а не закрепляем расхождение ручной правкой. Это согласуется с логикой AI-Disrupt PDLC: изменение требований должно оставаться видимым.

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

Временный перехват управления человеком (Human Takeover) — более радикальный сценарий, в котором человек временно становится исполнителем, сам разбирается с проблемой в IDE или во встроенном в систему редакторе кода, а затем возвращает управление оркестратору. Это именно управляемый перехват, а не параллельная работа человека независимо от процесса.

Как это выглядит в интерфейсе?

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

Консоль запуска

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

Human Gate

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

HG SDLC — это не только граф процесса

Если смотреть на HG SDLC как на платформу вокруг ИИ-процесса, то функциональность не заканчивается самим графом. Вокруг него есть несколько контуров, которые превращают процесс в управляемый производственный механизм:

• Команды и глобальные роли. Система поддерживает две группы ролей: глобальные роли и командные. Глобальные нужны для управления пользователями, командные — для настройки проектов и запусков ИИ-процессов в этих проектах.

• Каталоги навыков и субагентов. Предполагается, что группа команд ставит систему для себя и сама управляет обновлением. Для того, чтобы обмениваться переиспользуемыми навыками, субагентами и сценариями реализована функциональность синхронизации локального каталога с Git-репозиторием.

• MCP. Подключение MCP даёт сценариям доступ к внешним инструментам и системам. За счёт этого запущенный процесс может не ограничиваться локальным контекстом, а получать данные и выполнять действия во внешнем контуре.

• API. HG SDLC можно вызывать извне через API: запускать процессы, получать их состояние и результаты и встраивать работу оркестратора в другие системы — например, внутренние порталы, CI/CD, чат-боты.

• Запуск по расписанию. Сценарии можно запускать автоматически по расписанию. Например, в связке с Jira можно построить процесс, который по расписанию читает новые задачи из Jira, запускает реализацию, создаёт pull request и после этого переводит исходную задачу в статус «ожидание проверки человеком».

• Бенчмарки (экспериментальная функциональность). В системе можно тестировать разные версии навыков и сценариев на одной и той же задаче. Это позволяет сравнивать результаты на одинаковых входных данных, замечать регрессии и проверять изменения до их использования в рабочем процессе.

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

• Интерфейс для владельца продукта (экспериментальная функциональность). В качестве начального этапа перехода от SDLC к PDLC сделан отдельный упрощённый интерфейс для владельца продукта, в центре которого находятся задача, ход выполнения, результаты и решения, требующие участия человека, а не техническая конфигурация графа.

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

Связь платформы с AI-Disrupt PDLC

Если вернуться к концепциям из руководства AI-Disrupt PDLC, то HG SDLC в первую очередь фокусируется на петле намерения и петле реализации, предлагая пользователю самостоятельно сконфигурировать их через создание сценария (flow).

Проверка (validation spine) и контроль (governance mesh) пока материализованы частично: есть проверочные шаги, роли, гейты и история решений. Полноценный проверочный пакет, риск-адаптивные полномочия и контроль на всём пути требуют дальнейшей работы.

Оценка эффекта (outcome check) — следующий важный этап. После развёртывания нужно вернуться к исходной гипотезе и измерить результат, потому что технически принятое изменение не доказывает, что бизнес-цель достигнута. То есть нужен механизм доставки и настройки бизнес-метрик, их последующего замера и отправки результатов обратно в систему для запуска отдельного цикла изменения. Встраивание этой обратной связи в HG SDLC остаётся направлением развития.

Что показали первые месяцы работы?

Первые команды начали пробовать HG SDLC несколько месяцев назад. Важное наблюдение этого периода: переход к связанному ИИ-процессу начинается не с установки оркестратора, а с освоения SDD. Команде нужно договориться, как описывать изменения, какие знания и ограничения передавать агенту, что проверять и по каким критериям принимать результат.

Затем команды начали переносить свои SDD-процессы в HG SDLC: задавать шаги, инструкции, входные материалы, проверки и точки согласования. И уже после этого — экспериментировать с процессом в системе. Так сложилась последовательность: сначала освоить SDD, затем перенести процесс в оркестратор, после этого — расширять и улучшать его.

Какие сценарии пробуют команды?

Команды не начинают с чистого листа: за основу берут готовые SDD-сценарии, в том числе OpenSpec и BMAD, и адаптируют их к своим проектам. Дальше эксперименты идут в нескольких направлениях:

• Связать спецификацию и реализацию. Часть команд использует OpenSpec как основу процесса и настраивает передачу согласованного описания изменения в разработку.

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

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

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

Что уже даёт оркестратор?

Часть задач команды выполняют через HG SDLC, часть — напрямую с SDD и кодинг-агентом. Одни и те же сценарии мы пробуем и внутри системы, и без неё. Наличие оркестратора само по себе не делает агента сильнее и не заменяет качественную спецификацию, контекст и проверки.

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

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

Куда развивать платформу дальше?

На основании полученной от команд обратной связи мы видим много направлений для развития. Часть из них довольно локальна — например, можно задавать модель и набор MCP для конкретного ИИ-узла, чтобы не тащить лишние инструменты и контекст через весь процесс. Или сделать human-gate с обязательным одобрением нескольких людей, а не одного, и так далее.

Но помимо таких точечных улучшений мы выделяем несколько более крупных направлений развития платформы:

• цифровые сотрудники: объединение нескольких ИИ-процессов в целостную рабочую роль, которой можно назначать задачи;

• управление контекстом: подготовка и доставка агенту именно тех знаний, которые нужны на конкретном этапе процесса;

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

Цифровые сотрудники

В концепции HG SDLC цифровой сотрудник — это набор ИИ-сценариев, объединённых единой точкой входа. Получив задачу, он определяет, какой из доступных сценариев подходит для её выполнения, и запускает его.

Первые варианты мы собираем уже сейчас на текущей версии системы (через расписание и MCP-сервера). Пока это один-два сценария — например, проверка кода или исправление ошибок. Такому сотруднику назначают задачу в Jira, а настроенный сценарий организует её выполнение. Эти эксперименты помогают понять, какие работы уже можно оформлять как повторяемые поручения, а где по-прежнему требуется участие человека. Дальше мы хотим превратить такую сборку в удобную рабочую роль.

Управление контекстом: нужные знания на нужном этапе

Дать агенту доступ к источнику — не то же самое, что подготовить нужный контекст. Для вопросов «какие продукты затронет изменение?», «кто владеет сервисом?» или «какие API от него зависят?» нужна связная модель продуктов, систем, репозиториев, контрактов и владельцев.

Такой слой можно построить на графе знаний или другой структурированной модели. Но модель связей — только часть задачи. Нужно также определять актуальность сведений, их происхождение, область применимости и доступность конкретному исполнителю (то, что обозначается как Context Supply Chain в AI-Disrupt PDLC). Больше документов в контекстном окне — скорее, вред, чем польза, даже если большая часть из них полезна.

Улучшение процессов по истории запусков

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

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

Такой подход продолжает идею руководства AI-Disrupt PDLC о накопительной ценности среды и эволюции Paved Roads на основе телеметрии. Полезный опыт отдельной команды становится переиспользуемым знанием только после осмысления, проверки и закрепления в процессе.

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

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

Если дополнить результатами анализа бизнес-эффекта — какие гипотезы подтвердились, какие нет и почему, — обратная связь сможет помогать не только реализации, но и следующему циклу намерения. Агент будет участвовать в сравнении гипотез, а человек останется владельцем решения о том, какого результата стоит добиваться.

Вместо заключения: главный актив — не агент или модель

HG SDLC для нас — способ проверить, как перейти от отдельных сессий с агентом к повторяемой работе над задачами. SDD помогает явно описать изменение, ограничения и критерии приёмки. Оркестратор связывает шаги и сохраняет историю исполнения.

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

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

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

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

Попробуйте HG SDLC на своём процессе

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

Проект опубликован на GitVerse. Если у вас есть предложения, вопросы или вы обнаружили баги в системе, мы будем благодарны за обратную связь — на GitVerse или hgsdlc@sberbank.ru. Это поможет нам развивать инструмент дальше.

Источники

AI-Disrupt PDLC. Практическое руководство, версия 2.0, июнь 2026, Сбер. Сайт концепции · Руководство.

Для углубленного изучения: GitHub Spec Kit, OpenSpec, BMAD Method, Team Topologies, HG SDLC.