Выбор языка для агентов

Два десятилетия неявная функция стоимости при выборе языка сводилась к минутам человеческого времени на одну возможность, и здесь доминировали Python и TS. К 2026 году роль человека сместилась с написания кода к проектированию архитектуры и ревью того, что написали агенты, поэтому форма функции стоимости изменилась. Главным слагаемым теперь стала производительность агента - потраченные токены, число повторных попыток, корректность с первой или второй попытки, - и она расставляет языки совсем не так, как скорость работы человека. Эмпирические аргументы приведены в if-ai-writes-your-code-why-use-python.

Что изменилось

На производительность агента в конкретном языке влияют три базовых фактора:

Задержка компиляции и проверки. Короткий цикл обратной связи позволяет модели исправляться по сообщениям об ошибках. Дотошный компилятор с временем отклика меньше секунды работает как постоянный сигнал подкрепления.
Информативность системы типов. Ошибки, точно указывающие на место бага, куда полезнее сообщений вроде "TypeError on line 42". И структурная, и номинативная типизация сужают пространство поиска, когда модель выбирает между вариантами исправления.
Объём обучающего корпуса. Модель должна видеть достаточно кода на этом языке, чтобы писать идиоматично. Ниже определённого порога фактор обучающей выборки перевешивает всё остальное.

Rust получает высокие оценки по всем трём пунктам. Go хорош по пунктам (1) и (3), но средний по пункту (2). C++ силён по (3), но цикл компиляции и проверки слишком долгий, а сообщения об ошибках слишком зашумлены. Python и JS сильны по (3), но проигрывают по (1) и (2) - агенту приходится запускать программу (или тестовый набор), чтобы понять, ошибся ли он, вместо того чтобы за миллисекунды получить ответ от средства проверки типов. Zig, Haskell и Gleam сильны по (1) и (2), но слабы по (3); они застряли не на той стороне кривой обучающих данных.

Языки, которые людям давались тяжелее всего, агентам даются проще всего, причём по тем же самым причинам: педантичные компиляторы, быстрые итерации, строгие типы. За эти свойства человеку приходилось расплачиваться временем на освоение, а агенту - вычислительными ресурсами. А вычисления подешевели.

Что это значит для новых проектов

Традиционный совет "берите Python или TS для нового проекта" держался на трёх тезисах, и все они ослабли в 2025-2026 годах:

"Экосистема уже решает 90% задачи." Верно, но экосистема всё чаще представляет собой тонкую обёртку на Python/TS поверх внутренностей на Rust. pydantic-core, polars, orjson, tokenizers, ruff, uv, ty, Rolldown - под капотом у них Rust. Когда агенты могут писать низкоуровневый слой напрямую, обёртка становится лишней накладной нагрузкой. См. port-not-patch-contribution.
"Нанимать проще." Верно, но наём команды для написания кода перестаёт быть основной статьёй расходов, когда задача команды - архитектура и ревью. Роль архитектора и проверяющего требует людей из другого пула, нежели наём тех, кто "быстро пилит функциональность на Python".
"Вы быстрее поставляете продукт." Точнее, раньше продукт поставлялся быстрее потому, что главным узким местом был человек. Когда рутинную построчную работу берут на себя агенты, преимущество более быстрого языка по стоимости исполнения в runtime накапливается с каждым днём работы сервиса в production, тогда как эргономические преимущества с каждым кварталом значат всё меньше.

Оставшиеся контраргументы реальны, и их стоит перечислить: serverless-развёртывания, где бинарники на Rust создают сложности; исследования в области ML, где притяжение PyTorch непреодолимо; продукты с очень маленькой площадью API, где TS/WASM всё ещё выигрывает у нативного Rust (канонический пример - откат Prisma к прежнему движку запросов).

Чего из этого НЕ следует

Этот тезис легко истолковать превратно. Стоит избегать нескольких упрощений:

"Значит, все должны начинать на Rust." Речь идёт об изменении функции стоимости, а не о том, что Rust прямо сейчас подходит абсолютно для любого проекта. Сам Mitchem подчёркивает, что для ряда задач старый ответ по-прежнему остаётся верным.
"Значит, агенты заменили инженерное суждение." Работа по архитектуре и ревью по-прежнему требует чтения кода, понимания архитектуры и поиска инженерных компромиссов - см. skill-atrophy-supervision-paradox о текущих спорах вокруг того, не атрофирует ли использование агентов навыки, от которых зависит эта роль.
"Значит, Python умирает." PyTorch всё ещё безраздельно правит в ML-исследованиях и наверняка сохранит позиции надолго. Python остаётся оптимальным выбором для широкого класса внутренних инструментов, разового анализа и связующего кода. Аргумент касается выбора по умолчанию для новых долгоживущих сервисов, а не полного отказа от Python.

Как это соотносится с противоположными взглядами

Самые сильные контраргументы собраны на других страницах wiki:

no-silver-bullet-llms - аргумент Bennett о том, что граница между сущностной и случайной сложностью ограничивает рост продуктивности независимо от того, насколько хороши агенты. Полномасштабные портирования больших артефактов, на которые ссылается Mitchem, - это как раз те типы задач, где Brooks и предсказывал наибольшую отдачу от LLM; они могут не обобщаться на всё остальное.
simonw-zig-anti-ai - осознанный отказ создателей Zig принимать вклад от LLM, который перекрывает ровно тот механизм, что мог бы сократить отставание Zig в объёме кодовой базы.
ai-great-leap-forward - что происходит с рядовой компанией, когда выбор агентов по умолчанию превращается в приказ руководства. Примеры, приводимые Mitchem, созданы высококлассными инженерами (Hejlsberg, Carlini, Klabnik, Kling); корпоративная же версия сводится к нарисованным метрикам.
peril-of-laziness-lost - Cantrill о том, почему LLM лишены человеческой добродетели лени; бесконтрольная генерация порождает раздутый код. Позиция в пользу языков для агентов неявно делает ставку на то, что обратная связь компилятора заменит инстинкт лени, что пока не доказано.

Открытые вопросы

Сохранится ли эффект "короткий цикл компиляции = преимущество агента", когда агенты начнут выдавать код в таких объёмах, что узким местом станет набор тестов, а не компилятор.
Догонит ли зрелость экосистемы: библиотеки Rust хороши для системных задач, но менее развиты для высокоуровневых областей (веб-фреймворки, анализ данных), где по-прежнему доминирует Python.
Упадёт ли стоимость портирования между языками (как порт MiniJinja у Ronacher за $60) настолько, что "выбор языка" станет параметром настройки во время выполнения, а не долгосрочным архитектурным обязательством.
Является ли асимметрия обучающих данных (много для Rust/Go, мало для Zig/Haskell) устойчивой или временной. Подходы с синтетическими данными могут сократить разрыв, а отказ корпораций от менее популярных языков - увеличить его.

Проще всего проверить этот тезис на скучном практическом вопросе: какая доля новых greenfield-сервисов в небольших и средних компаниях через два года будет писаться на Rust или Go, а не на Python или TS? Mitchem делает ставку на то, что цифра превысит 50%. Лагерь скептиков ставит на то, что узкое место в лице супервайзера и проблемы с качеством кода удержат это число на низком уровне.