Приложение написал ИИ. Кто проверил код?

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

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

Выясните, к чему имеет доступ созданное приложение

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

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

Проверьте зависимости и обработку входных данных

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

Материал OWASP о небезопасной обработке выходных данных (2025) объясняет, как передача недоверенного ответа модели другим системам может вызвать проблемы безопасности. К сгенерированному коду нужен такой же подход: правдоподобный результат следует изучать и проверять, а не считать надёжным только потому, что он запускается.

Проведите испытания на реальных сценариях

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

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

Назначьте ответственного за выпуск

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

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

Пять вопросов при передаче проекта

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

Прежде чем принять приложение, созданное с помощью ИИ, спросите: к чему у него есть доступ? Где хранятся секретные ключи? Какие зависимости необходимы? Какие сценарии сбоев проверены? Кто сможет исправить проблему после запуска? Если ответы неясны, приложение пока остаётся прототипом. Польза ИИ в программировании — быстрее получить рабочий черновик; для безопасного запуска по-прежнему нужны доказательства качества готовой системы.