Агентный SDLC: шесть уровней внедрения ИИ в разработку

Больше года я внедряю ИИ в разработку зрелой SaaS-компании, вместе со сложившейся инженерной командой, которая поначалу относилась к ИИ скептически. Мы прошли большой путь: от копирования кода из ИИ-чата до того, что отдаём агентам разработку фич целиком. Мы не занимаемся вайб-кодингом и не делаем продукт за вечер одним промптом. То, чем мы занимаемся, я называю AI-инженерией: мы строим систему, которая стабильно выдаёт результат по нашим стандартам качества. Сейчас мы экспериментируем с полуавтономной агентной фабрикой в облаке.

Этот путь я разложил на шесть уровней, от привычной ручной разработки до «тёмной фабрики». Ниже — как меняется жизненный цикл разработкиSDLCSoftware development life cycle, этапы, которые проходит изменение от идеи до прода. В статье их восемь. на каждом уровне, как понять, где сейчас ваша команда, и что нужно, чтобы двигаться дальше.

На L0 люди делают каждый этап жизненного цикла вручную, как раньше: от сбора требований и написания кода до релиза и мониторинга.

Два года назад запросы на новые фичи и обращения в поддержку наша команда разбирала вручную, спека была страницей в Notion, а план реализации существовал только в голове разработчика. Часть сервисов жила по trunk-based developmentTrunk-based developmentРазработчики коммитят прямо в основную ветку маленькими шагами, прикрываясь feature-флагами, без пул-реквестов и без ревью.: без пул-реквестов и без ревью. Где ревью было, его делал коллега-разработчик по своему усмотрению. QA тестировали вручную на общем staging-сервере по исходной спеке PM, которая после реализации могла устареть; были и Playwright-тесты. В некоторых проектах было хорошее покрытие тестами и настроен статический анализ. Это хороший задел, потому что для агентной разработки CI критически важен.

На L1 у вас появляется подписка на ChatGPT, и вы начинаете задавать вопросы собеседнику, который как будто прочитал разом все айтишные книги, — мудрому и всегда доступному коллеге за соседним столом. Вы спрашиваете, как спроектировать фичу, просите набросать спеку, объяснить кусок кода, написать эффективный алгоритм или найти в нём ошибку. Он даже может написать простой скрипт, и вы копируете его обратно в IDE.

Потом в IDE появляется autocomplete или AI Assistant, и вы начинаете ожесточённо жать Tab и Accept. Вы работаете на уровне мелких правок и принимаете подсказки сниппет за сниппетом.

Люди решают задачи быстрее, но по сути ничего не меняется: у чата нет доступа к артефактам команды и нет инструментов, чтобы действовать за пределами разговора.¹²³ Дэн Шапиро, популярный автор в AI-кругах, сравнивает этот уровень с удержанием полосы и круиз-контролем: вы отдаёте конкретные, отдельные задачи «ИИ-стажёру».⁴ Организации здесь нужно немного: дать доступ к ИИ-инструментам и чётко сказать, какие из них разрешены и как ими пользоваться.⁵

На L2 у вас появляется агент — Claude Code или Codex. Он умеет не только болтать с вами в чате, но и менять проект: пишет тексты, спеки и код прямо в репозитории. Но скоро выясняется, что мудрый начитанный собеседник кодит как посредственный джун. Он пишет спеки и код так, как пишет интернет, а не так, как принято в вашей команде. Результата хватает, чтобы впечатлить бизнес («смотри, я за вечер собрал весь продукт одним промптом»), но всё начинает разваливаться, как только до продукта доходят настоящие пользователи. Поэтому вы начинаете учить джуна правилам: строите мир, основанный на правилах, и задаёте контекст.

В каждый репозиторий вы кладёте короткий, написанный руками AGENTS.md с правилами и инструкциями команды. Агент загружает его в каждую сессию и использует как долговременную память проекта. AGENTS.md уже стал стандартом: его выпустила OpenAI в 2025 году, а теперь им управляет Linux Foundation.⁶⁷ В нём вы собираете то, что рассказали бы новому разработчику и чего он не понял бы из кода сам: как устроен проект, архитектурные границы, паттерны, naming conventions, язык предметной области и доменные знания.

И всё равно агент не всегда делает по-вашему. Каждый раз, когда он ошибается, вы добавляете инструкции, которые объясняют, как «правильно», и ваша работа смещается от кодинга фич к созданию системы, которая кодит фичи: запустить агента, посмотреть результат, поправить инструкции. Ещё вы даёте джуну инструменты: команды и скрипты, которые запускают тесты и статический анализ; коннекторы к MCP-серверамMCP-серверКоннектор, который даёт агенту инструмент или источник данных (базу знаний, трекер, логи) через Model Context Protocol — открытый стандарт, который Anthropic представила в 2024 году. базы знаний компании, логов прода и Sentry; браузер, чтобы прокликивать интерфейс. Когда AGENTS.md разрастается, вы дробите его на файлы, которые агент загружает лениво, только по необходимости, а повторяющиеся задачи превращаются в скиллыСкиллУ ИИ-агентов скилл — это папка с файлом SKILL.md: инструкции плюс, по желанию, скрипты и справочные файлы. Агент видит только название и описание каждого скилла и загружает полные инструкции, когда они нужны для задачи. В декабре 2025 года Anthropic опубликовала этот формат как открытый стандарт Agent Skills..

Quality GatesQuality GateАвтоматическая проверка, которую изменение должно пройти до слияния: сборка, тесты, статический анализ. важны так же, как контекст. Гейт — это проверка, которую изменение должно пройти до слияния в основную ветку: сборка, тесты, статический анализ. Без гейтов джун-агент слепой: он не получает обратной связи и не ловит собственные регрессии. В нашей команде агент сверяет свою работу с обязательными проверками CI: тестами, статическим анализом кода, сборкой и проверкой архитектурных границ. Это первый цикл, который осваивает любой джун: написать код, запустить проверки, увидеть ошибки, исправить их. Этому циклу нужны пул-реквесты: trunk-based development без ревью работал в некоторых наших сервисах, пока код писали люди, но изменениям агента нужны CI и ревью.

QA тоже меняется. Когда агент умеет прокликивать приложение в браузере, он берёт на себя детерминированную часть тестирования, где сценарии чётко определены. Творческая часть остаётся за людьми: ставить продуктовые требования под сомнение, придираться к дизайну и UX, опираться на свой вкус и опыт.

Результат L2 — база знаний о вашем проекте: его архитектура, стандарты и процессы. ◦◦◦Базу знаний не только наполняют, но и чистят от лишних деталей: модели становятся сильнее, и часть подсказок им больше не нужна.Вы наполняете её, пока агент не начнёт стабильно выдавать результат, который отвечает ожиданиям команды. Эту часть процесса нельзя пропустить по пути на L3: даже если вы начинаете с шаблона или берёте готовую базу знаний, контекст всё равно придётся адаптировать к новому проекту.

На L3 джун дорастает до мидла: разработчик, как тимлид, отдаёт агенту фичу целиком. Чтобы это работало, агенту, как и человеку, нужна инструкция: вы записываете процедуры и учите его навыкам — скиллам.

Мы начали с небольших скиллов: открыть пул-реквест по стандартному шаблону, спланировать реализацию фичи, запустить локальные проверки, сгенерировать тест-кейсы для QA. Потом объединили их в один процесс — скилл /implement-feature. Мы даём ему спеку, за которую отвечает продукт, и план реализации с уже принятыми архитектурными решениями; он возвращает пул-реквест, уже прошедший ревью.

Скилл прогоняет гейты CI из L2 и цикл ревью: второй агент ревьюит PR, а отдельный скилл проверяет каждый комментарий, исправляет код по обоснованным замечаниям и запрашивает новое ревью. Ревьюит модель другого вендора, не та, что писала код, и это второе мнение заметно улучшает результат. Роль разработчика — принять архитектурные решения, передать задачу агенту и проверить результат.

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

Сдвиг мышления L3: команда поддерживает общий процесс, а не каждый разработчик пилит свои собственные решения и скилы.

Работа продакт-менеджера тоже меняется. PM больше не нужно идти к разработчику за разъяснениями: его агент понимает кодовую базу и нетехническим языком отвечает, как работает продукт. Агент может проинтервьюировать PM по исходным требованиям и с опорой на код найти детали и развилки решений для спеки. PM теперь может прототипировать фичу прямо в рабочем репозитории, на реальных компонентах дизайн-системы. Даже навайбкоженный прототип, который выглядит правильно, но толком не работает, даёт разработчику полезную отправную точку. Поэтому дизайн-систему важно перенести из Figma в код. Спека тоже переезжает из Notion в репозиторий, рядом с кодом, вместе с планом, тест-кейсами и отчётом о тестировании. PM осваивает основы Git: ветки и версии.

Наша команда QA построила собственную тестовую обвязку. Она генерирует тест-кейсы из спеки и реализации, включая расхождения между ними. Агент прогоняет детерминированные сценарии через браузер или Playwright, снимает скриншоты и видео и пишет отчёты о проблемах. QA сосредотачиваются на творческом тестировании: ставят требования спеки под сомнение, исследуют продукт, ищут неудобные места в UX и сценарии, о которых никто не подумал.

L3 переносит узкое место в ревью. В телеметрии Faros AI за 2025 год по 10 000 разработчиков команды с высоким уровнем внедрения ИИ сливали на 98% больше пул-реквестов, а время ревью PR выросло на 91%.⁸ Это корреляция для команд с высоким внедрением ИИ, а не замер L3, но она совпадает с тем, что происходит, когда агенты пишут целые фичи. Теперь объём выпуска упирается во время, которое разработчики тратят на ревью.

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

Ваш мидл выдаёт приличный результат, но узким местом становитесь вы: вы проектируете фичи, запускаете процессы и проверяете каждое изменение. ОбвязкаОбвязка (harness)Обвязка агента — софт вокруг модели, который даёт ей контекст, инструменты и права и крутит её цикл. Claude Code и Codex — это обвязки. всё ещё работает на вашем ноутбуке: это инструменты вокруг модели, которые дают ей контекст, инструменты и права и крутят её цикл.

На L4 агент переезжает в облако и берёт тикеты с общей доски. Продакт-менеджер пишет спеку; агент предлагает план и поднимает архитектурные вопросы. Когда разработчик и агент договорились о подходе, агент работает самостоятельно. Дальнейшие решения он может эскалировать или принимать сам по согласованной политике и записывать их для ревью. Агент возвращает пул-реквест, готовый к ревью и творческому тестированию на стейджинге. Сбер похожим образом перестроил свой автономный генератор тестов: теперь он в ключевых точках просит инженера подтвердить решение.⁹

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

На L4 агенту не обязательно ждать тикета. Он следит за ошибками и логами, разбирается с проблемами по мере появления и либо эскалирует их, либо предлагает исправление.

Наш скилл для Sentry уже умеет такие расследования. Он изучает ошибки и логи прода, читает код и запускает скрипты, которые только читают данные прода, чтобы проверить гипотезы. Он может воспроизвести дефект падающим тестом и подготовить план исправления; для подходящих проблем оператор может разрешить ему дойти до пул-реквеста. Сегодня процесс всё ещё запускает человек. На L4 расследование могла бы запускать сама входящая ошибка.

Через Slack или другой мессенджер агент доступен и людям вне разработки. Поддержка может спросить, как работает фича; продакт-менеджеры могут задавать вопросы, не читая код. Агент смотрит в код и базу знаний, отвечает по тому, что знает, и может превращать запросы в черновики спек для PM.

Теперь вы выпускаете больше, но спеки, пул-реквесты и решения копятся у вас на столе. Работа выматывает: сплошное проектирование и ревью, и вы снова узкое место. Постепенно вы учитесь доверять системе, ослабляете хватку на ревью и поднимаетесь на уровень абстракции выше.

На L3 разработчик ревьюит реализацию и исправляет найденное в пул-реквесте. На L4 каждое изменение проверяют автоматические гейты. Разработчики ревьюят по согласованным архитектурным принципам и по найденному улучшают гейты. Им не обязательно ревьюить каждое изменение, но без архитектурного ревью они не узнают, работают ли гейты, и не будут знать код настолько, чтобы поддерживать фабрику.

Не каждую находку должен заметить человек. На L4 фабрика учится на своих ошибках и собирает все исправления: упавшие тесты, замечания на ревью, ошибки в проде, слова человека «у нас так не делают». Когда исправление повторяется, агент предлагает изменить систему, а не чинить ещё один пул-реквест.¹⁰ Джуну больше не нужно напоминать одно и то же дважды. Самое сильное исправление делает ошибку невозможной на уровне архитектуры; дальше идут типы, правила линтера и проверки CI, потом тест, и только в последнюю очередь — строчка в AGENTS.md или в скилле: это самое слабое средство, потому что агент может его пропустить.¹⁰ Каждое предложение одобряет человек, прежде чем оно попадёт в систему, чтобы контекст не раздувался, а цикл не ошибался без присмотра.¹⁰

Как советует Коул Медин, сначала постройте процесс, которому доверяете, и только потом отдавайте агенту крупные куски работы под меньшим контролем.¹¹ У этого процесса должен быть владелец: AI-платформенный инженер поддерживает платформу и обвязку агента.

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

Без построчного ревью безопасность должна быть частью гейтов. Отчёт Veracode за 2026 год показал, что код, сгенерированный ИИ, проходит проверки безопасности в 56% случаев на эталонных задачах, если в промпте нет требований к безопасности.¹² По «правилу двух для агентовПравило двух для агентовПравило безопасности ИИ-агентов, которое Meta опубликовала в 2025 году: в одной сессии агент может сочетать не больше двух из трёх возможностей — недоверенный ввод, доступ к закрытым данным, изменение состояния или внешнюю коммуникацию. Если нужны все три, агент не должен работать сам: его действия подтверждает человек или другая надёжная проверка.» от Meta агент, который в одной сессии сочетает недоверенный ввод, доступ к закрытым данным и возможность менять состояние или общаться вовне, не должен работать автономно — у него может быть не больше двух из трёх.¹³ Наш скилл для Sentry это правило соблюдает: его скрипты по данным прода только читают, а пул-реквест он открывает, только когда это разрешит человек.

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

Остерегайтесь ложного L4: одних облачных агентов мало. Если архитектурное ревью продолжает находить дефекты на уровне строк, гейты не готовы и роль всё ещё на L3. Прежде чем люди перестанут читать каждую строку, кто-то должен убедиться, что гейты работают. Понять, улучшается ли процесс в целом, помогают метрики вроде доли принятых изменений и объёма переделок.

На L5 никто не сверяет результат с тем, что хотел получить, и поэтому мы останавливаемся на L4. Дэн Шапиро называет тёмную фабрикуТёмная фабрикаЗавод, который работает с выключенным светом, потому что в цехах нет людей. В разработке — конвейер, который превращает спеки в готовый софт без участия человека. В статье это L5. «чёрным ящиком, который превращает спеки в софт» (пер. автора).⁴ Её сторонники не отказываются от проверки: она переезжает из диффов в точные спеки, сценарные тесты и пороги качества, которые люди задают заранее.¹⁴ Dash0 добавляет, что для этого нужны спеки настолько точные, что в диффы уже никто не смотрит, и что черновые спеки на полной скорости дают черновой результат.¹⁴

Мы не стремимся на L5, потому что он убирает второй гейт — проверку, что вы получили то, что просили, а ради этого софт и делают. Это как разрешить мидлу отгружать работу клиентам, когда никто не сверяет результат с запросом. Автоматические проверки могут подтвердить, что результат отвечает критериям, написанным до того, как он появился. Но они не скажут, описывали ли эти критерии то, что вы хотели, и не заметят, что фича неудобна тому, кто будет ею пользоваться. Для этого нужен человек, который просил, и QA-инженер, который пробует фичу глазами пользователя. Более сильные модели этого не изменят. Это вопрос смысла, и каждый отвечает на него сам. Мы делаем софт для людей. Если никто не проверяет, получили ли мы то, что просили, работа теряет смысл и превращается в ИИ-мусор. Поэтому и смысл, и его проверку мы оставляем людям. Там, где результат предназначен не людям, ответ может быть другим.

Потолок для каждого вида работ задаёт цена ошибки

Насколько близко к L4 подпускать каждый вид работ, компания решает сама — по цене ошибки. Фреймворк Сбера AI-Disrupt PDLC ведёт отдельную шкалу прав агентов с учётом риска, где самые критичные пути остаются на уровне предложений, которые принимает человек.¹⁵

Потолок — это самый высокий уровень, на котором ваши гейты надёжно ловят ошибки, которые нельзя откатить. Аутентификация и биллинг остаются на L3 не потому, что человек читает код лучше гейта, а потому, что пропущенный там дефект не откатить, а гейты пока не исключают такой класс ошибок; когда научатся, потолок можно поднять. Dash0 говорит то же самое: сервис переходит на уровень выше только по доказательствам, по одному сервису за раз, а зоны высокого риска могут не пройти никогда.¹⁴

Будет ли в этом цикле нужен человек? Потеряете ли вы работу?

Я считаю, что люди останутся незаменимыми, но планка растёт: агент берёт на себя всё больше работы разработчика, поэтому вам придётся стать сеньором, который решает, оценивает результат и отвечает за него. Какие-то профессии исчезнут, большинство изменится; это тема для отдельной статьи, «Человек в контуре». Здесь я разбираю только то, что не меняется от уровня к уровню.

Два гейта остаются за людьми на каждом уровне ниже L5: решить, чего мы хотим, и проверить, получили ли мы это. Агент может найти пробелы в запросе и помочь превратить его в спеку, но проблему, результат и компромиссы выбирают люди. Результат проверяет тот, кто просил; на L4 эта проверка поднимается с каждой строки на архитектуру и продукт, а QA исследует продукт так, как это делал бы пользователь.

Между гейтами вы делегируете агенту так же, как разработчику: с договором, контрольными точками, гейтами и правилом, когда нужно спросить. Договор растёт от промпта (L1) к AGENTS.md (L2) и к спеке с планом (L3); на L4 гейты несут бо́льшую часть доверия, которое раньше держалось на построчном ревью. Где агент должен остановиться и спросить, решает каждая компания, а настраивает это платформенный инженер.

Команда почти никогда не находится целиком на одном уровне. Когда Райффайзенбанк разбил использование ИИ среди своих 500 инженеров по ролям, оказалось, что разработчики пользуются агентами довольно активно, а тестировщики, аналитики и DevOps — неравномерно.¹⁶ Труднее всего пришлось системным аналитикам: их первый артефакт сложнее отдать агенту и сверить с шаблоном.¹⁷ В тестировании World Quality Report 2025 года показал, что генеративный ИИ внедряют почти 90% организаций, но в масштабе всей компании — только 15%.¹⁸

Темп задаёт самая медленная роль. Работа копится в очереди на каждой передаче: от продукта к разработке, от разработки к QA. Поэтому ускорение одного этапа переносит очередь на следующий.¹⁹ Оценивайте зрелость по самому слабому измерению, а не по самому сильному.²⁰

Поэтому самопроверка идёт роль за ролью. Выберите роль в матрице уровней ниже и найдите самый высокий уровень, для практик которого вы можете показать доказательства: файл в репозитории, гейт в CI, тикет, замечание на ревью, ставшее правилом. Если показать нечем, роль не на этом уровне. Уровень роли — тот, что верен для большей части её работы, а рискованные части ограничивает потолок по цене ошибки.

Три вопроса определяют уровень роли быстрее любого списка инструментов. Откуда агент берёт наш контекст? Что ещё проверяет человек и на какой высоте? Когда ревью находит проблему, оно чинит это одно изменение или систему, которая его породила? Если ответ на последний вопрос — «это изменение», роль не дошла до L4. Уровни описывают, как устроен процесс, а не что он даёт: уровень, который не сокращает время поставки, дефекты или переделки, — ложный уровень.

На L4 ролей может остаться не три. Кто-то по-прежнему отвечает за требование, поддерживает конвейер и проверяет продукт. Компания, которая может себе это позволить, оставляет трёх специалистов. В 2026 году я вижу тренд: их сливают в две роли. AI Builder отвечает за продукт и надзирает за фичами, проходящими через фабрику, а AI Platform Engineer поддерживает платформу и обвязку агента. Компания, которая не может позволить себе больше, может прийти к одному AI Builder.

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