Когда LLM-интерфейсы и coding agents становятся рабочим инструментом команды, менять приходится не только инструменты, но и сам процесс поставки изменений.
Команды обычно приходят к формализованному процессу поставки не из любви к процессам, а тогда, когда нужно получать предсказуемые сроки, управляемый риск и воспроизводимый результат. В серии статей на примереRuStoreя уже разбирал такой процесс: kick-off, архитектурную проработку через ADR, technical design, реализацию, review и testing, затем pre-launch, post-launch и передачу изменений в эксплуатацию. Сам по себе этот процесс никуда не исчезает и вряд ли исчезнет в ближайшее время: он по‑прежнему нужен, если мы хотим стабильно доводить изменения до продакшена.
Но за последнее время изменилось базовое допущение: AI всё активнее входит в SDLC не как “интересный эксперимент на обочине”, а как рабочий слой повседневной разработки. GitHub ужевывел Copilot coding agent в GA, а в материалах DORA отмечается, что AI на работе используют 90% технологических специалистов и более 80% считают, что он повышает продуктивность.
Вместе с этим проявилась и менее очевидная вещь: AI действительно ускоряет создание артефактов, но часто переносит стоимость дальше по цепочке - в проверку, ревью, согласование и контроль стабильности. В терминахDORAэто напряжение между 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 становится не «вкладкой с чатом», а интерфейсом к рабочему контуру: через него команда инициирует проработку идеи, получает черновики артефактов, вносит замечания, запускает следующий шаг и двигает изменение дальше без ручной пересборки контекста.
Похожая логика всё чаще встречается и в индустриальных материалах: у AWS в описанииAI-Driven Development Life Cycleи в тексте Kief Morris на сайте Martin Fowler проhumans and agents in software engineering loops. Ключевое различие здесь практическое: в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это хорошо сформулировано через простую мысль: AI - это amplifier, он усиливает уже существующую инженерную систему вместе с её сильными и слабыми сторонами.
Если чуть утрировать, работу архитектора уже сейчас можно представить как голосовое взаимодействие с моделью-помощником. Архитектор получает черновик ADR, просматривает его и не переписывает документ руками, а голосом наговаривает замечания: что уточнить, что переформулировать, какие риски отметить, какие вопросы эскалировать. Система транскрибирует это, связывает комментарии с текущим артефактом, обновляет документ, помечает спорные места, запускает повторную валидацию и двигает артефакт дальше по процессу. Здесь LLM - не “чатик сбоку”, а интерфейс к работе и одновременно слой оркестрации вокруг артефактов.
Чтобы понять, зачем вообще всё это перестраивать, дальше важно посмотреть на экономику такого сдвига.
3. Главная экономика AI-native SDLC - не код, а коммуникация
Когда мы говорим про AI в разработке, чаще всего имеют в виду ускорение написания кода и подготовки артефактов. Но в реальном delivery одна из самых дорогих статей расходов - не сам набор текста, а передача работы между участниками, переключение контекста, повторная сборка знаний и бесконечные уточнения между аналитикой, разработкой, тестированием, эксплуатацией и обратно.
Поэтому главный экономический смысл AI-native SDLC - не в том, что код можно писать быстрее. Он в том, чтобысжать стоимость коммуникации и верификации.
Новый процесс должен делать дешевле:
- вход нового участника в задачу;
- передачу контекста между этапами;
- работу агента внутри ограниченного домена;
- review изменений;
- возврат продовых наблюдений обратно в разработку.
Отсюда и два практических следствия.
Первое: чем меньше размер передаваемого изменения, тем дешевле понять его, проверить, безопасно выпустить или откатить. Второе: всё, что важно для принятия решения, должно быть вынесено во внешний контекст, доступный во время исполнения.
Эту мысль хорошо дополняет текст OpenAI проharness engineering: для агента всё, чего нет в доступном во время выполнения контексте, фактически не существует. Если команда ускоряет кодогенерацию, но продолжает держать критическое знание в головах, чатах и созвонах, она получает не 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 - это не набор “официальных файлов”, а поддерживаемый слой контекста, в который попадают и формальные артефакты, и значимые рабочие договорённости.
Практический смысл здесь такой: критическое знание должно жить не в переписке и не в памяти отдельных участников, а в артефактах, к которым можно стабильно обратиться во время работы. Поэтому 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 становятся особенно полезны: они помогают явно закодировать ожидаемое поведение, снять двусмысленность между разными трактовками задачи и отделить вопрос “что агент вообще умеет делать хорошо” от вопроса “делает ли он это всё ещё стабильно после очередных изменений”. У Anthropic в текстеDemystifying evals for AI agentsэта логика хорошо разобрана.
Иначе AI-native delivery быстро скатывается в очень дорогойvibe codingс множеством PR.
4.5. Release telemetry и learning loop - уже для самого процесса
После поставки функциональности на прод и передачи её в поддержку в AI-native SDLC появляется ещё один объект наблюдения:сам процесс поставки.
После релиза команды должны разбирать не только:
- работает ли изменение;
- не выросли ли ошибки;
- не деградировали ли бизнес-метрики;
- где агент ошибся из‑за нехватки контекста;
- какие правила оказались недостаточными;
- какие задачи были слишком большими для безопасной делегации;
- где ревью утонул в шуме;
- какие части контекста устарели;
- какие проверки нужно поднять из “человеческой памяти” в инструменты 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 роль сильных инженеров в обучении команды не снижается, а растёт: через обязательное ревью, разбор ошибок, постмортемы, явные стандарты качества и постоянную калибровку инженерного мышления.
Главная ошибка переходного периода в том, что многие команды всё ещё пытаются ответить на старый вопрос:куда встроить 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-интерфейсов и агентов поверх него.