Як інструменти ШІ для написання коду сприяють популярності 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 року, тепер мають перевагу, що не має нічого спільного з якістю дизайну.

Для окремої компанії ризик є вужчим. Бізнес, чий продукт, інструменти й кадровий pipeline обертаються навколо одного сімейства мов, тричі зробив одну й ту саму ставку. Це зручно, поки сімейство мов зберігає своє домінування, але дорого коштуватиме, якщо воно його втратить.

Перший прогноз справдився наполовину. ШІ справді усунув значну частину витрат на написання коду мовою, якої ніхто в команді не розумів. Витрати на розуміння та відповідальність за код нікуди не зникли, і для більшості команд саме вони є основними витратами, що визначають технологічний стек.