[Непрерывное сканирование кода с помощью ИИ: почему разовый анализ упускает главное]

Инструменты с поддержкой ИИ изменили экономику разработки. Опытный инженер с Copilot или Claude выпускает рабочий функционал в два-три раза быстрее, чем прежде. Но "работает" и "безопасно" – не одно и то же, а разрыв между этими понятиями растет по мере того, как все больше ИИ-сгенерированного кода попадает в продакшн без соразмерной проверки.

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

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

Эта статья – о той слепой зоне, о классе проблем, которые она скрывает, и о том, почему мы перешли от разового анализа к непрерывному сканированию безопасности как архитектурному решению. Написана она с позиции команды, стоящей за Enji Fleet – нашей системой непрерывного сканирования для кодовых баз с интенсивным использованием ИИ – и основана на том, с чем мы сами столкнулись в своих проектах, ещё до того, как выработали системный ответ на эту проблему.

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

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

ИИ-сгенерированный код ломает это допущение в основании.

Когда LLM генерирует функцию, он не знает вашей модели управления доступом. Он не знает, что project_ids – это параметр, обеспечивающий изоляцию тенантов во всей системе. Он не знает, что пропуск единственного условия WHERE в одной таблице ведет к утечке данных всех клиентов базы. Модель генерирует синтаксически корректный, функционально правдоподобный код, который проходит линтер, проверку типов и юнит-тесты – и при этом содержит критическую уязвимость.

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

Разберем это на конкретном примере.

В PM агенте есть несколько специализированных агентов: чат-агент, агент для конференций и универсальный PM агент. Каждый из них обращается к одной и той же базе данных, но через разные пути выполнения кода. В одном из таких путей была функция execute_query() с параметром is_chat_agent. При значении True этот флаг полностью отключал установку переменной сессии copilot.projects_ids. Результат: SQL-запросы выполнялись без какой-либо фильтрации по проекту. Запрос, поданный безproject_ids или с пустым списком, обходил всю векторную базу данных – включая документы, чаты, метаданные и ссылки на треды из проектов других пользователей и компаний. Это классический случай CWE-863 "Некорректная авторизация" – уязвимость высокой степени критичности в категории CWE-284 "Ненадлежащий контроль доступа".

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

И это был не единственный случай. У чат-агента и агента для конференций в SQL-путях обнаружилась отдельная проблема: обход parameters = None, полностью исключавший область видимости проекта. Изоляция данных зависела от промпта, отправляемого языковой модели, а не обеспечивалась на уровне базы данных. В такой архитектуре одна prompt injection способна раскрыть чужие записи о встречах.

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

Уточним, что подразумевается под "разовым анализом". На него сегодня полагается большинство команд, и он охватывает три распространённых подхода.

• Статический анализ – такие инструменты, как SonarQube, Semgrep или CodeQL. Они проверяют исходный код без выполнения и хорошо выявляют известные паттерны: шаблоны SQL-инъекций, захардкоженные учетные данные, небезопасную десериализацию и тому подобное. CodeQL можно расширять пользовательскими запросами для проверки специфичных для проекта инвариантов, но написание и поддержка таких запросов требуют той же инженерной экспертизы, что и сам инвариант, – и у большинства команд их просто нет.
• Проверки при слиянии в CI-пайплайнах. Они ловят падение тестов, нарушения линтера, снижение покрытия и нарушения пользовательских политик. Они оценивают предложенное изменение, а не долгосрочную эволюцию кодовой базы.
• Периодические мануальные ревью силами старших инженеров. Могут быть тщательными, но обходятся дорого, непоследовательны и плохо масштабируются.

Все три подхода остаются ценными, и ни от одного из них не стоит отказываться. Но у них общее структурное ограничение: они оценивают код в единственный момент. Они отвечают на вопрос "приемлемо ли это изменение прямо сейчас?" Они не отвечают на вопрос "чем стала эта кодовая база за последний месяц интенсивной разработки с помощью ИИ?"

Вот что проваливается сквозь трещины:

Дрейф контроля доступа между компонентами
Функция запроса в одном модуле начинает принимать флаг, отключающий фильтрацию. Другой модуль начинает вызывать ее с этим флагом. Третий модуль копирует тот же паттерн. Каждое изменение в отдельности выглядит безобидно. Вместе они уничтожают изоляцию тенантов.

Семантическая деградация безопасности
Кодовая база может опираться на неявный инвариант – например, "каждый запрос к базе данных должен быть ограничен проектом запрашивающего пользователя". Это правило может не существовать в системе типов, линтере или универсальном наборе правил. Если ИИ генерирует новый путь запроса, он не имеет встроенного представления об этом соглашении.

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

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

Инфраструктурный дрейф за пределами кода
Если ИИ-сгенерированные изменения также вносят новые образы, пакеты или предположения о среде выполнения, командам необходимо сканирование контейнеров наряду с проверкой на уровне приложения. Иначе репозиторий будет выглядеть всё чище, пока среда выполнения становится все менее управляемой.

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

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

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

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

Исправление уязвимости в векторном поиске потребовало нескольких согласованных изменений:

• Добавление защиты по принципу fail-closed: пустой или отсутствующий project_ids немедленно возвращает пустой результат и записывает предупреждение.
• Написание девяти юнит-тестов, покрывающих сценарии защиты.
• Удаление обходов parameters = None, позволявших некоторым агентам пропускать область видимости проекта.
• Изменение поведения по умолчанию с разрешительного на запрещающее.

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

Это лучше соответствует принципам безопасности и требованиям таких фреймворков, как SOC 2 Type II и ISO 27001. Что важнее, это переносит принуждение на уровень базы данных, где ему и место. Промпт для LLM не является механизмом контроля доступа: его можно проигнорировать, манипулировать им или передать в некорректном виде.

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

Статический анализатор не обнаружил бы отсутствие условия WHERE, потому что в функции не было очевидного паттерна инъекции – она просто неправильно фильтровала. Проверка при слиянии не поймала бы это, потому что флаг is_chat_agent был введен в одном PR, а отсутствие принудительного ограничения области видимости было заранее существующим условием в другом пути кода. Периодическое ревью могло бы поймать это, но только если бы ревьюер случайно проследил весь путь запроса от агента через функцию до базы данных, понял модель мультиарендности и заметил отсутствующую переменную сессии.

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

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

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

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

Это архитектурное решение, потому что оно меняет роль качества в процессе разработки.

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

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

Но архитектура – лишь половина истории. Более важная половина – это то, что сообщает этим агентам, что именно искать.

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

Типичный SAST-инструмент знает о категориях OWASP Top 10, паттернах CWE и антипаттернах, специфичных для языка. Эти правила важны, но они универсальны. Они не знают вашего декоратора аутентификации, вашей ORM-обертки, вашей кастомной модели ошибок или принятых в команде соглашений о безопасном доступе к общим данным.

Это создаёт две проблемы одновременно:

1. Слишком много ложноположительных срабатываний на паттерны, приемлемые в вашей среде.
2. Слишком мало истинных срабатываний на проблемы, актуальные именно в вашей среде.

Уязвимость в PM агента – хороший пример. Ни один универсальный набор правил не будет знать, что каждый запрос к векторной базе данных в этом проекте должен устанавливать copilot.projects_ids перед выполнением. Это правило имеет смысл только внутри данной системы.

Поэтому важны ранбуки, специфичные для проекта. Ранбук – это переиспользуемый набор инструкций, определяющий, как следует оценивать конкретный класс задач в конкретной кодовой базе. Это не размытый промпт вроде "проверьте этот код на предмет проблем безопасности". Это структурированный рецепт: что проверять, в каком порядке, по каким стандартам, с какими исключениями и как сообщать о результатах.

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

Более эффективный подход – разбить работу на специализированные сессии, каждая со своим ранбуком:

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

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

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

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

Именно это разделение ответственности – одна специализированная сессия на ранбук, один агент на класс проблем – лежит в основе архитектуры Fleet. Вот как это выглядит на практике.

Настройка проста: 

• Fleet подключается к репозиторию через GitHub App и запускает задачи по расписанию или в виде циклических процессов. 
• Работа маршрутизируется между специализированными агентами: Claude, Codex, Gemini, Kimi. 
• Каждая задача выполняется в изолированном рабочем контейнере, отдельном от инфраструктуры приложения, – так что сканирующий агент никак не может изменить продакшн. 
• Команды могут использовать существующие подписки на API модели; отдельные ключи Anthropic или OpenAI не требуются. 
• Для более строгих окружений Fleet можно развернуть on-premise: в этом случае агенты работают с локально размещёнными моделями (сейчас это Qwen и Kimi), а не с внешними API-подписками, что сохраняет весь код и артефакты сканирования в инфраструктуре организации.

Для команд, работающих в рамках формальных требований соответствия (SOC 2 Type II, ISO 27001, PCI DSS), непрерывное сканирование практически меняет историю аудита. Вместо снимка на конкретный момент времени для ежегодной проверки у команды появляется задокументированный, воспроизводимый процесс, работающий по определенному расписанию и по определенным критериям. Ранбуки кодируют конкретные проверяемые контроли. История сканирований предоставляет хронологически упорядоченную запись о том, что, когда и с каким результатом проверялось. Это другая плоскость, нежели "мы проводили пентест в третьем квартале" – она ближе к непрерывному мониторингу, которого современные фреймворки соответствия все настойчивее ожидают, а не просто принимают.

Инфраструктура – это только базовый уровень. Главное – логика принятия решений Fleet: что именно и как проверяется. Она основана на проектно-специфичных ранбуках, определяющих критерии оценки, методику и формат отчётности для каждого агента. Именно поэтому Fleet работает в реальных кодовых базах: он не ищет универсальные "тревожные признаки", он верифицирует, что код по-прежнему следует правилам, на которые реально опирается команда.

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

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

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

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

Первым шагом стало определение проверок, которые можно выразить однозначно и последовательно применять со временем. Вместо того чтобы просить агента "искать проблемы безопасности", мы дали ему конкретные вопросы: какие пути кода имеют право обходить принудительное ограничение области видимости, где появляются разрешающие fallback-варианты вместо поведения deny-by-default, не ослабил ли поздний рефакторинг логику, которая раньше явно обеспечивала какую-либо границу.

Это стало основой первых ранбуков.

Оттуда мы расширялись слоями. После начальных проверок контроля доступа добавили ранбуки для поведения deny-by-default, для ИИ-рефакторингов и для изменений зависимостей или среды выполнения, которые необходимо интерпретировать вместе с рисками на уровне контейнеров. Развертывание было поэтапным намеренно. Мы не пытались закодировать всю систему сразу. Мы начали с правил, нарушение которых несло бы наибольшие последствия для безопасности.

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

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

Иными словами, разовая иттерация по анализу безопасности превращается в постоянный процесс проверки.

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

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

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

После запуска непрерывного сканирования операционная модель меняется по-разному для разных технических ролей.

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

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

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

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

Ценность проявляется наиболее отчетливо, когда результаты легко понять и легко действовать по ним. Вместо сырых задач в репозитории командам нужны четкие объяснения и приоритизированные сигналы риска, помогающие решить, что важно прямо сейчас. На сегодня Fleet доставляет результаты напрямую в репозиторий – задачами и пулзгреквестами с метками уровня серьезности. Специализированный дашборд, выводящий результаты с пояснениями на понятном языке и приоритизацией рисков, находится в активной разработке; на данном этапе интерпретация вывода Fleet требует базового знакомства с рабочими процессами GitHub.

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

Результат не в том, что CI, SAST или ручное ревью устаревают. Результат в том, что они больше не несут все бремя в одиночку.

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

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

Если ИИ ускорил ваш выпуск продукта, "работает ли оно сегодня?" перестает быть сложным вопросом. Сложный вопрос – видите ли вы, что меняется, можете ли объяснить, почему это безопасно, и удерживаете ли кодовую базу под контролем по мере ее эволюции.

Именно здесь непрерывное сканирование становится необходимостью. Описанная здесь установка – ранбуки, изолированные воркеры, запланированные сканирования, результаты в виде готовых задач и пул реквестов – это то, что Enji Fleet реализует из коробки. Если вы работаете с кодовой базой с интенсивным использованием ИИ и хотите увидеть, как это применимо к вашим конкретным инвариантам, запишитесь на демо.