Мы используем SDLC с поддержкой ИИ на многоарендной SaaS-платформе для клиента в регулируемой отрасли, где Claude Code пишет код, требования и тесты. У агента нет никаких привилегий, которых не было бы у младшего разработчика: три уровня CI-проверок и пять точек принятия решений человеком связывают каждое изменение с требованием, тестом и релизом.

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

Что такое SDLC с поддержкой ИИ?

SDLC с поддержкой ИИ — это жизненный цикл разработки программного обеспечения (SDLC), в котором ИИ-агент по написанию кода выполняет работу на каждом шаге, от спецификации до релиза, в то время как люди одобряют важные решения.

Все, что управляет агентом (инструкции, правила, навыки и хуки), хранится в репозитории и изменяется только посредством проверенных пулл-реквестов. CI-проверки проверяют каждое изменение одинаково, независимо от того, написали его человек или модель.

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

Задача: ИИ-агент в условиях требований аудита

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

Стек: бэкенд на .NET, фронтенд на TypeScript и React, облако Azure
Команда: наши инженеры и инженеры клиента в одном общем репозитории
Инструменты ИИ: Claude Code, локально и в CI-пайплайне, со структурированным рабочим процессом от идеи до развертывания
Отраслевые требования: журнал аудита, прослеживаемость требований, управление изменениями, высокий уровень безопасности и изоляция данных

Наше руководящее правило простое: у ИИ-агента нет никаких привилегий, которых не было бы у младшего разработчика. Он не выполняет слияние (merge), не делает пуш в защищенные ветки и не имеет доступа к секретам. Каждое его действие оставляет след в репозитории или пулл-реквесте, поэтому аудитор может восстановить картину того, кто, что и зачем сделал.

Мы описали общую методологию, применяемую для наших внутренних продуктов, в материале о разработке с помощью агентов производственного уровня. Здесь мы показываем, что меняется, когда процесс клиента подвергается аудиту — это тот тип проектов, которые охватывают наши услуги по разработке с помощью ИИ.

Как работает SDLC с поддержкой ИИ от начала до конца

Каждое изменение в SDLC с поддержкой ИИ проходит один путь из восьми шагов, а его сложность определяет, сколько именно из этих шагов задействуется. Агент выполняет работу на каждом шаге, а человек утверждает решения в пяти точках.

Дорожная карта: для каждой функции определяется уровень сложности от одного до четырех; исправления ошибок идут по быстрому пути.
Спецификация и план (решение человека): агент пишет спецификацию, критерии приемки и дорожную карту по фазам.
Требования (решение человека): требования версионируются в репозитории, утверждаются бизнесом и фиксируются после утверждения.
Проектирование: варианты и принятое решение, записываемые в виде архитектурного решения (ADR) в репозитории.
Сборка по фазам (решение человека): разработка через тестирование (TDD), субагенты, хук, блокирующий рискованные операции, и остановка после каждой фазы.
Пулл-реквест (решение человека): тесты, статический анализ безопасности приложений (SAST), анализ состава ПО (SCA), линт требований и рекомендательный обзор ИИ.
UAT и релиз (решение человека): приемочное тестирование пользователя (UAT) в браузере, релизный шлюз с динамическим тестированием безопасности приложений (DAST) и запись в журнале релизов.
Рефлексия: что сработало, что нет, и архив задач. Извлеченные правила возвращаются агенту в качестве контекста.

В основе всех восьми шагов лежит уровень контроля ИИ: инструкции, правила, навыки, субагенты, хуки и архитектурные решения, которые хранятся в git и изменяются исключительно через пулл-реквесты. Это обеспечивает агента контекстом на каждом шаге, а правила, извлеченные в ходе рефлексии, поступают обратно в систему.

Сложность оценивается на старте. Мелкие исправления используют кратчайший путь от задачи к реализации и пулл-реквесту, при этом CI все равно сообщает, каких требований они касаются.

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

Как требования превращаются в код

Требования в нашем SDLC с поддержкой ИИ рассматриваются как код: они версионируются в репозитории рядом с реализацией, а бизнес-инструмент используется только для их проверки и утверждения. Таким образом, каждое изменение кода «знает», каких требований оно касается.

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

Матрица прослеживаемости требований — это не документ, обновляемый один раз за релиз. CI проверяет ее при каждом пулл-реквесте: он сообщает, какие требования затрагивает изменение, блокирует изменения неутвержденных требований и выдает ошибку для крупной функции, у которой вовсе нет требований. Прослеживаемость поддерживается в актуальном состоянии, поскольку от нее зависит сборка.

Как репозиторий и CI/CD управляют агентом

Репозиторий и CI/CD применяют к агенту те же правила, что и к инженерам, и принудительно исполняют их механически на трех уровнях, а не только в виде письменных регламентов. Базовая политика веток строга: единственная главная линия разработки, защищенные ветки, доступные только через пулл-реквесты, стандартные имена веток и запрет на перезапись общей истории.

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

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

Как тестирование и безопасность работают с ИИ-агентом

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

Пирамида тестирования

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

Безопасность в процессе

Процедуры агента (навыки): защита конечной точки, например, представляет собой фиксированную последовательность шагов, и CI проверяет каждый из них.
Долг, который может только уменьшаться: существующие проблемы регистрируются; новое нарушение ломает сборку, а расширение реестра требует одобрения человека.
Полный набор сканирования: SAST, DAST, анализ зависимостей со спецификацией состава программного обеспечения (SBOM) и поиск секретов.

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

Как версионируются правила, навыки и шаблоны

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

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

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

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

Где люди одобряют изменения

Люди одобряют каждое изменение, попадающее в защищенную ветку, на продакшен или к клиенту: ИИ подготавливает, человек принимает решение. Пять точек принятия решений:

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

Еще два правила защищают контроль человека в ЖЦРПО (SDLC) с поддержкой ИИ. Правила, которым ИИ учится самостоятельно, никогда не могут переопределять правила, установленные людьми. Любое изменение области действия шлюзов безопасности требует одобрения команды безопасности, поэтому агент никогда не ослабляет собственные защитные механизмы. Мы писали о том, почему агентам нужны такие ограничения, в статье о реальных подводных камнях ИИ-агентов.

Как действия ИИ остаются проверяемыми

Действия ИИ остаются проверяемыми, поскольку репозиторий является единственным источником правды: каждый шаг агента оставляет артефакт в репозитории или в пулл-реквесте.

Для любых изменений аудитор может восстановить, кто действовал (человек или ИИ-модель), что было сделано, почему и на каком основании. Каждый коммит фиксирует, какая модель внесла вклад, пулл-реквест фиксирует, кто дал одобрение, а документ задачи фиксирует проектное обоснование. Результаты тестов, логи и отчеты о безопасности архивируются как артефакты CI.

В таблице сопоставлены типичные вопросы аудита с местом, где находится ответ.

Как телеметрия измеряет качество, модели и затраты

Телеметрия в нашем ЖЦРПО с поддержкой ИИ измеряет три параметра одновременно: качество кода, использование моделей и стоимость. Цель состоит в том, чтобы показать, во что обходится ИИ и что он дает, а не только сколько токенов он использовал.

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

Общая панель мониторинга сопоставляет затраты с результатами. Она отслеживает стоимость объединенного изменения, долю изменений, проходящих CI с первого запуска, точность ИИ-ревью и время от задачи до развертывания. Сами по себе показатели токенов не могут показать, окупается ли ИИ в ЖЦРПО, в то время как эти четыре метрики — могут.

Работает ли эта модель за пределами .NET?

Да, модель работает за пределами .NET, поскольку ее ядро составляют репозиторий, CI, правила и навыки, а не конкретный язык. В этом проекте мы работали с .NET и TypeScript. Для мобильных платформ, Java или Angular вы добавляете правила, навыки и шлюзы этой технологии, а механизм остается прежним.

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

Чему мы научились на практике

Практические уроки этого ЖЦРПО с поддержкой ИИ получены из пяти ситуаций, в которых его механизмы сработали или чему-то нас научили.

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

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

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

Доказательство того, что шлюзы блокируют. Мы намеренно инициировали каждый ключевой шлюз (например, с помощью падающего теста и специально внедренного поддельного секрета) и сохранили доказательство каждой блокировки в реестре релиза.

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

Когда эта модель имеет смысл

Эта модель ЖЦРПО с поддержкой ИИ имеет смысл там, где каждое изменение должно быть задокументировано, например в регулируемых отраслях и проектах с внешним аудитом.

Если вы планируете внедрить агентов кодирования с ИИ в процесс поставки, требующий аудиторского следа, поговорите с нашей командой о вашем проекте.

FAQ

Может ли ИИ-агент по написанию кода объединять собственные пулл-реквесты?

Нет. В этой модели у агента нет прав на слияние: владелец кода проверяет каждый пулл-реквест, а слияние выполняет человек.

Как помешать ИИ-агенту писать тесты, которые ничего не доказывают?

Каждый тест должен падать без проверяемого им поведения. Это правило прописано в инструкциях агента и контролируется при код-ревью, а интеграционные тесты проверяют состояние системы на реальном сервере и в базе данных.

Как защитить ИИ-ревьюера кода от инъекций промптов?

Ревьюер в CI умеет только читать и комментировать, а содержимое изменений он воспринимает как данные, а не как инструкции.

Какая модель ИИ обрабатывает какие задачи?

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

Что происходит с правилами, которые ИИ-агент изучает самостоятельно?

Им присваивается низкий приоритет, а также фиксируются их происхождение и частота подтверждения. Они никогда не отменяют правила, заданные человеком, и устаревают, если их не подтверждают.

Работает ли этот ЖЦПО (SDLC) с поддержкой ИИ в GitHub, GitLab или Azure DevOps?

Да. Агент запускается локально и в конвейере, поэтому модель не зависит от CI-платформы: она работает с GitHub, GitLab, Azure DevOps или Jenkins, а требования могут синхронизироваться с такими инструментами, как Jira или Confluence.