Я всё чаще ловлю себя на том, что агент ломается вообще не там, где я ждал.
Сидишь, даёшь нормальную задачу. Он понял контекст, нашёл нужные файлы, даже план выглядит адекватно. А потом начинается какая-то бытовая боль. Команда в терминале не запускается. MCP подключился, но молчит. API вернул странную ошибку. Файл вроде можно править, но sandbox не даёт. Переменная окружения есть, но агент её не видит. И ты такой сидишь и думаешь, ну как так. Модель же вроде умная. Потом смотришь внимательнее, и оказывается, что модель тут вообще почти ни при чём. Сломалась не голова агента. Сломались руки, которыми он трогает проект.
Нашёл исследование, где разобрали 3864 бага в Claude Code, Codex и Gemini CLI. Там интересная картина. Проблемы с самой логикой модели занимают около 10%. А больше трети багов связаны с API, конфигурацией, терминалом и интеграциями. Это хорошо объясняет, почему иногда AI-инструмент выглядит глупо на ровном месте.
Например, в обсуждениях Gemini CLI люди пишут, что включают все разрешения, allow edits, yolo mode, но агент всё равно не может нормально записать файл или продолжить сессию. В Codex issue был кейс, где агент не мог выполнить простую команду внутри workspace sandbox, хотя напрямую та же команда работала. У Claude Code был похожий пример с Docker MCP. Через обычный терминал инструмент отвечал за несколько секунд, а через агентный слой зависал и падал по таймауту. Снаружи это выглядит как агент тупит. Внутри это больше похоже на обычную инженерную проблему. Права, окружение, stdout, stderr, таймауты, сетевой доступ, формат ответа, состояние сессии. Поэтому я всё меньше верю в подход просто подключим агента к проекту.
Подключить можно за вечер. Сделать так, чтобы он стабильно работал каждый день, уже сложнее. Нужен простой контур проверки. Агент должен уметь прочитать файл, записать файл, запустить тест, сходить в нужный сервис, получить нормальный вывод команды и понятно объяснить, где именно упал. Не просто сказать something went wrong, а вернуть человеку внятную причину.
В нормальном проекте для агента нужны почти те же вещи, что и для любого сервиса. Логи, лимиты, понятные права, smoke-тесты, документация, список разрешённых команд, нормальные ошибки вместо тишины. OpenAI в материале про безопасный Codex как раз пишет про sandbox, approvals, network policy и OpenTelemetry. Звучит скучно, но на практике именно это решает половину боли.
Мы уже достаточно много говорили про то, какая модель умнее. Но в реальной работе всё чаще побеждает не самая умная модель в вакууме, а связка, где нормально собраны инструменты вокруг неё. Плохая интеграция легко делает сильного агента бесполезным. Он может понимать задачу, но если не может стабильно выполнить команду, достать логи или записать файл, для проекта это всё равно не рабочий инструмент. И вот это, наверное, самый трезвый взгляд на AI-разработку сейчас.
Модель важна. Но среда, в которой она работает, уже не менее важна.
· 18.05
Работал с Claude Code на проекте и могу подтвердить. Самое обидное когда агент выдаёт идеальный план, а потом спотыкается на правах доступа к файлу. Ты полчаса дебажишь не логику, а окружение. По факту сейчас больше времени трачу на настройку sandbox и конфигов чем на промпты. Инфраструктура вокруг модели это новый DevOps по сути.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён