Как заказчику принимать код, созданный с помощью AI

Что считать готовым результатом

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

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

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

Что изменилось с появлением агентов

GitHub в Octoverse от 28 октября 2026 года сообщает: в сентябре более 40% pull request на платформе начинались с черновика агента, против 17% в марте. Pull request — предложение изменения в репозитории, а не готовый клиентский продукт.

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

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

Что запросить у подрядчика вместе с кодом

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

• Репозиторий и версия. Доступ организации заказчика, история изменений, тег или SHA принятого коммита, перечень внешних репозиториев и владельцев. Проверьте, что назначенный сотрудник может получить исходники и управлять доступами в согласованном объёме.
• Инструкция сборки и запуска. Версии среды, команды установки и сборки, зафиксированные зависимости, системные библиотеки, начальная схема базы, безопасные тестовые данные. Отдельно — сервисы, без которых сценарий не работает.
• Конфигурация и секреты. Образец настроек без значений секретов, назначение переменных, владелец хранилища и процедура выдачи и смены доступа. Секреты передают через согласованный защищённый канал, а не в README.
• Зависимости и компоненты. Список пакетов, версий и лицензий, известные уязвимости и принятые решения по ним. Наличие списка не доказывает безопасность; важны актуальность проверки и разбор применимых находок.
• Проверки. Требования, сценарии, тестовые роли и данные, команды запуска тестов, результаты именно для передаваемой версии. Отдельно перечислите непроверенное и известные дефекты.
• Эксплуатация. Порядок обновления и миграций, резервирования и восстановления, место журналов и оповещений, ответственные за сбой и список внешних платных сервисов с владельцами аккаунтов.

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

Матрица приёмки: требование и доказательство

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

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

Почему зелёных тестов недостаточно

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

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

Документация GitHub Copilot code review рекомендует проверять обратную связь модели и дополнять её человеческим ревью: инструмент может ошибаться и пропускать проблемы. Это ограничение конкретного инструмента, а не оценка качества всех AI-систем.

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

Сборка, миграции и откат

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

В такой проверке «воспроизводимая сборка» означает повторяемое получение работающего приложения из указанной версии и зависимостей. Побайтовая идентичность артефактов — отдельное требование, если она нужна проекту.

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

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

Пример незавершённой передачи кабинета

В учебной ситуации подрядчик прислал архив исходников, видео входа администратора и снимок зелёного отчёта тестов. Кабинет открывается. Однако нет зафиксированной версии зависимостей, тестовых пользователей разных организаций, инструкции миграции и владельца аккаунта хостинга.

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

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

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

Когда нужна независимая проверка

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

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

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

Частые вопросы