Агентный SDLC: жизненный цикл разработки, перестроенный вокруг агентов
Агентный SDLC (agentic SDLC) — это жизненный цикл разработки ПО, перестроенный вокруг AI-агентов. Заставить одного агента взять тикет, написать код, прогнать тесты и открыть pull request — уже решённая задача. Настоящий вопрос в другом: что происходит, когда агенты работают в масштабах реальной организации, — именно это определяет, станет ли агентный SDLC преимуществом или тихо превратится в хаос.
Суть концепции автор гайда — CEO Port Зоар Эйни (Zohar Einy) — сводит к трём пунктам:
- Что это: агенты ведут весь жизненный цикл — планирование, код, тесты, ревью, релиз, эксплуатацию и стандарты. Работа инженера смещается к постановке намерения, ревью и управлению.
- Где сложно: один агент — просто, десятки в реальной организации — нет. Этот разрыв автор называет «агентным хаосом».
- Что реально выигрывает: не самый хитрый агент (это становится commodity), а control plane под ним — контекст, human-in-the-loop, guardrails, видимость и ROI.
Ассистент или агент: кто за рулём
Разница — в том, кто ведёт процесс. С ассистентом за рулём вы: он предлагает, вы принимаете или отклоняете, и код, и решения остаются вашими. Агент работает иначе: вы даёте цель — «исправь баг», «сделай эндпоинт» — и он идёт к ней через множество шагов без вашего контроля каждого: читает код, меняет, запускает тесты, разбирает падения, чинит собственную работу. Вы задаёте намерение в начале и оцениваете результат в конце. Всё, что между, — раньше основная часть профессии, — теперь работа агента.
Традиционный SDLC против агентного
Агентный SDLC не отменяет привычный жизненный цикл: этапы те же, меняется работа внутри них — и то, что остаётся в руках команды:
| Этап | Традиционный SDLC | Агентный SDLC | Что остаётся команде |
|---|---|---|---|
| Планирование | Инженер читает тикет, пишет спецификацию | Агент обогащает тикет контекстом, готовит спеку и дизайн | Уточнить намерение, утвердить план до кода |
| Разработка | Инженер пишет код построчно | Агент читает репозиторий, вносит изменения, открывает PR | Сформулировать задачу, ревьюить diff |
| Тестирование | Инженер пишет и отлаживает тесты | Агент генерирует тесты, читает падения, чинит свой код | Определить, что значит «протестировано достаточно» |
| Ревью | Человек читает diff другого человека | Агент помечает риски и нарушения стандартов, решение за человеком | Владеть решением о merge |
| Релиз | Инженер следит за раскаткой | Агент оценивает риск, катит за флагом, откатывает при регрессии | Задать политику релизов, держать kill switch |
| Эксплуатация | Дежурный вручную разбирает алерты | Агент триажит, предлагает фикс, пейджит с причиной | Одобрять фиксы, которые агент не должен делать сам |
Стандарты — сквозная работа, а не этап: когда агенты действуют сотни раз в день, проверка «воротами» в конце слишком поздна — она должна запускаться на каждом действии.
Метрики двигаются в обе стороны. Управляемый агентный SDLC улучшает и DORA, и SPACE; неуправляемый ухудшает change failure rate и MTTR, потому что некому перехватить плохое изменение до того, как оно разойдётся. Для хорошо настроенного процесса автор приводит такой сдвиг:
| Метрика | Традиционный SDLC | Агентный SDLC |
|---|---|---|
| Lead time for changes | Дни–недели | Часы |
| Deployment frequency | Еженедельно или по запросу | Много раз в день |
| Change failure rate | Базовый уровень | Ниже |
| MTTR | Часы | Минуты |
Что агенты делают на каждом этапе
Планирование. Приходит тикет «пользователи жалуются на медленный checkout». Planning-агент подтягивает связанные сервисы из context lake — живой модели инженерного ландшафта: сервисы, владельцы, зависимости, свежие релизы. Видит, что checkout вызывает payments- и fraud-сервисы, читает данные по латентности и готовит техспеку с вероятной причиной и списком файлов. Инженер получает настоящий план вместо тикета из одной строки.
Разработка. Кодинг-агент вроде Claude Code или Cursor добавляет кэш к вызову fraud-check, обновляет конфиг и открывает pull request. Дальше ничего нового: PR идёт через тот же CI/CD-пайплайн, который уже построила DevOps-команда. Задача агента — выдать чистое, ревьюимое изменение.
Тестирование. Агент пишет тесты для нового кэша и ловит провал: под нагрузкой кэш возвращает устаревшие fraud-оценки. Он читает stack trace, воспроизводит кейс, добавляет TTL и перезапускает, пока всё не станет зелёным. Этот цикл «написал — запустил — разобрал падение — починил» и отличает работающего агента от того, кто уверенно катит баг.
Ревью. Review-агент проверяет diff на соответствие стандартам до того, как его откроет человек: прогоняет через production-readiness scorecard и оставляет комментарии — кэш не экспортирует метрику, у него нет владельца, TTL захардкожен. Человек тратит внимание на единственный вопрос, где нужен интеллект: допустимо ли в принципе кэшировать fraud-оценки.
Релиз. Release-агент собирает контекст изменения, оценивает риск, публикует в Slack для выбора стратегии раскатки (canary, feature flag, blue-green), катит на малый срез трафика и следит за ошибками и латентностью. Метрики держатся — наращивает; нет — откатывается сам.
Эксплуатация. Через две недели Datadog поднимает алерт на fraud-сервис. Operations-агент связывает его с последним деплоем, указывает на кэш, готовит откат конфига и пейджит дежурного через PagerDuty с причиной и готовым фиксом. Человек одобряет решение вместо того, чтобы строить его с нуля посреди ночи.
Каждый сценарий по отдельности работает уже сегодня. Ломается всё на связке между ними — именно там умирает большинство агентных SDLC.
Три фазы индустрии и «агентный хаос»
Автор выделяет три фазы:
- Ручная разработка — люди пишут каждую строку, инструменты только линтят. Почти исчезла.
- AI-ассистированная — копилоты подсказывают, человек за рулём. Здесь большинство команд сегодня.
- AI-ведомая — агенты делают работу по всему циклу, люди задают намерение и управляют. Единичные команды, почти никто org-wide.
Разрыв между второй и третьей фазой — самое трудное место. Во второй агент работает на ноутбуке одного разработчика, и ущерб останавливается на его машине. В третьей агенты действуют на общих системах, с реальными кредами, на проде — десятками одновременно, и радиус поражения — вся организация. Именно здесь начинается «агентный хаос»: агенты через MCP подключают всё, до чего дотягиваются; контекст возвращается рваным — устаревшие владельцы, половина картины, противоречивые источники. Агент делает уверенный неверный вывод, сжигая токены, и действует по нему: бьёт не в тот сервис, выполняет разрушительную операцию, катит неаппрувленный change. Когда что-то ломается, никто не может проследить, какой агент это сделал, с чьих кредов и почему. А затем руководство спрашивает: что всё это AI-вложение реально даёт бизнесу?
Семь блоков, без которых агентный SDLC не живёт в проде
Агент сам по себе — маленькая коробка: несколько вызовов модели, промпт, определения тулов. Вокруг неё — семь блоков, каждый из которых — работа, о которой не думают, пока строят демо:
- Интеграции. Агенты должны достучаться до CI/CD, облака, инцидент-тулинга, репозиториев, секретов. Без центрального слоя каждая команда заводит свои креды, а одно изменение GitLab API заставляет шесть команд дебажить одну поломку по отдельности. MCP стандартизирует вызов тула, но не управляет кредами и не переживает изменение API.
- Context lake. Нужны два вида контекста: живой рантайм-контекст (кто владелец, что недавно релизилось) и decision traces — записи о том, что уже пробовали и почему. Без трейсов агент заново открывает PR, который другой агент получил отказ на прошлой неделе. Статический agents.md устаревает в момент смены владельца.
- Реестр агентов. Агентов уже в разы больше, чем сотрудников; их создают ежедневно в Cursor, Claude Code, n8n. Пока их не видно, их нельзя шерить, говернить и аудировать. Каждый должен стартовать из шаблона: владелец, тулы, затрагиваемые сервисы, состояние жизненного цикла.
- Метрики. SRE нужна наблюдаемость (что сделал агент, где порвалась цепочка), ML-инженеру — evals, руководству — деньги. Траты считаются атрибуцией токенов по агентам и командам, но ROI появляется, только когда их связывают с исходами: закрытыми тикетами, сэкономленными часами, предотвращёнными инцидентами.
- Human-in-the-loop. Деплой-агент может бегать свободно в стейджинге, но требовать аппрува на проде. Захардкоженные Slack-аппрувы не выживут при 100 агентах в 20 командах: нужны чекпоинты, заданные в одном месте, и общий экран, где видно работу агентов.
- Governance. Агент, собранный локально, наследует креды создателя — обычно без ревью. Governance — это правила в одном месте, мгновенное отключение скомпрометированного тула у всех агентов, аудит «кто что сделал с чьими кредами» и лимиты расходов, чтобы агент в retry-петле не сжигал бюджет.
- Оркестрация. Реальный воркфлоу — цепочка агентов, тулов и людей, и беда живёт в хэндоффах: если triage-агент ошибся, rollback-агент чинит не то. CI/CD-пайплайн предсказуем, у каждого шага фиксированные вход и выход; у агентных цепочек нет — одна правка промпта тихо ломает всю цепочку.
Хаос уходит, только когда все семь блоков живут в одном месте и говернятся вместе. Это и есть платформа агентной разработки — control plane, на котором строится агентный SDLC. Сам кодинг-агент становится commodity: через год разрыв между топовыми моделями будет сноской.
Роль platform engineering
Задача платформенной команды — построить control plane и сделать его достаточно хорошим, чтобы разработчики выбрали его сами, а не обходили. Старая сделка «самосервис плюс стандарты» сломалась: разработчики стали строителями агентных воркфлоу и не стали ждать разрешения, потому что Cursor и Claude Code запускаются локально. Результат — agent sprawl: агенты без аудита, без уважения к PII, с наследованными кредами.
У платформенной команды три варианта, и работает только один: ничего не делать (sprawl побеждает), всё запретить (бунт — тулы уже у разработчиков) или сделать платформу местом, где действительно хочется строить: discovery данных и интеграций до старта, стартовые шаблоны и форки скиллов для быстрых побед, реестр, где хорошая работа накапливается, как в open source. Сделанное хорошо, governance — не то, что тормозит, а то, что позволяет двигаться быстро и не пострадать.
Роль инженера
Работа инженера меняется сильнее, чем сокращается. Цикл был: взять тикет, собрать контекст, написать код, чинить. Стал: понять лучший способ решения, сформулировать задачу так, чтобы агент мог по ней бежать, и оценить результат. Навыки сдвигаются на уровень выше: выбирать переиспользуемое решение, а не одноразовое; формулировать намерение точно, чтобы агент не уплыл; ревьюить сверху — держится ли дизайн в масштабе, верный ли подход, а не просто «тесты зелёные».
Рычаг растёт: один инженер, направляющий и ревьюящий флот агентов, выпускает то, что раньше выпускала команда. Страх «AI заменит разработчиков» промахивается мимо того, где всегда были сложные места: они никогда не были в наборе текста — а исчезает именно он.
Итог
Выиграют не команды с самым хитрым агентом, а те, кто построил место, где агентам можно работать: общий контекст, скоупированный доступ, человеческие чекпоинты, полная запись действий. Сделаете — агентный SDLC станет самым большим рычагом инженерной организации за последние годы. Пропустите — получите хаос, который дорого расчищать потом.