Читацькі дописи
IT Community

Писати код більше не обов’язково означає… писати код. У 2025-му програмісти дедалі частіше замінюють синтаксис на промпти, IDE — на чат-інтерфейси, а функції — на щось, що «генерується автоматично». Це не означає, що програмування зникло. Але те, як ми підходимо до нього точно змінюється.

Про vibe coding уперше заговорив Андрій Карпати у лютому, майже жартома. Іронічна фраза про «лови вайб, забудь про код» швидко підхопилася у твітері, а потім і в командах, де експериментують з GitHub Copilot, ChatGPT, Cursor, Claude та іншими ШІ-асистентами. Згодом виявилось, що ця фраза не лише мем. Вона точно описує те, що вже робить чимало людей: пояснює комп’ютеру, що потрібно, не занурюючись у реалізацію.

 Кодити без написання коду: звучить сумнівно, але працює

Vibe coding — це новий підхід до програмування, де вихідною точкою є не код, а розмова. Вищезгаданий Андрій Карпати вперше вжив фразу vibe coding у відповідь на запитання про те, як девелоперам працювати з LLM.

Вже за кілька тижнів цей вираз почали використовувати IT-спеціалісти, продакт-менеджери та навіть венчурні інвестори, які без вагань включали його у свої пітчдекі.

Як виявилося, суть vibe coding доволі проста і дійсно відзеркалює назву: вам не потрібно писати код построково. Ви просто задаєте «вайб» і описуєте штучному інтелекту те, що ви хочете побачити у фіналі. Це може бути що завгодно — веб-додаток для догвокерів; скрипт, який синхронізує ваші таблиці з Notion; дашборд, що автоматично оновлює метрики KPI або цілий сайт. Ви даєте ШІ намір, промпт, а модель домальовує деталі. І незалежно від того, чи ви сеньйор-інженер, чи ніколи не відкривав VS Code — на вашому екрані зʼявиться справний софт.

Володимир Обрізан, директор Design and Test Lab та автор блогу про vibe coding описує цей підхід так: «Для мене вайб-кодинг — це в першу чергу стан, коли код пишеться не заради замовника, зарплатні або дедлайнів, а заради кайфу. Чомусь коли згадують застосування ШІ у програмуванні, то перше питання «чи багато клопоту підчищати за ШІ»?

Але я б першим пунктом поставив те, що програмування з ШІ повернуло мені те, що ні за які гроші не купиш — це натхнення у програмуванні, яке в мене було, коли я хлопчиком в школі вивчав програмування на ZX Spectrum, або студентом з другом на канікулах писав компʼютерну гру на Delphi. Чи треба було тоді багато років тому виправляти свої ж помилки, або помилки в документації, «підчищати»? Так! Але яка різниця для мене, якщо я роблю це з натхненням».

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

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

Розробники, з якими я говорила, уже встигли випробувати vibe coding на практиці. І хоча підходи різняться, майже кожен знайшов для себе ситуації, де це справді економить сили або хоча б пробуджує інтерес.

Хтось як Василь Мухар, Technical Director в Edvantis, використовує AI для генерації юніт-тестів і зізнається, що це дозволяє більше зосередитись на архітектурі.

Роман Гелембюк, Software Engineer з компанії Nasuni, каже, що Copilot для нього є must-have для повсякденної роботи, а Cursor працює чудово в добре структурованих проєктах.

Володимир Остапів, девелопер з N-iX, тестує vibe coding у pet-проєктах, особливо на Python, і каже, що LLM добре справляються з типовими задачами, поки не доходить до чогось нішевого, як Lua. А Android developer Анатолій Кокулюк розповідає, що використовує ChatGPT для створення Django-моделей, шаблонів, JavaScript-функцій, генерації тестів і навіть формулювання завдань у навчальній платформі.

Дехто з них експериментує обережно, інші ж — повністю занурені в процес. Але всіх об’єднує те, що це вже частина їхніх робочих чи дослідницьких процесів. Тепер природна мова стає інтерфейсом для створення продуктів. Замість того, щоб вчити синтаксис, користувач вчиться чітко формулювати свої потреби. І на виході, замість боротьби з порожнім файлом ми маємо співпрацю з моделлю, яка вже бачила мільйон подібних запитів.

З цього вимальовується інший важливий і, можливо, для когось приємний момент — vibe coding не лише для девелоперів. Дизайнери тепер можуть пропрацювати візуальну розмітку ще до того як відкрили стартову сторінку Figma, а sales-managers можуть попросити ШІ зробити «скелет» додатку, що аналізуватиме потенційний ріст продажів у різних регіонах залежно від віку, фінансових можливостей або уподобань.

Звісно, це не магія поза Хогвартсом. Код може згенеруватись кривим, логіка запитів може бути неідеальною, а результати роботи ШІ не завжди такі, які очікує людина. Однак, перша суттєва перевага тут все ж є — цей підхід стискає час між ідеєю і реалізацією. Він не вбиває розробку як таку, а просто прибирає потребу в рутинних процесах, вивільняючи простір на UX, тестування або запуск продукту.

Vibe coding vs. традиційне програмування: де знаходиться межа між намірами та кодом?

Поки vibe coding провокує нові дискусії та привертає до себе увагу, традиційні підходи до розробки програмного забезпечення все ще залишаються актуальними. Так, vibe-кодування може стати новим витком еволюції у розробці ПЗ, затьмарюючи класичний coding, але давайте згадаємо, що саме відрізняє традиційне програмування і нові підходи.

Традиційне програмування

Дана опція передбачає, що ви пишете все вручну, рядок за рядком, обираючи мову, фреймворк, архітектуру. Тут не обійдеться без суттєвого досвіду за плечами розробника. Та й часові інвестиції зовсім інші. Можуть знадобитися тижні, місяці на навчання і дні, тижні на розвиток. Побудувати можна дійсно що завгодно, але якщо з кодом щось не так, то можна застрягнути надовго, розвʼязуючи помилку. Тут немає готових шаблонів, на які ви можете покластись.

Low-code платформи

Деякі IT-спеціалісти кажуть, що вони з’явилися, щоб спростити життя. Людині достатньо мати базове розуміння концепцій програмування, а далі починається процес розробки, перетягування компонентів, налаштування параметрів. Тут немає перетинання з реальним кодом, а платформа як така все ж обмежує в можливостях. З low-code буде під силу впоратися тим, хто не готовий втрачати себе у технічних джунглях заплутаного та філігранного кодингу.

Vibe coding

Якщо в попередніх підходах йшлося про мінімальні зусилля у написанні коду, то як ми вже знаємо vibe coding не передбачає цього. Ви просто описуєте робочий софт, який хотіли б отримати, не використовуючи конфігурації, синтаксис. Якщо фінальний результат вас не влаштував, замість двобою з написанням коду, просто переформульовуєте промт. При цьому код існує, але користувач з ним напряму не працює. Фактично немає потреби знати, чим == відрізняється від ===. Потрібна лише чіткість формулювання запиту.

AI-інструменти, що підсилюють Vibe Coding

Vibe coding не виник з порожнього простору, за ним звісно ж стоїть чималий стек AI-інструментів, які спершу непомітно, а зараз вже повноцінно стали частиною щоденної рутини розробників, дизайнерів і продуктових команд. Разом вони формують хребет нового способу створення софту.

Великі мовні моделі (LLMs)

У центрі всього — LLM’и. Власне, вони й генерують усе це добро.

• GPT-4 / GPT-4o — досі найпопулярніші для загальних задач програмування. Добре тримають контекст, розбираються в багатокрокових запитах. Доступні через ChatGPT або API.
• Claude 3 (Anthropic) — набирає обертів завдяки м’якому тону та меншій схильності «галюцинувати» при структурованих завданнях.
• Gemini (Google), Command R+ (Cohere), Mistral — часто використовуються в опенсорс-інструментах або нішевих застосунках.

Обирати одну не обов’язково. Багато vibe-кодерів постійно стрибають між різними LLM, залежно від задачі, або ж використовують інструменти, що комбінують їх у бекенді.

Результат дуже залежить від того, яку саме модель ви використовуєте. Наприклад, Claude чудово справляється з Python, але намагається “зшити” C++ проєкти без особливої структури. Як каже Володимир, Java Developer з N-iX, іноді потрібно паралельно тестувати одну й ту саму задачу на кількох LLM, щоб побачити, яка з них “не зламає вам усе”.

Асистенти коду

Це досить зручні напарники в IDE. Вони підказують, генерують фрагменти, реагують на промпти.

Найвідомішим з них є Replit Agent, що діє як розробник програмного забезпечення на базі штучного інтелекту, який може генерувати фронтенд- та бекенд-код, налаштовувати бази даних і навіть автономно виправляти помилки. Його описують як дуже універсального асистента, здатного підтримувати багато мов програмування та фреймворків. До того ж він надає повний доступ до коду, якщо комусь захочеться зануритися у кодування глибше.

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

Ще один популярний асистент коду під назвою Cursor здобув собі славу майже колеги-розробника, який завжди поруч, усе пам’ятає і нормально розуміє твій код. Не просто допоміжний засіб, а повноцінний учасник процесу.

Як вказують розробники на форумах, якщо GitHub Copilot просто підставляє тобі код під час друку, то Cursor дає можливість спілкуватися з кодом. Можна виділити шматок функції й написати: «Додай обробку помилок» або «Чому тут падає запит?». Але здається найбільше Cursor люблять за те, що він зберігає історію запитів — і по файлам, і по задачах. Тобто можна повернутись до старого діалогу без зайвих пояснень. Не треба щоразу все заново формулювати як у звичайному чаті.

Cursor отримав багато схвальних відгуків і за зручність у вже структурованих проєктах.

Але додає, що на інших проєктах Cursor справляється гірше, особливо коли архітектура не впорядкована або стек менш популярний.

Серед ШІ-асистентів для створення вебзастосунків активно згадують і Bolt.new. Достатньо дати йому ТЗ, а далі він одразу генерує код і все відбувається в межах браузеру. Ніяких редакторів чи IDE, натомість відкриваєте вкладку, даєте задачу, отримуєте сайт. Під умовним «капотом» LLM, тож Bolt розуміє, що ви хочете і не просто генерує шаблони, а адаптує все під запит. Як і Replit Agent, він обробляє розгортання одним кліком тачпаду.

Дехто міксує ці інструменти: обирає Cursor для структури, Copilot — для дрібних доробок, ChatGPT — для генерації цілих фіч.

Василь Мухар, Technical Director в Edvantis, ділиться, що Copilot значно пришвидшує написання юніт-тестів, але вимагає ретельної перевірки: «Із мінусів — потрібна більш уважна перевірка коду».

Коли справа доходить до більш складних сценаріїв, на кшталт multi-agent workflow або автоматичного створення пайплайнів, то в гру вступають фреймворки.

Проте досвідчені інженери використовують vibe coding по-своєму.

LangChain, LlamaIndex, AutoGen виступають лідерами для зв’язування декількох викликів LLM в один логічний процес. А ось PromptLayer, Prompt Foo більше зосереджені на DevOps: логують, який промпт породив який результат, дозволяють тестувати й порівнювати різні підходи.

Поки важко говорити про весь арсенал інструментів, адже екосистема vibe coding ще тільки формується, але цікаво, що поки жоден інструмент не домінує і не виділяється настільки, щоб говорити про його лідерство у цій ніші. Всі асистенти рухаються в одному напрямку: формування запиту системі, а система реалізовує цей запит.

Vibe coding на словах і на ділі

Не кожен, хто працює з кодом, бачить у vibe coding готове рішення. Володимир Остапів, Java-розробник в компанії N-iX, розповідає:

Володимир використовує ШІ переважно для побічних проєктів: мікроконтролери, дрони, освітній YouTube. Там можна собі дозволити «повайбити», але навіть там він віддає перевагу промптам в окремому вікні, а не інтегрованим помічникам в IDE. Основна вигода, каже він, — зекономити час на тривіальних, повторюваних задачах, які не потребують глибокого мислення: згенерувати DTO, запит до бази, щось ізольоване.

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

Коли вайбкодинг рятує, а коли шкодить?

Чи можна стверджувати, що Vibe coding — це про швидкість та оптимізацію часу? Безперечно так. Але ця швидкість і простота мають свої обмеження, особливо якщо ви переходите від створення іграшкових апок до справжніх продуктів. AI-асистоване програмування дійсно пришвидшує роботу розробників, але водночас створює більше багів і вимагає додаткового часу на перевірку результату. Це і є основний компроміс: менше писати і більше перевіряти.

Що дійсно працює?

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

Вхід стає значно ширшим. Йдеться про те, що продуктові менеджери, дизайнери, навіть нетехнічні тімліди створюють базові апки самостійно. Їм не треба знати, що таке middleware. Достатньо чітко пояснити, чого ви хочете досягти.

Менше рутини. Для девелоперів це спосіб позбутись нудного: юніт-тести, генерація API — усе, що пожирає час, але не потребує глибокої логіки.

З чим все не так гладко?

Код виглядає правильним, але це лише вигляд. Моделі генерують щось, що наче працює, але це не гарантує безпеки, читабельності чи продуктивності. Це скоріше передбачення патернів, а не розуміння архітектури.

Дебаг — це боляче. Щось пішло не так і ви застрягаєте в лабіринті виправлень. А якщо ви писали код не самі, то знадобиться час та зусилля, щоб зрозуміти, що саме передбачала модель.

Фальшиве відчуття завершеності. Особливо у нетехнічних людей. Якщо скрипт запустився, то на перший погляд здається, що все абсолютно добре. Але відсутній null check чи дірка в авторизації можуть зламати все в проді.

Відсутність масштабування. Володимир, Java-розробник із N-iX, чітко це сформулював: «Якщо треба MVP або щось одноразове — вайб-кодинг економить час. Але якщо далі підтримувати та розвивати, то треба структурувати, писати тести, окреслювати зони відповідальності. Навайбкодити не вийде.»

Як тільки виникне потреба у підтримці, довготривале володіння кодом і впевненість, що він не впаде на краях системи, то скоріше за все виявиться, що одних лише промптів недостатньо і тоді код треба розглядати як систему, а не як набір фрагментів.

Так чи ні: що думає про vibe coding IT-спільнота?

Не всі погоджуються з популярним трактуванням vibe coding, якщо брати до уваги тільки назву цього поняття. Хтось вважає це природною еволюцією програмування. Хтось — модною фішкою з гарною назвою. Але більшість стоїть десь посередині: обережний оптимізм, але з певними умовами.

Андрій Карпати, який і ввів термін у лютому 2025 року, описав його у твіттері з іронією:

«Є новий тип програмування, який я називаю ‘vibe coding’: ти повністю віддаєшся вайбу, приймаєш експоненціальність і забуваєш, що код узагалі існує.»

Для деяких розробників це не така проста історія лише про вайб і тимчасове «забуття».

«Vibe coding — ох, огидний термін, приблизно як StackOverflow-driven development. ШІ-помічники — це інструмент, каталізатор. Може пришвидшити проєкт, а може й поховати його під шаром власної складності за кілька місяців», —  ділиться Android Developer Анатолій Кокулюк.

Але інші бачать у цьому зсуві щось глибше. Наприклад, для Володимира, директора Design and Test Lab, vibe-coding —  це більше про повернення до задоволення і натхнення, а не лайфхак:

«Для мене вайб-кодинг — це в першу чергу стан, коли код пишеться не заради замовника, зарплатні або дедлайнів, а заради кайфу. Чомусь коли згадують застосування ШІ у програмуванні, то перше питання «чи багато клопоту підчищати за ШІ»?

Але я би першим пунктом поставив те, що програмування з ШІ повернуло мені те, що ні за які гроші не купиш — це натхнення у програмуванні, яке в мене було, коли я хлопчиком в школі вивчав програмування на ZX Spectrum, або студентом з другом на канікулах писав компʼютерну гру на Delphi. Чи треба було тоді багато років тому виправляти свої ж помилки, або помилки в документації, «підчищати»? Так!»

Навіть скептики визнають, що ШІ-інструменти мають своє місце. Роман Гелембюк, Software Engineer у Nasuni, каже, що Copilot став частиною його щоденного процесу, але в обмеженому вигляді:

«Я використовую Copilot вже понад півтора року. Зменшує час написання коду десь на 10–15%. Але майже не редагую код, згенерований AI: або зразу добре, або в смітник.»

Він додає, що інструменти типу Cursor добре працюють у структурованих проєктах, але сиплються там, де хаос — особливо в мобільних додатках на Kotlin Multiplatform:

«Результати виглядали логічно, але були неробочими. Структура коду була не такою, як я вважаю правильною.»

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

Інші ж обережно ставиться до ідеї доручати ШІ архітектурні рішення:

«Узагалі не раджу використовувати такі асистенти для проєктування архітектури. Це потребує більше часу на формулювання запитів, а результат усе одно часто не відповідає очікуванням», —  Василь Мухар, Technical Director в Edvantis.

Але й він бачить переваги:

«Ці інструменти відчутно прискорюють роботу. Особливо під час написання unit-тестів. Завдяки економії часу на шаблонному коді з’являється більше можливостей для архітектури.»

Володимир Остапів, Java Developer з N-iX, не використовує ШІ в продакшн-коді — здебільшого з міркувань безпеки — але активно експериментує в побічних проєктах. Він вважає ШІ корисним, якщо зберігати контроль:

«Я делегую ШІ окремі частини, але це все ще я пишу код. Підхід до структурування не змінився.”
“На простому пайтоні все ок, а от Lua — краще писати самому. Чим менше прикладів у публічному просторі, тим гірше модель справляється.»

Він також звертає увагу на типову поведінку LLM:

«ШІ буде оптимізувати те, що займає 10 мілісекунд, щоб воно займало 5, але пропустить той факт, що підключення займає секунду. Він буде додавати логи для дебагу, але не спробує підійти з іншого боку. Тому тут якраз має вирішувати вже людина».

Серед інженерів точиться й дискусія про авторство. Якщо більшість фічі написана Copilot або GPT — то хто її справжній автор?

«Чи можна вважати себе автором сніданку, якщо приготував його з продуктів, до створення яких не маєш стосунку? Якщо відповідаєш за фічу — значить ти автор.”
“Ми — останнє покоління, яке взагалі цей код бачить. Як колись казали: Сі — гарно, але тільки на асемблері пишеться справді ефективний код.»

Втім, це не лише філософія. Щодня розробники приймають практичні рішення: як і чи варто інтегрувати ШІ у свій робочий процес. Хтось використовує ChatGPT у сусідній вкладці, хтось покладається на Copilot для швидкості. Але ясно одне — інженери все ще шукають свій підхід.

А ось в чому сходяться майже всі, так це в тому, що vibe coding — це інструмент. Не магія. Не кінець програмування. І точно не заміна інженерам. Однак це вже змінює щоденний досвід написання коду, якщо використовувати його з головою.

Vibe Coding пройшов стадію denial. Що буде далі?

Vibe coding поки не захопив світ розробки ПЗ настільки, щоб всі компанії почали пропонувати девелоперам використовувати цей метод, а девелопери, своєю чергою, перейшли на його постійне використання. Але й інтерес до vibe coding поки не знижується, а це про щось та й говорить.

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

AI-допоміжні процеси як мінімум змінюють підхід до створення й підтримки софту. Рутинні завдання, які раніше забирали години, наприклад, написання unit-тестів, оновлення HTML-шаблонів або створення CRUD API, тепер виконують Copilot, ChatGPT або Cursor. І для команд, на яких тиснуть дедлайни, це цілком непогана альтернатива.

Деякі розробники ставляться до ШІ як до будь-якого іншого інструменту: корисний, якщо використовувати з розумом, і небезпечний, якщо не розуміти, як працює.
Володимир Остапів, Java-розробник з N-iX, порівнює це з молотком:

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

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

Володимир Обрізан, директор Design and Test Lab, позитивно ставиться до сценарію, в якому компанії застосовуватимуть vibe coding і пояснює, що було б явно гірше, якби нових інструментів та підходів не зʼявлялося.

«Зрозуміло що є певна інерція: хтось не вірить, що ШІ взагалі може зробити більше ніж «привіт, світ!», хтось знайшов якусь помилку в коді ШІ та перекреслює усі переваги від його впровадження. Хтось взагалі не читає новин, не вчиться новому, та пише код як писав його останні 5 років. Як подолати цю інерцію? Навчатись самому, навчати інших. Як і з будь-якою іншою інновацією. Професія змінюється і це добре. Я би більше хвилювався, якби ніяких нових інструментів не зʼявлялося».

Тож, ніхто не відкидає ідею застосування vibe coding як таку. Більшість інженерів просто вибирають моменти, коли це доречно робити. Вони використовують vibe coding там, де це допомагає, і припиняють, коли це не приносить користі. Трюк у тому, щоб правильно розпізнати, коли це працює, а коли ні.

На думку Василя Мухара, технічного директора в Edvantis, все залежить від того, чи розробник розуміє, як працювати з цими інструментами й у здатності компаній навчати ефективній роботі з ШІ-помічниками.

Більшість розробників не планували ставати майстрами промптів. Вони вивчали мови, фреймворки, патерни, будували системи з нуля. Але якщо подивитися на те, що відбувається зараз, то точка входу змінюється. Там, де колись функціонал починався з коду, зараз він частіше починається з речення.

Це не означає, що написання коду зникне зовсім. Але сам процес “написання коду” може трансформуватися і перейти до опису намірів штучному інтелекту, про коригування згенерованого коду, і про управління результатом. Або ні. Ми це побачимо дуже скоро.

В IT-світі працюють ті ж закони та принципи, що і в повсякденному житті — найкращі результати не приходять від людей, які чекають на диво. Вони приходять від тих, хто знає, як контролювати обсяг робіт, аналізувати проблеми й тестувати те, що вони отримали. І, можливо, в цьому і криється справжня зміна. Не те, що ШІ моделі тепер можуть писати код, а vibe coding стає нормальною робочою практикою, а те, що розробники зараз проводять більше часу, визначаючи, що запитати й що перевірити.

Чи буде наступне покоління розробників кураторами «вайбів», а не авторами коду? Це теж поки не ясно. Але, ймовірно, ми дізнаємось відповідь набагато швидше, ніж думаємо. Як сказав один із наших співрозмовників: «Ми — останнє покоління, яке бачить код. Як колись — асемблер. Далі будуть ті, хто просто формулює завдання».