Нужно ли ревью AI-кода, если требования ведет аналитик?

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

AI меняет скорость появления кода, но не меняет природу ответственности. Модель легко собирает убедительный интерфейс и правдоподобный серверный обработчик, в котором право доступа проверяется после чтения записи, денежная сумма округляется дважды, а повторный запрос создает второй заказ. Аналитик заметит неверный тариф или пропущенный статус. Опытный разработчик увидит гонку, неатомарную запись и неявное доверие к данным клиента. Эти проверки пересекаются, но не заменяют друг друга.

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

Аналитик подтверждает смысл, а не устройство системы

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

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

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

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

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

Четыре проверки требуют разных доказательств

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

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

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

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

ISO/IEC 25010:2023 полезен именно этим разделением. Стандарт предлагает модель свойств качества для задания требований и оценки продукта разными участниками, включая разработчиков, заказчиков и специалистов по качеству. Из него не следует, что на каждый проект нужен отдельный эксперт по каждой характеристике. Следует другое: функциональная пригодность не доказывает надежность, сопровождаемость или защищенность. Одна успешная приемка не может считаться свидетельством по всем этим направлениям.

Приемочные сценарии должны ломать удобный путь

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

Допустим, аналитик задал правило: менеджер может подтвердить возврат до 10 000 рублей, а большую сумму подтверждает руководитель. Обычный сценарий с 5 000 рублями проверяет лишь кнопку. Набор ниже превращает смысл правила в воспроизводимый контракт:

Feature: Подтверждение возврата

Scenario: Менеджер подтверждает сумму ниже лимита
  Given возврат на 9999.99 рубля ожидает решения
  And текущий пользователь имеет роль manager
  When пользователь подтверждает возврат
  Then статус возврата равен approved
  And в журнале записан идентификатор пользователя

Scenario: Менеджер не подтверждает сумму на границе эскалации
  Given возврат на 10000.01 рубля ожидает решения
  And текущий пользователь имеет роль manager
  When пользователь подтверждает возврат
  Then сервер возвращает отказ в доступе
  And статус возврата остается pending

Scenario: Повтор запроса не создает вторую выплату
  Given подтвержденный возврат имеет ключ операции abc-123
  When тот же запрос отправлен повторно с ключом abc-123
  Then существует ровно одна выплата
  And ответ содержит результат первой операции

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

Сценарии не обязаны быть написаны на Gherkin. Подойдет таблица или тестовый код, если в ней явно видны предусловия, действие и наблюдаемый результат. Фраза «проверить возвраты» не годится, потому что два человека прочитают ее по-разному. Фраза «ровно 10 000 относится к полномочиям менеджера» годится, если команда заранее решила, с какой стороны проходит граница.

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

Разработчик видит ошибки вне приемочных требований

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

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

Ревьюер должен проверить несколько связей, которые редко присутствуют в бизнес-требовании:

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

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

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

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

Безопасность начинается с границ доверия

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

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

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

NIST Secure Software Development Framework идет дальше лозунга «проведите ревью». Практика PW.7 разделяет просмотр кода человеком и анализ инструментами и предлагает организации определить, когда и как применять каждый метод. Это разумная оговорка: обязательный ручной просмотр каждой косметической правки тратит внимание, а полный отказ от просмотра чувствительного обработчика оставляет риск без владельца. Политика должна связывать метод проверки с последствиями функции.

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

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

Состав ревью определяет цена ошибки

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

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

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

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

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

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

Малой команде нужна независимость, а не штат

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

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

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

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

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

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

Автоматические проверки не выдают разрешение на выпуск

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

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

Главная ловушка состоит в автогенерации большого числа тестов, которые повторяют структуру реализации. Модель видит условие if amount > limit и пишет два теста по обе стороны, но не спрашивает, верен ли строгий знак и в какой валюте задан лимит. Такие тесты защищают текущий код от случайного изменения, но могут навсегда закрепить неверное правило. Аналитик должен подтвердить ожидаемые значения независимо от кода.

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

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

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

Решение о выпуске должно оставлять след

Разрешение на выпуск должно показывать, кто проверил каждый риск и на какой версии. Чат «у меня работает» невозможно надежно связать с конкретным кодом, данными и окружением. Короткая запись решения полезнее длинного регламента, если она содержит факты.

Для изменения среднего или высокого риска я фиксирую пять вещей:

1. Идентификатор версии или снимка и точную область изменения.
2. Принятые бизнес-правила и ссылки внутри проекта на результаты сценариев.
3. Итог технического ревью с открытыми ограничениями, а не только слово «одобрено».
4. Результаты автоматических проверок и ручной проверки безопасности.
5. План отката, владельца решения и условие, при котором откат запускают.

Это единственный нумерованный процесс в статье, потому что порядок здесь важен: нельзя одобрить неизвестную версию, а план отката после выпуска уже опоздал. Если один человек исполняет несколько ролей, он отмечает каждую отдельно. Запись «Ирина: бизнес-правила и приемка; Алексей: схема данных, код и контроль доступа» лучше общей строки «команда проверила».

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

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

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

Без разработчика можно выпускать только ограниченный риск

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

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

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

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