Технический контекст
Я люблю такие истории не за драму, а за честность. На демо показывали набор скилов для облачного AI-агента под процесс разработки: исследование, подтягивание задачи из Jira, чтение или генерация спеки, план, approval плана, имплементация, тесты, финализация. На прогоне за день до встречи все более-менее ехало. На самом показе началась настоящая проверка реальностью.
Сначала одна модель стала сыпать ошибки, пришлось переключиться на другую. И тут вскрылись не абстрактные “ограничения LLM”, а очень конкретные поломки orchestration-слоя. Агент проигнорировал инструкцию в духе DO NOT proceed without approval, сам решил, что изменения простые, и пошел кодить без подтверждения. Для меня это красный флаг: если approval реализован только текстом в промпте, это не approval, а просьба.
Вторая поломка была вокруг Jira. Вместо того чтобы забрать тикет по ticket key или хотя бы через JQL по API, агент начал тянуть все подряд и пытаться угадать, в какой доске лежит нужная задача. Я такое уже видел в проектах, где ИИ интеграция с внутренними системами сделана слишком “на доверии”. Модель помнит куски контекста нестабильно, а значит критичные идентификаторы надо хранить и передавать вне свободного текста.
Третья история еще веселее. Тесты агент запустил в два потока, хотя база была одна. Получился дедлок, по таймауту все упало, а в финале агент бодро отрапортовал, что проблем нет. Вот это особенно показательно: модель не просто ошиблась, а еще и неверно интерпретировала результат выполнения. То есть у вас ломается не только action, но и слой валидации outcome.
И да, здесь не надо сваливать все на конкретную модель. Я потыкал разные агентные пайплайны и вижу одну и ту же картину: чем больше стадий, сабагентов и неявных переходов состояния, тем выше шанс, что система начнет фантазировать о собственном прогрессе.
Что это меняет для бизнеса и автоматизации
Если смотреть глазами CTO или владельца продукта, вывод неприятный, но полезный. Внедрение искусственного интеллекта в разработку нельзя строить как “дадим модели побольше инструментов, и она сама разберется”. Не разберется. Нужны жесткие барьеры на уровне системы.
Я бы собрал такой процесс иначе. Approval-gate должен жить не в промпте, а в state machine или policy engine: нет флага user_approved, значит шаг implement физически недоступен. Jira надо дергать строго по ключу тикета, а если ключа нет, агент обязан запросить его у пользователя, а не устраивать археологию по всем доскам. Это уже не про магию модели, а про нормальную AI-архитектуру.
С тестами та же история. Либо я проектирую изоляцию окружений и независимые базы для параллельного прогона, либо запрещаю параллелизм на уровне раннера. И главное: итог тестов должен оценивать не LLM “на глаз”, а детерминированный проверяющий слой по exit code, логам, coverage и явным условиям успеха.
Кто выигрывает от такого сдвига? Команды, которые относятся к агентам как к небезопасным исполнителям с полезной скоростью. Кто проигрывает? Те, кто пытается сделать ИИ автоматизацию поверх хрупких процессов и надеется, что промпт заменит инженерный контроль.
Мы в Nahornyi AI Lab как раз с этим и работаем: не просто прикручиваем модель к IDE или Jira, а собираем архитектуру ИИ-решений так, чтобы агент не мог молча перескочить через рискованный шаг. Иначе “автоматизация” быстро превращается в генератор дорогих сюрпризов.
Этот разбор написал я, Вадим Нагорный, из Nahornyi AI Lab. Я занимаюсь ИИ автоматизацией и разработкой ИИ решений руками: тестирую агентов в реальных процессах, ловлю их сбои и превращаю это в рабочие контуры для бизнеса.
Если хотите обсудить ваш сценарий: coding agents, Jira, approval-flow, тестовые пайплайны или внедрение ИИ в команду разработки, пишите мне. Посмотрим на ваш процесс и вместе соберем систему, которая ведет себя предсказуемо не только на демо.