Жозе Валим: как языки программирования должны измениться в эпоху ИИ-агентов

24 сентября 2026 года Жозе Валим опубликовал на сайте Dashbit эссе «Evolving programming languages in the AI era», сборник размышлений о том, как языки программирования могут меняться по мере того, как всё больше кода пишут ИИ-агенты. Сам автор называет текст черновым «дайджестом мыслей», допуская, что его взгляды ещё изменятся.

В первой части, «Reflections», Валим ставит вопросы без готовых ответов. Что происходит с сообществами вокруг языков (упор Python на «очевидный способ», удовольствие программиста в Ruby, культура изменения самого языка в Lisp-сообществах), если люди перестают писать основную часть кода? Экосистемы библиотек и фреймворков могут пострадать сразу в двух направлениях: агенты способны быстро закрыть разрыв между маленькими и большими экосистемами, перенося идеи и портируя реализации между языками, но одновременно снижают стимул объединяться в общий проект, раз получить нужную библиотеку «под себя» стало дёшево, незачем присоединяться к чужому решению. Отдельно он рассуждает об эргономике: удобные для человека синтаксические конструкции вроде optional chaining почти не важны для агентов, которым, по его выражению, что HTML, что Elixir, что Rust, всё одно «токены на входе, токены на выходе»; поэтому языки, которые заявляют, что созданы «для агентов», но сосредоточены на синтаксисе, на деле подстраиваются под сегодняшние ограничения моделей. На вопрос, заменят ли агенты компиляторы и не начнут ли сразу писать ассемблер, Валим отвечает, что не верит в такой сценарий: даже машинно-сгенерированный код нуждается в архитектурно-независимом промежуточном представлении, а разные классы задач (системное программирование, доказательство теорем, конкурентные и отказоустойчивые системы вроде Erlang/Elixir, запросы к данным, описание аппаратуры) требуют разных языков с разной семантикой и гарантиями, единого языка «снизу», который заменил бы их все, не существует.

Во второй части, «Agentic tooling», он переходит к конкретным предложениям и подчёркивает, что предлагаемые инструменты полезны, даже если агенты пишут всего 20% кода. Первое направление, усиливать гарантии программ вместо того, чтобы облегчать жизнь человеку. Например, вывод типов компилятором удобен людям, которым лень писать сигнатуры явно, но агентам многословность не мешает; при этом языки, где типы можно полностью вывести, обычно составляют лишь подмножество языков, где типы можно строго проверить, то есть погоня за выводом типов ограничивает и выразительность, и гарантии системы типов. Валим перечисляет способы усилить гарантии программ: «корректность по построению» (язык не даёт выразить недопустимое состояние), статические гарантии (типы, доказательства, статический анализ), гарантии рантайма (управление памятью, изоляция, границы возможностей) и эмпирическая проверка (тесты, property-based тестирование, фаззинг), и заявляет, что сейчас как никогда удачное время усиливать эти гарантии. Второе направление, заменить Language Server Protocol «программными базами данных» с языком запросов (SQLite, Datalog или собственный DSL): LSP спроектирован под интерфейс IDE и позиции в файлах (строка, столбец), которые агенты точно не отслеживают, а на своём опыте разработки инструмента Tidewave Валим убедился, что агентам удобнее задавать вопросы вроде «где определён BarBaz», чем работать с точными ссылками на позицию в коде; писать запрос ради поиска всех вызовов функции неразумно требовать от человека, но агент сделает это без труда, причём сможет составлять запросы, непрактичные для отдельных функций IDE, например, найти все публичные функции, которые в конечном счёте вызывают данную. Третье направление, заменить отладчики с точками останова на runtime observability: агенты могут инструментировать код и собирать трассировки исполнения быстрее человека, а раз им предстоит брать на себя больше ответственности за мониторинг и диагностику систем в продакшене, системы должны предоставлять состояние во время выполнения в виде, доступном для программного запроса. Здесь Валим отмечает, что Elixir, по его словам, всегда был силён именно в этой области рантайм-наблюдаемости, на этом моменте доступный фрагмент текста обрывается.

Ключевые факты

• Валим не верит, что ИИ-агенты заменят компиляторы и начнут писать сразу ассемблер: разным классам задач нужны разные языки с разной семантикой и гарантиями.
• Даже если агенты пишут лишь 20% кода, предложенные им инструменты уже приносят пользу.
• Он предлагает отказаться от оптимизации под вывод типов в пользу более строгой проверки типов, поскольку многословность не мешает агентам.
• Вместо Language Server Protocol предлагает «программные базы данных» с языком запросов (SQLite, Datalog или свой DSL), на опыте разработки инструмента Tidewave.
• Вместо отладчиков с точками останова, runtime observability: агенты должны получать доступ к состоянию системы во время работы, в чём, по его словам, Elixir традиционно силён.

Почему это важно

Эссе поднимает вопрос, который обычно обсуждают абстрактно: если ИИ-агенты берут на себя написание существенной части кода, то и сообщества вокруг языков, и экосистемы библиотек, и синтаксическая эргономика, и сами инструменты разработки (типы, LSP, отладчики) теряют часть привычного смысла и нуждаются в переосмыслении.

Кому это важно

Разработчикам самих языков программирования и фреймворков, авторам IDE, LSP-серверов и отладчиков, а также техлидам и командам, которые уже активно используют ИИ-агентов для написания кода и выбирают инструментарий под эту практику.

Как это применить

Валим намечает три конкретных направления для инструментов: усиливать гарантии программ (строгая проверка типов вместо вывода типов, статические и рантайм-гарантии, тесты и фаззинг) вместо оптимизации под удобство человека; заменять LSP «программными базами данных» с языком запросов, которые агент может гибко составлять сам; и выстраивать runtime observability, доступ к состоянию системы во время исполнения, вместо традиционных отладчиков с точками останова.

Можно ли доверять

Материал, авторская колонка Жозе Валима на блоге Dashbit, а не новость о конкретном продукте; сам автор называет текст сборником размышлений и допускает, что его мнение изменится. Доступный фрагмент текста обрывается на разделе про runtime observability, поэтому в статье могут быть дополнительные разделы и выводы, которые в этот пересказ не вошли.

Риски и подводные камни

Рассуждения носят умозрительный характер и не подкреплены данными о том, насколько предложенные подходы (программные базы данных вместо LSP, отказ от вывода типов) реально приживутся в языках и инструментах разработки; выводы автора о заменяемости LSP и отладчиков, это личный прогноз, а не установленный факт.

«Сейчас как никогда подходящее время, чтобы дать более строгие гарантии для нашего программного обеспечения.»

— Жозе Валим