Проверка кода, предложенного ИИ: как отделить ускорение разработки от допуска изменения в поставку

ИИ-подсказка и изменение для поставки — разные объекты

В понедельник разработчик получает от ассистента готовый фрагмент: он проходит локальную сборку, выглядит аккуратно и снимает задачу за двадцать минут вместо дня. В pull request остаётся один неудобный вопрос: что именно команда теперь знает об этом изменении? Понятна ли бизнес-цель, проверен ли доступ, есть ли сценарий ошибки и кто готов объяснить решение после инцидента?

ИИ ускоряет подготовку варианта, но не превращает вариант в принятый результат. ГОСТ Р 56939-2024 включает в безопасную разработку устранение недостатков и уязвимостей, а среди ключевых слов называет статический, динамический и композиционный анализ и функциональное тестирование. Это не готовая кнопка «проверить ИИ-код». Зато это важная рамка: качество поставки подтверждается набором работ, а не происхождением строки.

NIST SSDF формулирует практики безопасной разработки как дополняющие конкретный жизненный цикл и ориентированные на результат. Для руководителя это полезнее, чем спор «можно ли пользоваться ИИ»: один и тот же ассистент может быть приемлем для черновика документации и требовать усиленного маршрута для изменения авторизации. Вопрос не в ярлыке инструмента, а в границе изменения.

Пять доказательств вместо одной зелёной галочки

Первое доказательство — контекст. Автор должен назвать задачу, затронутую границу, риск и ожидаемое поведение. Если prompt или ответ модели содержал только «исправь ошибку», а в diff появляется смена правила доступа, ревьюер не знает, что именно сравнивать с намерением.

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

Третье — независимое ревью. OWASP описывает ручное ревью как проверку, которая дополняет автоматические инструменты анализом логики, потоков данных и контекстных рисков. Cheat Sheet OWASP отдельно рекомендует для diff-based review оценивать влияние на существующие контроли, новые векторы атаки и изменённые границы доверия. Поэтому задача рецензента — не перепечатать вывод ассистента, а восстановить смысл изменений по задаче и коду.

Четвёртое — проверки, которые действительно относятся к diff. Сборка подтверждает лишь часть свойств. Нужны уместные unit/integration/E2E-тесты, статический анализ, анализ зависимостей и проверка конфигурации; состав зависит от репозитория и класса изменения. Тест, которого нет на сценарий, не становится доказательством от зелёного CI.

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

Автоматизация полезна, когда у неё ограниченная роль

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

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

Не стоит отвечать на этот риск запретом всех ИИ-инструментов. Он отнимет пользу раннего черновика и всё равно не вернёт доказательства. Рабочая альтернатива — отделить этап генерации от этапа допуска: использовать ассистента для поиска вариантов, но требовать от человека и контуров проверки те же подтверждения, что требуются для любого другого изменения.

Маршрут усиливается вместе с границей изменения

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

×

Сила проверки зависит от границы изменения. Это методическая матрица НТА по ГОСТ Р 56939-2024 и NIST SSDF, а не шкала сертификации или измерение риска.

Матрица не назначает «высокую» критичность сама. Её определяет команда по своему контексту: архитектуре, данным, обязательствам и способу поставки. Равный набор проверок для любой правки иногда оправдан простотой, но тогда нужно честно принять его стоимость. Равное облегчение для любой правки — уже не простота, а отказ различать последствия.

Откуда берётся критичность: четыре вопроса до кода

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

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

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

Такой подход совместим с NIST SP 800-218A: профиль дополняет базовый SSDF практиками для генеративного ИИ, но не предлагает снять обычные обязанности безопасной разработки. В российском контексте это особенно важно читать как метод, а не как замену локальному регламенту: источник помогает поставить вопросы, но не отвечает за классификацию вашей системы.

Проверка начинается с происхождения, но не заканчивается им

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

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

Важнее всего связать историю с конкретным diff. После нескольких исправлений исходный ответ ассистента может уже не совпадать с поставляемым кодом. Проверять его как артефакт «истины» бессмысленно. Рецензент читает фактическую ревизию, тесты запускаются на фактической ревизии, решение относится к фактической ревизии. Если после review изменились существенные файлы или граница, проверка повторяется. Это правило полезно для любого автора; участие ИИ лишь делает разрыв между черновиком и финалом заметнее.

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

Что именно должны доказывать тесты

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

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

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

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

Независимое ревью: не второй взгляд на стиль

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

Особое внимание нужно четырём местам. Первое — проверки прав: где сервер повторно проверяет разрешение, а не доверяет интерфейсу. Второе — обработка ошибки: не скрывает ли новый catch реальную причину, не оставляет ли частично выполненное действие. Третье — данные: не добавлено ли в лог, кэш или ответ то, что не нужно получателю. Четвёртое — зависимость: не изменился ли контракт библиотеки или внешний API так, что тесты используют удобный, но нереалистичный mock.

Ревью не обязано превращаться в длинный комментарий на каждую строку. Достаточно, чтобы рецензент оставил проверяемое основание решения: какие риски он смотрел, какой вопрос вернул автору, почему контроли достаточны или почему изменение переведено в усиленный маршрут. Это делает review полезным и после merge — следующая команда видит не только подпись, но и логику выбора.

Исключения не должны исчезать в очереди

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

Рабочее исключение содержит четыре вещи: точную непроведённую проверку, причину, оценку затронутой границы и компенсирующий контроль. Например, вместо «security scan skipped» — «композиционный анализ не запущен из-за недоступности сервиса; изменение ограничено конфигурацией feature flag; рецензент проверил список зависимостей вручную; владелец риска разрешил поставку до восстановления сканера». Для высокой критичности сюда добавляется время пересмотра и подтверждённый способ отката.

Исключение не становится нормой от того, что его хорошо описали. Оно делает решение наблюдаемым. Если одна и та же проверка постоянно «временно» недоступна, это сигнал руководителю исправить контур, а не привычка разработчиков. ИИ здесь не создаёт особого правила: он просто может увеличить скорость появления новых diff, поэтому незаметное исключение начинает накапливаться быстрее.

Откат — это проверка способности признать ошибку

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

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

Этот этап полезен и как тест качества самого ИИ-предложения. Если никто не может назвать, что изменилось и как вернуть систему в ожидаемое состояние, команда ещё не понимает diff достаточно для допуска. Не нужно требовать сложной аварийной процедуры от каждой правки. Нужно соразмерить её границе, так же как соразмеряются тесты и review.

Как встроить маршрут в существующий pull request

Новый маршрут не требует отдельной платформы. Во многих командах почти все нужные объекты уже существуют: задача в трекере, ветка, pull request, обязательные статусы CI, код-ревью и описание релиза. Начинать стоит с минимального изменения шаблона pull request. Добавьте в него короткий блок: «какую роль сыграл ИИ», «какая граница изменена», «какие проверки обязательны», «какой отрицательный сценарий проверен», «как откатить». Не просите автора писать эссе. Нужны ответы, по которым следующий человек сможет принять или оспорить решение.

Затем свяжите шаблон с тем, что уже проверяет CI. Если изменение затронуло UI, ссылка на выполненный E2E-сценарий понятнее общего слова tests. Если добавлена миграция, укажите integration-проверку и способ посмотреть новую схему. Если меняются права, зафиксируйте отрицательный тест пользователя без роли. Это превращает шаблон из анкеты в индекс доказательств. Рецензент не ищет подтверждения по десятку вкладок и не верит автору на слово.

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

Важно не измерять успех числом заполненных полей. Плохой процесс может получить стопроцентное заполнение, если авторы пишут одинаковое «не применимо». Более полезные сигналы — доля PR, где review вернуло вопрос о границе; число исключений и их причины; время восстановления после дефекта; случаи, когда отрицательный тест поймал ошибку до поставки. Эти данные не доказывают причинность сами по себе, но помогают руководителю увидеть, что контроль работает как способ учиться, а не как ритуал.

Как не дать ИИ ускорить плохое решение

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

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

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

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

Роли руководителя, автора и рецензента

Руководитель разработки не обязан лично утверждать каждый PR. Его роль — создать ясную норму: какой класс изменений идёт усиленным маршрутом, кто может принять исключение, где хранятся доказательства и какой сигнал означает остановку. Если эти вопросы каждый раз решаются в личных сообщениях, команда получает зависимость от памяти конкретного человека. Правило должно быть достаточно коротким, чтобы его применяли до первого инцидента, и достаточно конкретным, чтобы оно не превращалось в «проверьте внимательно».

Автор отвечает за честный контекст. Это включает неудобные вещи: отметить, что использовал ИИ, показать, где не уверен, не прятать изменение в крупном форматировании и не маркировать непроверенную границу как «рефакторинг». Такая прозрачность не должна быть наказанием. Если упоминание ИИ автоматически делает автора подозреваемым, команда начнёт скрывать его использование, а руководитель потеряет именно тот сигнал, который нужен для выбора проверки.

Рецензент отвечает за независимое чтение, а не за магическое обнаружение всех багов. У него должно быть право вернуть PR за отсутствующим контекстом, непонятной границей или неподтверждённым исключением. Для критичных областей полезно заранее назначить владельцев: безопасность смотрит авторизацию и секреты, доменный эксперт — бизнес-правило, platform-команда — эксплуатационный контур. Это не означает собрать длинную очередь согласований для каждого файла. Это означает знать, где действительно нужна другая компетенция.

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

Первые две недели после запуска

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

На коротком ретро спросите не «нравится ли нам процесс», а четыре более точных вопроса: какой diff пришлось сузить после review; какая проверка оказалась лишней и почему; какой отрицательный сценарий нашли до merge; какое исключение было самым трудным объяснить. Ответы дают качественный материал для настройки маршрута. Не превращайте их в показатель личной производительности разработчиков — тогда участники перестанут честно говорить о неуверенности.

Через две недели оставьте только то, что помогло принять лучшее решение. Если дополнительное поле не меняет ни review, ни выбор теста, ни способность откатить изменение, его стоит убрать или автоматизировать. Если важная граница по-прежнему появляется только после инцидента, сделайте её видимой раньше: добавьте один вопрос к шаблону, небольшой сценарий в CI или назначение профильного рецензента. Цель маршрута — не доказать дисциплину, а дать команде безопасно пользоваться ускорением без ложного допуска.

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

Как выглядит карточка допуска

До merge руководителю не нужен новый громоздкий комитет. Достаточно, чтобы в pull request или связанной карточке были заполнены девять полей.

×

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

Важно не превращать карточку в отчёт задним числом. Если поле «граница изменения» заполняется после успешной поставки, оно не помогает выбрать проверку. Если «владелец риска» появляется только после инцидента, это уже не допуск, а поиск ответственного. Карточка работает, когда её заполняют до merge, а обязательные поля связаны с фактической ревизией.

Что проверять рецензенту именно в ИИ-предложении

Сначала восстановите исходный вопрос: какое поведение меняется и как пользователь или внешняя система заметит результат. Затем читайте diff по границам: входные данные, авторизация, состояние, ошибки, журнал, зависимости и конфигурация. Для сложного изменения полезно спросить автора не «модель это написала?», а «какое утверждение кода ты готов проверить отдельно?»

Далее ищите ложную уверенность. Типичные сигналы: большая переработка в маленькой задаче, внезапно добавленная библиотека, новая ветка обработки ошибки без теста, слишком общий catch, изменение доступа рядом с «косметикой», копирование сомнительного примера в несколько файлов. Ни один из этих сигналов не доказывает дефект. Каждый — причина сузить проверку и потребовать подтверждение.

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

Тест понедельником

Возьмите один уже открытый pull request, где ИИ участвовал хотя бы как черновик. До merge заполните девять полей карточки. Затем попросите человека, который не писал изменение, за пять минут назвать границу, обязательный тест, возможный негативный сценарий и способ отката. Если он может назвать только инструмент и зелёный статус CI, допуск ещё не собран.

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

Важное уведомление

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