Как меняется delivery, когда в команде появляются агенты

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

Команды обычно приходят к формализованному процессу поставки не из любви к процессам, а тогда, когда нужно получать предсказуемые сроки, управляемый риск и воспроизводимый результат. В серии статей на примере RuStore ^[1] я уже разбирал такой процесс: kick-off, архитектурную проработку через ADR, technical design, реализацию, review и testing, затем pre-launch, post-launch и передачу изменений в эксплуатацию. Сам по себе этот процесс никуда не исчезает и вряд ли исчезнет в ближайшее время: он по‑прежнему нужен, если мы хотим стабильно доводить изменения до продакшена.

Но за последнее время изменилось базовое допущение: AI всё активнее входит в SDLC не как “интересный эксперимент на обочине”, а как рабочий слой повседневной разработки. GitHub уже вывел Copilot coding agent в GA ^[2], а в материалах DORA отмечается, что AI на работе используют 90% технологических специалистов и более 80% считают, что он повышает продуктивность.

Вместе с этим проявилась и менее очевидная вещь: AI действительно ускоряет создание артефактов, но часто переносит стоимость дальше по цепочке – в проверку, ревью, согласование и контроль стабильности. В терминах DORA ^[3] это напряжение между throughput и delivery instability: выигрыш на этапе создания легко превращается в издержки на проверку.

Из-за этого меняется и сама постановка вопроса: если раньше его можно было сформулировать так: где в текущем процессе применить AI, чтобы ускорить отдельные этапы, то теперь всё же полезнее формулировать его иначе: каким должен быть сам процесс поставки, если часть решений, артефактов и шагов исполнения регулярно проходит через LLM-интерфейсы и coding agents.

AI-native SDLC начинается не там, где команда просто разложила AI по этапам разработки. Он начинается там, где команда заново проектирует сам процесс поставки – уже с учётом того, что рядом с людьми работают модели, агенты и AI workflow.

1. Что я здесь называю AI-native SDLC

Чтобы не запутаться в терминах перед разговором про AI-native SDLC, полезно развести три рабочих режима.

AI-assisted разработка – это режим, в котором AI ускоряет отдельные действия. Он помогает собрать требования, набросать ADR, придумать тест-кейсы, написать черновик документации или подсказать реализацию. Процесс при этом остаётся прежним: люди просто делают отдельные шаги быстрее.

Agentic delivery – это следующий уровень. Здесь в процесс входит уже не просто “умный ассистент”, а агент-исполнитель: он читает репозиторий, готовит изменения, прогоняет проверки, открывает PR и эскалирует вопросы человеку. То есть часть исполнения начинает жить не в чате с моделью, а в рабочем контуре команды.

AI-native SDLC – это уже сдвиг в сторону полноценной интеграции AI в SDLC. Здесь перестраивается не отдельный шаг и не только роль помощника, а сам процесс поставки. LLM становится не «вкладкой с чатом», а интерфейсом к рабочему контуру: через него команда инициирует проработку идеи, получает черновики артефактов, вносит замечания, запускает следующий шаг и двигает изменение дальше без ручной пересборки контекста.

Похожая логика ^[4] всё чаще встречается и в индустриальных материалах: у AWS в описании AI-Driven Development Life Cycle ^[5] и в тексте Kief Morris на сайте Martin Fowler про humans and agents in software engineering loops ^[6]. Ключевое различие здесь практическое: в agentic delivery агент встраивается в существующий процесс, а в AI-native SDLC сам процесс уже организуется вокруг совместной работы людей и агентов.

2. Исходный процесс остаётся, но через него проходит новый слой

Здесь легко подумать, что SDLC сам по себе больше не нужен. Это не так: процесс поставки, о котором я писал на примере RuStore, никуда не делся, но при AI-native SDLC меняется фокус, а точнее – что именно команда должна дополнительно проектировать и какие артефакты поддерживать.

С практической стороны исходный процесс отвечает на вопрос: как изменение идёт от идеи до эксплуатации, а AI-native SDLC добавляет второй вопрос: в какой среде, по каким правилам и с какими доказательствами человек и агенты проводят это изменение через весь путь.

• Problem framing и декомпозиция задачи – чтобы задача была понятна не только людям, но и агентным сценариям, а работа сразу резалась на безопасные и обозримые части.

• Context as system of record – чтобы критическое знание жило не в головах и чатах, а в поддерживаемом машиночитаемом контексте.

• Harness и агентные сценарии – чтобы у агентов была не “свобода действий”, а управляемая среда исполнения с явными правилами, правами и условиями остановки.

• Evidence-driven execution и quality gates – чтобы ревью опиралось не только на diff, но и на проверяемые подтверждения: тесты, ограничения, контракты и rollback-план.

• Release telemetry и learning loop – чтобы после релиза улучшался не только продукт, но и сам процесс поставки: правила, skills, документы, проверки и маршруты делегации.

Именно в подобном процессе AI перестаёт быть просто инструментом ускорения и начинает менять операционную модель взаимодействия. В DORA 2025 ^[7] это хорошо сформулировано через простую мысль: AI – это amplifier, он усиливает уже существующую инженерную систему вместе с её сильными и слабыми сторонами.

Если чуть утрировать, работу архитектора уже сейчас можно представить как голосовое взаимодействие с моделью-помощником. Архитектор получает черновик ADR, просматривает его и не переписывает документ руками, а голосом наговаривает замечания: что уточнить, что переформулировать, какие риски отметить, какие вопросы эскалировать. Система транскрибирует это, связывает комментарии с текущим артефактом, обновляет документ, помечает спорные места, запускает повторную валидацию и двигает артефакт дальше по процессу. Здесь LLM – не “чатик сбоку”, а интерфейс к работе и одновременно слой оркестрации вокруг артефактов.

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

3. Главная экономика AI-native SDLC – не код, а коммуникация

Когда мы говорим про AI в разработке, чаще всего имеют в виду ускорение написания кода и подготовки артефактов. Но в реальном delivery одна из самых дорогих статей расходов – не сам набор текста, а передача работы между участниками, переключение контекста, повторная сборка знаний и бесконечные уточнения между аналитикой, разработкой, тестированием, эксплуатацией и обратно.

Поэтому главный экономический смысл AI-native SDLC – не в том, что код можно писать быстрее. Он в том, чтобы сжать стоимость коммуникации и верификации.

Новый процесс должен делать дешевле:

• вход нового участника в задачу;

• передачу контекста между этапами;

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

• review изменений;

• возврат продовых наблюдений обратно в разработку.

Отсюда и два практических следствия.

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

Эту мысль хорошо дополняет текст OpenAI про harness engineering ^[8]: для агента всё, чего нет в доступном во время выполнения контексте, фактически не существует. Если команда ускоряет кодогенерацию, но продолжает держать критическое знание в головах, чатах и созвонах, она получает не AI-native SDLC, а просто более быстрый способ производственного хаоса.

Из этой логики и следуют изменения в каждом шаге процесса.

4. Что меняется по шагам

4.1. Problem framing и task slicing

На этапе kick-off команда обычно выравнивает цель, метрики, ограничения и первичное понимание задачи. В AI-native процессе этого уже недостаточно. Теперь задача этого шага – не только помочь людям договориться, но и собрать такой стартовый контекст, с которым смогут работать агенты и автоматизированные сценарии.

На выходе нужен не “чей-то конспект встречи”, а первый рабочий пакет:

• цель;

• контекст;

• ограничения;

• открытые вопросы;

• критерии готовности;

• риски;

• первичная нарезка на ограниченные задачи.

То есть на старте нужно не просто погрузить команду в фичу, а подготовить машиночитаемый и исполнимый артефакт, который станет первым слоем system of record.

4.2. Контекст как system of record

Следующий шаг ещё важнее. В исходном процессе архитектура, ADR и technical design были в первую очередь артефактами для людей. В AI-native процессе они должны стать источником истины и для людей, и для агентов.

Но тут важно не свести всё к папке с документами или страничке на вики. System of record – это не набор “официальных файлов”, а поддерживаемый слой контекста, в который попадают и формальные артефакты, и значимые рабочие договорённости.

Практический смысл здесь такой: критическое знание должно жить не в переписке и не в памяти ^[9] отдельных участников, а в артефактах, к которым можно стабильно обратиться во время работы. Поэтому ADR, design docs, API-контракты, ограничения по безопасности, команды локальной проверки, rollout notes и observability checklist здесь – не документация «ради документации», а рабочий контекст, доступный во время исполнения.

Но и этого мало: как правило, существенная часть решений рождается в чатах, комментариях к задачам, коротких синках и голосовых обсуждениях. Поэтому полноценный AI-native workflow должен уметь подхватывать и этот слой: выделять решения, спорные места, изменения позиции и затем обновлять единое пространство артефактов – decision log, task context pack, design note или changelog по фиче.

Иначе формальная документация и живая коммуникация снова разъедутся, а агент будет работать по устаревшей или неполной картине.

4.3. Harness и agent workflows

Когда мы говорим “нужно настроить coding agents”, многие до сих пор представляют себе большой системный промпт. На практике же SWE-агенты давно ушли дальше простого промптинга.

В AI-native SDLC главным объектом проектирования становится harness – контур исполнения: среда и набор правил, в которых работают агенты. Реальная автономия возникает не из “удачного промпта”, а из того, что в систему уже зашиты тестирование, валидация, ревью, фидбек луп и recovery.

На практике это означает три вещи.

Во-первых, у репозитория должны появиться явные правила работы для агентов:

• короткий AGENTS.md;

• команды сборки и тестов;

• явные запреты;

• ожидания к PR;

• критерии готовности;

• архитектурные ограничения и требования безопасности.

Во-вторых, повторяемые сценарии лучше зашивать как skills, playbooks или repo rules, а не заново описывать в чате на каждом шаге. Если workflow повторяется, его нужно превращать в воспроизводимый способ работы.

В-третьих, ограничения должны быть не только текстовыми, но и механическими. Система должна уметь не просто “подсказывать агенту, как надо”, а в нужных местах останавливать его: ограничивать права, блокировать рискованные изменения без обязательной валидации, запрещать merge без доказательств, ограничивать радиус воздействия изменений и переводить спорные действия в режим эскалации человеку.

AI-native SDLC начинается не там, где агент “стал умным” сам по себе, а там, где команда построила вокруг него рабочую среду с понятными правилами, границами и условиями остановки.

4.4. Evidence-driven execution, ревью, quality gates и evals

Одна из самых опасных иллюзий AI-assisted разработки звучит так: “раз агент пишет быстрее, значит ревью можно оставить как раньше”. На практике это быстро ломается: чем больше кода генерирует агент, тем больше работы по проверке ложится на людей, и выигрыш на создании быстро превращается в рост стоимости ревью.

Поэтому в AI-native процессе на ревью должен попадать не просто diff, а результат работы агентного контура, подтверждённый пакетом evidence.

Здесь полезно мыслить тремя слоями контроля.

Первый слой – evidence pack. Он делает проверяемым конкретное изменение и обычно отвечает на несколько вопросов:

• что именно меняется;

• какие сценарии покрыты;

• какие проверки были прогнаны;

• какие контракты, документы, логи или метрики обновлены;

• какие ограничения и известные риски остаются;

• как изменение откатывается.

Второй слой – quality gates. Для AI-native процесса недостаточно надеяться на внимательность людей в ревью: нужны явные точки контроля, которые не дают изменению пройти дальше без обязательных проверок.

Обычно сюда входят:

• ограничение размера изменений;

• обязательные test/validate commands;

• проверки на соблюдение архитектурных ограничений;

• проверка полноты evidence pack;

• ревью человеком по результату;

• обновление документации вместе с кодом.

Третий слой – evals. Он не заменяет ни evidence pack, ни quality gates. Evidence pack нужен, чтобы сделать проверяемым конкретное изменение, Quality gates нужны, чтобы не пропустить его без обязательных контролей, а Evals нужны, чтобы сделать предсказуемым сам workflow на повторяющихся задачах.

Именно тогда evals становятся особенно полезны: они помогают явно закодировать ожидаемое поведение ^[10], снять двусмысленность между разными трактовками задачи и отделить вопрос “что агент вообще умеет делать хорошо” от вопроса “делает ли он это всё ещё стабильно после очередных изменений”. У Anthropic в тексте Demystifying evals for AI agents ^[11] эта логика хорошо разобрана.

Иначе AI-native delivery быстро скатывается в очень дорогой vibe coding с множеством PR.

4.5. Release telemetry и learning loop – уже для самого процесса

После поставки функциональности на прод и передачи её в поддержку в AI-native SDLC появляется ещё один объект наблюдения: сам процесс поставки.

После релиза команды должны разбирать не только:

• работает ли изменение;

• не выросли ли ошибки ^[12];

• не деградировали ли бизнес-метрики;

но и:

• где агент ошибся из‑за нехватки контекста;

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

• какие задачи были слишком большими для безопасной делегации;

• где ревью утонул в шуме;

• какие части контекста устарели;

• какие проверки нужно поднять из “человеческой памяти” в инструменты AI workflow.

В исходном процессе повторяющийся сбой часто приводит просто к багфиксу. В AI-native процессе этого уже недостаточно: повторяющийся сбой должен становиться ещё и изменением в самом workflow – в system of record, skills, тестах, guardrails или quality gates.

Именно тогда AI-native SDLC начинает окупаться: каждая итерация улучшает не только продукт, но и сам способ поставки изменений. Следующую задачу команда проходит быстрее, а сам процесс становится предсказуемее.

5. Что сдвиг в процессах меняет в организации

Во‑первых, инженерный профиль становится шире. И речь не совсем о том, что завтра исчезнут все роли и останутся только “разработчики с агентами”. Речь скорее о том, что растёт ценность инженера, который может поговорить с бизнесом, быстро собрать описание проблемы, набросать high-level design, нарезать задачу, провести её через agent workflow, собрать evidence и довести изменение до наблюдаемого состояния в проде.

Во‑вторых, резко усиливается значение платформы и harness-инфраструктуры. Это касается platform engineering, внутренней инфраструктуры для агентов, observability, security, system of record, reusable workflows и validation tooling. Чем больше в процессе AI-исполнения, тем важнее не “какая у нас модель”, а “какая у нас среда, правила и качество внутренних платформ”. Вместе с этим появляется и вопрос зоны ответственности: кто поддерживает harness, обновляет repo rules, следит за качеством контекста и переводит повторяющиеся сбои в новые ограничения и проверки.

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

И здесь возникает реальный риск. Если AI становится первым местом, куда человек идёт за ответом, а наставничество и ревью остаются на самотёк, организация начинает выращивать не инженеров, а операторов автодополнения. Поэтому в AI-native SDLC роль сильных инженеров в обучении ^[13] команды не снижается, а растёт: через обязательное ревью, разбор ошибок, постмортемы, явные стандарты качества и постоянную калибровку инженерного мышления ^[14].

Вывод

Главная ошибка переходного периода в том, что многие команды всё ещё пытаются ответить на старый вопрос: куда встроить AI в существующий SDLC.

Но если LLM-интерфейсы и coding agents становятся частью повседневной работы, этого уже недостаточно.

Потому что теперь задача больше не сводится к ускорению требований, написания кода или тестов по отдельности. Меняется сам процесс поставки: человек формулирует намерение, AI workflow помогает прояснить и декомпозировать задачу, агент исполняет ограниченный по масштабу кусок работы, harness ограничивает и направляет, quality gates и evidence подтверждают результат, а post-launch улучшает уже не только продукт, но и сам процесс.

AI-native SDLC – это не замена исходного процесса поставки, а дополнительный слой управления контекстом, harness, quality gates и learning loop. Исходный процесс остаётся позвоночником delivery, а AI-native задаёт совместную работу человека, LLM-интерфейсов и агентов поверх него.