Как должен выглядеть Agentic SDLC

Продолжение темы с прошлого поста. В комментах был запрос на объяснение AI SDLC, так что рассказываю.

Для начала, стоит сказать, что Agentic SDLC, AI SDLC, agentic software development, agentic driven development – это всё одно и тоже. Про использование AI в разработке софта.

Кстати, тут Anthropic несколько недель назад выпустили статью про AI-native SDLC, которая по факту является рекламой и шоукейсом для их продуктов, но общее понимание сути трансформации она даёт, так что рекомендую полистать буклет.

Из чего состоит цикл SDLC?

Тут стоит упомянуть, что вообще, ещё существует цикл Product Development Life Cycle (PDLC). И SDLC – это всего лишь одно звено этого цикла – Implement.

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

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

И так, на вход в SDLC поступает задача от бизнеса и она проходит обычно следующие стадии:

1. Analysis & Research — понять, что именно нужно изменить

Классика: аналитик и разработчик уточняли задачу у бизнеса, изучали код и документацию, выясняли ограничения, зависимости и edge cases.

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

2. Solution Design — решить, как изменить систему

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

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

3. Implementation Planning — превратить решение в исполняемый план

Классика: разработчики и техлид разбивали решение на задачи, определяли зависимости, порядок работы, исполнителей и способы проверки.

Agentic: агент готовит окончательный план из черновика, декомпозирует его на milestones с критериями приёмки и тестами. Человек проверяет критические места.

4. Implementation — выполнить план

Классика: код, тесты (вряд ли), документацию (очень вряд ли) разработчики писали код.

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

5. Verification & Integration — проверить корректность и объединить изменения

Классика: разработчики проводили code review и объединяли ветки, QA проверяли сценарии и регрессии. Тесты и CI давали автоматическую обратную связь.

Agentic: агенты проводят независимеы ревью вдоль и поперёк PR. Проблемы возвращаются на исправление. Человек разбирает критичные места и принимает результат, когда всё остальное уже отработало.

6. Release & Deployment — довести изменение до production

Классика: разработчик или DevOps/SRE выпускал изменение через CI/CD, следил за миграциями и состоянием приложения, восстанавливал систему при сбое.

Agentic: CI/CD выполняет выпуск, агент помогает человеку проверять готовность, результаты деплоя и работу исходного сценария.

7. Maintenance & Evolution — поддерживать и развивать систему

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

Agentic: агент реагирует на алерты системы; исследует проблемы по данным мониторинга; проводит регулярные аудиты по кодовой базе. Человек выбирает приоритеты и проверяет основания для изменений. Подтверждённые задачи запускают новый цикл SDLC.

---

Если у вас сейчас разработка с агентами работает не так, то нужно что-то менять :) Потому что только так можно добиться снижения TTM, cost per unit и повышения throughput боевых единиц.

Тут конечно стоит добавить что у каждой компании набор этих звеньев, их название, исполняющие роли – свои.

А сложность этого процесса сейчас заключается в том, чтобы правильно переложить обязанности по ролям - чтобы и людей просто так не уволить и в тоже время чтобы не было такого, что вся работа QA с AI агентами заключается в том, что он берет ТЗшку для разраба и отправляет ее в кодекс со словами "возьми ветку от разраба, вот этот ТЗ и выпиши чо он там пропустил и не выполнил". Такая работа сейчас заменяется даже не скиллом, а одним .md блоком из 10-15 строчек в этом скилле :)

Лайк, репост,
✔️ Тимур Хахалев про AI Coding, подписывайтесь!