SDLC для ИИ-агентов: почему хороших промптов недостаточно

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

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

Что такое SDLC и что в нём меняют ИИ-агенты

SDLC (software development life cycle) — жизненный цикл разработки программного обеспечения: последовательность этапов от идеи до работающего продукта и его поддержки. Модели SDLC бывают разными — каскадная, итеративная, Scrum, — но этапы в них похожи. В таблице — что на каждом этапе может делать агент, что остаётся за человеком и какой артефакт передаётся дальше.

Без общего контекста каждый агент в этой цепочке начинает с нуля. Об этом — следующий раздел.

Как договоренности теряются между этапами

Во время разработки человек и агент уточняют поведение функции, обсуждают ограничения и согласуют решение. Если оно осталось только в чате, ревьюер получит diff, документацию и тикет без объяснения, почему выбран именно такой вариант. Он может предложить изменить уже принятое поведение, даже если ошибки нет. Затем с тем же пробелом столкнется агент, который пишет или запускает тесты.

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

Spec Driven Development: спецификация как общий контекст

Spec Driven Development (SDD) — подход, в котором работа над изменением начинается со спецификации, а код и тесты пишутся по ней. Спецификация лежит в репозитории рядом с кодом и обновляется вместе с ним. Для агентов это главный источник контекста: каждый следующий агент читает файл и получает те же договорённости, что и предыдущий.

Минимальная спецификация изменения может выглядеть так:

# Изменение: напоминание клиенту о встрече

## Цель
Сократить число пропущенных встреч в CRM.

## Сценарии
- Менеджер создаёт встречу — клиент получает напоминание за 24 часа и за 2 часа.
- Встреча перенесена — старые напоминания отменяются, новые ставятся.

## Ограничения
- Не отправлять напоминания с 22:00 до 8:00 по времени клиента.

## Критерии приёмки
- Тесты на перенос и отмену встречи проходят.
- В журнале видно, какие напоминания отправлены.

## Решения
- 2026-10-14: выбрали очередь задач, cron не умеет отменять отдельные напоминания.

Раздел «Решения» закрывает проблему из предыдущего раздела: ревьюер и агент-тестировщик видят, почему выбран именно такой вариант. Как подготовить проект и задачи к работе с агентами, разбирают на курсе ИИ для разработчиков 2.0, а почему контекст важнее формулировки промпта — в статье «Промпт-инжиниринг больше не главное: что такое инженерия контекста».

Почему ревью становится узким местом

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

Для описания степени самостоятельности агентов эксперт и преподаватель курса AI SDLC Алексей Могильников использует уровни L0–L5. На первых уровнях агент помогает внутри роли разработчика, аналитика или тестировщика. На L3 он может выполнить согласованную задачу по спецификации, а человек проверяет результат. На L4 несколько специализированных агентов работают в общем пайплайне. На L5 большинство знакомых задач может проходить автономно, но люди разбирают спорные и рискованные ситуации и контролируют изменение правил. Это рабочая модель описания зрелости, а не единый отраслевой стандарт.

Quality gates: какие проверки ставить между этапами

Quality gate — условие, без выполнения которого изменение не переходит на следующий этап. Часть проверок выполняется автоматически в CI, часть — людьми. Чем больше кода пишут агенты, тем больше работы стоит отдать автоматическим проверкам, чтобы ревьюер тратил время на архитектуру и решения.

Когда агент должен остановиться и позвать человека. Эти условия записывают в правила проекта заранее:

• требования в спецификации противоречат друг другу или не покрывают случай;

• изменение затрагивает схему базы данных, платежи, права доступа или персональные данные;

• quality gate не проходит после нескольких попыток исправления;

• задача выходит за границы, описанные в спецификации.

Уровни автономности агентов L0–L5

Модель уровней Алексея Могильникова в виде таблицы:

Переход с L2 на L3 упирается в спецификации: без них агенту нечего выполнять. Переход на L4 упирается в quality gates и пропускную способность ревью.

Как перестроили процесс в команде CRM

Команда из шести человек разрабатывала кастомную CRM. Агенты уже помогали писать код и тесты, но задач целиком им не поручали: актуальных спецификаций не было. Для нескольких компонентов агент подготовил первичные спецификации, PM уточнил сценарии и ограничения. Затем ввели карточки инкрементов с контекстом и критериями приемки. Агент готовил код, тесты и merge request, разработчики проверяли техническое решение, тестировщик — сценарии и регрессии, PM — соответствие требованиям. После приемки обновляли спецификации и журнал решений. По замерам сопоставимых небольших задач среднее время от готовой постановки до принятого MR на этих компонентах сократилось с четырех до двух дней. Финальную проверку оставили людям.

Что изменилось в команде CRM:

С чего начать перестройку процесса

1. Замерьте исходное состояние: сколько времени задача проходит от постановки до принятого пул-реквеста и где она дольше всего ждёт.

2. Выберите один компонент и подготовьте для него спецификацию. Первый черновик может написать агент по коду и документации.

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

4. Автоматизируйте проверки, которые сейчас делают люди: линтеры, тесты, статический анализ.

5. Запишите условия, при которых агент останавливается и обращается к человеку.

6. Через несколько недель повторите замер и сравните с исходным.

Где научиться выстраивать AI SDLC

На Хекслете этой теме посвящены три курса:

Курс AI SDLC ведёт Алексей Могильников — 15 лет в разработке и архитектуре, был CTO и CDO и построил AI-направление на 60 специалистов. Сравнение курсов по ИИ для разработчиков в разных школах — в подборке «Где учиться ИИ разработчику в 2026».

На бесплатном вебинаре Хекслета «Как выстроить сквозной SDLC для ИИ-агентов» 26 октября в 19:00 разберем, как составлять спецификации, передавать контекст между агентами и проверять результат до принятого PR.

Частые вопросы

Что такое AI SDLC?

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

Какие этапы есть в SDLC?

Обычно выделяют сбор требований, проектирование, разработку, тестирование, развёртывание и сопровождение. Ревью кода часто выносят в отдельный этап.

Чем SDLC отличается от PDLC?

PDLC (product development life cycle) описывает жизнь продукта целиком: исследование рынка, гипотезы, запуск, развитие. SDLC — его часть, которая касается разработки программного обеспечения.

Что такое Spec Driven Development?

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

Что такое quality gate?

Условие перехода изменения на следующий этап: тесты прошли, статический анализ не нашёл уязвимостей, ревьюер одобрил. Часть gate выполняется в CI автоматически.

Заменят ли ИИ-агенты ревьюеров и тестировщиков?

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

С каких инструментов начать?

Хватит coding-агента вроде Claude Code, Cursor или OpenCode, репозитория с CI и файла спецификации рядом с кодом. Для спецификаций есть отдельные инструменты, например OpenSpec, который разбирают на курсе AI SDLC.

Что почитать

• Анатомия агентного харнесса (обвязки)

• Что такое инженерия контекста

• Год разработки с ИИ-агентами: главные выводы Кирилла Мокевнина

• ИИ-агент, ассистент и чат-бот: в чём разница

• Навыки разработчика, когда код пишет ИИ

• ИИ-агенты и RAG: как компании внедряют LLM

• Где учиться ИИ разработчику в 2026