Ленты новостей последние пару лет носят Copilot и его друзей на руках. Кажется, что главная революция уже случилась, разработчики получили автодополнение на стероидах, генерацию функций по описанию и почти волшебство в IDE. Но есть одно «но». Если честно посмотреть на процессы, выясняется, что код у многих команд действительно стал писаться быстрее — а вот релизы выходят почти с той же скоростью, что и три года назад. Бутылочные горлышки просто переехали в другие части жизненного цикла разработки (SDLC).

Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG, рассказывает о том, что происходит дальше, когда от ассистентов по коду мир постепенно переходит к AI‑агентам: автономным исполнителям задач внутри SDLC. И о том, почему это меняет не только инструменты, но и роли в командах.

Как всё развивалось

Пройдемся по хронологии.

Фаза 1: ассистенты по кодированию

Если отмотать назад к 2023–2024 годам, картина была относительно простой. В IDE поселились умные подсказчики. Решения типа Copilot научились дописывать функции, подбрасывать варианты реализации, генерировать модульные тесты и иногда даже объяснять легаси‑код. Разработчик при этом остался в центре. Он формулирует запрос: «напиши функцию, которая делает вот это», «сгенерируй тесты к этому методу». AI отвечает, но ответственность за результат всё равно остаётся на человеке.

SDLC почти не поменялся, появился новый инструмент в одной точке процесса — на этапе кодирования. Всё остальное (требования, планирование, тестирование, релизы) работает по старым схемам. Эта фаза дала реальное ускорение локальных задач. Но довольно быстро стало понятно, что просто сделать IDE умнее — недостаточно.

Фаза 2: выход за пределы кода

К 2025 году AI начал потихоньку расползаться по соседним областям, например:

• Документация — генерация README, описаний API, черновиков технических спецификаций.

• Дизайн — подсказки по архитектуре, наводящие вопросы по разбору требований, эскизы интерфейсов.

• Тесты — больше генерации сценариев, помощь в автоматизации регрессии, поиск граничных условий.

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

И вот тут начинает возникать вопрос: если AI уже умеет писать код, помогать с тестами и документацией, почему бы не дать ему более крупную роль?

Фаза 3: агенты на всех этапах SDLC

2026 год стал моментом, когда этот вопрос перестал быть теорией. Подход смещается от «ассистент отвечает на запрос» к «агент выполняет задачу». Вместо того чтобы просить один инструмент «сгенерируй код вот сюда», команда формулирует намерение: сделать вот такую фичу, собрать вот такой дашборд, вытащить наверх самые важные задачи из бэклога.

Дальше получается такая цепочка:

• один агент собирает и уточняет требования;

• другой превращает их в спецификацию;

• третий пишет код;

• четвёртый проверяет его;

• пятый генерирует и прогоняет тесты;

• шестой помогает собрать и выкатить на нужный стенд.

Люди никуда не деваются — они остаются теми, кто задаёт направление, ставит гейты контроля и принимает решение, что результат норм. Но большая часть рутинной, повторяемой работы по дороге от идеи до работающего артефакта начинает выполняться агентами.

Что такое agentic‑разработка сейчас

В терминах рынка это уже называют agentic software development. Определений много, но по‑человечески это можно описать так:

Agentic‑разработка — это когда в вашей команде появляются AI‑участники с чёткими ролями и ответственностью, а SDLC перестаёт быть процессом «человек → ассистент → человек» и превращается в оркестр людей и агентов.

Главные отличия от привычных ассистентов:

• Агент не просто выдаёт кусок кода в ответ на запрос, а берёт на себя задачу: декомпозирует её, делает шаги, собирает артефакты, возвращается к человеку с результатом и, при необходимости, повторяет цикл.

• Охватывает весь SDLC: агенты всё чаще отвечают за анализ требований, сборку плана, подготовку тест‑плана, базовое ревью и даже простые деплои.

• Агент работает вместе с профессионалами, а не вместо них. Целевая аудитория таких систем — команды, которые живут в сложных кодовых базах, где одних подсказок в IDE мало. Там агенты становятся цифровыми коллегами, а не игрушками для одиночных экспериментов. У них есть роли («аналитик требований», «кодер», «ревьюер», «тестировщик»), свои ограничения и свой кусок контекста. Чем чётче это описано, тем меньше вероятность того, что система уйдёт в галлюцинации.

Как меняются роли: разработчик, тестировщик, архитектор

Следующий логичный вопрос — если в команде появляются агенты, что будет с классическими ролями?

Разработчик → оркестратор

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

• постановка задач, то есть умение формулировать намерение так, чтобы агент его понял и не ушёл в сторону;

• настройка границ: указать, что можно, что нельзя, какие ограничения по архитектуре и безопасности;

• валидация результатов работы агентов;

• думать процессами, а не только функциями.

Тестировщик → супервайзер агентов

Классическая работа тестировщика — писать сценарии, гонять тесты, разбирать отчёты — постепенно дополняется новой задачей: управлять агентами тестирования. То есть надо задавать цели по качеству, выбирать, какие части системы могут быть проверены агентами и где нужен человек, следить за тем, чтобы тестировались не только «обычные» фичи, но и сами AI‑компоненты.

Важно не упустить и гейты контроля, то есть точки, где человеческий взгляд обязателен, будь то требования, тест‑план или итоговые результаты.

Архитектор → инженер контекста

Архитекторы и senior‑инженеры становятся инженерами контекста, они задают рамки, в которых могут работать агенты. Также продумывают, какие данные агентам доступны, какие ограничения по безопасности и производительности, и отвечают за то, чтобы агенты не ломали архитектурные принципы системы. Появляется новая ответственность проектировать систему и для людей, и для цифровых участников, которые тоже будут принимать решения.

И ещё одно «но»: сеньоры всё равно нужны

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

Почему точечные AI‑инструменты не вытягивают

Теперь к неприятной части: многие команды уже попробовали добавить AI в разработку и остались слегка разочарованы.

Часто история выглядит так:

• внедрили ассистента по коду — скорость локальных задач выросла;

• реальные релизы всё равно проходят через те же согласования, тесты, ручные проверки;

• итоговый прирост по time‑to‑market и throughput команды заметно ниже ожиданий.

Исследования и практика дают похожие цифры: создание кода может ускориться на 30–40%, но если планирование, тестирование и релиз делаются вручную, общий прирост продуктивности команды часто меньше 10%. По телеметрии Faros (2026), AI-ассистенты дают ощутимый прирост на уровне человека — больше закрытых задач, больше смёрдженных PR. При этом время на ревью PR выросло на 441% в 2026 году, а в 2025 — на 91%. Бутылочное горлышко на этом этапе сузилось.

Agentic‑подход позволяет применять AI последовательно на нескольких стадиях SDLC: анализ, планирование, реализация, тесты, доставка. При этом можно автоматизировать и часть переходов между этапами, когда не человек вручную передаёт артефакты дальше, а агенты сами подхватывают их по событиям и правилам.

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

Последний кусок пазла — инфраструктура. Можно, конечно, собрать «зоопарк» из ассистентов, агентов, оркестраторов, собственных скриптов и интеграций. Но чем сложнее сценарий, тем выше ценность платформенного подхода.

Что обычно включает в себя платформа под agentic‑разработку:

• Оркестрацию нескольких агентов.
  Один умный агент — это уже неплохо, но серьёзные сценарии требуют цепочек: аналитик, архитектор, кодер, ревьюер, тестировщик, операционный агент.

• Сквозной контекст и память.
  Возможность складывать накопленный опыт, например, удачные паттерны, типовые ошибки, особенности домена, в память, которую агенты учитывают в следующих задачах.

• Интеграцию с SDLC‑инфраструктурой.
  Система контроля версий, CI/CD, мониторинг, трекинг задач — всё это становится источником событий и данных для агентов.

• Механизмы управления качеством и рисками.
  Логи, трассировка действий агентов, метрики эффективности, гейты, где человек обязан вмешаться.

Когда нет единой платформы, каждый инструмент работает со своей памятью контекста, логами и правилами доступа. Из-за этого начинаются типичные проблемы фрагментированной инфраструктуры — сложнее отлаживать сбои на стыках систем, дороже поддерживать интеграции и почти невозможно построить сквозную трассировку, кто из агентов и когда принял решение. По данным исследования DORA, внедрение AI связано со снижением пропускной способности доставки примерно на 1,5% и стабильности на 7,2%, а итог определяют зрелость платформенной инженерии и малый размер изменений. Поэтому лидеры рынка сейчас не столько выбирают коробочного вендора, сколько закладывают архитектурный принцип: агенты подключаются к общей шине данных и контроля, а не живут каждый в своём изолированном контуре.

Кратко

С точки зрения управленцев картина примерно такая:

• эксперименты с ассистентами по коду — уже норма, а не инновация;

• реальный эффект появляется там, где AI накрывает сразу несколько стадий SDLC;

• роли в командах меняются — разработчики, тестировщики, архитекторы всё больше становятся оркестраторами цифровых участников;

• точечные AI‑инструменты не дают кратного роста, если остальные части процесса остаются прежними.

Поэтому в 2026 году вопрос уже звучит не «нужно ли нам что‑то с AI», а «как мы будем перестраивать SDLC под совместную работу людей и агентов». И чем раньше у команды появится внятная стратегия, тем меньше шансов оказаться в ситуации, когда вокруг уже бегают автономные системы, а ваши процессы всё ещё живут в 2020‑м.

А в вашей команде уже пробовали передавать агентам целые этапы SDLC, а не только код? Что сработало, а что провалилось?