Coding-агенты и редкие языки: почему падает точность

Спросите любого coding-агента, как отсортировать список на Python, и получите рабочий ответ с первой попытки. Попросите тот же агент сгенерировать неблокирующий GenServer на Elixir или разобрать unsafe-блок на Rust с явным управлением временем жизни — и вероятность ошибки, лишнего импорта или несуществующей функции резко вырастает. Разрыв между «популярными» и «редкими» языками — одна из главных практических проблем LLM-агентов для разработки, и он напрямую связан с тем, сколько кода на этом языке модель видела при обучении.

Что происходит с точностью на редких языках

Крупные модели обучаются на публичном коде — прежде всего с GitHub и подобных площадок. Языки распределены крайне неравномерно: Python, JavaScript/TypeScript, Java, C++ и Go занимают львиную долю репозиториев, тогда как Elixir, Clojure, Zig, Nim, OCaml или мейнфреймовый COBOL представлены на порядки скромнее. Меньше данных — хуже покрытие идиом, стандартной библиотеки и свежих версий синтаксиса.

На практике это проявляется тремя способами:

• Галлюцинации API. Модель придумывает функцию или метод, которого нет в стандартной библиотеке языка, потому что «по аналогии» с Python так было бы логично.
• Смешение диалектов и версий. Код на Scala 2 и Scala 3, на старом и новом синтаксисе Swift, на разных редакциях Rust перемешивается в одном ответе.
• Перенос чужих идиом. На функциональном языке агент пишет императивный цикл с мутацией, потому что так устроено большинство виденного им кода.

Публичные бенчмарки это частично отражают. Тесты вроде HumanEval и MBPP исходно построены вокруг Python, а мультиязычные расширения — MultiPL-E, переносящий задачи HumanEval на десятки языков, — показывают, что pass@1 у одной и той же модели падает при переходе от Python к менее представленным языкам. Точные проценты зависят от модели и версии бенчмарка, поэтому конкретные цифры смотрите в публикации MultiPL-E и в карточках моделей, а не полагайтесь на память.

Агент не «понимает» язык — он воспроизводит статистику виденного кода. На редком языке этой статистики мало, и уверенный тон ответа ничего не говорит о его правильности.

Почему агент опаснее чата

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

* Coding-агент — LLM-инструмент, который не просто выдаёт текст, а выполняет цикл «прочитать код — предложить изменение — запустить — проверить результат» с доступом к файловой системе и терминалу.

Спасает здесь не сама модель, а обвязка: наличие компилятора и тестов в цикле. Если агент видит вывод компилятора Rust или падение теста на Elixir, он итеративно исправляется. Без обратной связи он остаётся при своей галлюцинации.

Как ведут себя разные инструменты

Ключевое различие между агентами — не «знание» языка (базовая модель у многих пересекается), а то, насколько плотно инструмент встроен в реальный цикл сборки и тестов. Сравнение ниже описывает подход инструментов, а не точные метрики: возможности и цены меняются, сверяйте на официальных страницах.

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

Что делать разработчику на редком стеке

1. Дайте агенту тесты и компилятор. Настройте так, чтобы он запускал сборку и прогонял тесты после каждого изменения. Это самый эффективный способ отловить выдуманный API.
2. Кладите примеры в контекст. Добавьте в промпт или в правила проекта пару файлов с идиоматичным кодом на вашем языке — модель ориентируется на них лучше, чем на абстрактную инструкцию.
3. Фиксируйте версию языка. Прямо указывайте: Scala 3, Swift 6, edition 2021 для Rust. Иначе агент усредняет по всем виденным версиям.
4. Дробите задачи. На редком языке одна крупная генерация чаще уходит в мусор, чем цепочка мелких проверяемых шагов.
5. Проверяйте импорты и вызовы вручную. Первое, что стоит перечитать в сгенерированном коде на редком языке, — обращения к стандартной библиотеке и внешним пакетам.

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

Пригодится, если вы пишете на Rust, Elixir, Clojure, OCaml, Zig или поддерживаете легаси на COBOL и уже упирались в галлюцинации агента. Понимание природы разрыва экономит время: вы перестаёте ждать от модели того, чего она дать не может, и выстраиваете цикл с тестами.

Пригодится и тем, кто ведёт монорепозиторий на смеси языков: типичный сценарий — бэкенд на Go, инфраструктурные скрипты на Nim или обвязка на Nix, где именно нишевые части агент ломает чаще.

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

Не поможет в закрытых внутренних DSL и полностью проприетарных языках, которых нет в публичных данных вовсе: тут никакая базовая модель не выручит, единственный рабочий путь — насыщать контекст вашими примерами и документацией.

Coding-агенты не «плохо знают» редкие языки — они просто видели их несравнимо меньше. Пока распределение публичного кода не изменится (а оно не изменится быстро), разрыв никуда не денется. Но он управляем: компилятор в цикле, тесты, явные версии и примеры в контексте превращают ненадёжного генератора в рабочий инструмент даже там, где данных мало.