Разработчики уже давно используют Claude Code, Codex, Cursor и другие ИИ-инструменты. Аналитики расшифровывают встречи и собирают требования с ИИ, QA генерируют тесты, руководители автоматизируют отчётность. Каждый отдельный этап ускоряется, но сама задача не всегда проходит путь от идеи до релиза быстрее. Контекст теряется между командами, результаты приходится переносить вручную, а единых правил и точек контроля нет.
Следующий шаг — связать эти инструменты в агентный SDLC. В такой модели специализированные ИИ-агенты участвуют во всём жизненном цикле разработки ПО: анализируют требования, помогают проектировать систему, пишут и проверяют код, запускают тесты, готовят релиз и разбирают данные эксплуатации. Ценность возникает не от количества агентов, а от того, насколько последовательно и управляемо они двигают задачу от одного этапа к другому.
В статье рассмотрим, какие этапы SDLC можно объединить в единый агентный процесс, как меняются роли разработчиков, архитекторов и руководителей, где нужно сохранить человеческий контроль и какие риски создают автономность, небезопасные зависимости и потеря управляемости.
Почему наличие AI-инструментов не формирует агентный SDLC
Разработчик с Claude Code или Cursor может быстрее подготовить код и запушить результать в репозиторий. Но дальше изменение всё равно попадает в прежний процесс: ждёт ревью, тестирования, согласования, деплоя в продакшен. Один специалист ускорился, но весь цикл почти не изменился. Иногда разработчик просто быстрее создаёт очередь для коллег.
В крупной компании ситуация становится ещё заметнее. У каждого свои модели, инструкции и рабочий контекст — результаты приходится копировать между сервисами вручную, а несколько подразделений могут независимо автоматизировать одну и ту же операцию. К примеру, сколько в вашей компании разных транскрибаторов записей встреч в департаментах?
В результате каждый инструмент приносит пользу, но они не образуют общего процесса. Агентный SDLC начинается там, где появляются единые данные, понятные форматы передачи результата, обязательные проверки и владельцы, отвечающие за каждый этап.
Как отдельные ИИ-агенты связываются в единый SDLC
В агентном SDLC бизнес-задача последовательно проходит через анализ, проектирование, разработку, тестирование и релиз. Данные эксплуатации возвращаются в следующую итерацию. На каждом этапе агент получает проверенные входные данные, выполняет свою часть работы и создаёт результат, который можно проверить, воспроизвести и передать дальше.
Анализ требований: от вводных к исполняемой спецификации
Первый агент собирает информацию из встреч, документов, задач и действующей системы. Он находит противоречия, формулирует уточняющие вопросы, описывает пользовательские сценарии и критерии приёмки.
На выходе появляется спецификация для следующих агентов: цель изменения, ограничения, затронутые процессы, требования к данным и признаки готового результата. Владелец продукта или аналитик проверяет, правильно ли система поняла бизнес-задачу.
Проектирование: от спецификации к плану реализации
Агент проектирования изучает архитектуру, кодовую базу, модели данных и интеграции. Он определяет затронутые компоненты, сравнивает варианты реализации и оценивает последствия каждого решения.
Результатом становится план: какие сервисы и модули нужно изменить, как будут передаваться данные, какие ограничения учесть и в какой последовательности выполнять работу. Решения, влияющие на надёжность, безопасность и дальнейшее развитие системы, принимает архитектор.
Разработка: выполнение задачи внутри заданных ограничений
Агент разработки получает утверждённую спецификацию, архитектурный план и правила репозитория. Он изучает существующий код, вносит изменения, обновляет документацию, запускает сборку и исправляет найденные ошибки.
На выходе — pull request с кодом, тестами и описанием изменений. Разработчик проверяет логику решения, соответствие архитектуре и понятность кода для команды, которая будет сопровождать систему.
Проверка и тестирование: независимый контроль результата
Код могут проверять несколько специализированных агентов. Один ищет дефекты и нарушения стиля, второй — уязвимости, третий — проблемы в зависимостях, четвёртый создаёт и запускает тестовые сценарии.
Один и тот же агент не пишет код и одновременно не признаёт собственную работу корректной — финальное решение о готовности изменения принимает инженер или QA, отвечающий за выпуск.
Релиз и сопровождение: работа продолжается после написания кода
Агенты анализируют результаты CI/CD, готовят описание релиза, проверяют состояние системы после развёртывания и сопоставляют новые ошибки с последними изменениями.
При инциденте агент собирает логи, определяет вероятную причину и предлагает откат или исправление. За действия в продакшн и их последствия отвечает назначенный владелец системы.
Связность такого SDLC держится на качестве переходов. Агент должен понимать, что именно он получил, что вправе изменить и в каком виде обязан передать результат дальше. Если эти правила не заданы, вместо конвейера получится цепочка плохо связанных чатов и скриптов.
Как это выглядит на одной задаче
Допустим, бизнес хочет добавить корпоративным клиентам оплату заказов по счёту. Аналитический агент получает запись встречи, текущие требования, документацию и сведения о действующей системе. Он описывает сценарии оплаты, ограничения и критерии приёмки. Аналитик проверяет и подтверждает спецификацию.
Агент проектирования изучает архитектуру и определяет, какие сервисы, модели данных и интеграции затронет изменение. Подготовленный им план проверяет архитектор.
После этого агент разработки получает утверждённые документы, меняет код, добавляет тесты и формирует pull request. Другие агенты независимо проверяют код, зависимости, безопасность и тестовые сценарии.
Если обнаруживается проблема, изменение возвращается на доработку с конкретным замечанием. После релиза агенты отслеживают ошибки и показатели новой функции, а собранные данные становятся вводными для следующей итерации.
Где лучше сохранять человеческий контроль
Человек остаётся владельцем результата при любом уровне автономности. Но это не значит, что инженер должен подтверждать каждую команду агента. Глубина контроля зависит от риска: где-то человек принимает каждое значимое решение, а где-то следит за процессом через автоматические проверки и подключается только при отклонениях.
При изменении архитектуры, схем данных, механизмов безопасности и production-среды человек должен оставаться внутри процесса. Типовые задачи с однозначной проверкой агент может выполнять самостоятельно — но только в заранее заданных границах и под наблюдением через тесты, логи и контрольные точки.
Полную автономность разумно оставлять для низкорисковых и обратимых операций: форматирования кода, обновления документации, подготовки release notes, диагностических проверок или небольших изменений в тестовой среде.
Главный критерий — цена ошибки. Чем выше возможный ущерб, сложнее автоматическая проверка и дороже откат, тем раньше к решению должен подключаться человек.
Как меняются роли
Агентный SDLC меняет работу всей команды. По мере того как рутинные операции переходят к ИИ-агентам, ценность смещается от механического выполнения задач к постановке, контролю и принятию решений.
Разработчики
Разработчик меньше времени тратит на написание типового кода вручную. На первый план выходят декомпозиция, постановка задач агентам, задание ограничений, проверка результата и разбор сложных отклонений.
Сильный инженер становится оператором нескольких параллельных процессов: один агент меняет backend, другой готовит тесты, третий анализирует зависимости. Ответственность за принятый код при этом остаётся у разработчика. Чем самостоятельнее работают агенты, тем важнее умение быстро понять чужое решение и заметить ошибку, которую пропустили автоматические проверки.
Аналитики
Качество работы аналитика напрямую влияет на весь агентный конвейер. Неполное или двусмысленное требование быстро проходит дальше — в архитектуру, код и тесты.
Поэтому аналитик готовит контекст, который одинаково понимают люди и агенты: фиксирует бизнес-цель, сценарии, ограничения, данные и критерии приёмки. Хорошая спецификация становится одним из главных производственных артефактов.
QA
Работа QA смещается от ручной проверки отдельных сценариев к проектированию всей системы контроля качества. Нужно определить, что проверяется автоматически, где требуется независимая оценка и какие ошибки должны останавливать движение задачи по конвейеру.
ИИ-агенты могут генерировать тесты, искать регрессии и анализировать дефекты. QA отвечает за то, чтобы проверки покрывали критичные сценарии, а зелёный статус не создавал ложного чувства качества.
Руководители разработки
Руководитель управляет производительностью связки «люди + агенты». Помимо загрузки команды он отслеживает скорость прохождения задач через SDLC, стоимость моделей, количество возвратов, качество автоматических проверок и допустимый уровень автономности.
Ещё одна задача — не допустить локальной оптимизации, когда один участок ускорился в несколько раз, а следующий превратился в новое узкое место.
CEO и CTO
Для CEO и CTO агентный SDLC — вопрос экономики и управляемости разработки. Им нужно решить, какие процессы автоматизировать в первую очередь, где ускорение действительно влияет на time-to-market, а где возможная экономия не оправдывает цену ошибки.
CTO задаёт технологические границы и отвечает за безопасность и качество инженерного процесса. CEO следит, чтобы рост производительности превращался в бизнес-результат: более быстрый запуск функций, снижение стоимости разработки или возможность делать больше прежней командой.
Изменение ролей требует и новых критериев эффективности. Ведь объём написанного кода в случае с агентным SDLC почти ничего не говорит о результате.
Как измерять эффективность агентного SDLC
Измерять нужно весь путь изменения — от утверждённой задачи до выхода в рабочую среду. Для начала достаточно пяти показателей:
- - время от утверждения спецификации до релиза;
- - доля изменений, которые возвращаются на доработку после проверки;
- - время, которое инженеры тратят на проверку результатов агентов;
- - стоимость принятого изменения с учётом моделей и человеческой работы;
- - доля релизов, после которых потребовалось исправление или откат.
Если код появляется в три раза быстрее, а задача по-прежнему две недели ждёт проверки и релиза, производительность SDLC стремится к нулю. Ключевая метрика здесь — Time to Market: сколько времени проходит от постановки задачи до выхода работающего изменения. Вместе с ней стоит отслеживать стоимость изменений и качество релизов. Так можно оценивать эффективность всего SDLC и видеть, на каком участке появляется новое узкое место.
Риски агентной разработки ПО
Агентный SDLC не только ускоряет разработку, но и увеличивает масштаб последствий ошибки. Чем больше действий агенты выполняют самостоятельно и чем теснее они связаны, тем важнее заранее ограничить их полномочия и сделать работу системы наблюдаемой.
Избыточные полномочия
Агенту легко выдать больше доступа, чем требует задача: к репозиториям, базам данных, облачной инфраструктуре, закрытой информации или рабочей среде. Тогда обычная ошибка модели превращается в операционный или информационный инцидент.
Права нужно ограничивать конкретной задачей и средой. Если для анализа pull request агенту не нужен доступ к производственной среде, такого доступа у него быть не должно.
Ошибка проходит дальше по конвейеру
В связанном SDLC результат одного агента становится входными данными для следующего. Неправильно понятое требование превращается в ошибочное архитектурное решение, затем — в код и тесты, которые успешно проверяют неправильное поведение.
Чем дальше такая ошибка проходит по цепочке, тем дороже её обнаружить и исправить. Поэтому требования, архитектурные решения и миграции данных нуждаются в отдельных точках проверки.
Небезопасные зависимости
ИИ-агенты охотно используют готовые библиотеки и пакеты. Они могут выбрать уязвимую версию, малоизвестную зависимость или пакет, появившийся совсем недавно.
Поэтому версии нужно фиксировать, зависимости — автоматически проверять на уязвимости, а подключение новых пакетов — ограничивать и контролировать.
Ложное ощущение качества
ИИ умеет создавать аккуратный код, тесты, документацию и убедительные объяснения. Всё выглядит законченным: сборка проходит, тесты зелёные, pull request оформлен. Эта гладкость опасна — хорошую упаковку легко принять за готовность к эксплуатации.
Проблемы проявляются позже: решение усложняет архитектуру, дублирует существующую логику или не учитывает редкие сценарии. Поэтому проверять нужно не только формальные признаки качества, но и соответствие исходной задаче, ожидаемому результату и требованиям системы.
Потеря управляемости
В компании быстро накапливаются модели, агенты, инструкции, интеграции и автоматические сценарии. Без единого реестра становится невозможно понять, кто имеет доступ к данным, какие действия выполняет, сколько это стоит и кто отвечает за результат.
Для CTO агентный SDLC должен оставаться наблюдаемой системой: с владельцами, журналами действий, версиями инструкций, лимитами и понятными правилами эскалации.
Ускоренный рост технического долга
Агенты увеличивают объём изменений быстрее, чем команда успевает их осмыслить. В коде накапливаются дублирование, обходные решения, лишние зависимости и отклонения от архитектуры.
Поэтому агентная разработка требует регулярного рефакторинга ИИ-кода и постоянного архитектурного контроля. Без них выигрыш в скорости быстро превращается в рост стоимости сопровождения.
Потеря понимания системы
Если инженеры постоянно принимают готовые решения агента, со временем команда перестаёт понимать, почему система устроена именно так. Особенно остро это проявляется при инцидентах, миграциях и нетиповых изменениях, когда готового сценария уже нет.
Критичные части системы должны оставаться понятными людям: архитектурные решения фиксируются, код проходит осмысленное review, а знания не остаются только в истории диалогов с моделью.
Размывание ответственности
Агент не отвечает за сорванный релиз, потерянные данные или уязвимость в рабочей среде. Ответственность остаётся у людей и компании.
У каждого автоматизированного процесса нужен владелец, который задаёт границы автономности, принимает критические результаты и подключается при отклонениях. Формулировка «это сделал ИИ» в инженерном процессе недопустима.
Как понять, что компания готова к агентному SDLC
Агентный цикл имеет смысл строить поверх уже управляемой разработки. Если команда плохо понимает, как задача проходит путь от требований до релиза, ИИ-агенты не исправят процесс — они быстрее усилят его слабые места.
Признаки готовности компании к агентному SDLC:
- - процессы разработки описаны и понятны участникам команды;
- - требования фиксируются в едином и понятном формате;
- - документация актуальна и доступна агентам;
- - CI/CD работает стабильно;
- - ключевые проверки и тесты автоматизированы;
- - права доступа управляются и выдаются по необходимости;
- - изменения проходят через pull request и фиксируются в истории;
- - критичные действия можно быстро откатить;
- - действия агентов журналируются и доступны для разбора;
- - у каждого этапа и результата есть конкретный владелец;
- - команда способна измерять скорость, качество и количество возвратов.
Не нужно доводить каждый пункт до идеала перед первым пилотом, но зрелость базы определяет допустимую автономность. Если документация устарела, тестов мало, а процессы хаотичны, начинать стоит с узкого и обратимого сценария, а не со сквозной автоматизации всего SDLC.
Заключение
ИИ-ассистенты отлично ускоряют отдельных специалистов, но если нужна гарантированная скорость на всём пути разработки — нужен агентный SDLC. Это принципиально разные уровни результата.
Зрелость агентной разработки определяется способностью людей и ИИ предсказуемо доводить изменения до эксплуатации: без потери контекста, с понятными границами автономности, обязательными проверками и ответственностью за результат.
Выиграют компании, которые выстроят такой процесс раньше конкурентов. Остальные рискуют получить объемы быстро созданного кода, новые узкие места и более дорогую в сопровождении систему.
