ИИ уже изменил то, как пишется код, но он не обязательно изменил то, как поставляется программное обеспечение.
Разработчики автоматизируют всё большую часть своей индивидуальной работы, чтобы быстрее генерировать код и устранять проблемы. Но их результаты по-прежнему должны проходить через этапы требований, реализации, тестирования, ревью, развертывания и сопровождения. Ускорение одной части этого процесса дает мало результатов, если это просто означает более быстрое столкновение с следующим узким местом.
Это порождает более масштабный вопрос: нужно ли менять саму модель поставки программного обеспечения? И именно в этом заключается предпосылка Agentic SDLC. Вместо того чтобы разработчики использовали инструменты ИИ в рамках практически неизменного процесса поставки, автономные агенты берут на себя ответственность за определенные этапы поставки ПО. Хотя инженеры-люди по-прежнему несут ответственность за работу, им больше не нужно выполнять или контролировать каждый шаг.
Это гораздо более масштабная задача, чем внедрение еще одного инструмента для разработчиков. Agentic SDLC меняет то, где выполняется работа, как она продвигается по жизненному циклу разработки (SDLC), как команды осуществляют управление и, потенциально, как планируются инженерные мощности. По сути, сравнение agentic SDLC с традиционным SDLC сводится к выбору операционной модели.
В этом руководстве рассматривается этот выбор по шести измерениям: пропускная способность, качество, стоимость, управление, масштабируемость и прозрачность рентабельности инвестиций (ROI). В нем также рассматривается то, что организациям необходимо изменить для осуществления перехода, где человеческое суждение остается необходимым и как решить, подходит ли агентная модель для вашей инженерной организации.
Как выглядит традиционный SDLC в 2026 году (и почему он испытывает давление)
Традиционная поставка программного обеспечения остается в значительной степени последовательной на уровне рабочих элементов, даже когда использующие ее команды применяют методы Agile. После того как требования определены и оформлены в виде тикетов, инженеры проектируют и реализуют решение. Затем код переходит на этап тестирования и ревью, прежде чем дойти до развертывания и сопровождения.
Сам процесс не является проблемой. Эти этапы существуют по уважительным причинам, и каждый из них обеспечивает контроли, которыми поставка корпоративного ПО не может просто пренебречь. Но именно то, как работа перемещается между ними, создает узкие места. Разработчик может быстро закрыть тикет и все равно ждать часами или днями проверки. Точно так же pull request может пройти ревью, но в итоге оказаться в очереди на тестирование. Без достаточного покрытия автоматизированными тестами для проверки того, что изменение ничего не сломало в другом месте, даже небольшое изменение требует более тщательного тестирования, прежде чем его можно будет безопасно продвигать дальше. И когда несколько команд полагаются на одних и тех же профильных рецензентов, ресурсы контроля качества (QA) или окна релизов, эти задержки быстро накапливаются.
Результатом является знакомое несоответствие между производительностью разработчиков и пропускной способностью поставки. Ускорение работы инженера не делает систему быстрее автоматически. Именно здесь первая волна инструментов разработки на базе ИИ достигает своего естественного предела. Помощники по написанию кода доказали свою высокую полезность: они помогают инженерам генерировать, объяснять, рефакторить и отлаживать код. Они также могут сократить время, необходимое для выполнения отдельных задач. Но они кардинально не меняют то, как работа продвигается по SDLC.
Это становится еще более актуальным по мере роста индивидуальной производительности. Если реализация занимает меньше времени, а емкость тестирования остается неизменной, узкое место смещается на этап тестирования. Ускорьте тестирование без решения проблемы пропускной способности ревью, и в очередь на ревью попадет еще больше работы. Более быстрый этап не обязательно приводит к ускорению всего SDLC.
Существует три показателя, которые выявляют это структурное давление: Время от тикета до pull request (Ticket-to-PR time) показывает, сколько времени требуется для того, чтобы определенная работа превратилась в код, готовый к ревью. Долг по покрытию тестами (Test coverage debt) указывает на то, какую часть кодовой базы нельзя изменить с уверенностью из-за неполноты автоматизированной валидации. Глубина очереди ревью (Review queue depth) показывает, сколько завершенной работы ожидает внимания человека, прежде чем она сможет продвинуться дальше.
Все это не означает, что традиционный SDLC потерпел неудачу. Напротив, это открывает нечто очень полезное: увеличение пропускной способности поставки ПО требует нечто большего, чем просто помощь разработчикам в более быстром написании кода. ИИ также должен взять на себя определенную работу в рамках всей системы поставки.
Что на самом деле означает Agentic SDLC
Именно это и делает agentic SDLC. Он выводит ИИ за рамки помощи отдельным разработчикам в написании кода и переносит его в более широкий процесс поставки ПО. Вместо того чтобы ждать, пока разработчик подаст запрос инструменту ИИ, автономным агентам может быть назначена определенная работа, и они могут выполнять ее на одном или нескольких этапах SDLC с минимальным вмешательством человека.
Важным отличием здесь является автономность. Помощник по написанию кода помогает инженеру выполнить задачу. Агент получает задачу, определяет шаги, необходимые для ее выполнения, использует правильные инструменты, выполняет работу, проверяет результат и продвигает его к определенному результату. Разработчику не нужно постоянно руководить каждым шагом.
На организационном уровне происходит переход от «разработчик использует инструмент ИИ» к «команда управляет уровнем поставки с помощью ИИ». Вместо того чтобы отдельные инженеры решали, когда и как использовать ИИ, команды назначают работу наиболее подходящим агентам в рамках управляемой системы, интегрированной в их существующие инженерные рабочие процессы. Exadel Colleague предоставляет один из примеров такой модели на практике, где автономные агенты выполняют определенную работу по поставке программного обеспечения в рамках существующих инженерных рабочих процессов.
Это не означает передачу всего SDLC автономным агентам. Различные этапы требуют разного уровня участия человека. Агенты хорошо подходят для ограниченной, повторяемой работы, где задачу, ее контекст, ожидаемый результат и критерии проверки можно четко определить. Это включает в себя реализацию ограниченных по масштабу изменений, создание и запуск тестов, устранение выявленных дефектов, обновление документации и подготовку работы для проверки человеком.
Человеческое суждение остается критически важным там, где решения связаны с неопределенностью, архитектурой, бизнес-приоритетами, рисками или ответственностью. Инженеры по-прежнему определяют, что такое хорошо, устанавливают границы, в пределах которых действуют агенты, при необходимости проверяют работу и сохраняют полную ответственность за то, что попадает в продакшн.
Таким образом, определяющей чертой agentic SDLC является не то, что все становится автономным. А то, что автономность становится частью самой модели поставки.
Шесть измерений, которые меняются в Agentic SDLC
Разница выходит за рамки того, кто (или даже что) выполняет работу. Агентная доставка программного обеспечения меняет то, как команды думают о пропускной способности, качестве, стоимости, управлении, масштабируемости и том, как они измеряют производительность.
Пропускная способность: от последовательной работы к параллельному выполнению
Традиционная доставка программного обеспечения в значительной степени ограничена человеческими возможностями. Разработчик берет тикет, выполняет работу и переходит к следующему. Увеличение пропускной способности обычно означает повышение производительности разработчиков, перераспределение приоритетов работы или привлечение большего числа людей.
Агенты предлагают другую опцию: параллельное выполнение. Несколько агентов могут работать над разными тикетами или задачами по доставке одновременно. Если работа достаточно ограничена и хорошо определена, пропускная способность может увеличиваться без соразмерного роста штата инженеров. Но агентская доставка не обязательно устраняет узкие места. Она просто дает командам другой способ обойти или устранить их без привлечения дополнительных людей. Когда агенты выполняют несколько задач параллельно, ограничение может просто сместиться в сторону проверки человеком, согласований, сред тестирования или контроля развертывания.
Качество: от тестирования как этапа к валидации, встроенной в работу
Тестирование традиционно следует за реализацией и опирается на тот же ограниченный человеческий потенциал. Это создает узкие места и повышает вероятность пропуска дефектов. Агенты могут встроить валидацию в саму работу. Они могут генерировать и запускать тесты, проверять их результаты на соответствие заданным критериям приемки и устранять сбои перед тем, как двигаться дальше. Разработка через тестирование (TDD) также может стать обязательным этапом в рабочем процессе, а не просто рекомендуемой практикой.
Это не значит, что созданная агентами работа изначально имеет более высокое качество. Более быстрая генерация кода может создать дополнительную работу на последующих этапах, если она также привносит дефекты или технический долг. Преимущество заключается в том, что валидация становится воспроизводимой, и ее сложнее пропустить. Агенты могут выполнять одни и те же проверки при каждом изменении, реагировать на сбои и повторять цикл перед тем, как передать работу на проверку. Это позволяет перенести бóльшую часть контроля качества на более ранние этапы процесса доставки, вместо того чтобы полагаться на обнаружение дефектов позже силами контроля качества или ревьюеров.
Результат также становится проще измерять. Команды могут отслеживать показатели прохождения тестов, количество пропущенных дефектов, переделку и то, как часто рецензенты-люди возвращают созданную агентами работу на доработку.
Стоимость: от экономики штата к экономике вычислений
Традиционный потенциал доставки тесно связан со штатом инженеров. Для выполнения большего объема работы обычно требуется больше людей, больше времени или и то, и другое. Агентская доставка добавляет в уравнение вычислительные мощности. Вопрос заключается в том, какой объем валидированной инженерной работы может быть выполнен при определенном сочетании человеческих усилий и ИИ-вычислений, а не просто в том, сколько инженеров доступно.
Это не делает затраты на человеческий инженерный труд незначительными, но меняет расчеты. Командам необходимо учитывать, сколько человеческих усилий устраняют агенты, каковы затраты на вычисления и сколько человеческого контроля все еще требуется. Дешевые вычислительные мощности имеют мало значения, если инженер затем тратит много времени на проверку, исправление или переделку результата. Реальная экономическая выгода наступает тогда, когда агенты могут выполнять полезную, валидированную работу с меньшими общими затратами человеческих усилий.
Управление: от человеческих процессов к аудируемой активности агентов
Большая автономность делает управление более, а не менее важным. Командам нужно знать, что сделал агент, к чему у него был доступ, что он произвел и кто одобрил результат. Эта прослеживаемость должна быть заложена в систему доставки. Действия агентов, результаты, утверждения и передачи должны оставлять следы аудита, которые обеспечивают подотчетность, ответственность и соответствие требованиям. Главное отличие заключается в том, что управление должно успевать за автономным выполнением. Если агент может вносить изменения, вызывать инструменты или продвигать работу вперед без непрерывного надзора, необходимо определить его права доступа и точки согласования до того, как ему будет разрешено действовать.
Масштабируемость: от пропускной способности найма к пропускной способности выполнения
Инженерный потенциал сложно быстро масштабировать. Наем требует времени, в то время как требование к существующей команде взять на себя дополнительную работу в конечном итоге создает очередное узкое место. Агенты предлагают другой способ расширения возможностей. Как только задача или рабочий процесс определены для автономного выполнения, команды могут назначать больше работы без линейного увеличения численности персонала.
Это не делает возможности безграничными. По мере масштабирования выполнения агентами сопутствующая система должна масштабироваться вместе с ними. Больший объем работы может создать повышенный спрос на проверку людьми, среды тестирования, инфраструктуру, согласования или возможности выпуска. Преимущество заключается в том, что команды могут отделить возможности выполнения от численности персонала, а затем более четко увидеть, где находится следующее ограничение.
Наем и адаптация инженеров требуют времени. Как только агентский рабочий процесс доказал свою эффективность и был регламентирован, можно задействовать дополнительные мощности без прохождения через тот же цикл найма и адаптации.
Видимость рентабельности инвестиций: от метрик активности к экономическим результатам
Сторипоинты и скорость (velocity) показывают командам, какой объем работы продвигается через разработку. Они говорят гораздо меньше об экономике этой работы. Это становится гораздо важнее, когда потенциал доставки больше не привязан напрямую к численности персонала. Командам нужно знать не только то, сколько работы завершают агенты, но и во сколько обходится эта дополнительная мощность и сколько человеческих усилий она реально экономит.
Агентская доставка делает взаимосвязь между человеческими усилиями, стоимостью вычислений и завершенной инженерной работой более простой для измерения. Человеко-эквивалентные часы (HEH), например, оценивают время человеческого инженерного труда, которое в противном случае потребовалось бы для выполнения работы, проделанной агентами. Сравнение этого показателя со стоимостью работы таких агентов дает командам более четкое представление о созданном потенциале и о том, во сколько этот потенциал обходится.
Переход на агентский жизненный цикл разработки ПО (SDLC)
Цель трансформации SDLC заключается не в том, чтобы развернуть агентов повсеместно одновременно. Сначала нужно определить, где они могут безопасно выполнять полезную работу и что должно быть создано для их успеха.
Фаза 0: сначала оцените бэклог
Прежде чем менять систему доставки, оцените работу, которая уже проходит через нее. Цель состоит в том, чтобы определить, какие задачи имеют достаточно контекста для обработки агентами и где пробелы могут помешать надежному выполнению. Начните с бэклога. Достаточно ли детализированы тикеты в Jira? Являются ли критерии приемки четкими и последовательными? Является ли определение готовности (definition of done) явным? Может ли агент определить, что именно нужно изменить и как проверить результат, не прибегая к помощи человека?
Рассмотрим тикет на обновление конечной точки API с четко определенными критериями приемки, существующим покрытием тестами и задокументированными зависимостями. У агента есть четкая цель, достаточно контекста для внесения изменений и способ проверки результата. Тикет, который просто гласит: «улучшить производительность оформления заказа», — это другое дело. Желаемый результат может быть понятен на уровне бизнеса, но причина, масштаб, компромиссы и подходящее решение все еще требуют исследования и экспертной оценки. Сложность — не единственный фактор при определении готовности задачи для агента. У агента также должно быть достаточно контекста для действий и надежный способ понять, когда работа завершена.
Подготавливайте работу, а не только технологии
Агенты работают наиболее эффективно, когда получаемые ими задачи имеют четкие границы и проверяемые результаты. Поэтому чем яснее и последовательнее ваши процессы доставки, тем лучше агенты подготовлены к выполнению работы. Командам необходимы последовательная гигиена в Jira, четкие критерии приемки, явное определение готовности (definition of done) и достаточный технический контекст, чтобы агенты могли действовать независимо. Критерии тестирования и валидации также должны быть достаточно ясными, чтобы агенты могли подтвердить выполнение работы.
Идея заключается не в том, чтобы перепроектировать весь SDLC. Вам просто нужно сделать достаточно для того, чтобы подходящая работа могла быть назначена, выполнена и проверена агентами.
Как могут выглядеть первые 90 дней
Переход должен быть постепенным. Начните с ограниченных задач, посмотрите, что работает, и расширяйте автономность по мере продвижения.
Первые 30 дней: Оцените готовность бэклога, определите подходящие сценарии использования, установите базовый уровень доставки и подготовьте небольшой набор четко определенных задач для агентов.
Дни 31–60: Внедрите агентов в существующие инженерные рабочие процессы. Измеряйте результаты, определяйте, где все еще необходимо вмешательство человека, и уточняйте инструкции, средства контроля и критерии валидации на основе полученного опыта.
Дни 61–90: Расширьте использование агентов на дополнительные задачи или этапы, где это подтверждается результатами. Вы можете стандартизировать успешные паттерны, усилить управление и начать измерять влияние на пропускную способность, качество, затраты и инженерный потенциал.
К 90-му дню у вас должна быть рабочая, управляемая модель доставки с четкими доказательствами того, где автономность создает ценность, а где людям все еще необходимо оставаться в процессе.
Распространенные заблуждения об агентном SDLC
Агентный SDLC — это относительно новое направление, поэтому большую автономность часто ошибочно принимают за меньшее участие человека. Также легко недооценить то, что агенты могут сделать на самом деле. Вот три заблуждения, которые стоит развеять.
«Это заменяет инженеров»
Нет, это не так. Это меняет то, на что инженеры тратят свое время. Агенты могут брать на себя четко определенную, повторяемую работу, в то время как инженеры обеспечивают контекст, суждения, надзор и ответственность, на которых по-прежнему строится доставка программного обеспечения. Цель состоит в том, чтобы расширить инженерный потенциал, а не устранить инженеров.
«Это работает только для простых тикетов»
Простые, четко определенные тикеты — очевидная отправная точка, но это не предел. Агенты могут справляться с более сложной работой, когда цель ясна, доступен необходимый контекст, а результат может быть проверен. Сложность — не главное ограничение. Важно то, можно ли четко определить работу и надежно ее проверить.
«Это требует нового технологического стека»
Агентный SDLC не требует от команд замены инструментов и систем, которые они уже используют. Агенты могут работать в рамках существующих инженерных рабочих процессов и с использованием таких инструментов, как Jira, системы контроля версий, CI/CD-конвейеры и фреймворки для тестирования. Подход, ориентированный на Jira, — один из примеров. Работа может назначаться через те же тикеты, которые команды уже используют, в то время как агенты выполняют задачи по всей цепочке инструментов доставки.
Меняется не обязательно сам стек, а то, как работа перемещается по нему и кто — или что — выполняет эту работу.
Готова ли ваша команда к агентному SDLC?
Вам не нужно оптимизировать каждую часть вашего SDLC, но то, как вы работаете сейчас, определит, с чего можно начать и что агенты могут реально взять на себя. Пять вопросов помогут вам определить, готовы ли вы двигаться дальше.
1. Достаточно ли хорошо определен ваш бэклог?
Агентам нужна работа, которую они могут понять и выполнить. Ищите тикеты с четкими требованиями, достаточным контекстом, критериями приемки и явным определением готовности. Если большая часть бэклога все еще зависит от того, что инженеры заполняют пробелы, это потребует внимания в первую очередь.
2. Можно ли независимо проверить результат?
Автономность работает лучше всего, когда агент может определить, успешно ли он выполнил задачу. Это могут быть автоматизированные тесты, критерии приемки, контрольные точки качества или другой объективный способ проверки результата. Если успех в конечном итоге зависит от того, что кто-то скажет: «Выглядит неплохо», задача, вероятно, пока не подходит.
3. Доступны ли агентам ваши инженерные инструменты и рабочие процессы?
Агентам нужно больше, чем просто тикет. Им может потребоваться контролируемый доступ к исходному коду, инструментам тестирования, CI/CD-конвейерам, документации и другим частям цепочки инструментов доставки. Вам не нужен специальный стек, «готовый к ИИ», но агенты должны иметь возможность безопасно работать в том, который у вас уже есть.
4. Знаете ли вы, где людям нужно оставаться вовлеченными?
У автономности должны быть границы. Команды должны знать, какие действия агенты могут предпринимать автономно, какие требуют проверки или одобрения, и где человек должен принять окончательное решение. Эти границы не обязательно должны быть одинаковыми для каждой задачи, но они должны быть явными.
5. Можете ли вы измерить, работает ли это?
Прежде чем внедрять агентов, установите, с чем вы будете сравнивать их производительность. Это может включать время доставки, усилия человека, качество, затраты или пропускную способность. Без этой базовой линии вы не узнаете, улучшают ли они доставку или нет. Готовность редко бывает одинаковой во всей инженерной организации. Одна команда может иметь сильное покрытие автоматизированными тестами, дисциплинированную систему тикетов и хорошо задокументированные сервисы, в то время как другая сильно полагается на ручное тестирование и недокументированные знания. Даже в рамках одного бэклога некоторые виды работ будут гораздо лучше подходить для агентов, чем другие.
Вот почему цель состоит не в том, чтобы объявить организацию «готовой к агентам» или «не готовой». Ценность заключается в определении того, где автономность может работать прямо сейчас и что нужно изменить, прежде чем двигаться дальше.
Знайте, прежде чем брать на себя обязательства
Вам не нужно получать «да» на все пять вопросов, прежде чем начать. Оценка готовности может показать вам, какие части вашего бэклога подходят для агентов и где лежат лучшие возможности.
Она также устанавливает базовую линию для измерения того, что произойдет дальше. Результат предоставит достаточно доказательств для принятия практических решений: где внедрить автономность, что исправить в первую очередь и оправдывает ли ожидаемая ценность дальнейшие шаги.
Автор: Алексей Гиржадович, директор по корпоративному ИИ и решениям
Сентябрь 2026 г.
