«Мови програмування більше не потрібні, коли є LLM» — згодні?

СЕО компаній стверджують: мови програмування відходять у минуле. Генеративний ШІ програмує за вас — вам залишається лише архітектурувати. Таке кажуть не лише розробники і провайдери ШІ-сервісів, або виробники чіпів для ШІ, а й керманичі сервісних компаній, що продають бізнесу інженерну експертизу.

Далі — мої цілком особисті й суб’єктивні міркування з цього приводу. У коментарях чекаю на ваші.

«Мови програмування тепер не потрібні взагалі»

Починаємо з найрадикальнішого трактування. Серед айтівців навряд хтось сприймає це серйозно, але розберемось.

По-перше, генеративний ШІ навряд буде безпосередньо видавати машинний код. Це потребує величезної кількості токенів і надширокого вікна контексту — надзвичайно дорого і технічно сумнівно для будь-чого складнішого за «Hello World». По-друге — в наступних пунктах.

«Вайб-кодинг — це як перехід від асемблера до мов високого рівня»

Аргумент популярний: мало хто зараз пише на асемблері, всі давно перейшли на високорівневі мови, і LLM — просто черговий шар абстракції. Звучить логічно. Але якщо трохи знатись на програмуванні та AI/ML — є спокуса заперечити.

Ось у чому принципова різниця: компіляція асемблеру або мови високого рівня — процес детермінований. Компілятор видасть рівно те, що написав програміст. Так, можуть бути баги в самому компіляторі, і навіть космічне випромінювання іноді «перевертає» біт у чіпі — але це edge cases. А знайдену вразливість патч фіксить так само детерміновано.

З генеративним ШІ все кардинально інакше — і так задумано by design.

LLM — це не компілятор і не інтерпретатор. Це статистична модель, яка працює з ймовірнісним розподілом над простором токенів. Спрощено: модель навчається передбачати наступний токен на основі мільярдів прикладів із мережі (подібно до того, як Т9 передбачає наступне слово повідомлення). На виході — не «правильна відповідь», а найімовірніша послідовність символів у заданому контексті. Параметр temperature контролює «ентропію» цього вибору: при temperature=0 модель майже детерміновано обирає найімовірніший (що не завжди означає бажаний) токен, при вищих значеннях — вносить більше різноманіття (читай: хаосу). Але навіть при «точних» налаштуваннях LLM все ж не є детермінованою машиною — вектори уваги (attention), ваги трансформера і семплінг токенів за своєю природою вносять варіативність у результат.

Чим більший проєкт, чим більше потрібно утримувати в контексті, підтримувати певну архітектуру і стиль — тим складніше передбачити фінальний результат. Це не недолік, це суть генеративних моделей.

Додамо ще один неприємний нюанс: дослідники з Оксфорду, Кембриджу та інших університетів у статті в Nature (2024) описали явище model collapse — деградацію моделей, навчених на даних, згенерованих попередніми моделями. Інтернет дедалі більше заповнюється ШІ-згенерованим контентом, на якому навчаються наступні покоління моделей. Помилки і шаблонні патерни посилюються з кожною ітерацією. «Хвіст» оригінального розподілу даних поступово зникає — і модель стає дедалі менш різноманітною й надійною. Якість результатів моделей є похідною від якості даних. Можна ретельно готувати лише «найкращі» дані, але це потребує колосальної роботи (часу, грошей, енергії) і значно звужує застосування. Але з тим як швидко змінюються ІТ технології це не вихід, бо тоді модель не знатиме актуальних підходів і бібілотек (спробуй встигай її довчати, якісні і ще й актуальні дані ставатимуть все ціннішими, дорожчими).

І ще трохи про економіку. Усі великі ШІ-провайдери зараз працюють у збиток. Вони свідомо «підсаджують на голку»: дешево, доступно, зручно — поки не сформується залежність. Але рано чи пізно потрібно виходити на прибутковість. Це має два наслідки: жорстка оптимізація моделей (що може суттєво погіршити якість виводу) і зростання цін на підписки та токени (та/або урізання токенів у наявних пакетах). Тобто код стає дедалі більш хаотичним — і водночас дедалі менш «безкоштовним».

Припускаю, що на нас чекає чимало цікавого стосовно локального запуску моделей — що може частково вирішити цю проблему для індивідуального (а може, й не тільки) використання. Але це вже окрема розмова.

«Ви архітектуруєте, а написання коду делегуєте LLM — як джуну»

Ось тут справді цікаво. Нейромережі від самого початку розроблялись як імітація роботи нейронів мозку. І якщо сприймати LLM не як заміну мовам програмування, а як ще одного співробітника — з розладами аутистичного спектру, амбівалентною поведінкою і рядом інших «фіч» у комплекті, але все ж — це цілком реальна і корисна модель взаємодії.

Але чи замінює це навички програмування? На мою думку — ні.

Недостатньо дати джуну інструкції і прийняти результат. Його ще треба вміти проаналізувати. Переконатись, що код скомпілювався і запустився — це мінімум (і навіть це може бути проблемою: згенерований код нерідко потребує відлагодження і рефактору щоб запустився). Він ще має відповідати вимогам безпеки, підтримуваності, архітектурного стилю проєкту. Джун може щось прогледіти, відійти від інструкції — або, навпаки, зробити «як сказали» там, де варто було зупинитись і перепитати.

Щоб коригувати код джуна — треба знати мову, на якій він пише. Бажано краще, ніж джун. Тоді делегування справді підвищує ефективність в рази (цих «джунів» може бути й кілька). Якщо ж власних знань бракує — робота з таким джуном може забрати більше часу і нервів, ніж зробити все самотужки.

LLM вміє не лише писати код, а й відлагоджувати його, шукати вразливості і пропонувати виправлення. Те, що починалося з простих лінтерів, поступово виросло до розширень для IDE, що пропонують готові фікси і дедалі частіше — цілком влучно. Але є підступний нюанс: ставши «в режим виправлення», LLM нерідко починає «лагодити» і цілком робочий код поруч — бо не розрізняє баг і архітектурне рішення, яке йому просто незнайоме. Чи зможе це помітити вчасно інженер, який не знає мову в достатній мірі? Чи зможе проконтролювати diff, зробити якісний code review? Питання риторичне.

Ще більш яскравий приклад — але з абсолютно іншої вагової категорії — модель Claude Mythos: в межах програми Project Glasswing за сім тижнів вона знайшла понад 2 000 раніше невідомих вразливостей у критичній інфраструктурі. Для порівняння — це близько 30% від усього річного світового обсягу до появи ШІ. Модель доступна лише вузькому колу партнерів — AWS, Apple, Google, Microsoft, Cisco, CrowdStrike — і це правильне рішення (чи не так?). Тож, як саме інженери нею користуються і які навички для цього потрібні — широкому загалу невідомо. Але маю припущення, що ці інженери дуже добре знаються на програмуванні — значно вище середнього рівня.

Як би там не було, навіть найкраща модель для пошуку вразливостей не позбавлена загальних проблем генеративного ШІ. Галюцинації, варіативність результату, необхідність людської верифікації — Schneier on Security звертає увагу: навіть при 89% збігу оцінок серйозності вразливостей картина залишається неповною. ШІ, що добре знаходить реальні баги, водночас може генерувати правдоподібні, але хибні спрацювання. А відповідальність за помилку — все одно на людині.

«Цінні тепер не знання мов, а розуміння Design Patterns»

Тут також є над чим замислитись. Уявімо ситуацію: команда з C#-досвідом потрапляє на проєкт з TypeScript. Фреймворк написали інженери без розуміння архітектури — без суворої типізації (бо TypeScript — лише обгортка над JS: IDE розмальовує все червоним, але вони ігнорують, все одно ж запуститься), без чистого коду, без розділення на шари. Підтримувати це — той ще квест. Нова команда не знає мову, але знає патерни. Стара — навпаки.

Досвідчені C#-інженери цілком можуть принести свої підходи на TypeScript-проєкт і дати хороший результат. LLM допомагає подолати мовний бар’єр. Можна подумати, що спрацювало саме знання патернів, а не мова.

Але є нюанс. C# і TypeScript — різні, але не кардинально. Перехід з C# на Python був би значно болючішим. Ба більше, бібліотеки відрізняються, IDE-досвід відрізняється, сама екосистема відрізняється. А моделі, навчені переважно на node.js-коді (де якість в публічних репозиторіях традиційно нижча, ніж у суворо типізованому C#), видають відповідний результат.

Згенерований код треба контролювати. Не можна приймати «як є». І коли ти погано орієнтуєшся в новій мові — ти працюєш далеко не на 100% своєї ефективності, навіть із найкращим промптингом. Результат може бути задовільним. Але ті самі інженери зі своїм рідним стеком покажуть значно кращий результат.

«На перше місце виходять soft skills. Кожен програміст — тепер менеджер»

Якщо LLM — це не новий рівень абстракції над мовами, а специфічний джун-помічник, то фокус на soft skills справді має сенс. Але тут виринають менш очевидні проблеми.

Є дослідження (Penn State, 2025), яке показало: грубіший тон у промпті підвищує точність відповідей ChatGPT 4o на 4% — з 80.8% при «дуже ввічливому» тоні до 84.8% при «дуже грубому». Водночас крос-лінгвальне дослідження (2024) показало протилежне для не-англомовних контекстів: там грубість погіршує результат. Правда, як завжди, залежить від контексту. Але факт залишається: моделі чутливі до тону — і це не технічний артефакт, а відображення патернів людського спілкування в тренувальних даних.

І ось де стає некомфортно: грубість дійсно допомагає і отримати кращий код, і «спустити пару» — бо цей «кіберджун» справді інколи дратує. А потім помічаєш, що починаєш грубіше спілкуватись і з людьми. Це не жарт, а реальна поведінкова трансформація. Провайдери вже реагують — деякі моделі можуть просто припинити відповідати у відповідь на надмірну агресію.

Привіт «зворотнім кентаврам»: LLM починає програмувати людину, яка нею користується.

До того ж «характер» моделі кардинально змінюється з кожним апдейтом. Soft skills потрібні не тільки для ефективної взаємодії з ШІ, а й щоб залишатись людяними у спілкуванні з колегами та близькими після восьми (а то й більше) годин «дипломатії» з моделькою.

А що ж СЕО?

Невже вони брешуть? Чи просто не розуміються на програмуванні?

Згадаємо свіжий кейс: у Terms of Use для Microsoft Copilot (оновлено у жовтні 2025, широко розійшлось у квітні 2026) з’явився дисклеймер великими літерами: «Copilot is for entertainment purposes only». Інструмент, за який компанії платять до $30 на місяць за одного користувача, офіційно «лише для розваг». Android Authority порівняв це з дисклеймером екстрасенсів. Microsoft пояснила, що це «legacy language» — але факт залишається: юридично компанія знімає з себе відповідальність за якість продукту, який агресивно продає корпоративним клієнтам.

Тож чи брешуть СЕО? Не зовсім.

1. СЕО і не повинні озвучувати технічно ідеальні тези, але бізнесово влучні. Порівняння LLM з переходом від машинного коду до мов високого рівня — красиве, але технічно некоректне. Втім, для ролі СЕО це і не обов’язково. Більше того, це порівняння цілком валідне, якщо мова про вплив нової технології на практики програмування. Як не крути, концептуально — це такий самий зсув парадигми розробки ПЗ (і не тільки).

2. СЕО кажуть те, що вигідно їхньому бізнесу. Коли очільник компанії, що надає доступ до моделей, каже «мови не потрібні» — він продає свій продукт. Коли те саме каже CEO виробника чіпів (основний покупець яких — якраз ШІ-провайдери) — він продає залізо. Обидва кажуть правду у вигідній для себе інтерпретації. Аутсорс і аутстаф заробляють, коли максимум інженерів перебуває на проєктах. Ринок змінюється, стеки стають то популярними, то ні. Якщо вдається переконати клієнтів, що важливі лише «розуміння патернів і вміння промптити» — bench скорочується, прибуток зростає. Здавалося б, клієнт отримує не найкращий результат, зате «достатній і передбачуваний». Що ж, часто-густо саме це і потрібно бізнесу — тут і зараз, не ідеально, але прогнозовано.

PS: Про стартапи і «демо-код»

Зараз часто «злітають» застосунки, де код нагенерували не програмісти. Це лише доводить, що LLM може дати гарний результат для демо. Раніше замальовували на аркуші в клітинку, тепер отримують цілком робочий прототип. Це прискорює старт в рази — і це реальна цінність.

Але коли стартап іде в продакшн — цей код доводиться рефакторити професіоналам. Іноді простіше написати з нуля. Гарний прототип, з якого все одно перепишуть буквально все — це таки краще, ніж його повна відсутність. Але не варто плутати прототип із production-ready рішенням.

Висновок простий: ігнорувати генеративний ШІ не можна — це вже не опція. Але й ковтати маркетингові заяви без критичного осмислення теж не варто. І стверджувати що «вивчати мови програмування — безглузда затія» поки зарано.

LLM має допомагати, а не думати замість вас. СЕО має вести компанію до успіху і продавати — а не занурюватись у технічні нюанси. І всі ми маємо навчатись жити в цьому дивному новому світі — бажано не втративши людяність у процесі, і не випавши з нього, не встигаючи за змінами.

Ваші думки — в коментарях.