# Блок 09. CI/CD

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 9 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/ii-v-ci-cd/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 5 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

> Конвейер – единственное место, где проверка масштабируется вместе с объёмом кода, поэтому для сгенерированного кода он не может быть мягче, чем для написанного человеком.

CI/CD означает непрерывную интеграцию и непрерывную поставку (continuous integration, continuous delivery): это автоматический конвейер, который собирает код, проверяет его и доставляет на среды. Для ИИ-разработки конвейер важнее, чем раньше, по простой причине: когда кода становится больше, а пишет его частично машина, масштабируется только автоматическая проверка. Ревью людьми так масштабироваться не может.

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

## CI: непрерывная интеграция

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

Главный принцип: любой код, сгенерированный ИИ, должен проходить ровно те же проверки, что и человеческий, без исключений и ускоренных путей. Соблазн «это же простая правка от агента, пропустим» опасен. [DORA](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) фиксирует рост нестабильности поставки вместе с ростом использования ИИ, а ускоренные пути проверки, по моему опыту, – одна из её причин.

## CD: непрерывная поставка

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

Для корпорации это ещё и требование аудита: должно быть однозначно зафиксировано, кто нажал кнопку.

## Инфраструктура как код

Инфраструктура как код (Infrastructure as Code, IaC) означает описание серверов, сетей и сервисов в виде конфигурационных файлов, которые применяются автоматически. ИИ хорошо генерирует такие описания: синтаксис строгий, примеров в открытом доступе много, результат проверяется применением на тестовой среде.

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

## SAST: статический анализ безопасности

SAST (Static Application Security Testing) означает автоматический поиск уязвимостей в исходном коде без его запуска. Для ИИ-кода это обязательный шаг по такой причине: модель обучена на открытом коде, где небезопасные шаблоны встречаются часто, поэтому она их воспроизводит. Типичные находки: жёстко зашитые секреты, небезопасная обработка ввода, устаревшие криптографические функции.

Кроме обычного SAST, нужна проверка на вещи, специфичные для ИИ: не попали ли в код секреты из промпта, не добавил ли агент зависимость, которой нет в разрешённом списке. О лицензионной чистоте зависимостей – в [блоке 12](/ai-cto/slozhnosti-vnedreniya-ii/).

## DAST: динамический анализ безопасности

DAST (Dynamic Application Security Testing) означает проверку работающего приложения на уязвимости снаружи, как это делал бы атакующий. Для ИИ-разработки это второй рубеж после SAST: часть уязвимостей проявляется только в работе.

ИИ здесь помогает в 2 ролях: генерирует сценарии атак для проверки (на основе [OWASP Top 10](https://owasp.org/www-project-top-ten/) – списка главных рисков веб-приложений от открытого проекта по безопасности OWASP – и специфики вашего приложения; если в приложении есть модель, ещё и [OWASP Top 10 для LLM-приложений](https://genai.owasp.org/llm-top-10/)) и объясняет найденные уязвимости инженерам, которые не специализируются на безопасности. Это снижает нагрузку на ИБ при условии, что ИБ согласовала такой подход.

## Lint: проверка стиля и типовых ошибок

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

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

### Пример: проверки в конвейере для кода с ИИ

Так выглядит список проверок для пул-реквеста в банке Даниила после внедрения. Обратите внимание: первые 8 проверок были и до ИИ, новые только 3 последние. Для пул-реквеста от агента и от человека список одинаковый.

| Шаг | Проверка | Блокирует слияние | Время |
| --- | --- | --- | --- |
| 1 | Сборка | Да | 4 мин |
| 2 | Линтер по стандартам компании | Да | 1 мин |
| 3 | Модульные тесты, покрытие изменённых строк не ниже 70% | Да | 6 мин |
| 4 | SAST, критичные и высокие находки | Да | 5 мин |
| 5 | Проверка зависимостей на известные уязвимости | Да | 2 мин |
| 6 | Интеграционные тесты | Да | 15 мин |
| 7 | Ревью человеком, для платёжных модулей – 2 людьми | Да | до 1 рабочего дня |
| 8 | DAST на тестовой среде, еженочно | Нет, отчёт в ИБ | 40 мин |
| 9 | Поиск секретов и фрагментов промптов в коде | Да | 1 мин |
| 10 | Новая зависимость только из разрешённого списка, лицензия из белого списка | Да | 1 мин |
| 11 | В описании пул-реквеста есть отметка об использовании ИИ и ссылка на спецификацию | Да | мгновенно |

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

**Корпорация:** все 11 проверок, включая аудит того, кто нажал кнопку деплоя, и обязательный DAST. Конвейер часто работает в собственной инфраструктуре, поэтому его пропускную способность нужно считать заранее.

**Небольшая компания:** достаточно 6 проверок – сборка, линтер, тесты, бесплатный SAST, поиск секретов, проверка зависимостей – всё это есть в стандартных сборках GitHub Actions или GitLab CI за 1 день настройки. Деплой по кнопке с подтверждением человека сохраняется и здесь: это защита не от регулятора, а от агента, который «просто поправил конфиг».

## Источники

- [DORA 2025 (рост нестабильности)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
- [OWASP Top 10, веб-приложения, 2025](https://owasp.org/www-project-top-ten/)
- [OWASP Top 10 для LLM-приложений 2025, официальная страница](https://genai.owasp.org/llm-top-10/)

## Что говорят коллеги

Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год.

Даниил и Мария о том, сколько свободы давать ИИ в конвейере.

**Даниил:** С поставкой согласен без оговорок: аудит у нас давно требует знать, кто нажал кнопку, поэтому агент в этой цепочке не пройдёт ни одну проверку. С инфраструктурой как код я осторожнее, чем блок. План и ревью нужны, но в банке за генерацией инфраструктуры для продуктивных сред следит ещё и регулятор, поэтому в первый год я оставлю ИИ только тестовые среды. SAST у нас уже есть, добавлю туда проверку зависимостей по разрешённому списку.

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

- **Мария:** Оставлять ИИ только тестовые среды значит перестраховываться. План изменений показывает всё, что будет сделано, а ревью делает человек с правами.
- **Даниил:** Для тебя план служит проверкой, а нашему регулятору важно ещё и то, кто автор изменения. Ответ «модель» его не устроит.

## Итог блока

Главное из блока: когда кода больше и часть его пишет машина, масштабируется только автоматическая проверка, поэтому ИИ-код проходит те же проверки, что и человеческий, без ускоренных путей. Решение о выкатке остаётся за человеком или детерминированной автоматикой, а линтер стоит настроить до внедрения. Дальше, в [блоке 10](/ai-cto/soprovozhdenie-monitoring/), показано, что ИИ меняет после выкатки: инциденты, мониторинг, журналы.