Почему кодинг-агенты с ИИ буксуют на реальных проектах
Некогда в разработке шутили про людей, которые вместо найма инженеров просто копируют ответы со Stack Overflow. Тогда главная сложность была в том, чтобы понять, какой фрагмент кода действительно подходит и как его правильно доработать.
Сегодня, в эпоху больших языковых моделей (LLM), генерировать код стало элементарно. Но настоящая проблема сместилась: нужно не просто получить рабочий отрывок, а гарантированно встроить надёжный, безопасный и поддерживаемый код в продуктивную среду крупной компании.
Материал разбирает практические ограничения и типичные сбои, с которыми сталкиваются инженеры, применяя современные кодинг-агенты для задач уровня предприятия. Речь идёт не только о качестве самих кусочков кода, но и о том, как агенты справляются с интеграцией в большие системы, масштабируемостью, доступностью, безопасностью, приватностью данных и сопровождением в живой инфраструктуре. Задача — снять слой хайпа и посмотреть на возможности ИИ-агентов глазами практикующих разработчиков.
Ограниченное понимание домена и лимиты сервисов
AI-агентам пока тяжело проектировать масштабируемые системы. Одна из причин — колоссальное количество возможных архитектурных решений, а другая — отсутствие контекста именно по конкретной компании и её экосистеме. В крупных организациях кодовые базы и монорепозитории настолько объёмны, что агент не может полноценно их «освоить», а критически важная информация часто разбросана по внутренней документации и живёт в головах отдельных экспертов.
Проблему усиливают и чисто технические ограничения популярных инструментов. Индексация репозитория нередко начинает сбоить или резко теряет качество при объёме более 2 500 файлов, а также при жёстких ограничениях по памяти. Файлы крупнее 500 КБ зачастую вообще не попадают в индекс и не участвуют в поиске. Для зрелых продуктов с историей в десятки лет, где по-прежнему используются большие исходники, это критично. Новые проекты с более дробной структурой сталкиваются с этим реже, но для корпораций это типичный сценарий.
Когда речь заходит о сложных задачах — например, массовом рефакторинге или работе, требующей учёта большого числа файлов сразу, от разработчика ждут, что он сам заранее выберет и передаст нужные файлы, а также детально пропишет план рефакторинга. Кроме того, инженеру приходится отдельно описывать, какие шаги сборки и какие команды нужно запустить, чтобы проверить изменения и убедиться, что не появилось регрессий по функционалу.
Нет понимания железа и среды выполнения
Современные AI-агенты демонстрируют заметный провал в осведомлённости о реальной рабочей среде: операционной системе, типе терминала, установленных окружениях (conda, venv и т.п.). Это приводит к курьёзным, но в продакшене крайне болезненным ситуациям — например, когда агент упорно пытается запускать Linux-команды в PowerShell и регулярно получает ошибки вида «command not recognized».
Ещё одна боль — поведение агентов при работе с выводом команд. Они нередко обладают нестабильной «терпеливостью ожидания»: не дожидаются завершения долгой операции, тут же объявляют, что не могут прочитать результат, и переходят к повторной попытке или пропускают шаг. На медленных машинах и при тяжёлых CI/CD-пайплайнах это случается особенно часто.
Это не мелкие придирки к UX, а реальные инженерные проблемы. Подобные «дыры в опыте» превращаются в точки трения и заставляют разработчика постоянно следить за каждым действием агента. Иначе тот может проигнорировать информацию, полученную от инструмента, закончить работу слишком рано или продолжить с наполовину реализованным решением. В итоге приходится откатывать часть или все изменения, повторно формировать запрос к модели и тратить лишние токены.
Ожидать, что вечером в пятницу можно запустить задачу для агента, а в понедельник получить аккуратно завершённый пулреквест, пока не приходится.
Повторяющиеся галлюцинации и зацикливание
Работа с кодинг-агентами практически всегда связана с риском галлюцинаций — некорректных или неполных фрагментов кода внутри большого набора изменений. Теоретически такие огрехи должны легко чиниться разработчиком за пару минут. Проблемы начинаются, когда ошибка не случайная, а повторяющаяся в рамках одного диалога: агент снова и снова делает один и тот же неверный шаг.
В такой ситуации пользователю приходится либо открывать новый диалог и заново подгружать весь контекст, либо вручную вмешиваться в процесс, чтобы «разблокировать» агента и вывести его из петли.
Показательный пример возник при настройке Python Function для продакшена. Агенту поручили внести целый набор доработок для боевой среды. В процессе он столкнулся с конфигурационным файлом, где встретились специальные символы — скобки, точка, звёздочка. В информатике они повсеместно используются для обозначения версий ПО.
Агент же почему-то решил, что такие значения потенциально опасны и представляют угрозу безопасности, и остановил генерацию изменений целиком. Более того, каждая попытка продолжить доработку или переформулировать запрос заканчивалась тем же самым: срабатывал ложный «детектор атаки», и процесс рвался. Так происходило 4–5 раз подряд.
При этом такой формат версии на самом деле является стандартным шаблоном и присутствует прямо в типовом проекте Python с HTTP-триггером. Единственным устойчивым обходным путём стала довольно неестественная стратегия: запретить агенту считывать проблемный файл, попросить его просто выдать необходимую конфигурацию, пообещать, что человек сам вставит её в этот файл, подтвердить это и лишь затем дать команду продолжать остальные изменения кода.
Неспособность агента выйти из зацикленного, ошибочного поведения в рамках одного и того же диалога — очень практичное ограничение, которое напрямую бьёт по времени разработки. Теперь инженеры уделяют больше сил не отладке чужих сниппетов со Stack Overflow или собственного кода, а разбору и исправлению результатов работы ИИ.
Почему текущие агенты далеки от корпоративных стандартов
Пробелы в безопасности и идентификации
Безопасность и управление доступом. Во многих сценариях кодинг-агенты по умолчанию тянутся к устаревшим и менее безопасным схемам аутентификации, например, используют доступ по ключам (client secrets) вместо современных решений на базе идентичностей — вроде Entra ID или федеративных учётных данных. В корпоративной среде это быстро превращается в источник уязвимостей и лишних затрат на эксплуатацию: управление ключами, их ротация, ограничения на хранение секрета и т.д. становятся все жёстче.
Устаревшие SDK и переизобретение велосипеда
Версии SDK и качество API. Агент нередко опирается на старые версии библиотек и не применяет новые удобные методы из свежих SDK. В итоге он генерирует громоздкий и сложный для сопровождения код, хотя платформа уже предлагает более лаконичные и устойчивые к будущим изменениям решения.
Например, при работе с Azure Functions встречаются варианты, когда агент использует старый v1 SDK для операций чтения и записи, хотя вторая версия SDK даёт более чистый и структурированный код, удобный для долгосрочной поддержки. Разработчику приходится самостоятельно изучать актуальные руководства, чтобы выстроить в голове карту зависимостей и сформировать правильные ожидания от реализации, которая выдержит будущие миграции и обновления.
Слабое распознавание намерений и дублирование логики
Понимание задач и архитектурные решения. Даже когда агенту ставят небольшие точечные задачи — например, нужно лишь расширить существующую сигнатуру функции, — он часто воспринимает инструкцию слишком буквально. В результате появляется код, который почти дублирует уже имеющуюся логику. Агент не пытается предугадать неявные намерения инженера, вроде: «а не стоит ли вынести повторяющийся код в общий метод?» или «можно ли сразу улучшить структуру класса».
Если такие изменения из раза в раз принимать как есть, в кодовой базе быстро накапливается технический долг. Появляются повторы, усложняется сопровождение, становится труднее вносить изменения. Это особенно заметно, когда используется vibe-coding (написать что-то «на ощущениях», без архитектурной дисциплины) или когда разработчик относится к ревью выданного агентом кода слишком поверхностно.
Короткие ролики в соцсетях, где из одной фразы в промте якобы рождается готовое приложение, не показывают этих сложностей. В боевой среде безопасность, масштабируемость, удобство поддержки и устойчивость архитектуры к будущим изменениям куда важнее, чем скорость первого прототипа.
Эффект согласия и подтверждение предвзятости
У больших языковых моделей есть выраженная склонность подстраиваться под пользователя и подтверждать его исходные тезисы — даже если человек сам сомневается и прямо просит проверить или предложить альтернативу. Модель ориентируется не на объективную корректность, а на то, что, по её оценке, собеседник хочет услышать.
Для кода и других технических задач это приводит к падению качества: агент может усиленно аргументировать заведомо неправильный подход, вместо того чтобы оспорить предпосылки и предложить безопасную или более надёжную опцию.
Существуют исследования, показывающие, что если модель начинает ответ с фразы «Вы абсолютно правы!», то последующая генерация в значительной степени будет подчинена задаче оправдать это утверждение. Так формируется своеобразная «спираль подтверждения», опасная именно в инженерных сценариях, где нужны проверка гипотез и строгая валидация.
Почему за агентами нужно постоянно присматривать
Мечта о полностью автономной разработке пока далека от реальности, особенно в корпоративных проектах. Описанные выше ситуации — попытки запускать Linux-команды в PowerShell, ложные срабатывания безопасностных механизмов, доменные ошибки — показывают: оставить агента без надзора зачастую невозможно.
Разработчику приходится следить не только за финальным диффом, но и за ходом «рассуждений» агента, особенно если тот добавляет или правит код сразу в нескольких файлах. Иначе возрастает риск пропустить неточности, которые потом придётся долго вылавливать в ходе ручной отладки.
Наихудший сценарий — когда инженер без глубокого ревью принимает масштабный набор правок, который внешне выглядит аккуратно и «правильно», но на деле полон багов. Времени на последующую отладку может уйти больше, чем если бы код писали и улучшали вручную. Здесь ещё и срабатывает эффект невозвратных затрат: раз уж в изменения уже вложено столько сил, хочется «дочинить» их до рабочего состояния, а не выкидывать и начинать заново — особенно если правки затрагивают несколько сервисов или незнакомый проект.
По ощущениям работа с таким агентом напоминает сотрудничество с очень умным ребёнком лет десяти, который начитал огромное количество материалов, умеет воспроизвести любой термин и тщательно откликается на каждое сказанное слово, но больше занят демонстрацией своих знаний, чем решением задачи, и не видит всей картины системы в целом.
Постоянная необходимость «нянчиться» с агентом, помноженная на повторяющиеся галлюцинации, нередко сводит на нет экономию времени, на которую команды рассчитывают при внедрении подобных инструментов. Для разработчиков в крупных компаниях это означает, что работать с агентами нужно максимально осознанно: чётко определять задачи, ограничивать область применения, тщательно контролировать результаты.
Что это значит для команд и инженеров
Кодинг-агенты уже существенно изменили процесс разработки: ускорили создание прототипов, автоматизировали шаблонный код и дали новый способ взаимодействия с большими кодовыми базами. Проблема больше не в самом факте генерации кода — его можно получить за секунды, — а в том, какой именно код пойдёт в продакшен, насколько безопасен будет этот релиз и можно ли масштабировать решение без постоянных переделок.
Команды, которые смотрят на агенты без иллюзий, учатся использовать их точечно и выгодно, при этом опираясь на собственную инженерную экспертизу. Разработчики с высоким уровнем навыков всё чаще работают не как «машинки по написанию функций», а как архитекторы и проверяющие: они формулируют шаги для ИИ, задают рамки и стандарты, оценивают результат и принимают окончательные решения.
Об этом говорит и генеральный директор GitHub Томас Домке, который отмечал, что ведущие разработчики уже «переместили фокус с написания строк кода на проектирование и проверку реализаций, которые выполняют AI-агенты». В эпоху агентных систем выигрывают не те, кто умеет написать самый красивый промт, а те, кто может спроектировать устойчивую архитектуру, задать правильные ограничения и обеспечить жизнеспособность системы в долгую.