Автор колонки на Хабре описал опыт, который, судя по реакции сообщества, знаком многим практикующим разработчикам: использование ИИ-агентов в повседневной работе не ускоряет процесс, а создаёт новый вид когнитивной нагрузки. В качестве инструментов он применял CLI-агент opencode с моделями Claude Sonnet 4.6, Claude Opus 4.6 и Qwen 3.5-397B.

Проблема не в том, что агенты пишут нерабочий код — хотя и это случается. Проблема в предсказуемости. Когда разработчик пишет код сам, он заранее знает архитектуру решения, стиль, объём. Когда тот же разработчик отдаёт задачу агенту, результат непредсказуем по определению: LLM — это вероятностная модель, она не гарантирует воспроизводимость даже при одинаковом промпте. Агент может использовать несуществующий метод, придумать библиотеку, неверно интерпретировать архитектурные ограничения или попутно переписать соседние классы «для улучшения качества».

Автор фиксирует конкретный паттерн: то, что умещается в 20 строк, агент реализует в 30–40. При масштабировании на десятки файлов это превращается в сотни строк избыточного кода, который нужно читать, понимать и проверять. Изучение чужого кода — а сгенерированный код именно таков — требует значительно большей когнитивной нагрузки, чем понимание написанного самостоятельно. Отдельно достаётся генерации юнит-тестов: агент стабильно создаёт избыточный инфраструктурный код с моками и сетапами, при этом сами тесты зачастую ничего не проверяют, не компилируются или противоречат логике основного кода.

Агент стабильно генерирует код на 30–40 строк там, где достаточно 20, и почти никогда не следует принятым в проекте соглашениям.

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

В более широком контексте это отражает реальное ограничение текущего поколения LLM в задачах кодогенерации: модели хорошо справляются с изолированными, хорошо описанными задачами, но плохо удерживают контекст большого проекта, его архитектурные соглашения и стилевые нормы. Инструменты вроде Cursor, GitHub Copilot или opencode пытаются решить эту проблему через RAG по кодовой базе и системные промпты с правилами проекта, однако полностью устранить недетерминированность они не могут — это свойство самих моделей. Пока разрыв между «агент написал код» и «код готов к продакшну» остаётся значительным, вопрос о реальной производительности разработчика с агентом против разработчика без него остаётся открытым.