Кодовые агенты и многоязычные проекты: где они спотыкаются

Типичный веб-сервис 2024 года — это не один язык, а слоёный пирог: бэкенд на Python или Go, фронтенд на TypeScript, инфраструктура на YAML и HCL, миграции на SQL, скрипты сборки на Bash. Когда за такую кодовую базу берётся ИИ-агент, задача усложняется не арифметически, а комбинаторно: ему нужно не просто понимать каждый язык, но и держать в голове связи между ними — какой эндпоинт вызывает фронтенд, какая таблица стоит за ORM-моделью, какой переменной окружения не хватает в контейнере. Именно здесь агенты чаще всего ошибаются, и разница между инструментами становится заметной.

Что вообще должен уметь агент в полиглот-репозитории

Разовое автодополнение в одном файле — задача, которую решает почти любой ассистент. Настоящая проверка начинается, когда правка в одном языке тянет за собой изменения в другом. Добавили поле в модель на Python — нужно поправить миграцию SQL, обновить сериализатор, изменить TypeScript-интерфейс на фронте и, возможно, тест на третьем языке.

Для этого агенту нужны три вещи. Первая — достаточно большое контекстное окно*, чтобы удержать связанные файлы одновременно. Вторая — навигация по проекту: умение грепать, читать структуру папок, находить, где определена функция и где она используется. Третья — понимание границ между языками: что вызов из TypeScript уходит по HTTP в Go, а не напрямую.

Агент, который отлично пишет функцию на Python, но не замечает, что она сломала контракт с фронтендом, экономит вам десять минут и добавляет час на отладку.

Где агенты спотыкаются чаще всего

• Границы контракта между сервисами. Изменение формата ответа API на бэкенде агент нередко не проецирует на клиента, который этот ответ разбирает, — особенно если клиент лежит в отдельной папке или отдельном репозитории.
• Сгенерированный код. Protobuf, GraphQL-схемы, ORM-модели порождают файлы на других языках. Агент может править сгенерированный файл вручную вместо исходной схемы — правка исчезнет при следующей генерации.
• Конфиги и инфраструктура. YAML, Dockerfile, переменные окружения — здесь мало языковой логики и много неявных договорённостей, которые нигде не записаны в коде.
• Редкие языки в проекте. Если 95% репозитория на TypeScript, а 5% на Rust, качество правок в Rust-части заметно ниже — как из-за меньшего объёма таких данных в обучении, так и из-за того, что агент реже туда заглядывает.

Как разные инструменты подходят к задаче

Ключевое различие — в том, как агент собирает контекст. Одни полагаются на индекс всего репозитория, другие читают файлы по мере надобности, вызывая инструменты поиска. Второй подход медленнее, но лучше масштабируется на большие проекты, где весь код в окно не помещается.

Оговорка: конкретные возможности и модели под капотом у этих продуктов меняются раз в несколько месяцев, а часть функций доступна только на старших тарифах. Перед выбором проверяйте актуальные характеристики и цены на официальных страницах — приводить их здесь как фиксированную истину бессмысленно.

Что реально помогает агенту

Независимо от инструмента, качество на полиглот-репозитории заметно растёт, если вы даёте агенту опору:

1. Файл с описанием проекта в корне (многие агенты читают такие файлы автоматически) — где какой язык, как запускаются тесты, какие есть контракты между сервисами.
2. Доступ к запуску тестов и линтеров. Агент, который может прогнать проверку после правки, сам ловит часть ошибок, которые иначе ушли бы в ревью.
3. Чёткие границы задачи. "Поменяй поле X в модели и всё, что от него зависит" работает лучше, чем "почини бэкенд".

Кому это пригодится, а кому нет

Пригодится:

• Командам с монорепозиторием, где фронт, бэк и инфраструктура лежат вместе — агент видит связи и может протащить изменение через все слои.
• Разработчику, которому нужно быстро разобраться в чужом сервисе на незнакомом языке: агент объяснит, что делает Go-код, пока вы живёте в TypeScript.
• Рутинным сквозным правкам: переименовать поле, добавить лог, обновить зависимость по всему проекту.

Скорее не пригодится или потребует жёсткого контроля:

• Проектам с большой долей кода на нишевых языках — там качество проседает, и правки нужно вычитывать построчно.
• Изменениям, где контракт между сервисами описан не в коде, а в устных договорённостях команды — агент их не знает и знать не может.
• Задачам с критичной безопасностью, где цена незамеченной ошибки в конфиге или SQL выше, чем экономия времени.

Практический вывод

На многоязычной кодовой базе агент — это ускоритель для человека, который понимает архитектуру, а не замена этого понимания. Самая частая ошибка не в том, что агент неверно напишет функцию, а в том, что он не заметит связь между языками. Поэтому связка "агент правит, тесты и линтер проверяют, человек ревьюит границы" пока даёт результат надёжнее, чем слепое доверие к любому из перечисленных инструментов.

* Контекстное окно — объём текста (кода, инструкций, файлов), который модель способна держать "в поле зрения" за один раз. Чем оно больше, тем больше связанных файлов агент может анализировать одновременно, не теряя начало.