Ключові висновки

Код перестає бути головним дефіцитом. Раніше вартість продукту значною мірою складалася з годин на набір і супровід рядків. Тепер перший варіант модуля часто з’являється за десятки хвилин. Рідкісними лишаються точна постановка задачі, контекст, якість і людина, яка підпише реліз.

«Написати код» і «створити робочу систему» — різна робота. Модель генерує кінцеву точку API, клас, компонент, SQL-запит. Інженер вирішує, навіщо це потрібно, де рішення зламається під навантаженням, що станеться під час збою і як це супроводжувати за кілька років.

Сильні стають сильнішими, вхід у професію — складнішим. Фахівець, який уміє оцінювати й спрямовувати результат, із ШІ робить роботу невеликої команди. Саме прості задачі, на яких раніше вчився junior, автоматизуються першими.

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

За 5–10 років межа ролей розмиється. Розробник, архітектор і технічний лідер дедалі частіше — одна людина, яка задає мету й обмеження, а агенти пишуть код, ганяють перевірки й забирають рутину. Платять не за обсяг дифа, а за те, що саме треба побудувати і чому.

Що змінилось у роботі програміста у 2023–2026

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

Потім за короткий час у повсякдення увійшли автодоповнення рівня GitHub Copilot, чат із ChatGPT і Claude, агентні режими в Cursor і сусідніх середовищах. Модель не лише пропонує наступний рядок: вона править кілька файлів, піднімає чернеток сервісу, пише тести за зразком, пояснює чужий модуль. 2023–2026 стали переломними не тому, що «нейромережі з’явились», а тому що генерація коду увійшла в щоденний конвеєр мільйонів розробників, а не лишилась демонстрацією на конференції.

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

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

Яку частку роботи вже бере ШІ

Хибне питання — «чи може ШІ написати код?». Може. Робоче питання інше: яку частку робіт зі створення програмного продукту тепер реально доручити моделі, якщо поруч є людина, яка вміє перевіряти.

На типових задачах частка вже висока. Генерація функцій і класів за описом. Каркас CRUD-сервісу: моделі, маршрути, форми, базові перевірки. Клієнт до зовнішнього API за документацією. SQL-запити й чернетки міграцій. Модульні тести за вже написаним кодом. Механічний рефакторинг імен і винесення повторів. Документація модуля. Пошук очевидних помилок за трасуванням. Чернеток інтерфейсу. Dockerfile, шаблон конвеєра CI, пояснення незнайомого фрагмента, підготовка повідомлення коміту, прототип цілого застосунку за вечір.

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

Чого в цьому списку немає: рішення, який сервіс узагалі має існувати; вибір меж модулів на роки вперед; розуміння, чому в легасі «дивне» правило не можна чіпати до закриття місяця; оцінка, чи безпечний згенерований патч; відповідальність, коли оптимізований SQL формально швидший, але порушує бізнес-обмеження.

Чотири короткі сюжети, які я бачу знову і знову.

Перший: модель за години збирає CRUD-застосунок, який відкривається в браузері. Демо виглядає як продукт. За місяць з’ясовується, що немає стратегії міграцій, секрети в репозиторії, а «тимчасовий» прапорець уже керує розрахунком.

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

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

Четвертий: прототип за кілька годин. Це справжня перемога — якщо команда пам’ятає, що прототип треба або викинути, або свідомо перетворити на систему.

Коли код стає дешевим

Раніше вартість програмного продукту значною мірою визначалась вартістю людської праці: написати, налагодити, супроводити. Що більше рядків і інтеграцій, то дорожча команда. Дефіцитним ресурсом був сам набір коду.

Зараз перший варіант задачі, яка займала кілька днів, часто з’являється за десятки хвилин. Людина перевіряє, виправляє, вбудовує в систему. Цикл «набрав → побачив → поправив» стискається. Код як сировина дешевшає приблизно так само, як колись подешевшав набір тексту після текстового процесора: писати легше, думати не легше.

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

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

Чому доброго інженера поки що не замінити

Різниця між «написати код» і «створити робочу систему» не в пафосі слова «інженерія». Вона в горизонті наслідків.

Модель може згенерувати кінцеву точку API, клас, компонент, SQL-запит. Це виконання відомого шаблону. Система з’являється, коли хтось відповів на інші питання. Навіщо це потрібно в продукті, а не в демо. Наскільки рішення коректне не в модульному тесті, а в життєвому циклі документа. Які в нього обмеження: навантаження, регуляторика, команда з чотирьох людей, легасі на п’ятнадцять років. Як поведеться на піку. Що станеться при збої сусіднього сервісу. Наскільки безпечно: секрети, права, ін’єкції, витік даних через підказку моделі. Як це підтримувати за три роки, коли автори агентного патча вже не в команді.

ШІ не «дурний» на цих питаннях — він не несе відповідальності і не сидів на нараді, де вирішили не чіпати таблицю до закриття періоду. Навіть сильна модель добудовує прогалини із загальних шаблонів відкритих репозиторіїв. У корпоративному контурі шаблон часто бреше: «правильне» рішення в стилі REST ламає договір із банком або звіт для регулятора. Розбір успадкованої системи це показує жорстко: ШІ і проєкт із 15-річною історією.

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

Нова ієрархія: від кодера до інженера продукту

Старі ярлики junior / middle / senior не зникають із ринку праці, але гірше описують, за що платять. Зручніше дивитись на чотири рівні цінності — не як на HR-грейди, а як на те, що лишається дефіцитним, коли код дешевшає.

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

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

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

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

Ієрархія навмисно груба. У житті людина стрибає між рівнями протягом дня. Сенс моделі — чесно відповісти собі: якщо завтра набір типового коду подешевшає ще вдвічі, що від моєї роботи лишиться дефіцитним?

Парадокс ШІ: сильні підсилюються, junior — у зоні ризику

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

Звідси формула, важливіша за будь-які порівняльні тести «+55% до продуктивності»:

Добрий інженер + ШІ ≫ добрий інженер без ШІ.

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

Найнапруженіший бік парадоксу — junior.

Стара драбина була простою: junior → middle → senior. Новачок отримував прості задачі — CRUD, правки за макетом, тести за зразком — і на них учився читати чужий код, помилятися дешево, нарощувати смак до якості. Саме цей шар задач автоматизується першим.

Виникає питання, якого індустрія ще не закрила: як отримати досвід, якщо ШІ вже виконує роботу, на якій раніше вчилися?

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

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

Чого вчитися у 2026 році

Список «React, Python, Java, Go, SQL» не став непотрібним. Він став недостатнім. Мова і фреймворк як і раніше потрібні, щоб читати диф і розуміти середовище виконання. Але конкурентна перевага від’їжджає у фундамент: алгоритми і структури даних, бази, мережі, операційні системи, паралелізм, розподілені системи, архітектура, безпека, тестування, налагодження, профілювання, Git, поведінка програми під час виконання.

Чому фундамент важливіший, ніж здається адепту «головне — промпти»? Бо модель генерує правдоподібний код. Щоб зрозуміти, чому він поганий, треба бачити систему: зайві запити в циклі, гонитву, витік з’єднання, хибний рівень ізоляції транзакції, діру в правах, тест, який перевіряє реалізацію, а не намір.

Шість практичних правил, які я вважаю робочими у 2026.

Вчити фундамент, а не ставати оператором чату. Без розуміння середовища виконання ви не відрізните прискорення від тихого псування архітектури.

Використовувати ШІ з першого дня. Змагатися з моделлю у швидкості шаблонного коду — програшна стратегія. Змагатися в постановці й перевірці — ні.

Учитися читати код. У найближчі роки вміння оцінювати чужий (і згенерований) код часто цінніше за вміння швидко його набирати. Рев’ю — основний робочий жест, не факультатив.

Учитися проєктувати. Межі сервісів, контракти API, модель даних, відмова сусіднього вузла, оборотність рішення. Спека до коду, а не «спочатку згенеруємо, потім подивимось»: розробка від специфікації.

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

Учитися працювати з агентами як із конвеєром, а не як із магічним вікном чату: мета, обмеження, перевірка, відкат. Це вже не «навичка промпту», а навичка процесу.

Промпти — навичка, а не професія

Популярна ідея 2023–2024 років: «тепер головна навичка програміста — писати промпти». У ній є частка правди і небезпечне перебільшення.

Частка правди: від формулювання завдання залежить, отримаєте ви корисний чернеток чи три сторінки впевненої галюцинації. Уміння звузити задачу, дати приклади, вказати обмеження, додати фрагмент коду — це грамотність, як уміння писати зрозумілий тікет.

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

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

Від написання коду до керування агентами

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

flowchart LR
  H[Інженер] --> A[Архітектура]
  H --> B[Серверна частина]
  H --> C[Клієнтська частина]
  H --> D[Перевірка якості]
  H --> E[Інфраструктура]

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

Роль інженера тоді схожа на роль режисера, а не єдиного актора. Він не зобов’язаний вимовити кожну репліку. Він зобов’язаний зрозуміти, чи ту п’єсу ставлять і чи не впаде декорація на глядача. Один сильний фахівець із набором агентів уже сьогодні закриває контур, на який учора йшла маленька команда — на прототипі, внутрішньому інструменті, добре обмеженому модулі. На критичному ядрі з регуляторикою картина скромніша, і це нормально: відповідальність не масштабується так само дешево, як генерація.

Три сценарії ринку: хто під ризиком

Чи стане програмістів менше? Одночасно правдоподібні три процеси.

Оптимістичний. ШІ знижує вартість розробки → з’являється більше програмного забезпечення → попит на інженерів лишається високим, хоча характер роботи змінюється.

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

Новий ринок. Дешеве ПЗ робить вигідними продукти, які раніше не окупали команду. Внутрішні інструменти, вузькі галузеві системи, персональні агенти під процес — шар, якого не існувало при дорогому коді.

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

Під найбільшим ризиком фахівці, чия щоденна цінність складається з типового CRUD, простих інтеграцій, верстки за готовим макетом, шаблонного серверного коду, механічного рефакторингу, очевидних тестів і чітко описаних тікетів без невизначеності. Головний критерій ризику: наскільки роботу можна розкласти на алгоритм і наскільки легко перевірити результат автоматично. Що ближче задача до «є специфікація і зелені тести = готово», то сильніший тиск автоматизації.

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

Історичні аналогії тут доречні саме як аналогії, не як гарантія. Калькулятор не знищив математиків — зсунув роботу з арифметики на постановку. Системи автоматизованого проєктування не знищили інженерів-конструкторів. Графічні редактори не знищили дизайнерів. Компілятори не знищили програмістів, хоча «писати в машинних кодах» перестало бути масовою цінністю. Пошук в інтернеті не знищив дослідження — знищив цінність «я пам’ятаю, на якій сторінці мануала це написано». Автопілот не прибрав пілотів із кабіни, де ціна помилки максимальна. Автоматизація операцій змінює рівень, на якому працює фахівець. Вона не зобов’язана знищувати професію — але знищує шар, який складався лише з цих операцій.

Прогноз на 5–10 років

З високою ймовірністю ШІ стане таким самим стандартним інструментом розробки, яким колись став Git або безперервна інтеграція. Ручного набору типового коду стане менше. Невеликі команди робитимуть помітно більше. Частка згенерованого коду в репозиторіях зросте — разом із вимогами до архітектури, рев’ю й спостережуваності, інакше потік патчів утопить продукт. Вхід на початковий рівень ускладниться. Інженери високого рівня стануть продуктивнішими. Межа між розробником, архітектором і технічним лідером розмиється: ці ролі й так перетинались, агенти лише підсилюють перетин.

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

Головний парадокс майбутнього формулюється коротко:

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

Як ця лабораторія дивиться на системи — у короткому поданні «Хімія коду». Тут достатньо однієї думки методу: прискорювач (агент) не скасовує вартість помилки; він робить дешевим складання і дорогим хибний інваріант.

Часті питання

Чи замінить ШІ програмістів?

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

Якщо ШІ пише код, чи треба ще вчитися програмувати?

Так. Без уміння писати і особливо читати код не можна перевірити модель. Змінюється акцент: менше зубріння синтаксису заради синтаксису, більше фундаменту, налагодження і системного мислення. «Оператор чату» без бази швидко впирається в правдоподібні помилки.

Що важливіше у 2026: новий фреймворк чи вміння працювати з агентами?

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

Як junior отримати досвід, якщо прості задачі забирає ШІ?

Робити ті самі задачі з перевіркою, а не замість мислення: спочатку власна спроба або розбір, потім порівняння з генерацією, потім пояснення, чому один варіант гірший. Брати домен, налагодження, читання легасі, тести на намір, а не лише «зроби CRUD». Використовувати модель як наставника, який ставить питання, а не як виконавця, якому здають мозок.

Чи достатньо опанувати інженерію промптів?

Ні. Це грамотність, як уміння писати зрозуміле технічне завдання. Без декомпозиції, предметної царини, тестів і архітектурних обмежень промпт дає чернеток, а не продукт.

Кому на ринку буде найважче?

Тим, чия цінність зводиться до алгоритмізованого виконання з легко перевірюваним результатом: шаблонний CRUD, верстка за макетом, очевидні тести, тікети без невизначеності. Легше тим, хто працює з невизначеністю, легасі, безпекою, продуктивністю і зв’язкою «бізнес → система».

Чи стане програмістів менше числом?

В одних компаніях — так: той самий продукт меншим штатом. В інших — ні: з’явиться більше софту, який раніше не окупався. Одночасно зросте попит на інженерів, які вміють тримати агентний контур. Середня «голова на ринку» може стиснутися, хвіст сильних — ні.

Що робити вже цього тижня?

Обрати одну робочу задачу і пройти її як інженер, а не як набірник: зафіксувати намір і обмеження до генерації, прочитати диф як рев’юер, написати або перевірити тест на намір, явно вирішити, що лишити людині. Повторити це як звичку, а не як експеримент.

Подальше читання

• Де закінчується генерація коду і починається інженерія — межа продукту і рядків
• Наскільки далеко просунувся ШІ — зрілість генерації не дорівнює зрілості професії
• Рев’ю коду в епоху ШІ — що перевірити після патча агента
• Як IDE працюють із кодом — конвеєр асистента в редакторі
• Агентна інженерія — процес навколо агентів, не «вайб»
• ШІ і проєкт із 15-річною історією — де модель допомагає розуміти систему
• Розробка від специфікації — намір до коду

Висновок

Професія програміста не вмирає. Вмирає уявлення про програміста як про людину, яка цінна передусім кількістю написаного нею коду.

Майбутній сильний розробник тримає розуміння — продукту і системи — і лише потім запускає агентів на виконання.

                 РОЗУМІННЯ
                     │
          ┌──────────┴──────────┐
          │                     │
       ПРОДУКТ              СИСТЕМА
          │                     │
          └──────────┬──────────┘
                     │
                ІНЖЕНЕР
                     │
                  ШІ × ШІ × ШІ

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