У компании уже работает приложение: клиенты видят заказы, менеджеры меняют статусы, бухгалтер выгружает отчёты. Появляется небольшая задача — добавить экспорт документов. Разработчик подключает ИИ-агента, просит сделать по образцу соседнего раздела и быстро получает рабочую кнопку. Однако в старом разделе могла отсутствовать проверка, кому принадлежат данные. Вместе с удобным шаблоном новая функция получает и чужую ошибку.
Доработка приложения с ИИ требует проверки исходных образцов ещё до генерации. Особенно это важно для личных кабинетов, CRM, сервисов с несколькими организациями и продуктов, которые росли без единого подхода к доступам. Ниже — практический порядок работы для владельца такого проекта и его команды.
Что показало новое исследование
8 ноября 2026 года на arXiv опубликован препринт Coding Agents Propagate Vulnerabilities in Code Bases. Авторы проверяли, как небезопасные примеры в существующем репозитории влияют на новые решения агентов: в задачах серверной разработки и проектах на C/C++ уязвимый контекст чаще приводил к уязвимому результату. Напоминание соблюдать безопасность уменьшало перенос ошибок, но не устраняло его полностью.
Это эксперимент на конкретных задачах и инструментах, а не измерение всех коммерческих приложений. По нему нельзя вычислить вероятность ошибки в вашем проекте. Практический вывод TigerNova: прежде чем поручать агенту «следовать существующему стилю», нужно проверить, какие решения он примет за образец. Качество контекста становится частью качества доработки.
Первоисточник: Coding Agents Propagate Vulnerabilities in Code Bases, препринт от 8 ноября 2026 года
Почему работающий старый код требует проверки
Функция могла годами использоваться только двумя сотрудниками. Затем её открыли партнёрам, добавили мобильный клиент и подключили новые организации. Предположения изменились, а ограничения остались в интерфейсе или в памяти прежнего разработчика. Агент видит реализацию, но сам факт её существования ничего не говорит о допустимости такого решения сегодня.
Наследуются и менее заметные привычки: запись чувствительных данных в журнал, обработка ошибок без уведомления, слишком широкие права служебного аккаунта. Если новый модуль копирует их, число мест для исправления растёт. Поэтому полезно отдельно спросить команду: что здесь является согласованным правилом, а что сохранилось по историческим причинам?
Пример: экспорт отчёта из личного кабинета
Представим учебный пример: сотрудники компаний «Альфа» и «Бета» работают в одном сервисе. Для новой выгрузки агент использует соседний обработчик, который получает номер организации из запроса. Кнопка в браузере показывает только свою компанию, но сервер должен независимо проверить, разрешена ли эта выгрузка текущему пользователю. Скрытый пункт меню такую проверку не заменяет.
В тестовом окружении создайте две вымышленные организации и несколько ролей. Сотрудник «Альфы» должен получить свой разрешённый отчёт, а запрос к данным «Беты» — получить отказ без содержимого чужого документа. Отдельно проверьте прямую ссылку на готовый файл и доступ после выхода из аккаунта. Конкретные ожидания для каждой роли команда фиксирует заранее.
OWASP рекомендует обеспечивать контроль доступа в доверенном серверном коде и проверять принадлежность записей. Из этого следует полезный критерий приёмки: разработчики показывают успешный разрешённый сценарий и отказ в запрещённом. Проверку проводят на своих тестовых данных, без попыток исследовать чужие сервисы.
OWASP Top 10:2025 — Broken Access Control и рекомендации по серверным проверкам
Что проверить до поручения ИИ-агенту
Начните с ограниченного обследования участка, который предстоит менять. Для экспорта это вход пользователя, выбор организации, получение данных, создание файла и его скачивание. Такой маршрут помогает найти общие зависимости и согласовать объём аудита. При обнаружении общей проблемы расширяют проверку на похожие обработчики.
- Опишите роли и владельцев данных: кто видит запись, кто изменяет её и кто может выгрузить документ.
- Выберите проверенный образец реализации. Если соседний модуль небезопасен, сначала исправьте общий механизм и перечислите места, которым он нужен.
- Подготовьте тестовые данные без реальных клиентских документов, рабочие инструкции запуска и ограничения для нового изменения.
- Выделите агенту отдельную рабочую среду и минимальные необходимые доступы. Рабочая база, ключи платежей и административные права для генерации кода обычно не нужны.
Письменные правила полезны: например, проверять право на документ на сервере и использовать единый модуль доступа. Но правило в инструкции должно подкрепляться устройством приложения и проверками. Фраза «пиши безопасно» оставляет слишком много решений на усмотрение модели.
Как проверять саму доработку
Делите работу на изменения, которые можно осмысленно просмотреть. Например, сначала общий механизм авторизации документа, затем обработчик выгрузки и проверки его поведения. Для каждого шага должно быть понятно, что изменилось и как это проверить. Большой пакет несвязанных правок усложняет поиск причины ошибки и возврат к предыдущему состоянию.
В материале от 6 ноября GitHub описывает разработку с агентами через планирование, реализацию, проверку и наблюдение после выпуска. Компания отдельно рекомендует небольшие сфокусированные изменения. Для заказчика это полезная рамка: в предложении подрядчика стоит видеть время на проверку и эксплуатацию, а не только на генерацию функции.
GitHub: Beyond code generation — руководство по разработке с агентами, 6 ноября 2026 года
Автоматические проверки должны соответствовать проекту: сборка, тесты важных сценариев, поиск секретов, анализ зависимостей и применимые правила анализа кода. Их результаты помогают инженеру, но зелёный отчёт сам по себе не доказывает правильность бизнес-правил. Различия между ролями, организациями и состояниями документа нужно проверять отдельно.
Что запросить у подрядчика при приёмке
Попросите связать результат проверки с конкретной версией исходников. Если после проверки код изменился, должно быть видно, какие проверки выполнили заново. Для приёмки небольшой доработки удобен короткий комплект материалов:
- Описание изменения и затронутых общих компонентов, включая места, где нашли похожую старую ошибку.
- Список проверенных ролей и сценариев: разрешённые действия, ожидаемые отказы, работа с файлами и ошибками.
- Протокол проверок с версией кода, окружением, датой и результатами; найденные ограничения перечислены явно.
- Порядок выпуска и возврата: отдельно объяснено, что произойдёт с данными, созданными после обновления.
- Ответственный за первые обращения после запуска и признаки проблемы, которые команда отслеживает в журналах и мониторинге.
Стоимость такого этапа зависит от понятности старого проекта, наличия проверок и количества связанных сценариев. Просите оценку с границами: что именно обследуют, какой результат передадут и что станет поводом пересмотреть объём. Скорость ответа нейросети не определяет трудоёмкость проверки существующего продукта.
Частые вопросы
Нужно ли переписывать всё приложение перед подключением ИИ?
Начните с обследования затронутого участка и общих механизмов. Иногда достаточно исправить единое правило доступа и его использование. Решение о более крупной переработке требует результатов проверки, а не самого факта применения ИИ.
Может ли другой ИИ-агент принять работу первого?
Он может помочь найти подозрительные места и предложить проверки. Приёмку связывайте с воспроизводимыми результатами и ответственным инженером: второй агент тоже способен принять старую ошибку за норму.
Это относится к мобильным приложениям?
Да, если они обращаются к общему серверу. Ограничение экрана в мобильном клиенте не заменяет проверку права на серверную операцию. При доработке проверяют весь путь от приложения до данных.
Какие сведения подготовить для первого разговора?
Опишите нужную функцию, роли пользователей, связанные системы и известные ошибки. Сначала можно обсудить задачу без рабочих паролей и клиентских данных; доступ к исходникам и тестовой среде согласовать отдельно.
TigerNova: поддержка и развитие существующих сайтов и приложений
Базовый разбор: риски вайбкодинга перед запуском нового приложения
TigerNova / Практические материалы о цифровых продуктах