Риски и типичные провалы

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

Карта рисков

Ниже — подробнее о самых важных.

Перегруз ревью и ложная уверенность

Отчёт DORA 2025 года фиксирует положительную связь внедрения ИИ с пропускной способностью, но отрицательную — со стабильностью поставки (Google Cloud). Механика понятна: изменений больше, внимание на каждое меньше. OpenAI отдельно предупреждает о соблазне считать чистое ревью ИИ гарантией безопасности, а не одним из слоёв защиты (OpenAI Alignment).

Признак беды — когда одобрение стало ритуалом. Что делать — в уроках «Ревью при росте потока MR» и «Ворота качества».

Безопасность сгенерированного кода

По отчёту Veracode 2025 года, в котором проверили больше 100 языковых моделей, 45% сгенерированных образцов кода не прошли проверки безопасности и содержали уязвимости из OWASP Top 10; от межсайтового скриптинга модели не защитились в 86% релевантных случаев, а новые и более крупные модели не оказались безопаснее (Veracode). Исследование не про Codex и не про агентов с тестами в цикле, но вывод переносится: функционально рабочий код не значит безопасный.

Для веб-проектов агентства это значит: SAST и сканирование зависимостей в CI, правила ревью про ввод пользователя и вывод в шаблоны, второй ревьюер на изменениях в авторизации и оплате.

Prompt injection и данные

Агент читает тексты, которые писали не вы: описание задачи, комментарии в MR, README зависимостей, веб-страницы. Любой из них может содержать инструкции для агента. Документация Codex называет главными рисками включённого доступа в интернет prompt injection, утечку кода или секретов, загрузку вредоносных или уязвимых зависимостей и нарушение лицензий (internet access). Отдельно сказано, что сетевой прокси песочницы не фильтрует веб-поиск, MCP-подключения и действия в браузере (approvals и безопасность).

Что в силах тимлида:

• права по умолчанию — workspace-write и одобрения по запросу; полный доступ только в изолированной среде;
• никаких боевых секретов в рабочем каталоге и в окружении агента;
• агенты с браузером — только на тестовых стендах;
• в CI — задания с ключом не запускаются на MR из форков и не исполняют код проекта.

Модель угроз на уровне компании и разбор инцидентов — в уроке «Инциденты и prompt injection».

Дрейф и энтропия

Агент воспроизводит шаблоны, которые видит в репозитории, включая неудачные. Команда OpenAI описывает, как сначала тратила на уборку за агентами каждую пятницу — 20% недели — и как это не масштабировалось; решением стали закодированные «золотые принципы» и регулярные фоновые задачи по уборке (Harness engineering). В агентстве с десятками проектов дрейф особенно опасен: каждый проект обрастает своими хелперами и подходами. Подробнее — в уроке «Энтропия и сборка мусора в коде».

Типичные провалы внедрения

Внедрение без базы. Нет измерений «до» — через месяц невозможно сказать, что стало лучше. См. «Метрики».

Правила в чате, а не в репозитории. Каждый разработчик объясняет агенту одно и то же в каждой сессии, у каждого свои формулировки. Документация Codex прямо называет антипаттерном долговременные правила в промпте вместо AGENTS.md.

Агенту не сказали, как проверять. Нет команд тестов и линта в AGENTS.md — агент приносит непроверенный код, и проверка ложится на ревьюера.

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

Параллельные задачи на одних файлах. Несколько агентов правят одно и то же без отдельных worktree, потом — конфликт и потерянная работа. См. «Несколько задач параллельно».

Автоматизация раньше ручной надёжности. Задачу ставят по расписанию или в CI, пока она нестабильна даже вручную.

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

Обещания клиенту. Сроки сокращают заранее, исходя из ощущений, — а потом команда экономит на проверке. Об оценке — в уроке «Оценка и планирование с агентом».

Ритуал: разбор инцидентов с агентом

Когда изменение с участием агента приводит к багу на проде, разбирайте его как любой инцидент, без поиска виноватых, но с одним дополнительным вопросом: какого правила, проверки или инструмента не хватило, чтобы агент или ревьюер поймал ошибку? Ответ превращается в MR — в AGENTS.md, линтер, тест или процесс. Это та же логика, которую OpenAI описывает для своей команды: при неудаче агента спрашивать, какой возможности не хватает, а не просить «стараться лучше».