Сколько ручной проверки нужно коду с поддержкой ИИ?

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

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

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

Проверяйте последствия, а не автора

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

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

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

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

Практический классификатор фиксирует эти факты в пул-реквесте, а не просит дать расплывчатую оценку риска:

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

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

Четыре уровня делают политику рабочей

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

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

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

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

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

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

review_tiers:
  tier_1:
    approvals: 1
    checks: [build, lint, unit]
  tier_2:
    approvals: 1
    checks: [build, unit, affected_suite, static_analysis, secrets, dependencies]
  tier_3:
    approvals: 2
    required_roles: [code_owner, domain_owner]
    checks: [tier_2, integration, security_scan, rollback_test]
  tier_4:
    approvals: 3
    required_roles: [code_owner, security_owner, release_owner]
    checks: [tier_3, threat_model, misuse_tests, staged_release]
protected_paths:
  tier_3: [auth/, billing/, migrations/, infra/, package-lock.json]
  tier_4: [crypto/, production/identity/, clinical/decision-support/]

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

Тесты должны доказывать рискованное утверждение

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

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

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

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

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

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

$ npm test access-policy.test.ts
PASS access-policy.test.ts
  assigned clinician can read (18 ms)
  unassigned clinician is denied (7 ms)
  missing assignment response fails closed (9 ms)
Tests: 3 passed, 3 total

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

Чувствительный код требует независимой оценки безопасности

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

OWASP Application Security Verification Standard дает командам полезный словарь. ASVS определяет уровни проверки с растущей строгостью и группирует требования по аутентификации, контролю доступа, валидации, криптографии, журналированию, защите данных, API и конфигурации. Я бы не копировал весь стандарт в каждый пул-реквест. Свяжите чувствительные пути продукта с применимыми требованиями, а затем показывайте эти требования при изменении таких путей.

NIST SP 800-218 высказывает похожую мысль в Secure Software Development Framework. Практика проверки проекта требует квалифицированного специалиста, который не участвовал в проектировании, автоматизированных процессов в цепочке инструментов либо обоих вариантов. Результаты нужно сохранять в виде артефактов. Квалификация важна. Случайное второе согласование не выполняет замысел, если ни один ревьюер не понимает изменяемую границу доверия.

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

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

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

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

Изменения зависимостей приносят невидимый в diff код

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

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

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

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

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

Явные согласующие предотвращают формальные подписи

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

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

Автор не может дать независимое согласование. Человек, который подготовил запрос для ИИ, также не становится независимым лишь потому, что код создала модель. Автор отвечает за изменение: понимает, редактирует, тестирует его и объясняет ограничения. Если автор не может объяснить ветвь или зависимость, проверку нужно остановить.

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

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

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

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

Результат ИИ требует проверки за пределами diff

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

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

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

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

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

Наконец, требуйте ответственности без показного ручного переписывания. Повторный набор сгенерированного кода не делает его безопаснее. Автор должен объяснить инварианты, воспроизвести тесты, проверить API, убрать лишний объем и ответить на замечания. Критерием служит понимание, подтвержденное доказательствами.

Исключению нужны срок и план восстановления

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

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

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

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

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

Настраивайте уровни по данным релизов

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

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

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

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

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

Часто задаваемые вопросы

Весь ли сгенерированный ИИ код требует ручной проверки?

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

Могут ли автоматические тесты заменить ревьюера?

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

Как классифицировать небольшое, но чувствительное изменение?

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

Должны ли ревьюеры знать, какой код написал ИИ?

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

Сколько согласующих нужно для рискованного изменения с ИИ?

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

Какие проверки безопасности запускать для кода с поддержкой ИИ?

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

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

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

Может ли срочное исправление обойти уровни проверки?

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

Какие доказательства приложить к пул-реквесту с кодом ИИ?

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

Как часто обновлять уровни проверки кода?

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