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

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

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

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

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

Вступ: чому ШІ змінив розмову про програмування

До 2022 року суперечка «чи потрібні програмісти» звучала абстрактно: автоматизація, low-code, «достатньо Excel». З появою великих мовних моделей, натренованих на репозиторіях, аргумент став конкретним: модель генерує код за описом природною мовою — іноді краще, ніж середній розробник на вузькому завданні.

Звідси ілюзія повної заміни: якщо ШІ пише функції, навіщо команда? Відповідь не в тому, що «ШІ тупий», а в тому, що програмний продукт — це не сума функцій. Це узгоджена система під конкретні обмеження: бюджет, регуляторика, legacy, команда, термін життя рішення.

Головне питання статті: у який момент перестає вистачати «написати код» і починається інженерія — робота, за яку платять senior-розробникам, архітекторам і технічним лідерам?

У 2026 році це питання перестало бути теоретичним. Команди вже щодня зливають у production diff'и, згенеровані агентами. Частина з них — якісні. Частина ламає інтеграції, які ніхто не перевірив, бо «модель так запропонувала». Різниця між успішним і провальним використанням ШІ — не в моделі, а в тому, чи є поруч інженерний контур: вимоги, review, тести, розуміння домену.

Код ≠ програмний продукт

Що таке генерація коду сьогодні

Під «генерацією» розуміють не лише автодоповнення в IDE. Це:

• чат із ChatGPT, Claude, Gemini за завданням «зроби endpoint + тести»;
• агентні режими (Cursor, Claude Code, Copilot Workspace), що правлять кілька файлів;
• вбудовані асистенти в GitLab, JetBrains, VS Code;
• корпоративні RAG-контури поверх внутрішніх репозиторіїв.

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

Типові успішні сценарії: прототип адмінки за вечір, чернетка OpenAPI-специфікації, рефакторинг іменування по всьому модулі, пояснення незнайомого фрагмента legacy на Java.

Чому робочий код ще не означає робочу систему

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

Код може:

• компілюватися;
• проходити unit-тести;
• навіть пройти code review «на око».

І при цьому система не готова до експлуатації: немає стратегії міграцій БД, не описані SLO, секрети лежать у репозиторії, інтеграція з банком не переживе зміну API, а «тимчасовий» прапорець у конфігурації уже три роки керує розрахунком ПДВ.

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

Аналогія з будівництвом

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

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

Що ШІ справді вміє добре

Генерація шаблонного коду

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

Автоматизація рутинних задач

• Тести — unit і іноді integration за зразком існуючих;
• Рефакторинг — перейменування, винесення методів, приведення до стилю проєкту;
• Документація — README, коментарі до API, опис модулів за кодом;
• SQL — запити, міграції, індекси під типові схеми.

Це не «іграшка», а вимірюваний приріст: команди фіксують двозначні відсотки прискорення на рутині (дані GitHub, JetBrains, галузеві опитування 2025–2026).

Швидке прототипування

MVP за години замість тижнів, демо для замовника, перевірка гіпотези «чи спрацює інтеграція з X» — класична зона перемоги ШІ. Бізнес отримує ранній зворотний зв'язок; інженер отримує чернетку, яку ще треба перетворити на продукт або свідомо відкинути.

Чому це уже революція

Три наслідки:

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

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

Де починаються проблеми

Маленьке завдання проти великої системи

Маленькі завдання (ШІ часто справляється добре):

• форма зворотного зв'язку;
• авторизація через OAuth у greenfield-проєкті;
• звіт по одній таблиці;
• скрипт міграції даних на 10k рядків.

Великі системи (контекст і наслідки):

• ERP з десятками модулів і інтеграцій;
• інтернет-банк з регуляторикою та antifraud;
• MES на виробництві з простоями на мільйони;
• державні сервіси з вимогами доступності та аудиту.

У великій системі локально правильний патч може зламати закриття місяця в іншому департаменті. ШІ без повного контексту не бачить цього зв'язку.

Проблема контексту

Модель не була на нараді, де відмовилися від event sourcing «до наступного року», і не знає, що таблиця payments_old ще читає нічний batch.

Чому ШІ складно з проєктами 10–15 років

• Legacy-код — кілька епох технологій в одному репозиторії;
• тисячі файлів — неможливо тримати цілком в одному запиті без індексації;
• неочевидні залежності — тригери, cron, «тимчасові» адаптери;
• застаріла документація — вікі суперечить коду;
• бізнес-логіка в головах — правила, які ніхто не закомітив.

Детальний розбір — у pillar-статті чи може ШІ розібратися в проєкті з 15-річною історією: там експеримент, цифри та межі «експерт + модель».

Справжня інженерія починається не з коду

Формалізація вимог

Замовник каже: «потрібен звіт з продажів». Інженерія починається з питань:

• Чого він хоче формально — Excel раз на тиждень чи дашборд у реальному часі?
• Чого він намагається досягти — контроль менеджерів чи прогноз закупівель?
• Де розходяться формулювання та ціль — і чи не купимо ми дорогу BI-платформу для задачі, яку закриває один SQL.

ШІ може допомогти сформулювати user story або checklist питань. Але відповідальність за узгодження з бізнесом — на людині.

Проєктування системи

• Архітектура — моноліт, сервіси, event-driven; де межі і чому;
• Межі сервісів — що можна змінювати незалежно;
• Вибір технологій — не «модний стек», а fit під команду, SLA і legacy;
• Масштабованість — що зламається при 10× навантаженні.

Див. також як проєктувати систему, яка проживе 10 років — про зв'язаність, еволюцію та ціну незворотних рішень.

Робота з обмеженнями

Інженерія — це оптимізація під обмеження, а не під абстрактний «ідеальний дизайн»:

• бюджет і терміни;
• розмір і досвід команди;
• технічний борг, який не можна ігнорувати;
• безпека — від OWASP до галузевих стандартів.

ШІ запропонує «найкращий патерн з підручника»; інженер обере досяжний патерн під ваші обмеження.

Управління ризиками

• Що зламається через рік при зростанні даних?
• Що станеться при піковому навантаженні в «чорну п'ятницю»?
• Які рішення незворотні (схема БД, публічний API, формат повідомлень у Kafka)?

Найбільш недооцінене завдання — ухвалення рішень

Між правильним і оптимальним

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

ШІ видає варіант A (часто усереднений по інтернету). Інженер обирає між A, B і «нічого не чіпати до релізу», знаючи контекст.

Ціна помилки

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

Відповідальність не можна делегувати ШІ

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

Чому бізнес платить не за код

За що платять на різних рівнях

Коли ШІ прискорює написання рядків, ринок не обнуляє оплату senior'ам — він переносить премію на все, що рядками не вимірюється.

За що платитимуть в епоху ШІ

• Управління складністю — legacy, інтеграції, організаційний масштаб;
• Архітектурне мислення — межі, еволюція, відмовостійкість;
• Робота на стику бізнесу та технологій — переклад домену в систему;
• Вміння вести ШІ-контур — промпти, агенти, перевірка, agentic engineering замість «vibe coding».

Матеріал як топ-команди реально використовують ШІ показує: лідери інвестують у каркас (тести, правила, CI), а не лише в модель.

Кейс: проєкт з 15-річною історією

Це не абстракція. В окремій статті розібраний реалістичний сценарій ERP-класу: мільйони рядків, сотні таблиць, десятки інтеграцій.

Що зробить ШІ:

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

Де потрібен інженер:

• відновити навіщо правило існує, якщо його немає в коді;
• оцінити наслідки зміни перед релізом;
• спроєктувати еволюцію системи, а не лише патч.

Цей кейс добре показує межу: модель може за години побудувати карту модулів, які торкаються статусу замовлення, але не скаже, чому у вересні 2019-го команда свідомо залишила синхронний виклик замість черги — і що станеться з закриттям кварталу, якщо цей виклик прискорити. Такі рішення живуть у ADR, листах і пам'яті людей, а не в diff'і, який агент щойно згенерував.

Підсумок експерименту: ШІ допомагає розуміти систему; не замінює того, хто розуміє бізнес і несе відповідальність. Читати повний розбір →

Як зміниться професія розробника

Чи зникнуть програмісти

Повне зникнення професії малоймовірне з тієї ж причини, через яку не зникли інженери-будівельники з появою prefab і CAD: складність задач і відповідальність зростають швидше, ніж автоматизація їх знімає. Попит зміщується — не обов'язково падає.

Навички, які подешевшають

• чисте запам'ятовування синтаксису;
• шаблонне написання CRUD без контексту;
• ручне копіювання boilerplate.

Навички, які подорожчають

• Системне мислення — ціле важливіше за файл;
• Архітектура і межі — див. чому ERP стають монолітами;
• Аналіз вимог і комунікація із замовником;
• Робота з ШІ — постановка задачі, верифікація, безпека;
• Domain knowledge — те, що ШІ не закриє у frontend і не лише.

Новий тип інженера

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

Практичний наслідок для кар'єри: junior, який вміє лише «просити ChatGPT написати функцію», конкурує з інструментом напряму. Junior, який розуміє, навіщо функція потрібна системі і як перевірити відповідь моделі, стає ціннішим саме через ШІ, а не попри нього. Той самий зсув стосується middle і senior — лише масштаб рішень інший.

Висновок

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

Інженерія дорожчає. Проєктування, аналіз, рішення під обмеження, відповідальність — те, за що компанії платять, коли помилка коштує не «переробити PR», а зупинку бізнесу.

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

FAQ

Далі для читання

• Чи може ШІ розібратися в проєкті з 15-річною історією — експеримент, RAG, межі моделі
• Як проєктувати систему на 10 років — архітектура та незворотні рішення
• Vibe coding vs agentic engineering — каркас навколо ШІ
• Як топ-команди використовують ШІ — практика, не хайп
• Чому ERP стають монолітами — складність, яку код не вичерпує
• Frontend: прогалина знань, яку ШІ не закриє — domain і контекст