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

Спонсорский контент

Как инструменты для программирования на основе ИИ способствуют популярности 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 — это подсчет активности на их собственном сайте, что создает конфликт интересов, поскольку они могут хотеть выглядеть лучше. Кроме того, модные тенденции влияют на тип информации, которая включается в общедоступные репозитории. Тем не менее, показатели все еще соответствуют данным опроса, что вполне разумно, учитывая масштабы этой конкретной тенденции.

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

Принцип работы довольно прост. Модели обучаются на основе опубликованного кода, а большая часть опубликованного кода написана на 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 года, теперь имеют преимущество, не имеющее ничего общего с качеством проектирования.

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

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

Источник: www.artificialintelligence-news.com