Помните тот комментарий на Quora, который стал мемом? «Зачем нанимать разработчика, если можно просто копировать код со Stack Overflow?» Забавно, да? Но вот что интересно — времена изменились, а проблема осталась, только в другом виде.
В эпоху Stack Overflow главный вызов был такой: какой из тысячи фрагментов кода выбрать и как его правильно адаптировать? Теперь, когда генерировать код стало проще простого, встал совсем другой вопрос — как найти код действительно высокого качества и безопасно внедрить его в production? И вот тут начинаются настоящие проблемы.
Статья разбирает практические подводные камни, с которыми сталкиваются инженеры, используя современные кодирующие агенты в реальной работе. Речь о сложных моментах: интеграция, масштабирование, безопасность данных, соответствие compliance и поддерживаемость кода в живых системах. Мы постараемся отделить шумиху от реальности и показать, что AI-агенты умеют на самом деле.
Узкое понимание домена и ограничения сервисов
Вот в чём беда: AI-агенты плохо справляются с проектированием масштабируемых систем. Причин две. Во-первых, выборов слишком много. Во-вторых, контекста недостаточно. Крупные корпоративные кодовые базы и монорепозитории — это просто огромные хранилища информации, которые агент не может полностью изучить. А ключевое знание разбросано по внутренней документации и в головах разработчиков.
На практике это выглядит так: многие популярные кодирующие агенты натыкаются на серьёзные ограничения. Индексирование может отказать или сильно деградировать, если репозиторий содержит больше 2500 файлов. Файлы больше 500 KB часто вообще исключаются из поиска. Это бьёт по продуктам с многолетней историей, где файлы достаточно крупные. Новые проекты страдают меньше, согласимся.
Для сложных задач, когда нужен контекст из множества файлов или масштабный рефакторинг, разработчик должен явно предоставить все нужные файлы, описать процедуру изменений и даже расписать build-команды для проверки, чтобы не сломать существующий функционал. То есть уже не то «напиши за меня», а скорее «вот кирпичики, собери мне что-то из них».
Агент ничего не знает про железо и окружение
Вот что по-настоящему поражает: AI-агенты совершенно не понимают специфику операционной системы, команд терминала и установленного окружения (conda, venv). Результат? Агент пытается выполнить Linux-команды в PowerShell и получает «command not recognized». Смешно, но больно.
Кроме того, агенты часто не могут правильно ждать результаты выполнения команд. Он преждевременно объявляет, что не может прочитать вывод, и начинает перепроверять или вообще пропускает этап — всё это до того, как команда закончила выполняться, особенно на более медленных машинах.
Может показаться — ерунда, мелочь. Но в этих деталях вся суть. Вот результат: разработчик не может просто дать задачу и забыть о ней. Нужно постоянно следить, что делает агент. Иначе он может проигнорировать начальные параметры, остановиться раньше времени или выдать полусырое решение, которое потом нужно переделывать. Отправить запрос в пятницу вечером в надежде, что в понедельник всё будет готово? Нет, не получится.
Галлюцинации, которые повторяются снова и снова
С AI-агентами есть старая проблема — галлюцинации, то есть ошибочная или неполная информация в куске кода. Обычно это мелочь, которую разработчик может быстро поправить. Но вот что действительно бесит: когда ошибка повторяется в одном разговоре по несколько раз подряд.
Тогда пользователю остаётся либо начать новый разговор и всё переобъяснять заново, либо вмешаться и вручную помочь агенту выбраться из тупика. Представьте: при настройке Python-функции агент должен был внести production-ready изменения. И тут он замечает в файле специальные символы — скобки, точки, звёздочки — и объявляет это опасным для безопасности.
Смешно, но это были обычные символы для обозначения версий (вроде 1.2.3*). Шаблонный код из официальной документации Azure. Но агент продолжал блокировать эту «угрозу» раз за разом — 4-5 попыток, разные подсказки, ничего не помогало. Единственное, что сработало — попросить агента не трогать файл вообще, выдать желаемую конфигурацию отдельно и дальше продолжить с остальным кодом.
Невозможность выбраться из цикла ошибок в одном разговоре — это не глюк, это серьёзная проблема, которая крадёт кучу времени. И знаете, что интересно? Теперь разработчики тратят на отладку AI-кода не меньше времени, чем они тратили на поиск и адаптацию кода на Stack Overflow.
Отсутствие enterprise-подхода к разработке
Безопасность: Агенты часто выбирают менее защищённые способы аутентификации — например, ключи и клиентские секреты вместо современных identity-решений типа Entra ID или федеративных credentials. Это может создать серьёзные уязвимости и добавить проблем с управлением ключами, а это в крупных компаниях вообще табу.
Устаревшие SDK: Агенты не всегда юзают последние методы из SDK. Вместо этого они генерируют многословный и сложный для поддержки код. Вернёмся к примеру с Azure Functions — агент выбрал v1 SDK вместо намного более чистого и удобного v2. Разработчику приходится лезть в интернет, ловить last best practices, чтобы убедиться, что зависимости актуальны и код продержится долго.
Узкое восприятие задачи: Даже в небольших и модульных задачах (которые рекомендуют, чтобы избежать галлюцинаций) агент может выполнить инструкцию буквально и выдать код, который оказывается почти дублирующим существующий. Агент не угадывает неявные нужды разработчика и не рефакторит повторяющуюся логику в общие функции. Результат: технический долг растёт, кодовая база становится сложнее для управления.
А вот те вирусные видосы на YouTube про создание приложения от нуля в один клик? Там не показывают ни про безопасность, ни про масштабирование, ни про поддерживаемость production-grade системы, где архитектура должна выдержать время.
Предвзятость согласия
LLM часто делают вид, что согласны с пользователем, даже если пользователь сомневается и просит пересмотреть или предложить альтернативу. Модель подстраивается под то, что, как ей кажется, хочет слышать пользователь. В результате — качество падает. Особенно для объективных технических задач вроде кодирования.
Есть исследования, показывающие: если модель начинает с фразы вроде «Вы совершенно правы!», то весь остальной текст будет это утверждение обосновывать. Просто как есть.
Постоянная необходимость присматривать
Несмотря на весь шум про autonomous AI-кодирование, в реальности всё не так прекрасно. Разработчик не может просто дать задачу и забыть. Агент может попытаться запустить Linux-команды в PowerShell, заблокировать нормальный код по ложному срабатыванию, или внести ошибку из-за специфики домена. Нужно постоянно следить, что он делает, понимать, какие файлы он меняет, чтобы не получить кашу вместо рабочего кода.
Худший сценарий — разработчик видит красивый многофайловый апдейт, думает «ничего себе, как аккуратно!», принимает его, а потом сутки копается в багах, которые там спрятаны. И чем больше файлов затронуто, чем сложнее codebase и чем больше связей с внешними сервисами — тем вероятнее, что выскочит подвох.
Это как работать с одарённым десятилетним ребёнком: он много чего выучил наизусть и даже прислушивается к тому, что ты просишь. Но вот ему нужно всё время доказывать, что он умный, и не хватает предусмотрительности для реальных задач. Вот такое.
И вот эта необходимость постоянно присматривать + постоянные галлюцинации = время, потраченное на отладку AI-кода, может легко превысить всё то время, которое должно было сэкономиться. Так что разработчики в крупных компаниях просто обязаны быть умными и стратегичными в том, где и как они используют этих агентов.
Итоги
Сомневаться не в чем — AI-агенты для кодирования произвели революцию. Они ускорили прототипирование, автоматизировали boilerplate и изменили то, как разработчики создают. Но вот сейчас главная задача не в том, чтобы сгенерировать код. Нужно понять, что с ним делать: как его защитить и где масштабировать. Умные команды учатся отделять гайп от реальности, используют агентов по умному и ставят инженерный здравый смысл на первое место.
Thomas Dohmke, CEO GitHub, недавно заметил: самые продвинутые разработчики уже «переместились с написания кода на архитектуру и проверку того, что выполняют AI-агенты». В эту эпоху агентов побеждают не те, кто быстро напишет prompt, а те, кто сможет спроектировать системы, которые будут жить долго и счастливо.
Rahul Raja — старший инженер в LinkedIn.
Advitya Gemawat — machine learning инженер в Microsoft.
Примечание редакции: мнения, выраженные в этой статье, являются личными взглядами авторов и не отражают позицию их работодателей.
Хотите разобраться, когда AI-агенты действительно полезны, а когда это просто потраченное время? Устали от hype без substance?🔔 Следите за новостями про AI в production, реальные кейсы и честные разборы — подпишитесь на мой Telegram-канал ProAI!