Как инструментите с ИИ за програмиране допринасят за популярността на JavaScript

През август 2025 г. TypeScript стана най-използваният език в GitHub. Това беше най-голямата промяна в класацията на езиците в GitHub през последните десет години и се случи в периода на най-ускорено внедряване на AI агенти за програмиране.

Преди се прогнозираше, че AI агентите за програмиране ще намалят значението на избора на език. Предполагаше се, че организациите ще станат независими от технологичния стек и ще избират стекове единствено въз основа на нуждите на бизнес проблема, оставяйки настрана съображенията, свързани с наличния пул от разработчици, които могат да бъдат наети. Вместо това, само две години след широкото възприемане на AI инструментите за програмиране, пазарът изглежда по-ограничен, с бързо стесняване на наличните езици за програмиране и с по-голямата част от фокуса върху едно семейство езици.

Анализ на промяната

Докладът Octoverse на GitHub от октомври 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

Основателно възражение срещу изложеното по-горе е, че разработката на AI се извършва на Python. Обучението на модели, оценяването им и повечето инструменти за изследвания работят на Python и това не се е променило.

Много малка част от това, с което взаимодейства клиентът, обаче е написано на Python. Всъщност предната част на един AI продукт по същество е прозорец, който предава токени. Тя също така изисква бутони за изпълнение на инструменти, стъпка за одобрение на всичко, което би могло да доведе до негативен резултат, както и обяснение какво е направила системата и защо. Всичко това се прави на 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. Генерирана заявка може да изглежда напълно нормално в средата за разработка с примерни данни, но в производствена среда да започне да сканира цяла таблица. Проверка за удостоверяване може да бъде поставена навсякъде в даден компонент и да се окаже неефективна, което създава илюзия за сигурност, но тази илюзия изчезва, когато някой действително я тества.

Съществува несъответствие, което екипите са склонни да пренебрегват. Капацитетът за генериране е почти неограничен и се увеличава с всеки допълнителен агент или нов абонамент. За разлика от него капацитетът за преглед е ограничен от броя инженери, които познават достатъчно добре системата, за да открият правдоподобна грешка. Малко вероятно е този брой да се увеличава със същата скорост. Добавянето на по-голям капацитет за генериране на код към екип, който вече е достигнал лимита на капацитета си за преглед, не увеличава скоростта на доставяне. То просто премества тясното място от писането към преглеждането. Един екип може да удвои капацитета си за генериране на код за седмица, но това няма да промени броя на хората, които могат да извършват преглед. Ето защо ограничението се е изместило и защо допълнителните инструменти не предлагат решение.

Същото не важи за практиките при наемане. Повечето подбори все още оценяват дали кандидатът може да стигне до работещо решение, което е именно частта, в която инструментите вече помагат. Някои компании започнаха да оценяват обратното умение. Те представят на кандидатите блокове AI-генериран код, съдържащи дефект, и наблюдават колко дълго той остава неоткрит.

Компаниите за подбор на персонал също се движат в тази посока. Например Full Scale вече описва JavaScript инженерите, които назначава, като хора с умения за работа с AI инструменти и продуктово мислене, а не според броя написани редове код. Компания, която се стреми да наеме специализиран JavaScript разработчик, вече придобива толкова капацитет за преглед, колкото и капацитет за изграждане. Това изглежда като малка промяна, докато генериран от AI процес за вход не попадне в производствена среда без човешка намеса.

Концентрацията има цена

Пазар, който цени това, което моделите вече познават, затруднява въвеждането на нещо ново. Нов фреймуърк, публикуван тази година, няма съществуващ корпус от тренировъчни данни, което затруднява работата на агентите с него, кара екипите да го избягват и води до ситуация, в която не се създава корпус. Типичното време до получаване на финансиране е недостатъчно, за да могат решенията, основани на заслуги, да прекъснат този цикъл. Фреймуърците, постигнали ключовите си етапи преди 2023 г., вече имат предимство, което няма нищо общо с качеството на дизайна.

Рискът е по-малък за отделна компания. Бизнес, чийто продукт, инструменти и процес по наемане са изградени около едно семейство езици, е направил един и същ залог три пъти. Това е удобно, докато семейството езици запазва доминиращата си позиция, и скъпо, ако тя отслабне.

Първоначалната прогноза беше наполовина вярна. AI действително премахна голяма част от разходите за писане на код на език, който никой в екипа не разбира. Разходите за разбиране и притежание на кода все още съществуват, а за повечето екипи те са основният разход, който определя технологичния стек.