Как инструменты ИИ для написания кода способствуют популярности JavaScript

В августе 2025 года TypeScript стал самым используемым языком на GitHub. Это был крупнейший сдвиг в рейтинге языков GitHub за последние десять лет, произошедший в период наиболее ускоренного внедрения ИИ-агентов для программирования.

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

Анализ изменений

В октябрьском отчёте GitHub Octoverse за 2025 год учитывалось число контрибьюторов TypeScript. Их 2,64 миллиона ежемесячных контрибьюторов означают рост на 66% по сравнению с предыдущим годом. В течение 2025 года более миллиона разработчиков впервые написали код на TypeScript на GitHub.

Этот рост дополняет и без того доминирующее положение языка. В 2025 году Stack Overflow провёл опрос разработчиков, собравший более 49 000 ответов. Из них 66% респондентов сообщили, что используют JavaScript. Почти каждый год с 2011 года JavaScript занимал лидирующую позицию. Таким образом, семейство JavaScript является одновременно самым используемым и самым быстрорастущим на GitHub.

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

Модели лучше всего пишут на коде, который видели чаще всего

Принцип работы довольно прост. Модели обучаются на опубликованном коде, а большая часть публикуемого кода написана на JavaScript и TypeScript. Более того, значительная его часть сосредоточена вокруг React.

Это создаёт существенную разницу в результатах, которые разработчики получают от своих агентов, уже через день после смены стека. Если попросить агента для программирования сгенерировать типизированный компонент React, результат обычно скомпилируется, будет соответствовать стандартам кодовой базы и потребует минимальных правок. Напротив, если попросить того же агента сгенерировать код для Svelte, Solid или менее популярного серверного фреймворка, результат, как правило, будет гораздо менее проработанным. Кроме того, в нём будет больше выдуманных API, а каркас потребует дополнительных исправлений, прежде чем его можно будет запустить.

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

Ничто из этого не указывает на технический вердикт. Solid и Svelte — хорошие фреймворки, а несколько более современных фреймворков превосходят React по чистой скорости. Рынок вознаградил выбор, который модели уже умели поддерживать.

Модели создаются на Python, но продукты выпускаются на JavaScript

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

Однако очень малая часть того, с чем взаимодействует клиент, написана на Python. Фактически фронтенд ИИ-продукта представляет собой по сути окно, в котором потоково отображаются токены. Он также требует кнопок для запуска инструментов, этапа подтверждения для любых действий, способных привести к негативному результату, и объяснения того, что система сделала и почему. Всё это реализуется на JavaScript и TypeScript — независимо от того, получена ли модель от OpenAI, Anthropic или является моделью с открытыми весами, размещённой компанией на собственном оборудовании.

К концу 2025 года GitHub сообщал о более чем 1,1 миллиона публичных репозиториев, использующих SDK для работы с LLM, что на 178% больше, чем годом ранее. Этот рост был обусловлен прежде всего разработкой приложений, а не разработкой моделей. Каждый корпоративный пилотный проект, который проходит дальше демонстрационной стадии, требует от кого-то создать пользовательский компонент, а стандартными инструментами отрасли для такой работы являются фреймворки JavaScript.

Системы типов стали защитным барьером для сгенерированного кода

По мнению GitHub, этот сдвиг означает, что разработчики переходят к типизированным языкам, поскольку системы типов делают разработку с участием агентов безопаснее. У сгенерированного кода есть особый тип ошибок. Он хорошо читается и имеет понятную структуру. В динамических языках он даже может работать без видимых проблем, а затем завершиться сбоем из-за несоответствия форматов через три вызова. Средства проверки типов выявят значительную часть таких проблем ещё до запуска кода.

На практике эта теория подтвердилась. В 2026 году доля профессиональных разработчиков, использующих TypeScript, достигла 78%, увеличившись с 69% двумя годами ранее. Примерно 40% разработчиков пишут исключительно на TypeScript, и лишь 6% разработчиков пишут исключительно на обычном JavaScript.

Типы ошибок, которые обнаруживает компилятор, как правило, относятся к тем ошибкам, которые человек может не заметить, столкнувшись с 400 строками вполне разумного кода.

●        Функция вызывается с объектом, в котором отсутствует одно из обязательных полей.

●        Код содержит предположение о существовании значения, в результате чего передаётся значение null или undefined.

●        Формат ответа API изменился, а сгенерированный обработчик по-прежнему использует старый формат.

Узкое место сместилось с написания кода на его проверку

В полевом отчёте OpenAI об использовании агентов для программирования в научных вычислениях, опубликованном в июле 2026 года, это ограничение сформулировано наиболее прямо: ограничивающим фактором стала проверка, а не генерация кода. Хотя речь идёт о поставщике, изучающем собственный продукт, и к результатам следует относиться с некоторой осторожностью, они совпадают с тем, что многие инженерные команды, особенно за пределами исследовательской сферы, отмечают уже в течение последнего года.

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

Ожидается, что эффект React будет срабатывать дважды во время разработки, и разработчик, не знающий об этом, может потратить целый день на расследование того, что он считает ошибкой из-за дублирующегося вызова API. Сгенерированный запрос будет выглядеть корректно в среде разработки на тестовых данных, но в рабочей среде может привести к сканированию всей таблицы. Проверку авторизации можно разместить в любом месте компонента и сделать неэффективной; это может создать иллюзию безопасности, которая исчезнет, когда кто-то действительно проверит её.

Здесь есть несоответствие, которое команды склонны упускать из виду. Возможности генерации практически безграничны и увеличиваются с каждым дополнительным агентом или новой подпиской. Напротив, возможности проверки ограничены числом инженеров, достаточно хорошо разбирающихся в системе, чтобы выявить правдоподобную ошибку. Вряд ли это число будет расти такими же темпами. Добавление возможностей генерации кода в команду, уже достигшую предела своих возможностей по проверке, не увеличивает скорость выпуска. Оно лишь перемещает узкое место с написания кода на его проверку. Команда может вдвое увеличить свои возможности по генерации кода за неделю, но это не изменит числа людей, доступных для проверки. Именно поэтому ограничение сместилось и поэтому дополнительные инструменты не решают проблему.

То же самое пока не относится к практике найма. Большинство отборочных испытаний по-прежнему проверяет, способен ли кандидат прийти к работающему решению, — именно с этой частью инструменты уже помогают. Некоторые компании начали оценивать противоположный навык. Они предлагают кандидатам фрагменты сгенерированного ИИ кода, содержащие ошибку, и наблюдают, как долго она остаётся незамеченной.

Кадровые агентства также движутся в этом направлении. Например, Full Scale теперь описывает нанимаемых им инженеров JavaScript через владение ИИ-инструментами и продуктовое мышление, а не через количество написанных строк кода. Компания, которая намерена нанять выделенного разработчика JavaScript, теперь приобретает возможности проверки в той же мере, что и возможности создания. Это кажется незначительным сдвигом — до тех пор, пока сгенерированный ИИ процесс входа в систему не попадает в рабочую среду без участия человека.

Концентрация имеет свою цену

Рынок, который ценит то, что модели уже знают, затрудняет внедрение чего-либо нового. У нового фреймворка, опубликованного в этом году, нет существующего корпуса обучающих данных, из-за чего агентам сложно с ним работать, команды начинают его избегать, и возникает ситуация, в которой корпус данных не формируется. Типичные сроки привлечения финансирования недостаточны для того, чтобы решения, основанные на достоинствах, смогли разорвать этот замкнутый круг. Фреймворки, достигшие своих ключевых этапов до 2023 года, теперь имеют преимущество, никак не связанное с качеством дизайна.

Для отдельной компании риск более узкий. Бизнес, чьи продукт, инструменты и кадровый pipeline целиком построены вокруг одного семейства языков, трижды сделал одну и ту же ставку. Это удобно, пока семейство языков сохраняет доминирующее положение, но дорого обойдётся, если оно пошатнётся.

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