Вхід і реєстрація
Різне · 5 січня, 15:30 7750
Vitalii Oborskyi, PMO&Delivery Head в Developex

Ілюзія економії: чому заміна розробників на AI — це шлях до технічного дефолту

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Ілюзія ефективності

Наприкінці 2024-го та протягом 2025 року в переговорних кімнатах IT-компаній закріпився небезпечний наратив. Логіка здавалася спокусливо простою: якщо AI-інструменти, такі як GitHub Copilot, Cursor або Windsurf, допомагають розробнику писати код на 20–50% швидше, то компанія може скоротити штат інженерів на аналогічний відсоток, зберігаючи той самий рівень продуктивності (output).

Ця «логіка Excel-таблиць» призвела до хвилі передчасних оптимізацій, де керівництво розглядає ліцензії на AI як пряму заміну людському таланту. Очікування просте: купуємо інструменти, звільняємо «найменш ефективні» 5–20% персоналу і спостерігаємо за зростанням маржинальності.

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

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

Ми спостерігаємо перехід від «творчої кризи» (writer’s block) до «творчого потопу» (writer’s flood). Розробники генерують величезні обсяги коду, який виглядає правдоподібно, але часто позбавлений глибини чи контексту. «Рядки коду» (LOC) завжди були метрикою марнославства, але в епоху AI вони стали пасивом. Індустрія фіксує сплеск «плинності коду» (code churn) — коду, який пишуть, пушать, а потім майже відразу видаляють або переписують, бо він не вирішує проблему.

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

Ключовий інсайт та дані:


Зростання Code Churn (плинності коду):
Масштабне дослідження GitClear, яке проаналізувало понад 211 мільйонів рядків коду, виявило тривожну тенденцію, що збігається з масовим впровадженням AI-асистентів (дані 2025 року).

Знахідка: Рівень «Code Churn» (відсоток коду, який оновлюється або видаляється менш ніж через два тижні після написання) стрімко зростає.
Наслідок: Це свідчить про те, що хоча AI допомагає розробникам друкувати швидше, це часто призводить до поведінки «copy-paste» та створення коду нижчої якості, який вимагає негайної переробки. Ми рухаємося швидше, але часто не в тому напрямку.

Джерело: GitClear: AI Assistant Code Quality Research

Теорія змін: чому трансформація спочатку коштує дорожче

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

Впровадження AI-native процесів — це не просто оновлення софту; це фундаментальна перебудова створення цінності. Згідно з класичною теорією управління змінами, зокрема Моделлю змін Сатір (Satir Change Model), будь-яке введення чужорідного елемента (у нашому випадку — AI) у стабільну систему викликає період хаосу. Перш ніж команда досягне «Нового статус-кво» з вищою продуктивністю, вона неминуче має пройти через долину опору та зниження продуктивності.

Цей феномен відомий як «J-крива» трансформації.
Коли керівництво скорочує штат на початку цієї кривої, воно фактично саботує трансформацію ще до її початку. Ресурси вилучаються саме тоді, коли організація перебуває під найбільшим стресом.

Щоб досягти успіху, компанії повинні діяти як те, що Harvard Business Review називає «Амбідекстрою організацією» (Ambidextrous Organization). Це вимагає одночасної роботи у двох суперечливих режимах:

  1. Exploit (Run the Business — Експлуатація): Підтримка легасі-систем, виправлення поточних багів та генерація доходу за допомогою встановлених процесів. Це вимагає наявного штату, щоб «світло не згасло».
  2. Explore (Change the Business — Дослідження): Експерименти з AI-агентами, побудова нових пайплайнів оцінки (evaluation pipelines) та перенавчання персоналу промпт-інжинірингу й архітектурному рев’ю. Це вимагає додаткового часу та ментальної енергії.

Фатальна помилка 2024–2025 років — це припущення, що можна забрати ресурси з першої групи, щоб профінансувати другу. У реальності двигун «Exploit» не може зупинитися, поки будується двигун «Explore».

Протягом 6–18 місяців організація мусить нести витрати на паралельні структури. Вам потрібні ваші сеньйори, щоб підтримувати старий стандарт якості й одночасно вчитися керувати новим хаосом, спричиненим AI. Це період інвестицій, що вимагає більшого бюджету і більшого штату (або принаймні стабільного штату з вищими витратами на навчання), а не меншого.

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

Ключовий концепт та джерело:


Організаційна амбідекстрія (The Ambidextrous Organization):
Дослідження Чарльза О’Райлі III та Майкла Ташмана підкреслює, що успішні компанії відокремлюють свої нові, дослідницькі підрозділи від традиційних експлуатаційних, визнаючи, що вони потребують різних структур, культур та метрик.

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

Джерело: Harvard Business Review: The Ambidextrous Organization
Концепція: The Satir Change Model (The J-Curve)

Приховані витрати паралельних операцій

Якщо «J-крива» з попереднього розділу описує часові рамки трансформації, то цей розділ — про рахунок, який доведеться оплатити в цей період.

Багато організацій розраховують ROI від впровадження AI за небезпечно простою формулою: порівнюють вартість ліцензії Copilot ($19–39 на місяць) із погодинною ставкою розробника. Цей розрахунок ігнорує операційну реальність перехідного етапу.

Під час переходу до AI-native процесів компанії стикаються з «Подвійним оверхедом» (Double Overhead). Ви не замінюєте одні витрати іншими миттєво; ви тимчасово їх нашаровуєте.

  1. Вартість підтримки (The Legacy Cost): Ви змушені продовжувати платити за підтримку існуючих систем. Це вимагає глибоких інституційних знань (domain knowledge) та традиційних інженерних навичок.
  2. Вартість трансформації (The Transformation Cost): Одночасно ви платите за побудову «Нового шляху». Це не лише ліцензії на софт, а й інфраструктура для RAG (Retrieval-Augmented Generation), векторні бази даних і, що найважливіше, «Податок на навчання» (Training Tax).

«Податок на навчання» — це час і гроші, необхідні для перекваліфікації вашої команди. Ефективне використання AI вимагає фундаментального зсуву навичок: від «написання синтаксису» до «промпт-інжинірингу», «кураторства контексту» та «верифікації результатів». Це не вроджені таланти; цьому треба вчити.

Крім того, мислення в стилі «cost-cutting» часто штовхає менеджмент до звільнення Middle-розробників заради «сплощення» структури. Це провокує «Відтік мізків» (Brain Drain) і втрату критичних знань про продукт.

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

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

Ключовий інсайт та дані:


Чому цифрові трансформації провалюються:
Дослідження McKinsey Digital послідовно демонструють, що головна причина провалу трансформацій — це недостатнє фінансування «двигуна змін».

Інсайт: Трансформації вимагають перерозподілу ресурсів на розбудову спроможностей (навчання та upskilling), а не лише на закупівлю технологій. Компанії, які фокусуються виключно на впровадженні інструментів без інвестицій у людський капітал («Податок на навчання»), зазнають невдачі у 2,5 рази частіше.
Урок: Ви не можете купити ефективність; ви повинні її побудувати. А будівництво вимагає витрат, перш ніж почне приносити економії.

Джерело: McKinsey: Unlocking success in digital transformations

Парадокс когнітивного навантаження: чому ваші сеньйори вигорають

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

Ця асиметрія найболючіше б’є по Senior-інженерах.

У традиційному робочому процесі сеньйор витрачав частину часу на кодинг, а частину — на рев’ю роботи Junior та Middle розробників. Обсяг коду, який надходив на перевірку, був природним чином обмежений швидкістю друку та мислення молодших колег.

З AI цей обмежувач зник. Джуніори, озброєні інструментами на кшталт Copilot, тепер можуть генерувати величезні шматки функціоналу за хвилини. Вони відкривають Pull Requests (PRs), які є більшими, складнішими та частішими, ніж будь-коли раніше.

Сеньйор, який діє як «воротар» якості (gatekeeper), раптово опиняється перед брандспойтом коду. Це призводить до «Втоми рев’ювера» (Reviewer Fatigue).

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

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

Це різко підвищує Когнітивне навантаження (Cognitive Load). Замість того, щоб фокусуватися на високорівневій архітектурі системи чи вирішенні критичних бізнес-задач, найдорожчі та найдосвідченіші інженери перетворюються на «AI-прибиральників». Вони витрачають дні на дебаг коду, який вони не писали і який автор часто сам до кінця не розуміє.

Результатом є парадокс: індивідуальна продуктивність (кількість згенерованих рядків коду) злітає до небес, але командна швидкість (фічі, доставлені в продакшн) падає, тому що процес рев’ю стає масивним «пляшковим горлечком».

Ключовий інсайт та дані:


Вплив когнітивного навантаження на досвід розробника (DevEx):
Microsoft Research та GitHub провели ґрунтовні дослідження того, що насправді драйвить продуктивність розробників. Вони виявили, що критичним є «Стан потоку» (Flow State), а високе когнітивне навантаження — головний ворог потоку.

Інсайт: Коли розробники змушені витрачати надмірну ментальну енергію на верифікацію ненадійного коду, їхня здатність вирішувати складні проблеми деградує. Високе когнітивне навантаження має сильну кореляцію з вигоранням та зниженням загальної якості системи.
Урок: AI-інструменти знижують когнітивне навантаження при написанні, але переносять його (з відсотками) на етап перевірки.

Джерело: Microsoft Research: DevEx: What Actually Drives Productivity

Пастка «Кількість проти Якості»

Прямим наслідком «Ілюзії ефективності» та «Втоми рев’ювера», описаних вище, є непомітна, але масштабна деградація якості програмного забезпечення. Ставлячи в пріоритет швидкість випуску (output), організації ненароком стимулюють створення технічного боргу в промислових масштабах.

Цей феномен створює те, що можна назвати «Ілюзією компетентності».

У минулому Junior-розробник, який не розумів суті проблеми, просто застрягав. Він був змушений просити про допомогу або читати документацію. Це слугувало природним запобіжником («дроселем») для кодової бази. Сьогодні той самий розробник може попросити AI «написати функцію, яка робить X», і отримати синтаксично ідеальне рішення за лічені секунди.

Код компілюється. Він запускається. Він може навіть проходити базові юніт-тести. Але чи обробляє він граничні випадки (edge cases)? Чи є він безпечним? Чи масштабується він?

Оскільки джуніор не писав цю логіку самостійно, йому часто бракує глибини розуміння, щоб відповісти на ці запитання. Він не «кодить», він «акцептує пропозиції» (accepting suggestions). Як результат, ми спостерігаємо розквіт «Happy Path» програмування — коду, який ідеально працює за нормальних умов, але катастрофічно ламається при першій же нестандартній поведінці користувача або некоректних даних.

Більше того, вартість виправлення цих помилок підпорядковується класичній кривій програмної інженерії: баг, знайдений на етапі проектування, коштує $1; баг у продакшені — $100. AI прискорює цикл «push to production», а це означає, що баги доставляються користувачам швидше, ніж будь-коли раніше.

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

Ключовий інсайт та дані:


Чи пишуть користувачі більш небезпечний код з AI-асистентами?
Дослідники зі Стенфордського університету вивчили вплив AI-асистентів на безпеку коду.

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

Джерело: Stanford: Do Users Write More Insecure Code with AI Assistants?

Реальне майбутнє: два горизонти цінності та Software 2.0

Песимізм попередніх розділів підводить до логічного запитання: якщо AI не економить бюджет «тут і зараз», а при неправильному менеджменті ще й знижує якість, навіщо він взагалі потрібен?

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

Горизонт 1: High-Velocity Delivery (Вдосконалення Software 1.0)

Перш ніж ми досягнемо науково-фантастичного майбутнього, правильне впровадження AI революціонізує поточну роботу. Це перший ефект грамотних інвестицій: справді швидша та якісніша доставка (delivery).

Коли команди навчені не просто «генерувати код», а використовувати AI для архітектурного рев’ю, генерації автотестів та рефакторингу легасі, метрики змінюються. Ми отримуємо не просто швидший набір тексту, а швидший цикл розробки (cycle time) та вищу надійність. У цьому режимі AI діє як мультиплікатор найкращих практик. Він дозволяє команді дотримуватися суворого TDD (Test Driven Development) без рутини або миттєво документувати складні системи.

Горизонт 2: Стрибок до Software 2.0 (Агентні воркфлоу / Поведінкове ПЗ)

Опанування Горизонту 1 є передумовою для Горизонту 2: створення речей, яких раніше не існувало. Ми є свідками платформного зсуву від «Копайлотів» (асистентів) до «Агентів» (акторів).

  • Software 1.0 (Поточна парадигма): Явна логіка, написана людьми. Ви використовуєте застосунок для подорожей, щоб вручну шукати, фільтрувати та бронювати.
  • Software 2.0 (Агентне майбутнє): Цілеорієнтовані системи (Goal-driven systems). Ви кажете застосунку: «Сплануй вихідні в Парижі», і агент автономно веде переговори з API, бронює рейси та замовляє трансфер.

Це являє собою створення «Поведінкових застосунків» (Behavioral Applications). Це не просто статичні інтерфейси; це інтелектуальні системи, здатні до міркування, планування та виправлення помилок.

Культурний міст: чому інвестиції неминучі

Критично важливо розуміти: ані Горизонт 1, ані Горизонт 2 неможливо досягти, просто купивши ліцензії та звільнивши персонал. Обидва вимагають радикальної зміни в інженерній культурі.

Побудова імовірнісних, агентних систем зміщує центр ваги від «генерації синтаксису» до «Оркестрації систем» та «Оцінки» (Evaluation). Щоб досягти успіху, вам потрібні не менше розробників, а трансформовані розробники. Вам потрібні інженери, які розуміють, як будувати «захисні бар’єри» (guardrails) навколо AI-моделей і як дебажити логіку, яка не була написана явно, а виникла(emerged).

Цей культурний зсув вимагає додаткових інвестицій, а не скорочень. Він вимагає бюджету на навчання, часу на експерименти та створення нових ролей, таких як «AI Ops». Щоб керувати цим переходом від детермінованого коду до імовірнісних систем, нам потрібні більше ніж просто інструменти — нам потрібен новий операційний стандарт, те, що я називаю «Архітектурою невизначеності» (Uncertainty Architecture).

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

Ключовий інсайт та візія:


AI-агенти та майбутнє програмного забезпечення:
Провідні венчурні фонди та техно-візіонери, включаючи Sequoia Capital та Білла Гейтса, визначили «Агентів» як наступний великий платформний зсув. Однак вони наголошують, що це зсув у можливостях, а не лише в ефективності.

  • Візія: «Агенти не просто змінять те, як усі взаємодіють з комп’ютерами. Вони перевернуть індустрію програмного забезпечення».
  • Реальність: Реалізація цієї візії вимагає переходу від «софту як інструменту» до «софту як сервісу» (виконання завдань). Це потребує нової породи інженерних команд, здатних керувати недетермінованими результатами — навичка, яку треба вирощувати через інвестиції.

Джерело: Sequoia Capital: AI Agents | Bill Gates: AI is about to completely change how you use computers

Висновок: Інвестуйте, щоб еволюціонувати, а не ріжте, щоб вижити

Наратив про те, що AI дозволить компаніям негайно урізати інженерні бюджети на 20–30%, є не просто оптимістичним; він структурно небезпечний. Як ми з’ясували, ця «Омана скорочення витрат» (Cost-Cutting Fallacy) ігнорує реалії J-кривої трансформації, приховані витрати паралельних операцій та нищівне когнітивне навантаження на сеньйорів.

Компанії, які розглядають AI виключно як механізм скорочення штату, приречені на провал. Вони, ймовірно, отримають короткостроковий сплеск маржинальності, за яким слідуватиме довгостроковий колапс. Вони не зможуть опанувати Горизонт 1 (потонувши в низькоякісному технічному боргу, згенерованому AI) і їм забракне талантів, щоб досягти Горизонту 2(нездатність будувати складні агентні системи майбутнього).

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

Для лідерів, які прокладають курс у 2026 році, плейбук зрозумілий:

  1. Фінансуйте J-криву: Прийміть той факт, що продуктивність впаде, перш ніж злетить. Закладіть у бюджет «Податок на трансформацію» і опирайтеся бажанню урізати ресурси під час переходу.
  2. Вимірюйте цінність, а не обсяг: Припиніть трекати «рядки коду» або «частоту комітів». Почніть вимірювати «cycle time», «надійність системи» та «вирішені проблеми клієнтів».
  3. Навчайте, щоб подолати розрив: Ваші експерти з доменною експертизою цінніші, ніж будь-коли. AI може написати синтаксис, але тільки ваші люди розуміють бізнес-логіку. Інвестуйте в їхнє навчання інструментам Горизонту 1, щоб вони були готові будувати агентів Горизонту 2.
  4. Будуйте для Software 2.0: Змістіть фокус з «як нам побудувати цей застосунок дешевше?» на «які інтелектуальні, агентні застосунки ми можемо побудувати зараз, що були неможливі раніше?».

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

Фінальна думка:


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

Author:
Vitalii Oborskyi — Head of Delivery & Ops | Creator of «Uncertainty Architecture» (AI Control Theory) | github.com/...​/uncertainty-architecture

Теми: AI, гроші
👍ПодобаєтьсяСподобалось27
До обраногоВ обраному8
LinkedIn

Найкращі коментарі пропустити

Олександр Шпак 09.01.2026 01:46

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

Приведу приклад успішних кейсів. Потрібно написати формулу в Google Sheet. Читати документацію та дивитися відео не було часу. На задачу за допомогою Gemini витратив хвилин 10. З них 8 хвилин розбирався, чому результат трохи непередбачуваний, допоки не знайшов помилку в даних, не в формулі. З другої спроби все запрацювало як треба. Раніше на це я витрачав точно більше години. Прискорення? Авжеж.

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

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

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

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Oleksiy Kozub 15.01.2026 12:25

Доброго здоров’я, всім!
Дуже дякую Віталію за змістовну та своєчасну статтю.
З мого досвіду, всі нові технології у своєму розвитку проходять декілька стадій:
1. «Ця технологія вирішить всі Ваші проблеми! Забудьте все старе!». На цій стадії всі кидаються застосовувати її всюди. Вона стає, як то кажуть, «на язику» у всіх. З ким не поговориш, що не почитаєш, скрізь присутня тема цієї нової технології.
2. «Фу, ви застосовуєте цю технологію?». На цій стадії приходить розуміння, що всяка технологія не панацея і не магічний грааль. Всі поділяються на три табори: ті хто беззаперечно підтримує цю технологію, противники її та ті, хто вичікують. Проходять баталії між прихильниками та противниками цієї технології — «ви нічого не розумієте», з одного боку та «дивіться, ось тут не працює» з другого.
3. Всі починають розуміти, що нова технологія це круто, але вона має свої правила і межі застосування. На цьому етапі нова технологія врешті решт знаходить свою нішу застосування. Баталії потроху закінчуються і людство отримує інструмент, що застосовується у певній ніші повсякденного життя (переважна більшість навіть не підозрює, що вони працюють з цією технологією).
Це стосується не тільки програмування, а й багатьох інших технологій у різних галузях людських знань.
Також хочу відмітити, що нові технології не стоять на місці і розвиваються впродовж цих трьох стадій. Це дає змогу відпрацювати технологію, зрозуміти та як її ефективно застосовувати.
Тож, панове, пробуємо використовувати, пишемо відгуки, вносимо свій вклад у розвиток технології та чекаємо, поки технологія не з’явиться у нашому повсякденному житті (або у якійсь її ніші). Ще раз висловлюю подяку Віталію за підняту тему.

Відповісти
Підтримати
Vitalii Oborskyi PMO&Delivery Head в Developex 16.01.2026 07:45

Сергію, ви абсолютно праві. Це хрестоматійний Gartner Hype Cycle в дії.

І судячи з сигналів ринку, ми якраз стрімко входимо у фазу «Ями розчарування» (Trough of Disillusionment). На жаль, знання теорії не рятує від повторення історії: попереду нас чекає охолодження інвесторів, банкрутства тих, хто не має юніт-економіки, і болісне протверезіння.
Парадокс у тому, що хоча всім відомі ці «граблі», C-level менеджмент масово приймав рішення за доволі «пласкою» логікою: «купимо ліцензію — отримаємо результат», ігноруючи складність інтеграції.

Власне, ця стаття — це моя спроба внести вклад у те, щоб ми швидше пройшли дно цієї «ями» і почали підйом на «Схил просвітлення» (Slope of Enlightenment). Це лише один елемент великої мозаїки, але про це треба говорити.

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

Відповісти
Підтримати
Sergey Lysak
Олександр Шпак Oarsman в Self Employed 16.01.2026 11:19
Сергію, ви абсолютно праві

Після цієї фрази спілкування з опонентом можна припиняти.

Відповісти
Підтримати
Vitalii Oborskyi
Jan Haring 16.01.2026 22:41

Як часто ця фраза зустрічається в інтернетах? 🤣

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 16.01.2026 23:50

Це фраза-маркер типова для ШІ.

Відповісти
Підтримати
Jan Haring
Sergey Lysak T/T Lead 16.01.2026 12:45
І судячи з сигналів ринку, ми якраз стрімко входимо у фазу «Ями розчарування» (Trough of Disillusionment)

Ще не входимо. Але думаю у цьому, або наступному році повинні гепнутись у ту яму.

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

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

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

Я останній рік і кажу — лудіти то самі менеджери, а не наймані працівники. Які звикли що їх недоопрацювання компенсують робітники-люди.

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 16.01.2026 14:02

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

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

І я переконаний, що справжню архітектуру цього «Нового Світу» побудує навіть не Big Tech. Його побудують ентузіасти, невеликі команди та стартапи. Саме вони створять ті продукти, які раніше здавалися неможливими. Великі гравці дадуть «електрику» (моделі), а «прилади» зроблять інші.

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

Відповісти
Підтримати
Sergey Lysak
Jan Haring 12.01.2026 12:20

Ну так, кодинг став набагато швидше. Рев’ю також. Але усе одно треба попинати людей у Slack щоб отримати апруви i це займає багато часу, а кодинг найменьше.

Цiкаво було робити annual self-review. Агент сам витягнув обжективи, усi оцi company values, полiз у джиру та слак, та налабав непогану таку рибу, пiсля пари правок так i запостив.

Відповісти
Підтримати
Мама програміста 15.01.2026 14:53
Але усе одно треба попинати людей у Slack

тількі у Слак? в мене бувають дні, коли я майже готова сідати на лісапет та їхати до людини додому, щоб пнути підсрачника наживо

Відповісти
Підтримати
Jan Haring
Jan Haring 15.01.2026 14:54

Тю, я один раз просив квиток до Шанхаю, щоб пенделя дати)

Відповісти
Підтримати
Мама програміста
Мама програміста 15.01.2026 15:04

це тема для скрам мастера

— з’ясувати, чи дійсно необхідно летіти в Шанхай
— з’ясувати, чи дійсно необхідний пендель
— чим можна замінити пендель, щоб не потрібно було летіти в Шанхай і без погіршення team dynamics

Відповісти
Підтримати
Jan Haring
Jan Haring 15.01.2026 15:05

Дали пенделя менеджеру, далі менеджер роздав вниз)

Відповісти
Підтримати
Мама програміста
Просто Анон 15.01.2026 15:27
Цiкаво було робити annual self-review. Агент сам витягнув обжективи, усi оцi company values, полiз у джиру та слак, та налабав непогану таку рибу, пiсля пари правок так i запостив.

Теж так робив, ще історію за пів року в git передивився і виписав основні фічі, фікси.

Відповісти
Підтримати
Jan Haring
NoName 11.01.2026 00:56

Когда то давно читал фантастику про какуюто далекую планету где были войны и достижения цивилизации были частично утрачены. И там старцы молились богу машины что бы она ехала вперед. Потом машина поломалась и они замочили старца — он типа плохо молился, или как то так. И вот сижу я за своим VC кодом и пишу в промт агента — пожалуйста, добавь юнит тесты что бы покрыть весь новый код, что бы у них были имена как у старых тестов и что бы один тест покрывал одно изменение, и что бы после каждого теста был ресет и перед каждым тестом был сетап. Алилуя !

Відповісти
Підтримати
Мама програміста 12.01.2026 10:14
И там старцы молились богу машины что бы она ехала вперед.

це сіньор вайбкодер, 40 років досвіду, бачив все

Відповісти
Підтримати
NoName
Alexander Novikov Video software developer в Codedo Limited 10.01.2026 12:47

Прикол в том что хотя AI не дает того преимущества которое ему приписывают, клиенты уверены что даёт, причём лучшие — то есть самые тупые — клиенты — думают в наибольшей степени. Так что увы, спрос на программистов оно дико снижает, и в первую очередь самый вкусный, высокомаржинальный спрос от клиента «закодил, сорвал 10x бабла и выбросил» — потому что те кто раньше были готовы так платить, сейчас все уверены что программисты вообще больше не нужны.

Відповісти
Підтримати
Dr Alban 09.01.2026 20:15

залишився осадочок від

Джерело: Sequoia Capital: AI Agents | Bill Gates: AI is about to completely change how you use computers

оце все про залізти без мила в життя, стати другом.

Відповісти
Підтримати
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 17:00

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

Якщо у вас є предметне запитання чи бажання обговорити тему глибше — пишіть через форму контакту тут або стукайте в LinkedIn. Там вірогідність конструктивного діалогу зараз вища.

Ну а якщо ви просто хотіли написати, що я ні на чому не розуміюся і пишу нісенітниці — то запевняю вас: не варто витрачати зусиль. Я це розумію і давно з цим змирився :)

Відповісти
Підтримати
Dr Alban 09.01.2026 14:36
Наприкінці 2024-го та протягом 2025 року в переговорних кімнатах IT-компаній закріпився небезпечний наратив. Логіка здавалася спокусливо простою: якщо AI-інструменти, такі як GitHub Copilot, Cursor або Windsurf, допомагають розробнику писати код на 20–50% швидше, то компанія може скоротити штат інженерів на аналогічний відсоток, зберігаючи той самий рівень продуктивності (output).

це пошесть якась.
З останніх новин, M$ планує скорочення 22 000 співробітників. Точніше\мабуть це буде re-Hiring.

Відповісти
Підтримати
Олександр Шпак Oarsman в Self Employed 09.01.2026 01:46

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

Приведу приклад успішних кейсів. Потрібно написати формулу в Google Sheet. Читати документацію та дивитися відео не було часу. На задачу за допомогою Gemini витратив хвилин 10. З них 8 хвилин розбирався, чому результат трохи непередбачуваний, допоки не знайшов помилку в даних, не в формулі. З другої спроби все запрацювало як треба. Раніше на це я витрачав точно більше години. Прискорення? Авжеж.

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

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

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

Відповісти
Підтримати
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 09:56

Олександре, ваш досвід ідеально лягає на суху статистику, яку я наводив у коментарях.

Ви емпіричним шляхом дійшли до висновку, який на макрорівні показує звіт GitClear: у масштабах індустрії AI-асистенти сьогодні принесли більше обсягу (мільйони зайвих рядків коду), ніж реальної користі.

Фактично, ми можемо чітко окреслити Безпечну зону для поточних інструментів, яку ви описали:
1. Одноразовий код (Disposable code): скрипти, формули для Excel, швидкі парсери. Те, що запустив один раз і забув.
2. Перевірка гіпотез (PoC): як у вашому кейсі з JVM. Швидко накидати, перевірити, чи працює концепція, і викинути.
3. Атомарний пошук: знайти рішення для ізольованої, тривіальної проблеми.

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

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

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 10:18

Ну а на ринку зараз відбувається класичний Дикий Захід посеред піку Gartner Hype Cycle. Ситуація розшарувалася на кілька паралельних реальностей:

1. Інженерна спільнота Долини. Там йде справжня, важка робота над тулами та технікою. Але інженери програють битву за наратив власним маркетинговим відділам. Маркетологи загортають складні інженерні рішення в обгортку чарівної таблетки, продаючи ринку, по суті, Snake Oil (зміїну олію) замість технології.

2. Корпоративні гравці та Чорні скриньки. Є компанії-споживачі, які наче побудували щось солідне. Але це пропрієтарні, закриті системи (Black Boxes), суто внутрішні розробки. Ринку в цілому вони не потрібні, бо цей досвід не масштабується.

3. Торговці страхом. Великі вендори ведуть агресивну гру на випередження: Купіть нашу чорну коробку, інакше завтра ваш бізнес впаде, бо конкуренти вже купили. Це розганяє масову істерію (FOMO) і змушує приймати ірраціональні рішення, але ніяк не покращує якість впровадження.

4. Регулятори (The Adults in the Room). А осторонь сидять регулятори та організації зі стандартизації, дивляться на цей цирк і намагаються пояснити: у такому хаотичному вигляді, без прозорості та правил, воно на рівні критичної інфраструктури не полетить.

Ми зараз саме в цій точці — між маркетинговим шумом, агресивними продажами страху та необхідністю навести інженерний порядок.

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 09.01.2026 11:31
Ви емпіричним шляхом дійшли до висновку

Базуючись на знаннях, як працюють LLM, скоріше. Тому що я не очікував більшого та був готовий на те, що мені нагенерують неробочої маячні.

а використання LLM як архітектурного блоку самого додатку

Це скоро теж почне загинатися. Задач, які LLM може робити якісно не так багато. Вбудовувати дорогу хрінь, щоб робити пару відсотків корисної роботи — це економічно недоцільно.

Відповісти
Підтримати
Vitalii Oborskyi
Олекса Мащиць засновник в QA Україна 09.01.2026 12:36

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

Але це не правило. Тим же гуглом не треба було користуватися «як правило» та обов’язково застосовувати у кожному кроці — це залежало від потреб фахівця. Не треба було весь софт писати однією (кращою) мовою, або використовувати мікросервіси у 100% випадках чи всім підіймати повноцінний важкий DevOps процес у розробці.

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

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 13:01

Це цікавий вектор дискусії і по-своєму вірний, але хотів би внести важливі уточнення в модель «адаптації інновацій».

Існує популярний міф, що технології приживаються суто «знизу», тому що інженери спробували і їм сподобалось (органічний ріст), або суто «зверху», бо Big Tech це нав’язав.
Реальність складніша. Між інженером і бізнесом є «Третя сторона» — робочі групи, інституції та методологи, які займаються синтезом стандартів. Те, що ми вважаємо «природним вибором інженера» сьогодні, часто є результатом цілеспрямованої роботи цієї третьої сторони 10–15 років тому.

Давайте поглянемо на історію, про яку часто забувають:

1. Кейс DevOps.
Ви згадали про DevOps як про щось, що «вирішують підіймати чи ні». Але сам DevOps як професія і підхід — це штучно створений конструкт.
До 2009 року цього терміну не існувало. Це був синтез, започаткований групою ентузіастів (Патрік Дебуа, пізніше Джин Кім та Джез Хамбл), які намагалися вирішити конфлікт між Dev та Ops.
Але індустріальним стандартом це стало не саме по собі. З’явилася організація DORA (DevOps Research and Assessment), яка роками проводила наукові дослідження, доводячи цифрами зв’язок між практиками та бізнес-результатом. Пізніше Google купив DORA, фактично інституціоналізувавши ці метрики. А потім підтягнулися гіганти на кшталт PMI (Project Management Institute), які почали скуповувати методики (як Disciplined Agile), щоб перетворити «культурний рух» на сертифіковані стандарти.
Тобто DevOps не просто «виріс у полі» — його виростили, описали і продали індустрії як готовий інженерний рецепт.

2. Кейс Мікросервісів.
Це теж не просто «інженери так захотіли». Цей архітектурний стиль був формалізований та популяризований конкретними людьми (Мартін Фаулер, Джеймс Льюїс з ThoughtWorks) у 2014 році як відповідь на проблеми масштабування організацій (Закон Конвея). Вони дали цьому назву, визначення та правила. Без цієї методологічної роботи ми б досі мали просто «хаос розподілених систем», а не патерн «мікросервіси».

Висновок:
Технологія стає індустріальним стандартом не тоді, коли вона просто «корисна» окремому інженеру, а тоді, коли з’являється методологічний прошарок (Framework/Standard), який пояснює, як це масштабувати, вимірювати та контролювати.
З ШІ зараз відбувається те саме. Поки ми на етапі «дикого поля». Щоб це запрацювало системно, нам потрібен не просто Copilot, а нова методологія (умовний «AI-Ops» або те, що я називаю Uncertainty Architecture), яка перетворить магію на інженерну дисципліну.

Відповісти
Підтримати
Олекса Мащиць
Микола Сидоренко 09.01.2026 13:23

Ви от говорите правильні речі, які я цілком підтримую, але навчіться лаконічності нарешті!
1. Навіщо повторювати один і той же абзац із разу в раз, коли ви і так вже це сказали. Всі, хто читає, пам’ятає його. Ми, люди, здатні зберігати контекст набагато довше за ШІ.
2. Навіщо писати купу «води»? Отой екскурс в DevOps кому потрібен? Хіба тема про нього? Хіба ми не знаємо що то таке?
3. Чим довша ваша відповідь, тим більша ймовірність, що опонент її не захоче читати. Ну бо кому цікаво витрачати купу часу на читання простиней із «води»?
Для статей це допустимо, а от для коментів — ні.
«Лаконічність — сестра таланта» ©

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 13:26

Приймається. Критика по суті.

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

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

Відповісти
Підтримати
Микола Сидоренко
Олекса Мащиць засновник в QA Україна 09.01.2026 13:32

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

Я не прибічник ідеї імплементації технологій «суто знизу», проте дивлячись на попередній абзац сказав би, що для умовної категорії «гугл» чи «автокомпліт» це працює, а для умовної категорії «DevOps» одного «знизу» замало. Але агресивного нав’язування все одно не відбувалося, ані з гуглом, ані з DevOps.

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

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

Моя теза не виключає існування досліджень чи експериментів з «ШІ», напроти, я напряму закликаю до цього (dou.ua/forums/topic/57311). Але ми не можемо казати про «ШІ» настільки широко та серйозно дивитися на «ШІ» як на цілісну технологію, бо вона не цілісна. Наприклад, з машинним навчанням (яке є частиною ШІ) все доволі зрозуміло і питань щодо доцільності цієї технології немає. Туди ж й комп’ютерне бачення тощо.

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 13:54

Погоджуюсь щодо шкідливості насильницького впровадження.

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

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

Я запропонував рішення цієї колізії через Control Theory (Теорію Управління). Реакція міжнародної спільноти на Reddit (аномально висока кількість збережень та шерів при мінімумі коментарів) доводить: інженери шукають саме системний підхід, а не просто хайп.

Щоб не розписувати деталі тут, пропоную глянути суть запропонованого рішення за посиланням:
www.reddit.com/...​ndatascience/s/x05Els5v3a

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 14:03

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 14:13

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

1. Де це обговорюється?
Якщо подивитися на еволюцію управлінської думки за останні 5 років, то ключові бестселери саме про це.
Team Topologies (Skelton & Pais) — вся книга побудована навколо терміну Cognitive Load (когнітивне навантаження). Головна теза: сучасні системи стали настільки складними, що одна команда більше не може тримати повний контекст без шкоди для delivery.
Platform Engineering — цей тренд (який Gartner називає топ-стратегією) виник як реакція на те, що концепція You build it, you run it (DevOps у чистому вигляді) почала ламатися під вагою інструментарію. Розробники почали тонути в конфігах K8s замість писати код. Це і є та сама стіна складності.

2. Технології як відповідь на бар’єри.
І до речі, ті напрямки, які ви згадали (квантові обчислення тощо) — це теж не просто «інші причини». Це спроби пробити ту саму стелю, просто в іншому вимірі.
Квантові обчислення розвиваються саме тому, що класична архітектура фон Неймана вперлася в фізичні межі (кінець закону Мура) для певного класу оптимізаційних задач.
Тобто і Platform Engineering (організаційна складність), і Quantum (обчислювальна складність), і GenAI (семантична складність) — це все фронти однієї війни. Війни проти обмежень поточних підходів, які перестали масштабуватися лінійно.

3. Відчуття болю проти термінології.
Ви праві, пересічний інженер може не використовувати термін Complexity Wall. Але він відчуває цю проблему щодня як біль. Це проявляється у фразах: Чому онбординг займає 3 місяці?, Я боюся деплоїти це в п’ятницю. Це симптоми того, що складність систем зростає, а когнітивна спроможність людини — величина стала.

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

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 14:41

Оцінюю написане більше як філософську задачу, ніж практичну. Якщо казати про когнітивне навантаження, то подивимося на створення мов програмування високого рівня та відстань від print("Hello«) до керування транзистором. Ми легко подолали цю складність, а вона значно більша, ніж кількість документації якогось окремо взятого програмного продукту.

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

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

Для прикладу. Нам знадобився захист комунікації у вебі — з’явився SSL->HTTPS. Це конкретна проблема, не уявна. Знадобилося зручно передавати файли — з’явився FTP. Ось якого рівня проблему я хочу побачити, коли ми стверджуємо, що «ШІ» розв’язує її. Або ж ми маємо казати про покращення, не розв’язання проблеми.

Квантовий комп’ютер не замінює традиційний, ми не дивимося на нього як на те, що «в’бє» класичний ПК. Швидкість обчислень впирається не у людський мозок, коли ми кажемо про чіпи, але в технологічні, часто фізичні особливості матеріалів. Про це можна казати дуже конкретно. І Microsoft зі своїм квантовим чипом, і SpaceX з своїми ракетами, Starlink та Neurolink й навіть OpenAI не кажуть про те, що є проблема з когнітивною складністю для створення їх продуктів. Якби це було так, то як би вони виникали? Як би виникали 2нм технології виробництва чипів? Все це зроблено без «ШІ».

Всі ці складні продукти створені дуже якісно і людьми. А це суперечить тезі про стелю, як нагальній проблемі. В розробці часто це вирішується правильним процесом. Інколи ок бути Agile, а в іншому випадку — беремо сувору V-модель та отримуємо найвищу якість, якщо нам саме це потрібно. А потім робимо гібрид, як це було з ракетами Маска, коли він у скрам стилі навмисно запускав mvp та знищував їх, випробовуючи їх межі.

Отже, поки не можу погодитися з озвученою проблемою.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 15:18

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

Я ваш аргумент зрозумів, особливо акцент на інженерній еволюції та рівнях абстракції. Свою позицію щодо системної складності я теж озвучив. Тож пропоную на цьому зафіксувати status quo: ми по-різному оцінюємо природу поточних бар’єрів в індустрії, і це нормальний стан речей для такої широкої теми. Дякую за змістовний діалог.

Відповісти
Підтримати
Олекса Мащиць
Олександр Шпак Oarsman в Self Employed 09.01.2026 16:08
Як би виникали 2нм технології виробництва чипів?

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

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 16:25

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 16:52

Я не бачу поки що жодного шансу для AI почати генерувати нові рішення для якихось проблем, а не покращувати наявні. Бо поки що така технологія.

Відповісти
Підтримати
Олекса Мащиць
Олександр Шпак Oarsman в Self Employed 09.01.2026 14:35
Нові технології продовжують з’являтися та утилізуватися, ми ніде не зупинилися.

Вони не нові, вони гарно забуті старі, або трохи оновлені.

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 14:50

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 16:09

Ок, тоді запитання, які технології, на вашу думку, є новими?

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 16:19

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 20:05

Я б тоді розділяв нові технології та нові продукти. Технологія — це про процеси та підходи, а не про інструменти. Тому компіляція наявних інструментів в новий не створює нову технологію.

Приведу приклад деревообробки. Ручний фрезер є гарним взірцем нового продукту. Він приніс абсолютно інший спосіб обробки деревини, якого не існувало до його винаходу. Або транзистор. Його поява зробила революцію в електрониці, створивши новий клас продуктів.

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 20:39

Покладемо на наш стіл для препарацій фреймворк чи бібліотеку, наприклад React або FastAPI. А можливо навіть Angular чи HTML. Ми звично називаємо все це загальним словом «технології». Таким є популярний та звичний нам контекст. Глобально ж, ймовірно, це може бути лише «інструментами», правильно розумію запропонований спосіб розрізняти їх?

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 21:03

Рендерити дані на стороні клієнта — технологія. Порівнювати два дерева для визначення різниці — технологія. React — лише одна з реалізацій даних технологій. Інструмент. Server-side rendering, templating, data compression, caching, bidirectional data transfer, SSO та інше — технології.

Відповісти
Підтримати
Олекса Мащиць
Олекса Мащиць засновник в QA Україна 09.01.2026 21:11

Ок, має сенс. Тепер до новизни. Можемо вважати, скажімо, SSR новою технологією? Або умовно новою? Можливо, введемо поняття «в широкому» та «у вузькому» сенсі? Здається, тут вже потрібен чіткий контекст. Бо я на тлі загального захоплення «ШІ» як супер-пупер-нової та революційної технології я схильний казати, що вона не нова, та скоріше еволюційна. А в сенсі знаходження підходів до її ефективної утилізації — вона може вважатися новою.

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 21:35

Колеги, тисну ваші віртуальні руки — дискусія вийшла дійсно глибокою.

Ви зараз підійшли впритул до сутності, яку можна назвати «Сучасна Інженерна Культура». Якщо подивитися на це крізь призму вашої дискусії, стає зрозуміло, чому ШІ викликає такий когнітивний дисонанс.

На найвищому рівні (стандартизації та методології) завжди відбувається синтез абстрактних сенсів. І поява ШІ як будівельного блоку для софту ламає цей фундамент, бо змінює базові аксіоми, на яких інженерія стояла 50 років.

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

Але що таке «баг», якщо ваша функція — це генератор ймовірностей (стохастична система)?
Якщо модель видала інший результат — це помилка чи варіативність (Temperature > 0)?
На цьому рівні старих визначень вже недостатньо. Система зламана на рівні сенсів. І саме необхідність перевизначення таких базових істин каскадно вимагає перегляду всіх процесів.

І тут ми повертаємося до «Стіни Складності», про яку я згадував раніше. З суто інженерної точки зору, без урахування цієї «архітектури сенсів», її важко розгледіти. Але академічна спільнота та організації зі стандартизації вже бачать цей бар’єр. І саме перехід до ймовірнісної парадигми (з правильною методологією контролю) розглядається як єдиний можливий спосіб подолати цей поріг складності, який лінійними методами пробити вже не вдається.

Сподіваюсь, цей кут зору на стику філософії та інженерії вдало доповнить ваш діалог.

Відповісти
Підтримати
Олекса Мащиць
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 21:40

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

Але поява контрольованого ймовірнісного компонента (Probabilistic Component) як будівельного блоку — це зміна самої фізики процесу. Це перехід від масштабування інструкцій до масштабування міркувань (Reasoning).
Коли ми починаємо будувати систему з блоків, що мають, умовно кажучи, «інтелект» і здатність діяти в умовах невизначеності — ми переходимо на зовсім інший рівень «якості» вихідного софту.
Тут перестають працювати старі лінійні методи масштабування, але натомість відкриваються горизонти автоматизації, які раніше були закриті для нас саме стіною лінійної складності.

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 09.01.2026 21:53
бо змінює базові аксіоми, на яких інженерія стояла 50 років.

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

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

Це ваша персональна бульбашка, не узагальнюйте. Я вже років з 15 живу в парадигмі коду як біологічної системи: fail safe та fault tolerant, де поганий результат або його відсутність вважається в першу чергу результатом. Парадігма, в якій «баг» це будь-яка нештатна з боку системи ситуація, не є аксіомою.

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 21:58

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

1. Fault Tolerance vs Probabilistic Logic.
У вашій парадигмі Fail Safe ви обробляєте відмови інфраструктури або помилки виконання. Але ваша логіка обробки цих помилок — детермінована. Ви пишете: Якщо сервіс не відповів за 200мс -> повернути кеш або дефолтне значення. Це все ще жорсткий алгоритм (If-Then), створений людиною. Ви контролюєте кожен шлях виконання.
У випадку з GenAI компонентом ми говоримо про інше. Ми не просто обробляємо помилку (мережу/таймаут). Ми отримуємо на виході валідий JSON і статус 200 ОК, але семантично відповідь може бути хибною (галюцинація) або просто іншою за змістом (дрейф).
Тобто: у класиці невизначеність лежить у середовищі виконання (мережа, залізо), а код — це острівець стабільності. У GenAI невизначеність лежить всередині самої логіки прийняття рішень (всередині «функції»). І це вимагає зовсім інших методів контролю (оцінка семантичної відстані, а не просто try-catch).

2. Щодо складності та абстракцій.
Анекдот про абстракції — вічна класика, згоден. Але складність, про яку я кажу — це не (тільки) наслідок моди на фреймворки. Це наслідок вимог бізнесу.
Ми не можемо вирішити задачу персоналізації контенту для мільйона юзерів або задачу автономного водіння простими скриптами. Ця складність емерджентна. І спроба керувати нею лінійними методами якраз і призводить до того, що ми будуємо крихкі монстри.
ШІ як архітектурний блок (а не просто генератор коду) обіцяє інкапсулювати цю складність, дозволяючи оперувати цілями (Goals), а не інструкціями (Steps). Це і є зміна аксіоматики: від імперативного до агентного підходу.

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 22:19

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

1. Емпірична валідація.
Поява перших агентних систем та успішні впровадження GenAI у вузьких вертикалях (Vertical AI) доводять життєздатність концепції. Це вже не paperware, це працюючі MVP нової парадигми.

2. Академічний ренесанс.
Ми спостерігаємо «розморожування» фундаментальних знань. Теорія ймовірностей, класична кібернетика та Computer Science десятиліттями накопичували базис, який вважався «чистою академічною абстракцією» через брак обчислювальних потужностей. Сьогодні ці теореми стають прикладною інженерією. Академія отримала потужний імпульс і тепер рухається вперед, перетворюючи математичні моделі минулого на архітектурні патерни майбутнього.

3. Ринковий драйвер (Business Pain).
Бізнес рідко артикулює потребу в «ймовірнісних системах», він артикулює це через біль масштабування.
Класичний приклад: гіперперсоналізація контенту для мільйонів користувачів. Намагатися вирішити це детермінованим шляхом — це писати сотні тисяч `if-then` правил. Це шлях до комбінаторного вибуху та непідтримуваного коду.
Бізнес вперся в стелю лінійності, і саме тому він (свідомо чи ні) вимагає переходу до систем, здатних до автономного прийняття рішень (Reasoning) без жорсткого хардкодингу кожного сценарію.

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 09.01.2026 22:19
Але ваша логіка обробки цих помилок — детермінована.

Звісно ж детермінована. Тому що визнання помилок результатом є як раз тим самим детермінуванням.

Ви контролюєте кожен шлях виконання.

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

Це наслідок вимог бізнесу.

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

ШІ як архітектурний блок (а не просто генератор коду) обіцяє інкапсулювати цю складність, дозволяючи оперувати цілями (Goals), а не інструкціями (Steps).

ШІ не може це зробити. Поки що. На жаль. Тому що така технологія.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 22:24

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

1. Щодо детермінізму та Fail-Safe.
Ви тут змішуєте «надійність системи» (Robustness) та «детермінізм логіки».
Те, що система обробила помилку і не впала (Fail Safe) — це вимога до стійкості.
Але детермінізм — це про те, що на вхід А ми завжди отримуємо однаковий вихід Б, пройшовши однаковий шлях виконання.
У стохастичних системах (агентах) шлях виконання (Plan) формується в Runtime. Система може досягти цілі різними шляхами або згенерувати різні, але валідні відповіді. Це не про «не впасти», це про варіативність прийняття рішень, якої немає в if-then логіці.

2. Щодо «Бізнес ніколи такого не вимагав».
Реальність B2C-сектору (особливо з мільйонними аудиторіями) свідчить про зворотне. Бізнес завжди артикулює потребу в Mass Customization або гіперперсоналізації.
Проблема не у відсутності вимоги, а в неможливості її реалізації поточними методами за адекватні гроші. Спроба реалізувати таку варіативність детермінованим шляхом (написати мільйон if-then правил) веде до комбінаторного вибуху і захмарних бюджетів.
Тому бізнес відмовляється не від ідеї, а від нерентабельного способу її реалізації.

3. Щодо «ШІ не може це зробити. Поки що».
«Гола» LLM — дійсно не може. Вона лише передбачає токен.
Але Агентна Система (Модель + Тулзи + Пам’ять + Контрольний контур) — вже може.
Це класична помилка оцінки: судити про можливості системи (автомобіля) по можливостях окремого компонента (двигуна). Двигун сам не їде, але він є серцем машини, яка їде.
Ми будуємо архітектуру навколо ймовірнісного ядра, щоб отримати ту саму Goal-Oriented поведінку, яка вже працює в передових реалізаціях (від Customer Support до складних RAG-пайплайнів).

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 22:34

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

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

Проблема в тому, що останні 10–15 років масовий IT-сектор (особливо аутсорс/аутстаф) виховував «майстрів фреймворків», а не інженерів.
Ми навчилися віртуозно склеювати API та малювати форми на React, але ми масово забули (або й не вчили) теорію ймовірностей, лінійну алгебру та класичну кібернетику.

Коли Research Scientist будує агента, він мислить категоріями «простір станів», «функція винагороди», «ентропія».
Коли пересічний розробник намагається зробити те саме, він мислить категоріями «зараз напишу промпт і розпаршу JSON».

Без повернення до теоретичного технічного базису (Computer Science fundamentals) ми не зможемо перетворити ці дорогі прототипи на надійні індустріальні стандарти. Нам потрібно заново навчитися інженерії, а не просто кодингу.

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 09.01.2026 22:36
1. Щодо детермінізму та Fail-Safe.

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

Бізнес завжди артикулює потребу в Mass Customization або гіперперсоналізації.

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

«Гола» LLM — дійсно не може. Вона лише передбачає токен.
Але Агентна Система (Модель + Тулзи + Пам’ять + Контрольний контур) — вже може.

Я не бачив жодного бізнесу яким би керував повністю AI, та який був би успішним.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 22:41

Олександре, давайте розкладемо це по поличках, особливо щодо бізнесу та повністю автономних компаній.

1. Щодо користувачі не хочуть персоналізації, вони хочуть свободи.
Тут ви сперечаєтесь не зі мною, а з ринковою статистикою останніх 10 років.
Феномен успіху TikTok, Netflix чи Spotify базується саме на тому, що вони забрали у користувача свободу вибору (яка часто призводить до Analysis Paralysis) і замінили її на жорстку алгоритмічну гіперперсоналізацію.
Користувач (масовий) не хоче налаштовувати функціональність, він хоче отримати дофамін/користь за мінімальну кількість кліків. Зменшення тертя (Friction) через передбачення бажань користувача — це головний драйвер Retention Rate в сучасних B2C продуктах. Тому це не помилкова інтерпретація, це основа unit-економіки гігантів.

2. Щодо Я не бачив жодного бізнесу, яким би керував повністю AI.
Це класична логічна хиба Опудало (Straw Man fallacy). Ви спростовуєте твердження, якого я не робив.
Я писав про Агентні Системи як архітектурні блоки (компоненти) для побудови софту.
З таким самим успіхом можна сказати: Я не бачив жодного успішного бізнесу, яким би керувала База Даних Oracle. Звісно, ні. Але спробуйте побудувати сучасний банк без баз даних.
Агентна система — це не заміна CEO чи всієї компанії. Це інструмент автоматизації інтелектуальної праці (Reasoning), так само як верстат — інструмент автоматизації фізичної праці.

3. Щодо Fail-Safe.
Наявність подушки безпеки (детермінованого протоколу обробки помилки) не робить сам процес їзди (прийняття рішень моделлю) детермінованим. Ви плутаєте контур безпеки (Safety Layer) з ядром виконання (Execution Core). Те, що ми знаємо, що робити, коли система помилилась — не означає, що ми можемо жорстко закодити, як саме вона має досягти успіху в кожному унікальному кейсі.

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 22:49

Щодо агентів: я особисто не вірю, що на цьому етапі можлива поява AGI (Загального ШІ).

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

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 09.01.2026 23:09
Агенти — це нові руки, а не новий мозок.

То навіщо ви мені інше розповідаєте? o_O

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 23:21

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

Коли я кажу про інтелект (Reasoning) у агентів — я маю на увазі здатність динамічно будувати ланцюжки дій для вирішення задачі. Це Vertical AI (вузькоспрямований ШІ).
В цьому вузькому сенсі вони мають інтелект, але глобально — це все ще інструмент (руки).

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

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 23:08
Тут ви сперечаєтесь не зі мною, а з ринковою статистикою останніх 10 років

Правда? Давайте джерело даних.

Феномен успіху TikTok, Netflix чи Spotify базується саме на тому, що вони забрали у користувача свободу вибору (яка часто призводить до Analysis Paralysis) і замінили її на жорстку алгоритмічну гіперперсоналізацію.

В чому вона проявляється?

Користувач (масовий) не хоче налаштовувати функціональність, він хоче отримати дофамін/користь за мінімальну кількість кліків.

Давайте ви все ж таки визначитеся, яку позицію займаєте.

Ви спростовуєте твердження, якого я не робив.

Я роблю висновки з ваших слів. Якщо ви кажете, що щось крякає, то я роблю висновок, що ви кажете про качку.

Ви стверджували, що агенти домопожуть в вирішенні питання Goals. В бізнес-середовищі під цим терміном зазвичай розуміють стратегічний рівень. Стратегія — це рівень С (chiefs). Тому я й висловив сумнів, що AI спроможний зараз зазіхати на цей рівень.

Ви плутаєте контур безпеки (Safety Layer) з ядром виконання (Execution Core).

.
Звідки така впевненість? Safety Layer тут до чого?

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 23:24

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

1. Щодо ринкової статистики та «де це проявляється».
Джерело концептуальне: Баррі Шварц, «Парадокс вибору».
Джерело практичне (бізнес-кейси):
— TikTok: Його інтерфейс — це відсутність вибору. Ви не обираєте контент, вам його «згодовують». Алгоритм вирішує за вас, що ви побачите наступним. Це і є жорстка персоналізація. Якби TikTok давав «свободу» і змушував шукати відео вручну — він би не став TikTok-ом.
— Netflix: За їхніми власними звітами, 80% контенту переглядається через рекомендаційні механізми, а не через пошук.
Користувач хоче результат (розвагу), а не процес вибору (свободу налаштувань). Це аксіома UX сучасних платформ.

2. Щодо Goals та «Стратегічного рівня».
Ось тут корінь непорозуміння. Ви інтерпретуєте термін Goal з точки зору MBA (стратегічні цілі бізнесу), я ж використовую його в контексті Agentic AI (інженерія).
У теорії агентів Goal — це цільовий стан системи (наприклад, «знайти квиток дешевше $100» або «зібрати логи за вівторок»).
Це не рівень C-level (стратегія розвитку компанії). Це рівень тактичного виконання.
Сьогоднішні скрипти працюють по Steps (крок 1, крок 2). Агенти працюють по Goals (ось ціль, побудуй план кроків сам).
Тобто: Агент — це не CEO, який вирішує «куди рухатись компанії». Агент — це розумний асистент, якому кажуть «забронюй готель», а він сам вирішує, на який сайт зайти і яку кнопку натиснути. Це автоматизація тактики, а не стратегії.

3. Щодо Safety Layer.
Впевненість — з інженерної практики.
Якщо я огорну виклик `random()` у блок `try-catch`, моя програма стане fail-safe (не впаде), але генерація числа всередині не перестане бути імовірнісною. Вимога «не впасти» не робить внутрішню логіку детермінованою.

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 11.01.2026 11:30

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

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

Чому ми не можемо покладатися на «внутрішню чесність» моделі?
Навіть підходи до Explainable AI, які намагаються пояснити результат через вивантаження внутрішнього стану (weights/activations), часто дають нам просто величезний набір «сирих» даних.
Це ідеальна аналогія з біохімією мозку: спроба зрозуміти, яку думку думає людина через аналіз стану її нейронів. Ви отримаєте терабайти даних про те, як бігають сигнали між синапсами, але скласти це в єдину картину «сенсу» — неможливо.

Крім того, є прагматичний бар’єр:
Найефективніші агенти будуються на SOTA-моделях (Closed Source), і вендори навряд чи дадуть нам доступ до їхніх «нутрощів». А навіть якщо дадуть — жодна базова модель не може містити в собі контекст вашого конкретного бізнес-домену та специфічних обмежень вашого проєкту.

Тому для інженера LLM залишається «Чорною Скринькою». І це нормально.
Це не означає, що такий компонент неможливо використовувати. Якщо звернутися до класифікації систем з «The Book of Why» Джуди Перла (Judea Pearl), нам достатньо знаходитися на другому щаблі «Драбини причинності» (Intervention — втручання), щоб система вважалася контрольованою. Це повністю корелює з Control Theory.

Нам не потрібно розуміти кожен нейрон. Нам потрібно взяти цю відкриту стохастичну систему (Open Loop) і «огорнути» її в Safety Layer, створивши замкнений контур (Closed Loop). Ми додаємо зовнішній фідбек і жорсткі кордони, які «відсікають» галюцинації на виході, а не намагаються виправити їх у «мозку» моделі.
І будувати цей шар треба на рівні кожного конкретного проєкту, бо лише там відомі критерії істини для бізнесу.

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 09.01.2026 21:42
Можемо вважати, скажімо, SSR новою технологією?

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

Можливо, введемо поняття «в широкому» та «у вузькому» сенсі?

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

Бо я на тлі загального захоплення «ШІ» як супер-пупер-нової та революційної технології я схильний казати, що вона не нова, та скоріше еволюційна.

Схожа думка. Бо не технологія революційна, а продукт. Тут беззаперечно.

А в сенсі знаходження підходів до її ефективної утилізації — вона може вважатися новою.

Я приводив вже приклад з фрезером. Продукт створив нову технологію використання. До цього аналогічний результат досягався в рази дорожче.

Відповісти
Підтримати
Олекса Мащиць
Alexander P 09.01.2026 14:57

ну отчего же, архитектура трансформеров — вполне себе инновация, дала путь к построению LLM и всех этих широчайших практических возможностей.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 16:11

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

Відповісти
Підтримати
Alexander P
Олекса Мащиць засновник в QA Україна 09.01.2026 16:21

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 14:34
Традиційні методи, де на кожен сценарій треба прописати чіткий алгоритм, досягли межі ефективності в сучасних масштабах.

Проблема складніша, ніж здається. Сучасний ринок програмного забезпечення попав під каток маркетингу корпорацій. Хайп навколо якоїсь маячні настілький сильний, що він швидко увів фокус в сторону, але найгірше за все — неймовірно здорожчав процес розробки. 15 років тому розпочати роботу над стартапом можна було одразу — сів та пиши. Зараз треба налаштувати оточення, процедуру збірки, деплойменту, тестування та купу іншої хріні, яка необхідна для того, щоб тільки розпочати роботу. Ще жодного рядку коду не написав, а вже втомився. Чи потрібно воно все? В більшості випадків — ні. Але так «заведено», «правильно», так всі роблять, діди так робили, батьки робили, я роблю й онуки мої будуть так робити.

Якщо подивитися на фундаментальні речі, то вони майже не розвиваються, бо панує карго-культ. Ви коли востаннє бачили щось дійсно нове та унікальне (окрім AI) за останні 20 років? Що такого зʼявилося, що стало революційним, проривним, спростило роботу та досягнення цілей? Я нічого не можу пригадати...

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 10.01.2026 04:46

нужно различать AI как технологию, и AI как инструмент производства. нужно ли использовать LLM-based технологии в продукте да, будут решать инженеры. но вот использовать AI в производстве или нет, заверяю, решит рынок и самым безжалостным образом. мне многие ораторы в этом треде напоминают крестьян, которые смотрят на трактор, в испуге крестятся и говорят: «Нееет, бесовская машина! Мы будем пахать, как деды наши пахали — на лошадке, медленно, да зато проверенно. Да и потом, если все на трактор пересядут, то кто через пять лет в конюхи-то пойдет?»
ребята, тренд нарастает, бизнес уже отчетливо осознал перспективы, просто гляньте на капитализацию компаний AI coding ассистентов, чтобы понять как рынок оценивает происходящее. в соседнем топике уже писали, что компании от рекрутеров требуют искать кандидатов, умеющих в AI coding. скоро те, кто старинке руцями расставляет пробелы в своем питоновском коде, станут просто профнепригодны. использование AI агентов в работе очень скоро будет вопросом не желания, а skill isue.

вот, сегодняшняя новость: dou.ua/...​am-and-cursor-partnership

Відповісти
Підтримати
Олекса Мащиць
Donald Trump 10.01.2026 06:17

Додатково, вот статистика як токени перетворюються в комодіті і як росте usage.
openrouter.ai/...​-vs_-closed-source-models

Схожа картина у всіх LLM провайдерів.

Відповісти
Підтримати
Alexander P
Donald Trump 09.01.2026 13:35
а в хайпі, який роздмухують компанії з метою отримання інвестицій.

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

Вот хто можен назвати ще якісь компанії? Такі що:
1. Публічні
2. Говорять про АІ більше ніж використовують
3. Отримують інвестиції
(там «і» між пунктами, не «або»)

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.01.2026 14:24
Із публічних компаній хто на хайпі піднявся завдяки АІ, тільки палантір на думку приходить.

Подивіться сучасні презентації різних компаній, наприклад тих самих Intel, AMD, nVidia, Qualcomm та інших. Там одне суцільне AI, AI, AI, AI, AI...
Хайпують всі...

думаєте що інвестиції ідіоти роздають

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

Відповісти
Підтримати
Donald Trump
Donald Trump 10.01.2026 00:42
Подивіться сучасні презентації різних компаній, наприклад тих самих Intel, AMD, nVidia, Qualcomm та інших. Там одне суцільне AI, AI, AI, AI, AI...

Це не хайп а реальність. Вони створюють високо-дефіцитний продукт, заробляють на цьому великі гроші і не залежать від зовнішніх інвестицій. Тобто з точністю до навпаки до того, що ви написали. Чому вони не мають говорити про АІ?

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

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

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

Вже кілька разів просив тут, но ніхто не може привести. Лише жовті заголовки журналістів повторюють і цитують друг друга, но самі не розбираються в питанні.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 10.01.2026 15:22
Тому попрошу ще раз: приведіть список публічних компаній, які хайпуть на АІ не маючи відношення до АІ чи не використовуючи АІ для підняття маржинальності чи дохідності бізнеса, і яким при цьому інвестори дають гроші, бо почули АІ.

Нові умови підʼїхали... Я не зможу швидко надати перелік, але вони точно є.

Приведіть список публічних компаній, вартість яких виросла на хайпі АІ

OpenAI чим не приклад?

Відповісти
Підтримати
Donald Trump
Donald Trump 11.01.2026 02:58
Нові умови підʼїхали...

Умови ті самі:

1. Публічні
2. Говорять про АІ більше ніж використовують
3. Отримують інвестиції
(там «і» між пунктами, не «або»)
Я не зможу швидко надати перелік, але вони точно є.

Це тому, що ти прочитав кілька жовтих заголовків, кілька коментарів від таких же «експертів» як ти, скрутив це все якось в своїй голові в один вузол, ось і вся твоя аналітика.

OpenAI чим не приклад?

1. Приватна компанія.
2. Вони створюють АІ, всі їх продукти навколо АІ, а не просто балаболять і хайпують. Це як критикувати епл за те, що говорять про смартфони, а амазон — про онлайн магазини.

Тобто задовільняє лише одному пункту із трьох.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 11.01.2026 18:53
Це тому, що ти прочитав кілька жовтих заголовків

Не знаю, не знаю. Чи можна вважати finance.yahoo жовтою пресою?
finance.yahoo.com/...​ocks-smart-113000447.html

Вони створюють АІ, всі їх продукти навколо АІ, а не просто балаболять і хайпують.

Створювати щось не значить не брати участі в роздмухуванні бульбашки. Вони глибоко дотаційні, не герерують достатнього кешфлоу щоб бути повністю на самозабезпеченні, їх вартість побудована на очікуванні їхнього зростання. Як тільки бульбашка AI лопне, то OpenAI може вмерти. Куплять їх потім за безцінь майки, та всі забудуть, що такі існували колись.

Відповісти
Підтримати
Donald Trump
Alexander P 11.01.2026 21:38
Не знаю, не знаю. Чи можна вважати finance.yahoo жовтою пресою?
finance.yahoo.com/...​ocks-smart-113000447.html

ты вообще читаешь сам ссылки, которые ты постишь?

во-первых, статья за июль 2024 года. ну это уже традиционно: находим какой-то пыльный отчет и тащим его на ДОУ.

во-вторых, что же там написано? а написано, что Adobe теряет в стоимости из-за того, что

the rapid pace of AI software development could make many Adobe video and photo editing products obsolete. Also, it could severely cut into the company’s customer base. In fact, many potential stock footage customers may be drawn away by AI-generated photos and videos.

И?

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 11.01.2026 22:13
во-вторых, что же там написано? а написано, что Adobe теряет в стоимости из-за того, что

А чому проігнорована та сама Arista, яка з 2024 збільшила вартість акцій в два рази? Чи це не враховується?
Добре, читаємо, що написано про C3.ai

That’s because the company has no profits with which to justify its current price. It is a product of investor speculation.

Я ще раз задам запитання, вважаємо finance.yahoo жовтою пресою чи ні?

Відповісти
Підтримати
Alexander P
Donald Trump 12.01.2026 03:13
А чому проігнорована та сама Arista, яка з 2024 збільшила вартість акцій в два рази? Чи це не враховується?

Можливо тим що чистий прибуток виріс в 1.5 рази?

Добре, читаємо, що написано про C3.ai

Достатньо глянути на історію щоб зрозуміти що вона завжди така була.

ЇЇ капіталізація 2 млрд., ми серйозно обговорюємо такі компанії із-за яких «лусна АІ бульбашка» а разом з нею весь фондовий ринок? Таких компанію в будь-якому секторі хватає.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.01.2026 12:25
Можливо тим що чистий прибуток виріс в 1.5 рази?

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

, ми серйозно обговорюємо такі компанії із-за яких «лусна АІ бульбашка» а разом з нею весь фондовий ринок

А чому ми мусимо їх відкидати?

Відповісти
Підтримати
Donald Trump
Donald Trump 12.01.2026 14:40
Це взагалі нічого не значить. Прибуток може вирости з багатьох причин, наприклад від скорочення витрат при сталому доходові.

Тобто нічого не значить? Вартість компанії не залежить від прибутку компанії? Чого тільки на доу не прочитаєш )

А чому ми мусимо їх відкидати?

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.01.2026 15:50
Вартість компанії не залежить від прибутку компанії?

Прикинь! Вартість — очікування людей, що компанія має цінність. Прибуток, доходність, маржинальність, стабільність — не грають особливої ролі. OpenAI — глибоко збиткова компанія, вартість якої зростає. Раніше таким був Uber. До цього Netflix, й тому подібне.

яка хайпує з 2009 року і якось не виходить інвестицій багато залучати

Тому що намагання заробити на хайпі не дорівнює зароблянню на хайпі. Але зауваження справедливе. Погоджуюсь.

Відповісти
Підтримати
Donald Trump
Donald Trump 13.01.2026 02:29

Яке це має відношення?

Дано:
прибуток компанії виріс в 1.5 рази і продовжує рости (нові датацентри будуються)
вартість компанії виросла в 2 рази

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

Причому ти подав це під соусом, ніби це сама компанія хайпує навколо АІ.

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 14.01.2026 13:25

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

Тут немає конфлікту, є різниця в часовому горизонті:
1. Arista (про яку каже Donald Trump) — це виробник інфраструктури («продавець лопат»). Вони заробляють тут і зараз, тому їхня оцінка прив’язана до поточного прибутку.
2. OpenAI та інші розробники моделей (про яких каже Олександр) — це R&D-бізнеси на стадії агресивного росту. Вони спалюють інвестиції, щоб створити ринок, якого ще не існує. Їхня оцінка — це віра інвесторів у майбутній Cash Flow.

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

Відповісти
Підтримати
Donald Trump
Олександр Шпак Oarsman в Self Employed 14.01.2026 16:37
прибуток компанії виріс в 1.5 рази і продовжує рости (нові датацентри будуються)

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

Но ні, на твою думку вартість вирсла не із-за прибутку

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

Причому ти подав це під соусом, ніби це сама компанія хайпує навколо АІ.

Так, хайпує. Щоб збільшити власну вартість. Зіграти на очікуваннях. Фізично компанія не зможе швидко вирости, навіть в два рази, тому залишається тільки хайпувати.

Відповісти
Підтримати
Donald Trump
Donald Trump 12.01.2026 02:45

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

1. yahoo це агрегатор, він не пише сттаті, в даному випадку це посилання на якусь рандому ресьорч конторку яких тисячі

2. да, це жовта стаття так як компанії, які там згаданні, на АІ ніколи і не хайпували, єдина яке має пряме відношення до AI (C3.ai) була заснована в 2009 задовго до AI «бульбашки» і ти про неї навіть ніколи не чув, взагалі крім Adobe із тих компаній мабуть нікого не знаєш.

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

4. Тільки ANET із списку виросла в 3 рази за останні 4 роки, но і їх прибуток за ці 4 роки виріс в 2.5 рази. Тобто це органічний ріст а не якийсь приписаний «АІ хайп». Adobe дешево і я би сказав смачно зараз виглядає, їх прибуток продовжує рости не дивлячись на АІ, акції падають. C3.ai взагалі риє дно.

5. Жодна із трьох компаній не отримали ніяких суттєвих інвестицій про які б всі говорили

6. Їх загальна капіталізація 300 млрд. що ніщо, це в 15 раз менше капіталізації однієї nvidia. Якщо вони зникнуть, маркет навіть не помітить.

І т.д. і т.п. мені достатньо було 10 хв щоб зібрати інформацію і написати коментар.

TL;DR Ти привів чужу статтю про 3 компанії, 2 з яких ноу нейм або відомві в вузькому колі і впливу на ринок не мають, одна з капіталізацією 2 млрд, 0.5 компаній з яких хайпують на АІ, жодна із яких не показала росту на АІ наративі. А тебе послухати, так половина компаній із S&P500 хайпують і роздуваються до рівня бульбашки яка ось-ось лусне.

Відповісти
Підтримати
Олександр Шпак
Vitalii Oborskyi PMO&Delivery Head в Developex 12.01.2026 09:39

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

1. Щодо «збитковості» та «хайпу»
Ви праві: бізнес-моделі навколо чистого ШІ (особливо у розробників LLM) зараз глибоко дотаційні. CapEx (капітальні витрати) на залізо та енергію значно перевищують поточний виторг. Якщо дивитися на це як на зрілий бізнес — це виглядає як бульбашка.

2. Щодо «віри інвесторів»
Але ринок оцінює не поточний кешфлоу, а потенціал. Ми зараз у фазі глобального R&D. Технологія фактично ще не імплементована. Чат-боти та копайлоти — це лише 1% від реальних сценаріїв (як «demo-версія» майбутнього).

Аналогія з нафтою:
Уявіть компанію, яка має геологічні дані про величезні поклади нафти. Вона витрачає мільярди на буріння (R&D/GPU), але нафти поки що видобула на копійки.
— Чи це «спекуляція»? Так, бо нафта може не піти.
— Чи це «обман»? Ні, бо геологія (технологія) реальна.

Ми зараз саме в цій точці. Це водночас і бульбашка (бо хтось точно прогорить, не «добуривши»), і реальна технологічна революція для тих, хто знайде правильне застосування.

Відповісти
Підтримати
Donald Trump
Vitalii Oborskyi PMO&Delivery Head в Developex 12.01.2026 09:56

І на вашому прикладі, і в тому, що описано вище, ми бачимо різні патерни ринкової поведінки гравців та інвесторів.

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

Поведінка інвесторів та їхні публічні коментарі теж поляризувались:
1. Одні готові інвестувати тільки тоді, коли «нафта вже піде» і бізнес-модель буде стабільною. Вони називають поточний стан бульбашкою.
2. Інші готові інвестувати в перспективу.

Що буде далі?
Значна частина тих, хто готовий інвестувати в перспективу — прогорить. Але ті, хто робить це серйозно, розумно оцінюючи ризики, — не просто зароблять, а створять нові ринки, на яких домінуватимуть.

Обережні ж інвестори, які не хочуть застрибувати на «хайп-трейн», з одного боку діють безпечно сьогодні. Але завтра вони ризикують втратити свої ринки та бізнеси, якщо технологія зайде в їхню нішу, а вони опиняться у хвості.

Цікаві часи.

Відповісти
Підтримати
Vitalii Oborskyi
Олександр Шпак Oarsman в Self Employed 12.01.2026 12:54
1. yahoo це агрегатор, він не пише сттаті, в даному випадку це посилання на якусь рандому ресьорч конторку яких тисячі

То агрегатор не мусить мати репутації? Я ж не просто так задавав запитання, чи вважає пан саме цей ресурс жовтою пресою чи ні. Це про довіру джерелу.

2. да, це жовта стаття так як компанії, які там згаданні,

За якими критеріями було визначено жовтізну статті? Тому що вона тобі персонально не подобається? Жовта преса зазвичай другує плітки, чутки, напівправдиву або відверто брехливу інформацію. То що з наведеного в статті підпадає під це?

3. Adobe взагалі гарний приклад, це компанія яку АІ навпаки убиває і яка крутиться і намагається вбудувати генеративний АІ в свої продукти щоб народ не уходив

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

5. Жодна із трьох компаній не отримали ніяких суттєвих інвестицій про які б всі говорили

Це не той тип компаній.

6. Їх загальна капіталізація 300 млрд. що ніщо, це в 15 раз менше капіталізації однієї nvidia. Якщо вони зникнуть, маркет навіть не помітить.

Помітять, бо капіталізація nVidia зараз більше бульбашкова, ніж реальна.

Відповісти
Підтримати
Donald Trump
Donald Trump 12.01.2026 14:58
За якими критеріями було визначено жовтізну статті? Тому що вона тобі персонально не подобається?

Тому що зміст не відповідає голосному заголовку

Від того, що в Фотошопі зʼявиться якась функція генерації картинок за допомогою штучного інтелекту, сам продукт не стане іншим.

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

Помітять, бо капіталізація nVidia зараз більше бульбашкова, ніж реальна.

Ти продовжуєш наступати на ті самі граблі. Ти же вже експерт по yahoo finance, потикай таби в профайлі компанії, подивися фінанси nvidia а потім вже розказуй про бульбашку.

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

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 13.01.2026 13:27
Тому що зміст не відповідає голосному заголовку

Наче нема протиріччя...

Лол шо?

Лол те. Фотошоп набагато складніший та багатофункціональніший, ніж примітивні операції по генерації картинок.

Ріст капіталізації відповідає росту прибутку,

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

Відповісти
Підтримати
Donald Trump
Андрій Сторожук python developer 08.01.2026 20:11

дякую за статтю, проблеми описані дуже добре, і я абсолютно згоден з ними!

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

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

Відповісти
Підтримати
Vitalii Oborskyi PMO&Delivery Head в Developex 08.01.2026 20:29

Дуже тверезе бачення.
Навколо ШІ сьогодні справді багато шуму, бо ми все ще знаходимося на піку Gartner Hype Cycle. Історія повторюється: так було з доткомами. Пузир неминуче лусне, і на узбіччі залишаться 90% інвесторів, які гналися за хайпом.
Але є і хороша новина: ті 10%, що виживуть (як це сталося з Інтернетом), стануть фундаментом нового світу. Інтернет теж спочатку вважали іграшкою, а тепер це кровоносна система економіки. Я думаю, ШІ чекає такий самий шлях, але не сьогодні і точно не в форматі «чарівної палички».

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

Тому я вірю, що ключ не в очікуванні дива, а в створенні нового операційного середовища для цих інструментів.
Мене зараз цікавить концепція «поведінкового софту» (Behavioral Software). Це зміна парадигми: від додатків, де ви клікаєте кнопки, до агентів, які діють автономно.
Уявіть, що ви кажете: «Хочу у відпустку в Париж». А система — це не просто пошуковик квитків. Це агент, який знає ваші смаки, сам бронює логістику, готелі, і головне — динамічно реагує на зміни. Якщо в Парижі страйк чи затор, він сам переплановує маршрут і пропонує: «Замість музею А їдемо в парк Б, таксі вже чекає».

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

Відповісти
Підтримати
Андрій Сторожук
Андрій Сторожук python developer 08.01.2026 20:47

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&Delivery Head в Developex 09.01.2026 00:09

Ви зачепили самий корінь проблеми — довіра.
Сьогодні ми хочемо самі вибирати готелі, тому що ціна помилки висока (зіпсована відпустка), а довіра до «чорної скриньки» ШІ — нульова. Розробники самі бояться викатувати такі продукти на мас-маркет, бо розуміють: серія галюцинацій при масштабуванні — це гарантовані судові позови, які поховають бізнес.
Але моя теза в тому, що це зміниться, як тільки з’явиться інженерна гарантія.
Уявіть сервіс, де ви платите $10 за підписку, але в смарт-контракт вшитий SLA (Service Level Agreement): «Якщо агент помилився і готель не відповідає критеріям, ми повертаємо х10 від вартості туру».
Чи погодились би ви віддати контроль за таких умов? Більшість — так. Скепсис зникає, коли ризики фінансово застраховані.
Але щоб бізнес міг дати таку гарантію і не збанкрутувати, йому треба математично довести надійність агента. Йому треба знати, що ймовірність помилки <0.01%.
Саме тому я займаюся архітектурою надійності (Uncertainty Architecture). Ми маємо навчитися вимірювати і обмежувати ризики, щоб перейти від «іграшки» до фінансово відповідального продукту. 20 років тому вводити номер кредитки на сайті теж здавалося божевіллям, але надійні протоколи безпеки змінили світ. Тут буде так само.

Відповісти
Підтримати
Андрій Сторожук
Donald Trump 09.01.2026 06:59

Тут діло в банальному нерозумінні ШІ.

Для когось, більшість в цьому топіку, ШІ — це LLM і чатик типу chatgpt (чи аналогічний від клода і gemini). Вони толком більше нічого не знають і не пробували. Що дратує, що ці люди вбили собі в голову (і ти також) що всі, хто хайпить за ШІ, вони хайплять саме за такий сценарій користування, який, звісно, багато скілів не вимагає но і не працює в інженерії так, як потрібно.

Що насправді таке сучасий ШІ і за яким стоїть хайп в «певної частки людей»? Це: agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering.

Ті, хто хоча б на половину це пробували і конфігили, хто має парочку підписок, пробували зараз а не пів року назад, і уж тим більше не рік назад коли нічого цього не було, пробували моделі типу opus 4.5 (бажанно саме в claude code), gpt-5-codex (бажанно в codex cli), у них сумнівів немає що він «класний і корисний», питання лише в скілах. Я не знаю жодної людини, які купили підписки за 20$, і потім сказали що нє, фігня, не працює, і відмінили. Зате знаю багато які купили додаткові підписки, чи апгрейднулися на підписки 100 баксів в місяць, парочка взагалі на 200 баксів.

Раджу почитати оригінальний твіт Карпати (цитата звідти):
x.com/...​tatus/2004607146781278521

Відповісти
Підтримати
Андрій Сторожук
Андрій Сторожук python developer 09.01.2026 15:34

як власне я і написав — прибіжать адепти «ШІ може все» і почнуть з піною у рота доводити що це панацея від всіх болячок )

ну що ж розкладемо по поличках:

Для когось, більшість в цьому топіку, ШІ — це LLM і чатик типу chatgpt
Що дратує, що ці люди вбили собі в голову (і ти також) що всі, хто хайпить за ШІ, вони хайплять саме за такий сценарій користування

Для багатьох «хайперів» (і для тебе також) LLM — це і є ШІ. Але літера «І» в цій абревіатурі означає «Інтелект». А інтелект передбачає розуміння своїх дій та здатність їх пояснити. Наразі ж «інтелектом» тут і не пахне — як не годуй модель сторонніми інструментами чи RAG. Це все ще генератор тексту, навчений на гігантській базі знань, який видає «середнє по палаті».

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

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

Я не знаю жодної людини, які купили підписки за 20$, і потім сказали що нє, фігня, не працює, і відмінили

тепер знаєте :D

Я працюю з API OpenAI понад 1.5 роки. Моя компанія надає доступ до будь-яких моделей (в тому числі останніх моделей Anthropic), у половини девів у нас є Cursor (я особисто користуюсь Pycharm але там теж є плагіни з підключенням АПІ). Пробував і codex, є підключені MCP, тестую час від часу все про що кричать на кожному кроці, треба ж йти в ногу з часом.

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

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

Кажучи про те що автор не експерт, я не хочу нікого образити, бо коли мені треба було написати деякий код на Rust, який я перший раз в житті побачив, чи для свого pet-проекту доводиться вчити і писати C#, то я теж використовую coding-assistant і у мене теж це відчуття — як класно, воно все зробило за мене.

Але коли я прошу зробити задачу в моїй експертній області і на моєму проекті який я знаю як свої 5 пальців, то я бачу або — «Боже, що воно несе», або те що задача зроблена на 50%, і розумію що той код що воно сгенерувало мені для С# і Rust скоріше за все теж гівно «але ж працює»... до моменту поки технічний борг не стане таким що доведеться або кликати спеціаліста, або самому ним ставати)

Відповісти
Підтримати
Donald Trump
Donald Trump 10.01.2026 01:27
Для багатьох «хайперів» (і для тебе також) LLM — це і є ШІ. Але літера «І» в цій абревіатурі означає «Інтелект». А інтелект передбачає розуміння своїх дій та здатність їх пояснити. Наразі ж «інтелектом» тут і не пахне — як не годуй модель сторонніми інструментами чи RAG. Це все ще генератор тексту, навчений на гігантській базі знань, який видає «середнє по палаті».

По-моєму очевидно що використовують термін «АІ» для масс, для спрощення. Но ні, у деяких все-одно пригорає навіть в 2026.

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

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

Зате я бачив багато людей і журналістів, які хайпують на ШІ, починаючи статті в стилі: «Всі розказують як ШІ замінює людей, повністю беручи на себе їх роботу, і зараз я вам розкажу як все насправді». Тобто придумуємо якийсь міф, а потім, надіваючи окуляри, розвінчуємо його, щоб почесати своє ЧСВ і показатися розумним )

Прямо як техно-ютюбери, які, називають своє відео: «Ніхто не розказує про цю проблему в {якийсь хайповий продукт}?». Бля, да всі про неї розказують мало не першим пунктом.

Придумуємо міф — хайпуємо на ньому.

Відповісти
Підтримати
Андрій Сторожук
Donald Trump 09.01.2026 07:54
Можливо я занадто молодий для того щоб пам’ятати розмови того часу — але я щось не можу пригадати щоб мене змушували користуватись комп’ютером коли він зв’явився, або інтернетом, чи потім телефоном і т.д. по списку.

Було, все це вимагало значно більше часу до адопшину і прийняття масами

Може тому що якщо річ крута і дійсно корисна то люди самі почнуть цим користуватись?

TL;DR поріг входу високий

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

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

Відповісти
Підтримати
Андрій Сторожук
джаваскрипт энджоер 08.01.2026 18:49

блин, с этими статьями про ии то одни рассказывают, что ии на авто аксепте всех заменит, то другие рассказывают, что наборот использовании ии только тормозит разработку

и вот я посреди этого не понимаю: с одной стороны я вижу что эта тулза без меня не работает, с другой — вижу что я делаю работу лучше используя эту тулзу.

но при этом аналитики с обеих сторон говорят, что это все не так и я не прав. как такое вообще возможно?

Відповісти
Підтримати
Alexander P 08.01.2026 18:52
как такое вообще возможно?

дождись какого-то индустриального отчета, выжди год, чтобы выводы настоялись, а затем ты узнаешь, что твой опыт ставит под угрозу целую индустрию :)

Відповісти
Підтримати
джаваскрипт энджоер
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 19:24

Олександре, оцінив гумор :)
Але давайте без перекручувань: я нікого не звинувачую в «руйнуванні індустрії» персонально.

Тут насправді немає конфлікту між вашим досвідом і даними.
Щодо звіту METR (metr.org/...​experienced-os-dev-study) — він і справді поки що точковий. Може там є похибка, хто знає.
На індивідуальному рівні людина здатна зайти дуже глибоко в створення своїх власних флоу та автоматизацій, і разом з прогресом самого ШІ це дійсно може дати суттєвий прогрес конкретному інженеру.

Тож я ваш досвід під сумнів не ставлю.
Але ж стаття — про великий бізнес та індустрію, а не про нас з вами особисто. Звіти показують проблеми саме масштабування (макро-рівень).

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

Відповісти
Підтримати
Alexander P
джаваскрипт энджоер 08.01.2026 22:00

возможно это просто эволюция маркетинга
сначала продавали просто «всего за xxx вам откроется вся магия ии»
теперь продают «истинную магию ии открыть тяжело, но всего за ххх я вам ее открою»

Відповісти
Підтримати
Alexander P
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 11:03

Щоб уникнути спекуляцій про «старі дані» та міфів про те, що «в кінці 2025 року агенти все виправили», пропоную звернутися до сухої статистики.

Ось звіт GitClear за 4-й квартал 2025 року (дані включають період активного використання агентних моделей):
www.gitclear.com/...​_output_from_2022_to_2025

Аналітика показує, що ситуація з появою агентів не покращилася, а навпаки — тренд на генерацію «цифрового сміття» посилився.

1. Падіння реальної доставки (Delivery Metrics).
Попри те, що писати код стало легше, метрики успішної доставки (Deploy Frequency успішних фіч без хотфіксів) демонструють стагнацію або падіння.
Причина в диспропорції: кількість доданих рядків коду (Lines of Code Added) зросла на 131%, тоді як кількість змістовних операцій (Commits/Tasks Completed) зросла всього на 6%.
Тобто ми генеруємо в 2 рази більше тексту, щоб отримати той самий бізнес-результат. Це призводить до забивання каналів Code Review і сповільнення Cycle Time.

2. Code Churn б’є рекорди.
Показник «плинності коду» (код, який був написаний, а потім змінений або видалений протягом 2 тижнів) сягнув історичного максимуму.
Це прямий доказ того, що агенти часто генерують «правдоподібне, але невірне» рішення. Розробники витрачають час не на створення, а на виправлення того, що згенерував ШІ. Це не прискорення, це створення роботи заради роботи.

3. Структурна деградація.
Вперше зафіксовано, що частка «Copy/pasted» коду перевищила частку «Moved/reused».
Агенти не вміють ефективно перевикористовувати існуючу архітектуру, вони схильні дублювати логіку. Це роздуває кодову базу (Bloatware), роблячи її підтримку експоненціально дорожчою.

Висновок: Індустрія у 2025 році потрапила в пастку: ми інвестуємо в інструменти, які збільшують OPEX (вартість підтримки та виправлення помилок) в рази, даючи при цьому мізерний приріст реальної цінності. Це не зростання продуктивності, це інфляція коду.

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 12:16

Тепер накладіть ці цифри (131% росту коду при 6% росту результату) на популярну стратегію: «Звільнимо джунів/мідлів, залишимо сеньйорів з ШІ».

Для серйозної компанії (не стартапу на 5 людей, де код можна переписати за вихідні) це гарантований шлях до катастрофи за трьома напрямками:

1. Операційний колапс (Bottleneck effect).
Сеньйори — це найдорожчий ресурс, чия цінність в архітектурних рішеннях та стратегії. Ця стратегія перетворює їх на «AI-прибиральників».
Оскільки обсяг згенерованого «сміттєвого» коду виріс удвічі, а мідлів, які раніше фільтрували прості задачі, звільнили — сеньйор опиняється під завалом Code Review. Він перестає думати про розвиток системи і займається виключно розгрібанням ентропії. Це призводить до вигорання і звільнення ключових експертів.

2. Інституційна лоботомія.
ШІ знає синтаксис, сеньйор знає архітектуру, але саме Middle-розробник зазвичай є носієм контексту бізнес-логіки та деталей реалізації («чому ми зробили цю милицю 2 роки тому»).
Звільняючи цей прошарок, компанія втрачає «м’язову пам’ять» продукту. ШІ не може відновити цей контекст, бо він не був задокументований ідеально. Як наслідок — будь-яка зміна в легасі стає ризикованою авантюрою.

3. Знищення ланцюга постачання (Supply Chain Suicide).
Це удар по індустрії. Junior стає Middle, Middle стає Senior. Це цикл дозрівання експертизи, який займає 5–7 років.
Якщо індустрія масово перекриває «вхід» і вирізає «середину» заради короткострокової економії P&L, то у 2030 році ми отримаємо вакуум. Сеньйорів просто фізично не буде, бо їм нізвідки взятися. Це призведе до шаленої інфляції зарплат решти експертів і зробить український IT-сектор неконкурентним на глобальному ринку через ціну.

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

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 08.01.2026 12:16
Щоб уникнути спекуляцій про «старі дані» та міфів про те, що «в кінці 2025 року агенти все виправили», пропоную звернутися до сухої статистики.

Ось звіт GitClear зат 4-й квартал 2025 року (дані включають період активного використання агентних моделей):

Почитайте уважніше статтю а не копіпастіть бездумно з чату гпт.

final year is measured as «the final 365 days from when the data was measured,» which was October 2025.

Тобто 2025 рік це з 1.10.2024 по 1.10.2025.

І там чітко написано, що навіть протягом цього часу, 15% девелоперів підвищили свою продуктивність в 2 рази. А скільки з тих решти 85% ще не використовує АІ?

But the 85th percentile developer authored 2x as much work this year than in the final pre-AI year.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 12:25

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

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

2. Щодо «top 15% authored 2x as much work».
Ви плутаєте Volume (обсяг) з Value (цінністю).
Фраза «authored 2x as much work» у контексті GitClear корелює з метрикою Lines of Code Added.
Так, топ-перформери згенерували в 2 рази більше тексту. Це факт.
Але подивіться на іншу метрику з того ж звіту: Code Churn (плинність/переробка цього коду) також зріс до історичних максимумів.

Висновок:
Те, що топ-розробники почали писати у 2 рази більше коду завдяки агентам, не означає, що вони стали у 2 рази ефективнішими для бізнесу. Це означає, що вони роздули кодову базу (Bloatware) у 2 рази швидше.
Якщо ви генеруєте більше коду, який потім вимагає більше підтримки (Churn), ви не підвищуєте продуктивність — ви прискорюєте генерацію технічного боргу. Саме про цю «Ілюзію ефективності» я і пишу. Не плутайте швидкість набору тексту з вирішенням бізнес-задач.

Відповісти
Підтримати
Просто Анон
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 12:32

Мушу визнати: я помилявся, коли раніше погодився з тезою, що «хоча б сеньйори стали продуктивнішими». Після додаткової перевірки та крос-аналізу даних виявилося, що навіть це твердження є хибним.
Ось звіт METR (Model Evaluation & Threat Research), опублікований у липні 2025 року. Це «Золотий стандарт» дослідження: рандомізоване контрольоване випробування (RCT).
Посилання: metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
Умови були ідеальні для успіху ШІ:
1. Еліта: Досвідчені мейнтейнери великих Open Source проєктів (1M+ рядків коду). Ставка участі — 150 доларів за годину.
2. Контекст: Вони працювали над власними репозиторіями (тобто знали код ідеально).
3. Інструменти: Використовували топовий стек 2025 року (Cursor Pro + Claude 3.5/3.7 Sonnet).
Результати шокують:
1. Реальний результат: Уповільнення на 19%. Коли цим експертам дозволяли використовувати AI-агентів, вони виконували задачі на 19% довше, ніж без них. ШІ не прискорив, а загальмував роботу навіть в умовах ідеального знання кодової бази.
2. Розрив сприйняття (Perception Gap). Найцікавіше: самі розробники вірили, що ШІ їх прискорив на 20%. Відчуття «потоку» створило ілюзію ефективності, хоча таймер показав протилежне.
Висновок:
Це ідеально корелює зі звітом GitClear. Сеньйори генерують удвічі більше коду («authored 2x work»), відчувають, що летять, але по факту витрачають на 19% більше часу, щоб розгребти згенероване і закрити задачу. Тому стратегія «залишити тільки сеньйорів з ШІ» — це самообман. Ви отримуєте команду, яка коштує дорого, працює повільніше (хоча впевнена у зворотному) і генерує подвійний обсяг легасі.

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 08.01.2026 13:08

я помню эту бумагу, ее в коммьюнити подробно разобрали еще летом, когда она появилась. вы, Виталий, по прежнему отстаете в своих данных))
смысл в том, что исследование достаточно однобокое, что признают и сами его участники. я не поленился, нашел в своих закладках тред чувака, который участвовал в исследовании x.com/...​tatus/1943948791775998069
он пишет, что лично у него AI ускорил на 38%, что одна из причин замедления работы у других в том, что новым воркфло нужно банально учиться (что вам тут не устают объяснять другие, в том числе и я). было много дискуссий вокруг этого репорта, просто уже полгода прошло, вы извлекли то, что другие уже давно проехали. вы не анализируете тренды, вы копаетесь в архивах, подыскивая аргументы под свои убеждения.

P.S. честно говоря, такое ощущение, что постоянно отвечаю боту. попробуйте ради разнообразия не пропускать свои ответы через ChatGPT.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 13:20

Олександре, давайте серйозно. Ви намагаєтесь спростувати результати RCT (рандомізованого контрольованого дослідження) посиланням на твіт однієї людини?

1. «Помилка того, хто вижив» у прямому ефірі.
Те, що ви знайшли учасника, який стверджує про приріст у 38% — це чудово. Але це називається анекдотичним доказом. У будь-якій статистичній вибірці завжди є відхилення (outliers). Наука робить висновки на базі середнього значення по групі, а не на базі «одного чувака з твіттера».
Ба більше, цей приклад ідеально ілюструє головний висновок дослідження — **Perception Gap**. Дослідження показало, що розробники *відчували* себе швидшими на 20%, навіть коли були повільнішими. Ваше посилання лише підтверджує, що ілюзія працює бездоганно: людина впевнена, що вона прискорилась. Але чи був у неї секундомір і контрольна група для самої себе, щоб це об’єктивно підтвердити? Сумніваюсь.

2. Тренди, а не архіви.
Ви закидаєте мені «копання в архівах» (липень 2025), але ігноруєте те, що ці дані ідеально корелюють зі свіжим звітом GitClear за 4 квартал 2025.
Картина цілісна: METR пояснює механіку (чому сеньйори гальмують), а GitClear показує масштаб наслідків (чому індустрія тоне в коді). Це не вибіркові факти, це узгоджені дані з різних джерел.

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

P.S. Щодо бота — сприйму це як комплімент моїй структурованості. Але, на жаль, сухі факти часто звучать механічно, на відміну від емоційних історій.

Відповісти
Підтримати
Alexander P
Alexander P 08.01.2026 13:31
цифрами на вибірці хоча б у 100 людей

вы только что выложили как доказательство бумагу, построенную на опросе 16 (!!!) людей, а от меня требуете хотя бы 100?))

To directly measure the real-world impact of AI tools on software development, we recruited 16 experienced developers
Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 13:37

Приймається. Ви праві, у звіті METR вибірка — 16 експертів.
Але давайте подивимось на повну картину доказової бази, яку я вам надав. Вона складається з двох частин, що взаємно підтверджують одна одну:

1. Макро-рівень (GitClear).
Вибірка: 200+ мільйонів рядків коду.
Період: 4 роки аналізу.
Що показує: Глобальний тренд по індустрії — вибухове зростання Code Churn (+131%) і стагнація реальної продуктивності.
Це і є ті самі «великі дані», які ви просили. Вони показують *наслідок*.

2. Мікро-рівень (METR).
Вибірка: 16 топових експертів (RCT).
Що показує: Механіку процесу. Чому саме падає продуктивність? Бо на виправлення та перевірку йде на 19% більше часу.
Такі дослідження (RCT) ніколи не проводяться на тисячах людей через складність і вартість. Але вони дають розуміння *причини*.

Висновок:
У мене:
— Масив Big Data на 200 млн рядків (статистична значущість).
— Контрольований науковий експеримент, який пояснює аномалії в цих даних.
І обидва джерела незалежно одне від одного показують одну й ту саму картину: ілюзія швидкості призводить до реальних втрат часу.

У вас:
— Один твіт.

Тож моє питання залишається актуальним: чи є у вас хоч один індустріальний звіт (а не думка в соцмережах), який спростовує дані GitClear?

Відповісти
Підтримати
Alexander P
Alexander P 08.01.2026 13:50

у меня есть самое главное — личный практический опыт, который кореллирует с опытом множества других. и разумное объяснение, почему выводы мои и других не совпадают (или только частично) с приведенными отчетама/иссследованиями.

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

проблема в том, что с вашим подходом вам придется дождаться, когда компании массово внедрят у себя новые технологии, сформируется новая статистика, по ней напишут отчеты, а вы их через год откроете для себя. безнадежно отставшим.

идти по проторенной дороге еще означает плестись в хвосте у всех. вот вам свежая мысль, подумайте за чашкой кофе))

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 14:17

Олександре, ви знову боретеся з «солом’яним опудалом».

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

1. Щодо «спробувати в пісочниці».
Те, що ви описали (гіпотеза -> пілот -> заміри -> масштабування) — це не «свіжа думка за кавою», це стандартний операційний цикл моєї щоденної роботи.
Але я реаліст. Не варто думати, що ми з вами найрозумніші, а решта ринку просто «не здогадалася» спробувати. Тисячі компаній роблять саме такі пілоти. І, судячи зі статистики (GitClear, METR), на рівні масштабування вони провалюються. Це системна проблема, яку не вирішити просто «ентузіазмом».

2. Щодо «плентатись у хвості».
Якраз тому, що я бачу цей глухий кут, я не чекаю звітів, а дію на випередження.
Зараз я працюю над Open Source проєктом («Uncertainty Architecture»), мета якого — створити методологію для успішного створення саме агентських систем.
Я не просто «читаю звіти», я валідую ці концепції на рівні інженерів Кремнієвої долини, академічної спільноти (Стенфорд) та експертів PMI.

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

Відповісти
Підтримати
Alexander P
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 15:15

Чому я обрав саме Open Source шлях, а не локальну «пісочницю», яку ви пропонуєте?

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

Перевірити це в «тепличних умовах» своєї компанії неможливо — це дасть лише локальний результат, обтяжений упередженням автора (confirmation bias).
Тому я пішов шляхом «відкритої архітектури»: спочатку валідація концепцій з експертами, а далі — публічний тест рандомними командами з різним контекстом. Це найчесніший спосіб перевірити, чи працює операційна модель насправді, чи це просто черговий «успішний пет-проект», який неможливо масштабувати.

Відповісти
Підтримати
Vitalii Oborskyi
джаваскрипт энджоер 08.01.2026 22:05

интересно на какой дистанции мерялась продуктивность?
потому что у меня есть дни, когда я просто не пишу код. не потому что я занят чем-то другим, а потому что... ну вот так вот (условно накапливается когнитивная нагрузка, которую надо сбросить)

и вот раньше в такие дни я просто не делал ничего. теперь я пописываю себе промптики для простых задач и потихоньку что-то даже двигается

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 09.01.2026 00:36

Дуже влучне спостереження про «розвантажувальні дні». Ви інтуїтивно намацали те, що в системній інженерії є критичним параметром.

Якщо ви питаєте про мої тези зі статті, то я розглядаю когнітивне навантаження (Cognitive Load) не просто як «втому в кінці дня», а як модельований інженерний показник.

Це цікава історія: спочатку я «винайшов велосипед» — розробив модель розрахунку навантаження для своїх команд, щоб прогнозувати ефективність (детальніше розбирав це тут: www.linkedin.com/...​urney-from-oborsky-j4r0f ).
А вже потім, копаючи глибше, з’ясував, що в цивільному менеджменті (PMI, MBA) це дійсно «біла пляма». Цивільний менеджмент методологічно завмер десь у 70-х роках, після останнього сплеску кібернетики (той самий Стаффорд Бір і «Brain of the Firm»).

Але там, де ставки вищі за гроші — у військовій сфері — ця наука не зупинялася. Пентагон та НАТО використовують моделювання когнітивного навантаження (Cognitive Load Index) при плануванні операцій, бо в умовах хаосу війни перевантажений офіцер — це гарантована помилка.

Тож ви праві: використання ШІ в «дні низького ресурсу» для підтримки мінімального руху — це, по суті, грамотний особистий менеджмент когнітивного навантаження. Ви використовуєте «екзоскелет», щоб рухатись, коли власні «м’язи» втомилися. Проблема виникає лише тоді, коли бізнес думає, що в цьому екзоскелеті можна бігати марафон 24/7 без відпочинку.

Відповісти
Підтримати
джаваскрипт энджоер
NoName 11.01.2026 00:41

нада быть детски наивным что бы верить в эффективные методы считания продуктивности девелоперов. Единственный метод который я видел — это покер, обсуждение таски и попадание девелопера в этот эстимейт. Все остальные вещи типа — миллионы коммитов, миллионы добавленных строк, тысячи закрытых тикетов — это невозможно считать. Потому что потом оказывается что коммиты по 10 строк, добавленные строки это какие то дампы логов на 20к строк и тикеты закрываются с пометкой обсолит. Я пользуюсь агентами почти каждый день, и сравнивая с автодополнением от интеллиЖ я не вижу особой продуктиваности, а вот свое жалание порефакторить этот большой клас или попросить агента — так чаще прошу агента и теряю скиллы как это делать самому. Тоесть моя личная еффективность падает, но моя в паре с агентом растет.

Відповісти
Підтримати
Alexander P
Просто Анон 08.01.2026 17:57
Період з жовтня 2024 по жовтень 2025 — це саме час масового виходу та активного використання AI-агентів та значно «розумніших» моделей.

Лол, пишіть ще

Відповісти
Підтримати
Vitalii Oborskyi
Bohdan Pomazan 12.01.2026 12:22
Агенти не вміють ефективно перевикористовувати існуючу архітектуру, вони схильні дублювати логіку.

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

Ну і звісно повинні бути всі відповідні архитектурні скили + кожен «єпік» повинен завершуватися прогонкою протоколів дедублікації, тестування, сонара і тд.
+ використання спеціалізованих MCP для семантичного та графого пошуку таких як github.com/...​anbohdan/memory-mcp-1file (як раз прорекламую) які єкономлять токени та показують агентам всю кодову базу та залежності без необхідності повного сканування.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 12.01.2026 12:51

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

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

Те, що ви описали — це не просто «впровадження ШІ», це побудова складної інженерної системи. Щоб реалізувати ваш сценарій (субагенти, валідація архітектури, MCP, пайплайни дедублікації), компанії потрібно зробити величезні інвестиції:
1. Інженерна перебудова: Створення тієї самої «обв’язки», про яку ви пишете.
2. Операційна адаптація: Переписати внутрішні стандарти та змінити флоу Code Review.
3. Навчання людей: Команду треба навчити керувати цією системою агентів.

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

Звісно, якщо бізнес-модель вже була збиткова, і ви ріжете «мертві» проекти — це оптимізація. Але взяти прибутковий проект, скоротити хедкаунт і роздати тим, хто лишився, «голі ліцензії» — це не трансформація. Це вбивство успішного активу, бо навантаження зросте, а пропускна здатність (без налаштованої агентної системи, про яку ви кажете) впаде.

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

Відповісти
Підтримати
Bohdan Pomazan
Юра 08.01.2026 09:39

все не осилив.. але ось... стосовно «генерації коду»...

можна запхати в ллм 50 підручників з математики... попросити «видали задачі... залиш тільки інструменти»,

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

ну так... людині все одно треба все це аналізувати...
але це ж мабуть цікавіше, чим читати код...

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 10:08

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

Але стаття — про індустрію в цілому. І тут магія зникає, поступаючись місцем сухій статистиці.
Ось свіжі дані за 4 квартал 2025 року (GitClear): www.gitclear.com/...​_output_from_2022_to_2025

Що ми маємо по індустрії:
1. Ілюзія роботи: Реальна продуктивність (кількість змістовних комітів) зросла всього на 6–9%.
2. Генерація збитків: Кількість доданого коду (Lines Added) виросла на 131%, а Code Churn (код, який треба переписувати або викидати) б’є рекорди.
Тобто глобально індустрія зараз генерує більше технічного боргу, ніж цінності.

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

Що буде далі: Це пастка. Якщо ми сьогодні закриємо вхід у професію і приберемо мідлів, то знищимо ланцюжок відтворення кадрів (Supply Chain). Через 5 років індустрія зіткнеться з тотальним дефіцитом експертів, бо новим сеньйорам просто нізвідки буде взятися. Це стратегія «з’їсти посівне зерно» заради економії сьогодні.

Відповісти
Підтримати
Юра
Юра 08.01.2026 16:09

мені складно уявити причини, щоб людина переживала за «індустрію» ... це як переживати за ввп... і що таке «закриємо вхід у професію» ? 🤔

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 17:24

Все доволі просто — це природна еволюція інтересів.

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

Чому я за це «переживаю»? Це не абстрактна турбота про ВВП, це турбота про екосистему, в якій ми всі працюємо.
Ось приклад: Спільнота С++ зараз веде запеклі баталії про безпеку пам’яті та конкуренцію з Rust. Розробникам С++ за це не доплачують, але вони розуміють: якщо не вирішити цю інженерну проблему на рівні індустрії, мова просто вмре, і їхні знання знеціняться.

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

Відповісти
Підтримати
Юра
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 17:29

І ще в продовження думки про те, що може зробити одна людина.

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

Я не маю ілюзій щодо гарантій. Цей текст може загубитися, а може стати частиною того глобального дискурсу, який змусить хоча б кількох стейкхолдерів переглянути стратегію.
У складних системах зміни відбуваються саме так: через накопичення критичної маси правильних питань у публічному просторі. Тому це спроба докласти зусиль там, де я можу це зробити, навіть без гарантії результату.

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 09.01.2026 01:03
Розробникам С++ за це не доплачують, але вони розуміють: якщо не вирішити цю інженерну проблему на рівні індустрії, мова просто вмре, і їхні знання знеціняться.

на этом месте разработчики на Коболе, Фортране и PL/1 смахнули бы слезу))

бізнес хоче замінити джунів на ШІ. Це означає, що ланцюжок «Junior -> Middle -> Senior» розривається. І через 5 років ми отримаємо шалений дефіцит інженерів, здатних вирішувати складні задачі.

ваша ошибка, Виталий, заключается в убеждении, что не побывав джуном и не потренировавшись на кошечках, то бишь, реальных клиентах, нельзя стать сеньором. вот именно это рынок и поменяет.

по моим наблюдениям, наибольший эффект от AI assisted coding получают именно сеньоры, которые умеют:

— четко описать скоуп задачи и основной флоу
— декомпозировать фичу
— задать пошаговый план
— описать тестовые сценарии
— описать граничные случаи

наконец, они умеют делегировать и оценивать исполнение.

мидлам и тем более, джунам, проще написать код самому — иллюзия контроля.

на самом деле написание кода — это такая простая и рутинная операция, что ее не боятся поручать джунам, которые только-только выучили синтаксис языка и сигнатуры основных функций в библиотеках. почему нужно бояться перепоручить эту задачу AI агенту, который на порядки дешевле — я не понимаю.

да, индустрия поменяется, вкатиться в IT после трехмесячных курсов уже не получится. придется учиться по серьезному, но это даже хорошо на самом деле.

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 07.01.2026 16:40

господи, автор, этот отчет опубликован в январе 2025. прошел целый год стремительных изменений. вы только что расписались в том, что не следите за индустрией и строите выводы на устаревших данных.

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 20:11

Прошу, ось звіт за 4 квартал 2025 року (дані за вересень-жовтень). www.gitclear.com/...​_output_from_2022_to_2025
Тенденція, про яку я писав, не просто збереглася — вона посилилася:

1. Ілюзія продуктивності: Медіанна кількість комітів (реальної роботи) зросла лише на 6–9% порівняно з 2022 роком.

2. Code Churn на стероїдах: Кількість доданих рядків коду (Lines Added) зросла на 131%. При цьому обсяг змістовних змін (Diff Delta) виріс лише на 6%. Тобто ми генеруємо в рази більше тексту, щоб отримати той самий результат.

3. Деградація інженерії: Це перший період в історії, коли «Copy/pasted» код статистично перевищив «Moved/reused».

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

Відповісти
Підтримати
Alexander P
Просто Анон 07.01.2026 20:33

Вас не переконаєш, тому думаю що до вас є смисл йти на роботу)

Берете якщо в людини є ще 1-2 проекти але перформанс буде вище середнього в команді?

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 20:45

Щодо найму — я цим напряму не займаюсь, у нас для цього є рекрутери.

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

А щодо «вас не переконаєш» — тут ви помиляєтесь.
Мене легко переконати, якщо ми говоримо в одній площині.

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

2. Рівень індустрії. Саме тут криється проблема. Окремі історії успіху (як ваша чи моя) не масштабуються автоматично на рівень великих компаній без зміни процесів.

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

Відповісти
Підтримати
Просто Анон
Alexander P 07.01.2026 21:06
Окремі історії успіху (як ваша чи моя) не масштабуються автоматично на рівень великих компаній без зміни процесів.

о чем и речь. эффективность подтверждена, теперь ее нужно масштабировать. совершенно согласен, что для компании теперь это главная задача. «Адаптируйся, или умри»

— просто «ріжучи кости» і ігноруючи наслідки

это частый управленческий прием. принимаем решение, режем косты и дальше адаптируемся. меньше балласт, меньше инертность, условия сознательного кризиса требуют быстрых действий и перехода на новые рельсы.
Маск в свое время уволил половину Твиттера, только ленивый его не пнул — как же так, выгнал того инженера, который написал такой замечательный кусок кода! ну все, пропал Калабуховский дом. но нет, твиттер замечательно живет и стал очень классным и удобным, то, как интегрирован в продукт Грок — это просто образец.
для компании гораздо больше риск когда она в эпоху перемен функцирует с раздутым штатом и неэффективными процессами.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 21:13

Олександре, давайте все ж таки оперувати фактами, а не враженнями про «зручний інтерфейс».

1. Щодо «успішного кейсу» Twitter/X.
Фінансова реальність каже про інше. Інвестиційний фонд Fidelity (один з інвесторів угоди) станом на 2025 рік оцінює вартість X на 72% нижче від ціни покупки. Рекламні доходи впали більш ніж на 50%.
Якщо падіння капіталізації бізнесу на 30+ мільярдів доларів ви називаєте «приймаємо рішення і адаптуємось», то у нас різні уявлення про успішний бізнес. Маск — бізнес-акула з глибоко диверсифікованим портфелем, він може дозволити собі спалити 44 мільярди заради експерименту чи політичного впливу. Звичайна сервісна чи продуктова компанія після такої «шокової терапії» просто припиняє існування.

2. Щодо «інженерного раю» та Маска.
Давайте відверто: Маск — геніальний візіонер, шоумен і опортуніст, але його методи управління токсичні для інженерної культури. Це не секрет, що в SpaceX та Tesla існує прошарок менеджменту, головна задача якого — не пускати Ілона до прямого втручання в інженерні процеси, щоб він не зламав те, що працює.
Повірте, якби ви працювали в режимі «hardcore», який він запровадив у Твіттері — з ночівлями в офісі та звільненнями за «неправильний погляд» під час код-рев’ю — ваш оптимізм швидко б згас.

3. Ризики.
Ви пишете, що «роздутий штат» — це ризик. Згоден. Але «анорексія» організації, коли втрачається експертиза і здатність підтримувати продукт — це гарантована смерть. Twitter вижив за рахунок інерції величезної платформи та мільярдів власника. У 99% компаній на ринку немає ні першого, ні другого. Тому копіювати цю стратегію — це «помилка того, хто вижив» у чистому вигляді.

Відповісти
Підтримати
Alexander P
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 21:23

Щодо тези про «масштабування через скорочення» (різати кости, щоб еволюціонувати).

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

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

У таких випадках посилання на ШІ в прес-релізах — це просто зручне виправдання (excuse) для інвесторів та ринку, спроба прикрити модною темою «інновацій» роки управлінських помилок та роздування штату.
Але правда в тому, що компанії в режимі «виживання» (cost-cutting) вкрай рідко створюють проривні інновації. Інновації народжуються з ресурсу та експериментів, а не зі страху та економії на сірниках.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 21:34

Додам трохи інсайтів щодо «зразкової» інтеграції Grok та ролі Маска.

Ви ідеалізуєте ситуацію. В індустрії (зокрема серед AI-researchers Долини) секрет Полішинеля полягає в тому, що головна задача топ-менеджменту в компаніях Маска (SpaceX, і тепер xAI) — це створення «ізоляційного шару» між Ілоном та інженерами.

1. Успіх SpaceX — це заслуга Гвінн Шотвелл, яка роками фільтрувала імпульсивні рішення Маска, не даючи їм зруйнувати виробничі процеси.
2. Провал Twitter/X (технічний борг, падіння виручки) стався саме тому, що там цей буфер був знищений. Маск напряму втручався в код (історія з вимогою «роздрукувати код на папері» — це хрестоматійний приклад технічної некомпетентності).
3. Щодо xAI (Grok): там працюють вихідці з DeepMind та OpenAI. Це люди, які коштують на ринку мільйони. Вони працюють там лише за умови відносної автономії. Якби Маск застосував до них підходи «твіттерського менеджменту», xAI спорожніла б за тиждень.

Тож Grok розвивається не *завдяки* управлінському стилю Маска, а *всупереч* йому, або ж завдяки тому, що команда навчилася давати йому «іграшку» (налаштування «anti-woke»), щоб він не ліз в архітектуру. Це не масштабування ефективності, це героїчний менеджмент ризиків з боку команди.

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 08.01.2026 02:48
Тож Grok розвивається не *завдяки* управлінському стилю Маска, а *всупереч* йому, або ж завдяки тому, що команда навчилася давати йому «іграшку» (налаштування «anti-woke»), щоб він не ліз в архітектуру. Це не масштабування ефективності, це героїчний менеджмент ризиків з боку команди.

вы вообще не поняли, что сделал Маск. он просто пришел и без церемоний потыкал палкой эту устоявшуюся еще при Джеке Дорси, обленившуюся касту инженеров, которые со скрытым презрением смотрели на коммерса, ничего не понимаюшего в коде, и у которых рука руку моет и прикрывают друг друга. потом он зарезал половину из них, после чего остальные начали шевелиться. Маск — отличный менеджер, он абсолютно уверен в своем успехе и умеет заставить других из кожи вон лезть. тем более, когда он только что заплатил 44 ярда за эту богадельню снобов.

Виталий, мне кажется, вы выросли из программистов в менеджера :) в вас чувствуется цеховая солидарность, вот эта вся бережливость к джунам/мидлам и противопоставление команды к ничего не понимающим владельцам. забудьте. вы — executive, ваша задача — генерировать для компании деньги, а не создавать пионерлагерь для джунов в надежде, что из них вырастут сеньоры — компания может до этого не дожить. если человека можно заменить более дешевым AI и тем самым сократить расходы и стать конкурентноспособнее — ваша задача это сделать и первым среди других. вы должны искать возможность, а не рыться в пыльных отчетах за обоснованием, почему этого не нужно делать))

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 08:52

1. Щодо «успіху» Твіттера.
Я вам вже описав своє бачення, ми тут розходимось

2. Щодо «піонер-табору» та грошей.
Моя позиція базується не на сентиментах до джунів, а на холодній логіці Supply Chain (ланцюга постачання).
Ви пропонуєте модель: «Замінимо всіх на AI, залишимо тільки сеньйорів».
Так, ця модель працює. Але виключно для маленьких продуктових бутиків, яким треба «тут і зараз».
Для індустрії загалом це — шлях до структурного колапсу. Якщо ми сьогодні зупинимо вхід у професію (знищимо джунів/мідлів), то через 5–7 років на ринку фізично не залишиться сеньйорів, здатних валідувати роботу AI.

3. Економіка AI.
Ви кажете: «замінити дешевшим AI». Я вам наводив цифри GitClear: AI наразі не зменшує витрати, а трансформує їх у Code Churn (переробку коду) та технічний борг. Тобто ви пропонуєте зекономити на зарплаті (CAPEX), щоб отримати експоненціальний ріст витрат на підтримку (OPEX). Це і є та сама короткозорість, про яку я пишу.

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

Відповісти
Підтримати
Alexander P
Просто Анон 08.01.2026 00:26
стратегія «урізати ресурси, щоб вирости» під час технологічного зсуву є значно ризикованішою, ніж стратегія доінвестування.

Так а звідки гроші брати?
Хто буде «доінвестовувати»?

Там пан вище написав дуже правильно

меньше балласт, меньше инертность, условия сознательного кризиса требуют быстрых действий и перехода на новые рельсы.

Завжди є ті хто не хочуть або не можуть адаптуватись.
От їх також звільняють

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 08:54

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

1. Звідки гроші? (Reallocation vs New Money)
Доінвестування не означає «знайти валізу грошей зверху». Це означає зміну структури бюджету.
Замість того, щоб витрачати шалені кошти на пошук, найм та онбординг нових «готових» сеньйорів (Recruitment Cost + Onboarding Cost), компанія інвестує ці ж кошти в навчання існуючої команди (Upskilling).
Утримання та перенавчання лояльного мідла з глибоким знанням домену часто дешевше, ніж цикл «звільнити старого — знайти нового — чекати 6 місяців, поки він зрозуміє продукт».

2. Щодо «баласту» та інерції.
Це небезпечна метафора. У складних інженерних системах те, що менеджмент називає «баластом», часто є носієм інституційної пам’яті (Institutional Memory).
Звільняючи людей, які «недостатньо швидко біжать», ви часто викидаєте тих єдиних, хто знає, чому система працює саме так, і як її не зламати.
Коли ви «скидаєте баласт», корабель стає легшим, але втрачає стійкість. У шторм (яким є впровадження ШІ) це призводить до перекидання.

3. «Умови кризи».
Якщо у компанії немає ресурсу на адаптацію (R&D, навчання) і єдиний вихід — це різати персонал, щоб звести P&L, то це діагноз бізнес-моделі. Така компанія вже в стані «зомбі». ШІ її не врятує, він просто відтермінує кінець.
Виграють ті, хто знаходить ресурс на трансформацію, а не ті, хто намагається зекономити на шляху до прірви.

Відповісти
Підтримати
Просто Анон
Alexander P 08.01.2026 01:51
Фінансова реальність каже про інше. Інвестиційний фонд Fidelity (один з інвесторів угоди) станом на 2025 рік оцінює вартість X на 72% нижче від ціни покупки. Рекламні доходи впали більш ніж на 50%.

18 марта 2025 года Financial Times написали, что оценка X вернулась снова на 44 ярда. вы, Виталий, в своих данных снова на год отстаете)) а учитывая всю ту пользу, которую Маск извлек из такого актива, то он точно остался в плюсе. ну а, как потребитель, отмечаю что слухи о скоропостижной смерти твиттера из-за того, что оттуда выгнали половину мидлов, оказались преждевременными. продукт напротив, стал очень удобным и главным источником информации.
метод децимации, когда из компании регулярно отсекают 10% хедкаунта, существует давно. он доказал, что работает, кровопускания только улучшают общее благополучие.

мы сейчас рассуждаем со стороны, конечно, лично я бы не хотел в какой-то момент оказаться в числе тех 10% или больше, которых в один день отсекут. но для бизнеса очень важно оставаться худощавым и иметь инстинкт выживания. если ты не можешь тренд переломить, то к нему нужно присоединиться, иначе вылетишь на обочину истории. а вы, Виталий, своими рассуждениями о том, что мидлы — это становый хребет компании, так как хранят в себе сакральное знание, потому нужно оберегать их от бесовского AI, выглядите как луддит)) без обид, я шучу. реальность такова: AI кодинг стремительно набирает обороты и нехитрые приемы помогают быстро и эффективно генерировать качественный код. ваша прямая обязанность как Head of PMO препарировать эти приемы и масштабировать на всю компанию, помочь ей сократить косты и успешно конкурировать с другими. а если при этом придется уволить кого-то из джунов или мидлов, ну что ж!

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 08:57

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

1. Щодо FT та оцінки $44 млрд у березні 2025.
Ви побачили заголовок, але пропустили суть. Повернення оцінки відбулося не через те, що рекламний бізнес X «ожив» (він досі глибоко збитковий), а завдяки фінансовій інженерії — тісній інтеграції з xAI та переоцінці активів на фоні хайпу навколо Grok.
Фактично, Маск використав успішний AI-стартап як «донора», щоб врятувати баланс соціальної мережі. Це геніальний хід фінансиста (перекласти гроші з однієї кишені в іншу), але це не доказ ефективності менеджменту самого Твіттера. Операційно — це все ще дотаційний актив.

2. Щодо «методу децимації» (відсікання 10%).
Ви пропонуєте практику, відому як «Stack Ranking» або «Rank and Yank», яку популяризував Джек Велч у GE ще у 80-х.
Але ви забули згадати, що Microsoft відмовився від неї у 2013 році, визнавши її руйнівною. Ця система створила токсичну культуру страху, яка вбила інновації та призвела до «втраченого десятиліття» компанії. В креативній індустрії (якою є розробка) страх опинитися в «bottom 10%» змушує людей не ризикувати і не створювати нове, а підсиджувати колег. Це анти-інновація.

3. Щодо моєї ролі.
Робота Head of Delivery/PMO — це максимізація **Цінності (Value)**, а не мінімізація **Витрат (Cost)**. Будь-хто з калькулятором може звільнити 10% людей. Але побудувати систему, яка згенерує у 10 разів більше доходу тією ж командою — це інженерна задача. Я обираю друге. Ви — перше.
Тому я — не луддит. Я — прагматик, який будує стійку систему, а не картковий будинок на страху та хайпі.

Відповісти
Підтримати
Alexander P
Donald Trump 08.01.2026 03:40

Якісь порівняння, тим більше з 2022 роком, не мають жодного смислу так як:
1. Адекватні тулзи і адекватні моделі для девелоперів з’явилися тільки в 2025
2. Кількість розробників які юзають АІ в розробці дуже мала, може десь 10% (в смислі ганяють агентів, мають підписки. Чатгпт не рахується, всі ним користуються)
3. Кількість розробників які вміють правильно використовувати тулзи і роблять це на постійній основі, у яких адекватно налаштований агентський воркфлоу — одиниці, може 1-2%. Навіть я себе, хто топить за АІ і використовує АІ з самого початку, не можу в цю категорію віднести — важко слідкувати за трендами і поратися з зоопарком тулзів, які розвиваються і змінюються кожен місяць.

Навіть якщо підсумовувати цю статтю, то:
1. Ефективність звичайного гребця виросла на 5-10% (очікованно)
2. Продуктивність топових гребців виросла на 50-100% (також очіковано)

Нічого нового.

Відповісти
Підтримати
Vitalii Oborskyi
Undisclosed User 08.01.2026 05:54

Chat gpt найтупіший, краще Claude чи grok, їх безкоштовних обмежень вистачає на rnd о 3й годині ночі. З високою вірогідністю код що вони генерують запрацює одразу, плюс вони не такі моральні і менше трахають мозги.

Відповісти
Підтримати
Donald Trump
Donald Trump 08.01.2026 07:34

потужна заява )
особливо без укаразання конкретних моделей, тулізв, агентів які використовувались, но, догадуюсь що безкоштовні веб версії чатів які ніякого відношення до програмування не мають, просто гугл на стероїдах

Відповісти
Підтримати
Undisclosed User
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 09:01

Проблема в тому що по свіжим даним які я давав вище за 4 квартал 2025 року по індустрії ефективність виросла на 6% а кількість коду роздутого і не потрібного на 125%. Це не приріст, це збитки

Відповісти
Підтримати
Donald Trump
Donald Trump 08.01.2026 10:25

Хз, єдине що я бачу що якась внутрішня метрика (яку намагається продати цей сервіс) виросла на 6% і що кількість коду на 125%. Нічого не бачу про ефективність, нічого не бачу про якість коду, нічого не бачу про результативність.

Не говорячи вже що немає жодної кореляції між кількістю коду і ефективністю. У нас деякі невеличкі, ледь помітні фічі вимагають 2 тижні і кілька тисяч строк коду зміненого, не говорячи вже про різні рефакторинги які по метриці «ефективність» покажуть 0 а насправді корисні.

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

Короче там така стаття що кожен сам може інтерпретувати як завгодно і підганяти під свої теорії.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 10:33

Ви описали «Vibe Coding» як перевагу, але з точки зору бізнесу та управління процесами — це опис проблеми, а не рішення.

1. Про «Вайб-кодинг» та ефективність.
Те, що ви описали («фігачу купу коду, потім підчищаю, відкачую, пробую інший підхід») — це метод перебору, або «Brute Force Engineering».
Раніше інженер витрачав час на *подумати* (System Design) і писав одне вірне рішення. Тепер він витрачає час на *генерацію варіантів*.
Якщо для отримання того ж самого результату (ті самі фічі) вам тепер потрібно згенерувати та відфільтрувати в 3 рази більше коду — це не ріст продуктивності. Це ріст ентропії та спалених ресурсів (часу та обчислень). Ви почуваєтесь продуктивнішим, бо «процес іде», але Value Stream не прискорився.

2. Про метрики та інтерпретацію.
Звіт GitClear базується не на «внутрішніх метриках», а на аналізі DORA metrics та Code Churn (плинності коду).
Зростання Code Churn (код, який написали і майже відразу видалили/змінили) на тлі стагнації кількості деплоїв — це клінічна картина того, що індустрія буксує. Ми генеруємо гігабайти тексту, щоб отримати міліграми цінності.

3. Про «чистий няшний пулл реквест».
Це ідеальний сценарій. Статистика каже про інше: PR стають більшими, а час на їх рев’ю (Review Cycle Time) зростає. Тому що навіть «чистий» код, згенерований ШІ, часто містить приховану складність.
Коли масштабувати ваш підхід «вайб-кодингу» на компанію з 1000 людей, ми отримуємо не експерименти, а хаос, за який бізнес платить шалені гроші, не отримуючи прискорення Time-to-Market.

Відповісти
Підтримати
Donald Trump
Donald Trump 10.01.2026 02:53
Якщо для отримання того ж самого результату (ті самі фічі) вам тепер потрібно згенерувати та відфільтрувати в 3 рази більше коду — це не ріст продуктивності. Це ріст ентропії та спалених ресурсів (часу та обчислень). Ви почуваєтесь продуктивнішим, бо «процес іде», але Value Stream не прискорився.

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

Тут правда ремарка що це не значить що бізнес отримає фічі швидше, так як корпоративному сегменті розробка, кодинг, це лише 20% часу. Но вот для своїх проектів, де я сам собі господар, де не маю мітингів, ревью, не треба ні з ким нічого узгоджувати я деліверю в 5 раз швидше ніж раніше.

Статистика каже про інше: PR стають більшими, а час на їх рев’ю (Review Cycle Time) зростає. Тому що навіть «чистий» код, згенерований ШІ, часто містить приховану складність.

Статистика каже що на умовній БМВ розбиваються частіше ніж на ланосі. Но чи робить це ланос кращою машиною за БМВ і що треба всім купити ланос, бо не всі зможуть навчитися нормально їздити на БМВ?

Коли масштабувати ваш підхід «вайб-кодингу» на компанію з 1000 людей, ми отримуємо не експерименти, а хаос, за який бізнес платить шалені гроші, не отримуючи прискорення Time-to-Market.

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

Нам дали тулзи, використовує їх десь 10%. Інші працюють по старому. Ви придумуєте якісь абстрактні сценарії «а що якщо всіх різко посадити на АІ, що буде і що з цим робити?», і починаєте об’ясняти. Но реальність така що такого не буде.

А історії про «в глотку засовують АІ а якщо не використовуєш то звільняють», це одне із:
1. Байка
2. Перебільшення
3. Самодурство в якійсь окремій команді на 3.5 людини в окремій компанії

Відповісти
Підтримати
Vitalii Oborskyi
Andrii ФОП 08.01.2026 11:23
1. Адекватні тулзи і адекватні моделі для девелоперів з’явилися тільки в 2025

Зі ймовірністю 99.9 в 2029 Дональд Трамп напише, що адекватні тулзи та моделі з’явилися в 2029

Відповісти
Підтримати
Donald Trump
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 12:04

Саме так. Це класична пастка «відкладеного майбутнього».

Я вже наводив вище статистику за 4-й квартал 2025 року: навіть з «адекватними тулзами» 2025-го тренд на Code Churn та роздування кодової бази не просто зберігся, а погіршився.
Тому аргументів по суті ми, ймовірно, більше не почуємо. Залишається лише сліпа віра в «Святий Апдейт»: мовляв, модель, що вийшла тиждень тому, точно все виправить.

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

Відповісти
Підтримати
Andrii
Philip Pristupa 07.01.2026 14:24

Стаття тішить розробників.
Але реальний світ значно цинічніший.
Працює цикл:

1. Менеджмент впроваджує новий інструмент.
2. Збір метрик.
3. Якщо метрики демонструють впевнений ріст продуктивності без втрати якості, — далі йде глибша інтеграція інструменту та оптимізація витрат.

Який саме це інструмент, не має значення: нова IDE, мова програмування чи ШІ.
1. ШІ дає приріст продуктивності — факт.
2. Якість коду ШІ для багатьох лінійних задач достатня — факт.
3. Інтеграція ШІ у бізнес-процеси вже глибока — факт.
Оптимізація витрат за рахунок скорочень є неминучою.

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 14:37

Ви ідеалізуєте менеджмент і те, що відбувається на стику бізнесу та інженерії. Ваша модель «Метрики -> Ріст -> Оптимізація» працює для еволюційних змін (як нова IDE), але ламається при революційних зсувах.

Щоб зрозуміти помилку, треба взяти ширший фрейм. ШІ — це не новий інструмент, це технологічний зсув рівня винаходу електрики, а не інтернету. Теорія менеджменту пережила свій останній великий стрибок у 60–70-х роках, спираючись на кібернетику (згадайте Стаффорда Біра та його «Brain of the Firm» або Viable System Model). Але останні 30–50 років і бізнес, і інженерія рухалися по інерції в парадигмі детермінованої розробки: «зробив А, отримав Б».

ШІ, а особливо агентні системи — це стохастична (ймовірнісна) парадигма. Для неї сьогодні не існує адаптованої теорії управління. Ні PMI, ні бізнес-школи не стикалися з таким зсувом. Корпоративний менеджмент — це споживач готових фреймворків, а не їх винахідник. Чекати, що вони самі «видадуть рішення» в умовах, коли навіть академічна наука не знає, як керувати недетермінованими системами — наївно.

І щодо ваших «фактів». Ви стверджуєте, що «ШІ дає приріст продуктивності». Це не факт, це гіпотеза, яку спростовують дані. Я навів у статті дослідження GitClear: впровадження ШІ корелює не з ростом продуктивності, а зі сплеском Code Churn (плинності коду). Ми бачимо збільшення velocity генерації технічного боргу, а не цінності. Тому ваші висновки базуються на хибних припущеннях, а не на реальній статистиці індустрії.

Відповісти
Підтримати
Philip Pristupa
Просто Анон 07.01.2026 14:45
ШІ, а особливо агентні системи — це стохастична (ймовірнісна) парадигма. Для неї сьогодні не існує адаптованої теорії управління. Ні PMI, ні бізнес-школи не стикалися з таким зсувом

Хватить вже копіпастити дурниці з чату гпт.

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 14:48

Ще раз, дивіться дослідження GitClean. По індустрії в цілому нема зростання продуктивності

Відповісти
Підтримати
Просто Анон
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 14:50

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

Вся теорія управління розробкою (SDLC), якою ми користуємось сьогодні — це результат десятиліть роботи таких організацій, як PMI. Я мав честь долучитися до дискусій з представниками PMI та академічних кіл (зокрема Стенфорду) щодо майбутніх стандартів для AI-систем.

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

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 07.01.2026 15:15
По індустрії в цілому нема зростання продуктивності

Та смисл не в «зростанні продуктивності» компаній, а в тому що спосіб роботи змінився.
От ви юзаєте чат зараз, а чому? Бо він підвищує продуктивність.

Ті хто адаптовуються, ті і виживуть

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:20

Саме про це і моя стаття. Ми згодні в головному: спосіб роботи змінився, і адаптація необхідна для виживання.

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

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

Відповісти
Підтримати
Просто Анон
Philip Pristupa 07.01.2026 16:16
це не «купити ліцензії на ШІ та скоротити хедкаунт»

Реальність знов жорстокіша і цинічніша.
Якщо на ринку 10 компаній зі 100 скоротили штат і за рахунок цього можуть оказувати той же обсяг послуг за меньші кошти — інші будуь вимущені скорочувати штат щоб вижити.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 16:36

Ви описуєте класичну «Гру на пониження» (Race to the bottom). Якщо 10 компаній знижують якість і ціну, щоб вижити — вони просто вбивають маржинальність всього ринку. Це шлях до банкрутства, а не до успіху.

Так само було під час бульбашки доткомів. Збанкрутували і ті, хто бездумно витрачав, і ті, хто намагався «пересидіти» зміни в режимі економії.
Але давайте зупинимось тут. На цьому етапі наша дискусія перейшла з площини фактів у площину філософії. У нас діаметрально протилежні погляди на природу конкуренції: для вас це ціна (Cost), для мене — цінність (Value). Дякую за дискусію, було цікаво зіставити ці два світогляди.

Відповісти
Підтримати
Philip Pristupa
Philip Pristupa 07.01.2026 16:50

Нажаль ви так і не зрозуміли, що сучасний ШІ дозволяє і зменьшувати ціну і збільшувати цінність одночас. Так само як гігапресс від Маска en.wikipedia.org/wiki/Giga_Press дозволяє і збільшувати якість і скоротити до 600 робочих на підприємстві.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 16:56

Аналогія з Giga Press красива, але вона ілюструє фундаментальну помилку у вашому сприйнятті природи розробки ПЗ. Ви намагаєтесь застосувати закони конвеєрного виробництва до інженерії знань.

1. Детермінованість vs Стохастика.
Giga Press — це вершина детермінованого процесу. Вона штампує ідеальні, ідентичні фізичні копії.
ШІ в розробці — це стохастичний (імовірнісний) генератор. Він не «штампує» ідеальний код, він пропонує вірогідний варіант. Якби ШІ працював як Giga Press (автоматично підвищував якість), ми б не бачили у звіті GitClear рекордного зростання «Code Churn» (переробок) та зниження якості коду. Giga Press зменшує кількість браку, а неконтрольоване впровадження ШІ (за даними досліджень) наразі його збільшує.

2. Природа продукту.
Мета Giga Press — створити тисячі однакових деталей.
Мета розробки ПЗ — створювати унікальні рішення для унікальних бізнес-умов. Код — це не деталь, це записане знання. Скорочуючи людей, ви скорочуєте носіїв знання, а не «операторів пресу».

3. Парадокс автоматизації.
Навіть у Tesla впровадження Giga Press вимагало колосальних інвестицій у R&D та нових висококласних інженерів для обслуговування цього процесу. Маск не просто «звільнив робітників», він замінив ручну працю на високотехнологічну, змінивши структуру витрат, а не просто обрізавши їх.

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

Відповісти
Підтримати
Philip Pristupa
Philip Pristupa 07.01.2026 18:11
Детермінованість vs Стохастика.

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

створювати унікальні рішення

Рішення — унікальні. А модулі, методи і функції, з яких створюються ці рішення — ні.

Відповісти
Підтримати
Vitalii Oborskyi
Sergey Lysak T/T Lead 14.01.2026 20:32
А модулі, методи і функції, з яких створюються ці рішення

то чому ж їх по новому писали десятками років?

оті круди — ну і скопіпастили б у рішення.

80% комерційного коду — це — повторювані паттерни.

якщо за десяткі років розвитку розробки ці 80% не стали «цеглинами» з заводу, а повинні виготовлятись кожен раз на кожному проекті — то у чому — повторюванність цих цеглин?

Відповісти
Підтримати
Philip Pristupa
Stanislav Katkov Product Owner в N-iX 08.01.2026 10:11

підтримую у декількох моментах

1. ріст продуктивності через АІ — наш СТО має багато дашбордів які міряють умовну «продуктивність» девелоперів (всі ці велосіті, ху**сіті, і далі по списку). На початку 2025 року, він роздав всім дев командам АІ тули\ліцензії і сказав щоб використання АІ тепер обовязкове для всіх задач. В кінці 2025 року, графіки моєї команди були використані як приклад того, що АІ бустить «продуктивність» і дозволяє девелоперам краще і швидше працювати бо наші метрики (велосіті\ху*сіті) виросли і були кращі\стабільшіні ніж в інших командах....

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

ця презентація пішла нагору інвесторам... ці інвестори потім будуть качати своїм кентам з яким грають гольф про «АІ = продуктивність». І так пішло поїхало. Стандартне корпоративне лайно.

2. я працюю з Enterprise Architecture і там всі сучасні фреймворки і підходи до роботи побудовані на підходах які заснували в IBM в 70х з BSP — Business Systems Planning. Воно вже тоді було застаріле бо почався розвиток комплексних систем і просто в тупу менеджити процеси девів як на заводі аля інпут — процес — аутпут вже було пізно. Але нікого це особливо не колише і ми маємо 50 років специфікацій і фрейморків які +\- базуються на тих самих підходах.

3. корпоративний менеджемент (я думаю всі погодяться) — це гниле болото де вмирає все хороше і людьське. І цитуючи свого кента якому 75 років і який все життя пропрацював на С-лвл позиціях в США — «corporate world is borderline psychotic because if they see someone doing some shit, they will copy it without thinking.»

Там ніхто не має часу розбиратись чи думати. Там всі «жеруть» одне одного. Почули «АІ = продуктивність» + побачили пару статтей десь в McKinsey чи Gartner... ну всьо, поїхали. З АІ ця проблема ще множиться на х2 бо багато корпоративних олдів взагалі не дружить з ІТ (це класика) і коли АІ генерує картинку за 5 секунд, а дизайнер відмальовує іконку за 10 чи 20 чи 30 — ну всьо, на*уй того дизайнера чи девелопера. Це ментальність «ЗАВОДУ» бл**ь. Заводи в 50х робили коробки, цих менеджерів набрали в ІТ і вони почали в ІТ робити «коробки» бл**ь з метриками для «коробок». І так вже 50 років.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 10:19

Станіславе, дякую. Це, мабуть, один з найбільш глибоких та тверезих коментарів у всій дискусії, бо ви дивитесь на систему, а не лише на свій IDE.

1. Щодо кейсу з вашим СТО.
Ця історія — просто еталонний приклад «помилки атрибуції» (Attribution Error). Це і є та сама «Ілюзія», про яку я писав.
Найіронічніше те, що ваша команда досягла росту саме завдяки тому, про що я кажу: інвестиціям в процеси (документація, спайки, комунікація з дизайнерами). Тобто спрацювала «Інженерна Культура», а менеджмент продав це інвесторам як «Успіх ШІ». Це створює хибний зворотний зв’язок: бізнес думає, що купив срібну кулю, і починає різати кости, хоча насправді успіх забезпечили люди та процеси.

2. Щодо «ментальності заводу» (Factory Mindset).
Ви абсолютно праві. Спроба натягнути детерміновані метрики конвеєра (input-process-output) на креативну та стохастичну роботу інженерів була помилкою ще 50 років тому. А спроба застосувати їх зараз до генеративного ШІ — це катастрофа.
Ми намагаємось керувати ймовірнісними системами за допомогою метрик для штампування коробок. Саме тому ми бачимо ріст метрик «велосіті» (кількість коробок/коду), але падіння реальної бізнес-цінності.

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

Відповісти
Підтримати
Stanislav Katkov
Stanislav Katkov Product Owner в N-iX 08.01.2026 11:02

я б ще підсвітив 1 важливий момент

рахувати — важко.

в випадку CTO, я на 100% впевнений, що було як мінімум 3 фактори які вплинули на його заміри.

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

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

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

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

це ж одна з основних причин чому ніхто ніколи не хоче довіряти централізованим дашбордам і self service analytics. Нам типу сказали, «буде демократизація рішень і даних»... так б**ть, як можна демократизувати дата-дрівен рішення якщо більшість людей не вміє рахувати і не шарить як метрики працюю в першу чергу? Ну і якось це все відноситься до АІ метрик і як бізнес їх інтерпретує.

Відповісти
Підтримати
Vitalii Oborskyi
Busted Gipsy 09.01.2026 19:26

Как боженька прокоментировал
Все так и есть

Відповісти
Підтримати
Stanislav Katkov
Просто Анон 07.01.2026 11:30

Чудова стаття, багато з чим не згоден але викладено дуже доступно, відформатовано, з посиланнями на першоджерела.

Відповісти
Підтримати
Просто Анон 07.01.2026 11:29
звільняємо «найменш ефективні» 5–20% персоналу і спостерігаємо за зростанням маржинальності.

Навіть без АІ це підвищить маржу і продуктивність.
Це ж одну найслабшу людину з команди дропнути.

мислення в стилі «cost-cutting» часто штовхає менеджмент до звільнення Middle-розробників заради «сплощення» структури. Це провокує «Відтік мізків» (Brain Drain) і втрату критичних знань про продукт.

Критичні знання про продукт це сіньори і вище.

написання коду стало миттєвим, а читання коду залишається на людській швидкості.

Ця асиметрія найболючіше б’є по Senior-інженерах.

У традиційному робочому процесі сеньйор витрачав частину часу на кодинг, а частину — на рев’ю роботи Junior та Middle розробників.

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

Два зайці одним пострілом, і гроші зекономили, і сіньори не тратять час на рев’ю всякого сміття=)

AI — це не спосіб робити ту саму роботу меншою кількістю людей.

З мого досвіду останнього року, це якраз навпаки — хороший інструмент для толкового сіньора робити більше ніж той сіньор + 2-3 джуна/міда раніше.

Раніше треба було тратити багато часу на опис і пояснення тікетів іншим людям, рев’ю їхньої роботи, правок.
А тепер замість того міда/джуна (особливо «вічних» мідів) є АІ.

Думаю тому оцим «вічним мідам» і важко зараз роботу знайти.

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 11:47

Логіка «один Senior + AI замінює команду» звучить привабливо в короткостроковій перспективі, але стратегічно це пастка з кількох причин:

1. Bus Factor (Фактор автобуса). Коли у вас є команда (Junior/Middle/Senior), знання про проект розподілені. Коли у вас є «один толковий сіньйор з AI», ви створюєте критичну точку відмови (Single Point of Failure). Якщо цей сіньйор вигорить або піде (а з таким навантаженням це станеться швидко), ви залишаєтесь з гігантською кодовою базою, згенерованою AI, в якій ніхто більше не розбирається. AI не передасть справи наступнику.

2. Роль Middle-розробників. Ви недооцінюєте їхню функцію. Якщо Senior — це про архітектуру та абстракції, то Middle — це часто головний носій глибокого знання доменних деталей та бізнес-логіки конкретних фіч. Звільняючи їх, ви втрачаєте «м’язову пам’ять» проекту.

3. Питання майбутнього. Junior — це майбутній Senior. Якщо вся індустрія перейде на модель «тільки Сіньйори», то через 5–7 років, коли поточні експерти підуть на пенсію чи в консалтинг, новим нізвідки буде взятися. Ми просто знищимо пайплайн відтворення кадрів в індустрії.
Тому це економія сьогодні ціною існування індустрії завтра.

Відповісти
Підтримати
Просто Анон
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 11:53

Тому така поведінка C-level не просто етично безвідповідальна (що в наш цинічний вік мало кого турбує). Вона є стратегічно безглуздою і структурно небезпечною для їхнього власного бізнесу. Це свідоме створення вразливості та знищення механізму відтворення кадрів заради короткострокової ілюзії економії.

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 07.01.2026 14:02
поведінка C-level ....є стратегічно безглуздою і структурно небезпечною для їхнього власного бізнесу

Не будьте джуном який вчить архітектів)
На то вони і С-level щоб думати про стратегії. От Маск звільнив 80% девів з Твіттера, і нічого, якось працює.
То в чому проблема скинути баласт?
Я працював з кадрами від який ККД для тіми було від’ємне.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 14:58

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

Але зараз ми переживаємо тектонічний зсув. Весь SDLC (життєвий цикл розробки), на якому базується індустрія, потребує перегляду. Я маю можливість обговорювати ці виклики безпосередньо з ключовими розробниками нового стандарту PMI AI (Core Members). І спільний висновок цих дискусій — старі шаблони управління більше не гарантують успіху в еру недетермінованого ШІ. Тому сліпо покладатися на те, що «зверху видніше», ігноруючи інженерну реальність — це ризик.

Щодо Маска і Twitter — це класична «помилка вижившого».
По-перше, компанія перейшла з фази активного R&D та росту у фазу жорсткого maintenance (підтримки). Для підтримки дійсно потрібно менше людей.
По-друге, капіталізація компанії після цих дій впала в рази.
Якщо ваша стратегія — скоротитись, перестати створювати нове і просто підтримувати існуюче, втрачаючи вартість бізнесу — тоді так, це «успішний кейс». Але я пишу про розвиток і створення цінності.

Відповісти
Підтримати
Просто Анон
Donald Trump 07.01.2026 12:02

Хватить бота ганяти, відповідай сам своїми словами, ШІ згенерованого контекту на роботі хватає )

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 12:19

Безперечно, я використовую ШІ. Але виключно як «розумного редактора», щоб структурувати думки, прибрати помилки та зробити текст лаконічним.

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

Відповісти
Підтримати
Donald Trump
Philip Pristupa 07.01.2026 14:14
езперечно, я використовую ШІ. Але виключно як «розумного редактора»,

Ось ви і скоротили одного розумного редактора десь на фрілансі.
Чому це вам можна скорочувати, а великим компаніям ні?

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:01

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

А щодо компаній — тут якраз і криється різниця мислення.
— Логіка скорочення (Cost Cutting): звільнити редакторів, бо ШІ пише швидко.
— Логіка створення цінності (Value Creation): навчити редакторів використовувати ШІ, щоб той самий штат міг генерувати в 5 разів більше якісного контенту, захоплюючи нові ринки.

Я виступаю за другий підхід. Звільнення — це найпростіша, але найменш далекоглядна стратегія.

Відповісти
Підтримати
Philip Pristupa
Philip Pristupa 07.01.2026 16:34
я просто отримав інструмент, який покращив мою особисту якість

Потрібно визначитися. ШІ покращує якість чи ні?
Чому якість вашої роботі ШІ може покращувати, а якість інших — ні?

— Логіка створення цінності (Value Creation): навчити редакторів використовувати ШІ, щоб той самий штат міг генерувати в 5 разів більше якісного контенту, захоплюючи нові ринки.

Ринок — обмежений і вже насичений. Йде боротьба за ті долі, що є.
Якщо хтось вкрутив ШІ, скоротив витрати і може зменьшити ціну, інші будуть змушені зробити так само, бо інакше не виживуть.
Я дійсно це повинен пояснювати РМО?

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 16:45

Тут немає жодного протиріччя, якщо розуміти механіку роботи інструменту.

1. Щодо якості. ШІ — це мультиплікатор, а не заміна.
У моєму випадку: Експерт + ШІ = Вища якість (бо я валідую результат і використовую ШІ для шліфування форми, а не генерації сенсів).
У випадку масових скорочень: Відсутність експерта + ШІ = Хаос (бо нікому перевірити галюцинації чи контекстну відповідність).
Саме тому, коли компанії звільняють людей, які мають валідувати роботу ШІ, якість падає (згадайте GitClear).

2. Щодо «насиченого ринку».
Ви описуєте економіку як «гру з нульовою сумою» (Zero-sum game), де пиріг фіксований. Але історія технологій доводить протилежне — працює Парадокс Джевонса. Коли ресурс (в даному випадку — створення софту) стає ефективнішим і дешевшим, попит на нього зростає експоненціально, а не залишається сталим.
Світ потребує більше складного софту, більше автоматизації, більше інтеграцій. Компанії, які використовують ШІ для Value Creation, заберуть цей новий попит. А ті, хто просто знижує ціну, вбиваючи власну експертизу, потрапляють у пастку комодитизації, де маржа прямує до нуля.

Відповісти
Підтримати
Philip Pristupa
Philip Pristupa 07.01.2026 17:32
1. Щодо якості. ШІ — це мультиплікатор, а не заміна.

Трактор людину не замінить.
Проте людина на тракторі замінить половину села.
Іншу половину замінить людина на комбайні.
Я вважаю, що дійсно цю розмову потрібно завершувати, бо я вимущен досвідченому РМО пояснювати найпростіші речі.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 17:37

Дякую за екскурс в історію агропромисловості.

Але ви зараз робите справді героїчну річ. Ви намагаєтесь переїхати метафорою про трактор суху статистику аналізу 200+ мільйонів рядків коду. Це справді важка і невдячна праця — спростовувати індустріальні Big Data за допомогою притчі про село.

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

Відповісти
Підтримати
Philip Pristupa
Philip Pristupa 07.01.2026 19:00
Дякую за екскурс в історію агропромисловості.

Буль-ласка.

Але ви зараз робите справді героїчну річ. Ви намагаєтесь переїхати метафорою про трактор суху статистику аналізу 200+ мільйонів рядків коду. Це справді важка і невдячна праця — спростовувати індустріальні Big Data за допомогою притчі про село.

Мій героїзм міркне поряд з вашим. Ви намагаєтесь переїхати реальність. У сусідній гілці пишуть, що SoftServe скоротився на 30%, Infopulse скоротився, потім був продан (infopulse.com). FAANG і Microsoft пишуть, що до 30% коду тепер буде писати ШІ. І проводять скорочення. Багато IT-напрямків з появою ШІ зникли як клас. Ви самі використовуєте ШІ в написанні текстів і самі кажете, що він підвищує швидкість та якість.

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

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

не саджає пластикову кукурудзу замість пшениці у 30% випадків (галюцинації)

Це було в 2023-му.
Зараз 2026.
Ші з одного коректного промту генерує одразу робочий, структурований і відкоментований код на 500 рядків, готовий до продакшну 80% проектів.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 19:21

Давайте подивимось на найбільш свіжі дослідження (дані за 4 квартал 2025 року):
www.gitclear.com/...​_output_from_2022_to_2025

Ось що кажуть цифри про «революцію» 2025 року, на яку ви покладаєте такі надії:

1. Міф про масовий ріст продуктивності.
Медіанна кількість комітів (реальних одиниць роботи) зросла всього на 6–9% порівняно з 2022 роком.
Навіть CEO Google Сундар Пічаї у 2025 році оцінив ріст Engineering Velocity в компанії лише у 10%. Тобто, на макрорівні ніякого «кратного зростання» для середнього інженера не відбулося.

2. Code Churn на стероїдах.
А ось де ми бачимо справжній вибух: кількість доданих рядків коду (Lines Added) на одного розробника у 2025 році зросла на 131% (для Average) та на 76% (для Median).
Порівняйте: комітів +6%, а обсяг коду +76%.
Це математичний доказ тези моєї статті: ми перейшли від вирішення проблем до генерації тексту. ШІ дозволяє роздувати кодову базу вдвічі швидше, але цінність від цього майже не росте. Ми просто топимо проекти в бойлерплейті, який потім треба підтримувати.

3. Ефект «Багаті стають багатшими».
Звіт підтверджує ваш особистий кейс: топ-перформери дійсно змогли суттєво наростити темп (майже в 2 рази). Ви — у цій категорії. Але медіанний розробник (яких більшість) залишився на тому ж рівні продуктивності, проте почав генерувати значно більше «сміттєвого» коду.

Висновок звіту однозначний: 2025 рік з його новими моделями лише посилив тенденцію до створення «роздутого» коду (bloatware), вартість підтримки якого зростає експоненціально. Тому теза про те, що «нові моделі все виправили», спростовується даними за той самий період.

Відповісти
Підтримати
Philip Pristupa
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 19:27

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

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 07.01.2026 19:31
«нові моделі все виправили»

нет, новые модели не исправляют, новые модели только усиливают те тенденции, которые начали формироваться. а именно, из ваших же данных: топ-перформеры, вооруженные новыми инструментами, смогут перформить больше и быстрее, а джуны и отчасти, мидлы, станут не нужны вовсе или останутся в малом количестве. команды сократятся. это то, что наблюдают разработчики повсеместно сейчас, это уже происходит.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 19:36

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

Те, що ви описуєте як «посилення тенденцій» — це і є та сама пастка стратегічного самогубства, про яку я пишу у статті та коментарях вище.
Давайте подивимось на 5–7 років вперед. Senior 2032 року — це Junior, якого найняли у 2025-му. Якщо індустрія сьогодні, керуючись короткостроковою вигодою, знищить прошарок Junior/Middle і закриє вхід у професію, то:
1. Зникне механізм відтворення кадрів (Supply Chain).
2. Через 5 років ми отримаємо катастрофічний дефіцит експертів, бо старим нікому буде передати знання, а новим нізвідки буде взятися.

Це називається «eating your seed corn» (проїдання посівного зерна). Ви радієте, що сьогодні ми ситі (ефективні сеньйори з ШІ), ігноруючи той факт, що завтра нам нічого буде сіяти. Моя стаття саме про те, що бізнес має усвідомити цей ризик зараз, поки не пізно, а не про те, що ШІ поганий.

Відповісти
Підтримати
Alexander P
Alexander P 07.01.2026 19:53

я думаю, что у вас слишком апокалиптический настрой :) индустрия перестроится и выживет (но не все, конечно).

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 08.01.2026 00:14
Через 5 років ми отримаємо катастрофічний дефіцит експертів

Звучить чудово, буде нова стеля сіньора не 8к а 15к)

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 08.01.2026 00:12
топ-перформери дійсно змогли суттєво наростити темп (майже в 2 рази). Ви — у цій категорії. Але медіанний розробник (яких більшість) залишився на тому ж рівні продуктивності, проте почав генерувати значно
більше «сміттєвого» коду.

Так отих медіанних і нижче тому і звільняють.
Вони і до АІ генерували в 2-3 рази менше користі, тепер різниця вже 4-6.
Як я і писав, стає логічно звільнити джунів/мідів, взяти ще одного сіньора.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 09:06

Ваша логіка про «стелю в $15к» звучить чудово для вашої особистої кишені, але вона вбивча для бізнесу.

1. Економічне самогубство (Unit Economics).
Ви пропонуєте свідому стратегію: звільнити джунів/мідлів (які в сервісній моделі часто генерують найвищу маржинальність для компанії) і замінити їх на дорогих сеньйорів.
Це знижує маржинальність бізнесу сьогодні і створює дефіцит кадрів завтра.
А якщо через цей штучний дефіцит зарплата українського сеньйора справді стрибне до $15к, то український IT-сектор просто зникне з глобальної мапи. Клієнти не будуть платити ці гроші, вони підуть у Латам, Індію чи В’єтнам. Ви пропонуєте сценарій, де виграють одиниці, а індустрія втрачає конкурентоспроможність.

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

Це не стратегія розвитку. Це стратегія паразитування на кризі.

Відповісти
Підтримати
Просто Анон
Просто Анон 08.01.2026 12:21
А якщо через цей штучний дефіцит зарплата українського сеньйора справді стрибне до $15к, то український IT-сектор просто зникне з глобальної мапи. Клієнти не будуть платити ці гроші, вони підуть у Латам, Індію чи В’єтнам.

Скажіть своїму АІ що у Латамі, Індії теж стане 15к.

Пишіть відповіді руками, бо тут вже є кілька кадрів чиї АІ коменти просто прогортують.
Простиня тексту і 1 речення зі смислом

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 09.01.2026 00:23

Ваша теорія про «в Індії теж буде $15к» розбивається об структуру світового ринку праці.

У нас різні бізнес-моделі.
1. Захід (і ми, якщо копіюємо їх) переходить на модель «Діамант»: відрізаємо низ (джунів), залишаємо тільки дорогих сеньйорів з ШІ. Ми зупиняємо конвеєр вирощування кадрів.
2. Глобальний Південь (Індія, В’єтнам, Латам) працює за моделлю «Піраміда». Великі аутсорсери (Infosys, Tata, Wipro) не звільняють джунів. Навпаки — глобальний бізнес скидає туди всю рутинну роботу, яку «дорого» робити тут.

Що це означає стратегічно?
Вони продовжують масово «тренувати» своїх джунів на реальних задачах (які ми віддали їм). Через 5 років у них буде надлишок нових сеньйорів, вирощених природним шляхом.
У нас же буде дефіцит, бо ми свій «інкубатор» закрили.

Тому закон попиту і пропозиції спрацює невблаганно: у них сеньйорів буде багато (ціна стабільна), у нас — мало (ціна космічна). І бізнес піде туди, де є ресурс, а не туди, де є амбіції по $15к.

Відповісти
Підтримати
Просто Анон
Vadim Kopanev Architect 09.01.2026 02:46

чёт получилось слишком много манипуляции

Відповісти
Підтримати
Vitalii Oborskyi
Busted Gipsy 09.01.2026 19:39
я вимущен досвідченому РМО пояснювати найпростіші речі

Я заметил что с годами стал меньше общаться с другими людьми, так как за годы карьеры в IT устал от этого слегка прикрытого хамства.

Я читаю этот поток комментариев и не везде согласен с Виталием, но большая часть ответов, включая этот — это попытка примитивизации, полного упрощения. Ну реально подумай, бро, как можно сравнивать разработку ПО и село, полевые работы. Ты в своем уме вообще?

Відповісти
Підтримати
Philip Pristupa
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 09.01.2026 20:56

Концептуально я з вами згоден. Саме тому я в певний момент просто зупиняю такі діалоги. Немає сенсу продовжувати, коли співрозмовник застряг у власній метафорі (як із тим селом) і спроби піднятися на інший рівень абстракції не працюють.

Але я намагаюся ставитися до цього філософськи. Будь-яка подібна стаття — це спроба охопити величезний контекст і задати певну рамку (фреймінг). Це як моделювання на основі Big Data: модель ніколи не буває на 100% повною або єдино істинною, бо змінних мільйони. З одного й того ж набору фактів можна зібрати різні проекції.

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

Відповісти
Підтримати
Busted Gipsy
Alexander P 09.01.2026 22:22
как можно сравнивать разработку ПО и село, полевые работы

собеседник утрирует, конечно, но сравнение вполне допустимое. наша профессия — это не что-то загадочное, какое-то непостижимое для простых смертных искусство. нет, это обычное ремесло, мы обслуживаем бизнес, делаем для них инструменты. это обычная работа и она, так же как и сбор кукурузы, должна быть управляема и измерима. нельзя контролировать то, что нельзя измерить. вся история индустрии ПО состоит из попыток процесс измерить (будь-то миллионы строк кода или человеко-месяцы), планировать и контролировать. и внедрение механистичности в работу, когда вместо человека, который выполняет рутинные операции по кодированию отдельных функций, ту же работу выполняет автоматический агент быстрее, дешевле и более прогнозируемо — это неизбежно. человек должен работать головой, проектировать и управлять, а рутинные операции по кодированию, так же как сбор кукурузы или укладка кирпичей, будут выполнять автоматические агенты.

Відповісти
Підтримати
Busted Gipsy
Volodymyr Dvernytskyi Senior Developer в beeDynamics 09.01.2026 08:59

Насправді іронічно, що самі головні критики ШІ самі його використовують, щоб здаватись розумнішими ))

Відповісти
Підтримати
Donald Trump
Просто Анон 07.01.2026 13:55
Коли у вас є команда (Junior/Middle/Senior), знання про проект розподілені

Не зовсім.
Знання розподілені коли є кілька сіньорів. Ідіть запитайте своїх джунів про проект, в кращому випадку назвуть список технологій і домен.
А ті міди/джуни які толкові, тих швидко промоутають до сіньора на проекті.

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

Middle — це часто головний носій глибокого знання доменних деталей та бізнес-логіки конкретних фіч

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

Питання майбутнього. Junior — це майбутній Senior

Тут згоден, але це було і раніше. Чомусь умовному ЕпаСерву було вигідно тратити гроші на ІТ Академії, а інші компанії вже переманюють сіньорів від них.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 14:12

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

Сіньйори мислять рівнями абстракцій та архітектури. Їм часто банально нераціонально (і нудно) занурюватися в кожну дрібну деталь бізнес-логіки. Якщо вони не можуть це делегувати, то з часом просто втрачають фокус або «закопуються» в рутині. І тут на сцену виходять мідли.

Саме Middle-розробник часто знає реалізацію конкретної фічі та її «підводні камені» краще за будь-якого архітектора. І ніякий Cursor цього не замінить. ШІ може за 2 хвилини пояснити, *що* робить цей код. Але він не пояснить, *чому* ми написали його саме так пів року тому після складної розмови з клієнтом. ШІ не має історичної пам’яті про домовленості та компроміси.

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

Ну і про джунів. Давайте відкинемо пафос про «майбутнє індустрії» і подивимось прагматично. Якщо всі компанії сьогодні стануть такими «ефективними оптимізаторами» і перестануть наймати новачків, то де ви (і ми всі) візьмемо сіньйорів через 3–5 років? Ринок просто висохне. Талановиті джуни зростають, це природний процес, і переривати його заради економії сьогодні — це стріляти собі в ногу завтра.

Відповісти
Підтримати
Просто Анон
Просто Анон 07.01.2026 14:26
Але він не пояснить, *чому* ми написали його саме так пів року тому після складної розмови з клієнтом

Як і мід, який пів року тому тільки прийшов на проект.

Ну і про джунів. Давайте відкинемо пафос про «майбутнє індустрії» і подивимось прагматично

Саме так і роблять компанії, звільняючи 5-10% людей, акумулючи за рахунок цього капітал для інвестицій в АІ.

І добавте в свій промпт «будь лаконічним, пиши без води».

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:09

1. Щодо акумуляції капіталу.
Те, що ви описуєте («звільнити 10%, щоб інвестувати в ШІ»), в економіці називається «Eating your seed corn» (проїдання посівного зерна).
Так, ви отримаєте короткостроковий кеш-флоу. Але ви руйнуєте механізм відтворення експертизи в компанії. Інвестувати в ШІ треба, але не ціною руйнування командної структури, яка цей ШІ має обслуговувати та контролювати.

2. Щодо мідлів та контексту.
Якщо у вас Middle за пів року на проєкті не розібрався, «чому» працює фіча — то це питання до вашого онбордінгу та процесів, а не до грейду. Але статистично, людина, яка працює з системою щодня (Middle), має значно вищий шанс зловити логічну помилку ШІ в бізнес-логіці, ніж Senior, який дивиться на код раз на тиждень, або ШІ, який взагалі не розуміє поняття «бізнес-ціль».

І дякую за пораду щодо промптів, але я надаю перевагу власному стилю, навіть якщо він здається вам недостатньо «сухим».

Відповісти
Підтримати
Просто Анон
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:25

3. Про роль Сеньйора в зрілій організації.
Давайте будемо чесними: в нормальних умовах із налагодженими процесами основна цінність Senior-інженера — це зовсім не написання коду під кожну фічу 24/7. І навіть не просто Code Review.

Його ключова цінність — це прийняття технічних рішень: архітектура, проектування масштабованих систем, управління технічним боргом, оцінка ризиків безпеки та вибір стратегії реалізації. Це функція Technical Leadership, а не Production Line.

Стратегія «звільнити команду, залишити Сеньйора з ШІ» змушує цього Сеньйора спускатися на рівень мікроменеджменту коду та імплементації рутинних задач (навіть якщо ШІ їх прискорює). Ви фактично берете найдорожчий ресурс компанії і змушуєте його виконувати лінійну роботу. Це все одно, що використовувати головного хірурга лікарні для накладання пов’язок, бо «він робить це швидше за інтернів». Це не оптимізація, це неефективне використання (misallocation) найціннішого активу.

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 07.01.2026 15:38
Інвестувати в ШІ треба, але не ціною руйнування командної структури, яка цей ШІ має обслуговувати та контролювати.

Звільнення 10% це ніяк не «руйнування команди»

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:44

Все залежить від контексту, але це вже доволі драматична подія для команд. В управлінні персоналом прийнято вважати, що ротація в межах 5% (часто пов’язана з performance review) є допустимою операційною нормою. Все, що вище — це вже структурні ризики та гарантований «синдром вцілілого» у команди. Але найбільша проблема тут у причинно-наслідковому зв’язку. Обіцянка, що скорочення персоналу призведе до росту продуктивності завдяки ШІ — це небезпечна ілюзія. Я вже писав про модель Сатір та амбідекстерні організації: саме це шлях до адаптації інновацій, а не механічне урізання штату. Тобто не урізання а інвестиції потрібні щоб цього досягти з найбільшими шансами на успіх

Відповісти
Підтримати
Просто Анон
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:55

До речі, якщо вам цікаво, рекомендую переглянути обговорення дослідження GitClear на англомовних профільних ресурсах. Бо ми тут місцями вже ходимо по колу. Це реальна дискусія, де стратегії компаній за останні 2 роки та ставка на ШІ в тому «сліпому» вигляді, як вона робилася, ставляться під сумнів — відкрито і масово.

Справа зовсім не в тому, що я не вірю в ШІ. Навпаки, я вірю, і мій посил — не про тотальну недовіру (хоча є матеріали, які на базі цього ж дослідження називають це все шарлатанством). Я якраз чітко бачу перспективи. Моя мета — зробити внесок у те, щоб вектор розвитку пішов найбільш ефективним шляхом. Шляхом, де на Горизонті 1 ми справді отримаємо економію, а на Горизонті 2 — нову цінність.

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 07.01.2026 16:34
рекомендую переглянути обговорення дослідження GitClear

там нечего обсуждать, они анализировали во-первых, corp репозитории, во-вторых, код за 2020-24 года. все это outdated уже, Opus 4.5 вышел чуть больше месяца назад, а произвел небольшую революцию в написании кода.
лучшие практики по использованию AI агентов в разработке сейчас создаются по инициативе снизу, а не потому что в корп среде один вице-президент спустил указание по вертикали всем закупить Copilot.

я пишу код каждый день на протяжении 20 лет. заверяю, с внедрением в работу AI агентов моя эффективность выросла кратно. мне не нужны репорты, чтобы понимать, какое влияние окажут современные технологии на индустрию. те, кто это не понимают, окажутся на обочине. вместе с луддитами, которые отрицают.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 16:54

Олександре, ви робите логічну помилку, плутаючи «версію софту» з «бізнес-циклами».

Стаття аналізує конкретні управлінські стратегії (cost-cutting та сліпе впровадження ШІ), які масово застосовувалися бізнесом саме в період 2024–2025 років. Звіт GitClear та інші дані, наведені у статті — це фактологічний доказ наслідків цих стратегій.

Тобто:
1. Стратегія (2024–2025): «Звільнити людей, дати ШІ».
2. Результат (дані звіту): «Ріст Code Churn, падіння якості».

Ці дані не можуть бути «застарілими» для цієї дискусії, тому що вони є прямим відображенням результатів тих дій, які ми обговорюємо. Ми аналізуємо причинно-наслідковий зв’язок, а не новини в стрічці OpenAI. І поки індустрія не змінить стратегію, ці результати будуть лише масштабуватися, незалежно від того, вийшов Opus 4.5 вчора чи місяць тому.

Відповісти
Підтримати
Alexander P
Alexander P 07.01.2026 17:05

отчет GitClear не может анализировать то, что происходило в 2025 году, потому что он был выпущен в январе 2025. кроме того, он анализировал репозитарии за 2020-2024 года, т.е. те данные, когда AI coding assistants либо еще не существовали, либо только начинали применяться и были ограничены возможностями моделей, существовавших на тот момент.

на дворе — январь 2026 года, за прошедший год мы от 4o прошли к GPT 5.2, Gemini 3 Pro, Opus 4.5. от простых моделей к повсеместному использованию ризонинга. от one-shot подходов к мультиагентным системам. отчет попросту устарел и нерелевантен.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 17:07

Олександре, ви робите класичну помилку, плутаючи «цикл хайпу» з «виробничим циклом».

1. Релевантність даних.
Звіт за січень 2025 року підсумовує результати масового впровадження AI-асистентів протягом 2024 року. Це саме той період, коли компанії почали робити ставку на «економію» та Copilot.
Те, що ми бачимо у звіті (зростання Code Churn, зниження якості) — це зафіксований факт наслідків цієї стратегії.
Те, що пройшов рік і вийшли нові моделі, не відміняє фізики процесу: мільйони рядків неякісного коду, згенеровані у 2024–2025 роках, зараз знаходяться у продакшені. І компанії витрачають бюджети 2026 року на боротьбу з цим технічним боргом, а не на інновації.

2. Відсутність контр-даних.
Ви стверджуєте, що «все змінилося». Але де ваші дані?
Поки немає жодного індустріального звіту (на вибірці хоча б у 10 млн рядків коду, а не особистих вражень), який би показав, що у 2026 році крива Code Churn різко пішла вниз.
Доки таких даних немає, ваша позиція — це віра («цього разу буде інакше»), а моя позиція — це аналіз трендів («поки процеси не зміняться, результат буде той самий»).

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

Відповісти
Підтримати
Alexander P
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 17:32

На індивідуальному рівні, посилаючись виключно на власні відчуття, я можу з вами погодитись.

Opus — дійсно потужний, NotebookLM — вражаюча річ для роботи з джерелами. Мій власний сетап (Obsidian + Cloud Code + Copilot) теж кардинально підвищив мою продуктивність і швидкість аналізу розрізнених даних. Технологія справді вражає і дає буст.

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

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 07.01.2026 17:43

Виталий, я вам еще раз объясняю, что ваши данные в настоящий момент не стоят ничего, так как они датированы январем 2025 года, а значит, устарели. соответственно, и ваш сегодняшний анализ на основании данных за 2024 год был бы уместен в январе прошлого года, а не сейчас. дождитесь свежего отчета, что ли.

про инерцию, да, это вы верно подметили. новые приемы быстрее всего схватывают в малых командах с высокими автономностью и скоростью принятия решений. в суровом энтерпрайзе сначала закупают на всех лицензии копайлота, а потом удивляются. но я верю во всемогущую руку рынка, те, кто смогут адаптироваться, масштабировать инициативы снизу на процессы всей компании, те выживут. и это правильно.

Відповісти
Підтримати
Vitalii Oborskyi
Просто Анон 08.01.2026 00:18
Релевантність даних.
Звіт за січень 2025 року підсумовує результати масового впровадження AI-асистентів протягом 2024 року.

Як ви стали менеджером? Сперечаєтесь коли вам кажуть що число 4 парне.

Вам уже кілька разів написали що АІ агенти тільки з’явились у 2025, а реальне впровадження це друга половина 2025.
Як можна взагалі посилатись на дані 2024?

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 09:08

Дякую за турботу про мою кар’єру. Менеджером стають, коли вміють аналізувати факти, а не жити у світі бажаного.

Ви стверджуєте, що «АІ агенти з’явилися у 2025» і все змінили?
Ось вам звіт GitClear саме за 4-й квартал 2025 року (дані за вересень-жовтень 2025), який враховує вплив агентів:
www.gitclear.com/...​_output_from_2022_to_2025

Що ми бачимо в «епоху агентів» (2025 рік):
1. **Lines of Code Added (обсяг коду):** вибухове зростання на **131%** порівняно з базою.
2. **Commit Count (реальна робота):** зростання лише на **6–9%**.

Тобто ваші «агенти» у 2025 році не виправили ситуацію, а погіршили її. Вони дозволили генерувати сміттєвий код (Churn) ще швидше, ніж у 2024-му, при цьому корисний «вихлоп» залишився майже незмінним.
Тому перш ніж звинувачувати когось у некомпетентності, раджу ознайомитися з актуальною статистикою, а не лише з маркетинговими брошурами про «успішний успіх».

Відповісти
Підтримати
Просто Анон
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 08.01.2026 09:16

Якщо ваш наступний аргумент буде в стилі «просто агенти ще не встигли, ефект буде у 2026-му», то мушу вас зупинити.

Я у своїй роботі керуюся не емоціями, відчуттями чи гаданням, а аналітикою на базі трендів. А тренд із моменту появи перших копайлотів і до епохи агентів (включно з Q4 2025) є абсолютно чіткий і послідовний:
1. Ефективність (корисна робота) зростає маржинально (в межах 5–10%).
2. Code Churn (сміттєвий код) зростає вибухово (в рази).

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Alexander P 07.01.2026 14:31
Саме Middle-розробник часто знає реалізацію конкретної фічі та її «підводні камені» краще за будь-якого архітектора. І ніякий Cursor цього не замінить. ШІ може за 2 хвилини пояснити, *що* робить цей код. Але він не пояснить, *чому* ми написали його саме так пів року тому після складної розмови з клієнтом. ШІ не має історичної пам’яті про домовленості та компроміси.

я думаю, тут проблема не с AI, а с тем, что все держится на памяти мидлов. для начала процессы в компании чинить надо, AI тут ни при чем. AI тут наоборот, поможет, потому что будет поддерживать документацию в актуальном состоянии.

на мой взгляд, статья устарела, все меняется очень динамично. согласен с ораторами выше, что Senior + AI с умелыми приемами использования — это сильный буст в производительности, джуны становятся просто не нужны.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 15:08

Ви зачіпаєте цікаву тему «живої документації». Але тут є фундаментальна помилка в очікуваннях.

1. Щодо документації: ШІ чудово описує «Що робить цей код» (імплементацію). Але він, як і код, не знає «Чому було прийнято таке рішення» (інтенцію).
У розробці є принцип «Паркан Честертона»: не розбирай паркан, доки не зрозумієш, навіщо його поставили. ШІ бачить паркан і може описати його висоту та колір. Але він не знає, що ми поставили його, бо 3 роки тому тут «бігали вовки» (специфічна вимога регулятора або обмеження старого API). Цей контекст живе в головах людей (часто тих самих мідлів), а не в коді. Якщо ви їх звільните, ви залишитесь з ідеально задокументованим, але небезпечним для змін кодом.

2. Щодо «стаття застаріла»: Динаміка дійсно шалена, але закони економіки та соціології не змінюються так швидко, як версії LLM.
Якщо ми сьогодні знищимо клас джуніорів як явище, то через 5 років ми отримаємо кризу пропозиції на ринку сеньйорів. Це не питання технологій, це питання ланцюга постачання (Supply Chain) кадрів. Ви пропонуєте з’їсти все зерно сьогодні, не залишивши нічого на посів, сподіваючись, що «технології щось придумають». Це ризикована ставка.

Відповісти
Підтримати
Alexander P
Alexander P 07.01.2026 16:18

любой кусок кода должен быть привязан к спеке, а та, в свою очередь привязана к требованию, а там указано как и когда это требование возникло. если у вас это не делается, то проблема у вас не в AI, а в банальных процессах. потому что умные люди еще 40 лет назад в индустрии описали, как должны строиться процессы, чтобы все не держалось в головах людей.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 16:43

Методологічно ви праві на 100%. Але ми живемо не в підручнику, а в реальному світі.

Такий рівень наскрізної простежуваності (Traceability: вимога -> спека -> код) на практиці реалізований у одиниць, навіть серед Enterprise-сектору. Більше того, звіти за 2024 рік показують, що саме «Data Silos» (ізольованість даних) та їхня низька якість стали головним бар’єром, через який буксують масштабні ШІ-трансформації у гігантів.

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

Я детально розбирав цю проблему тут: dou.ua/forums/topic/54329
Власне, через відсутність Traceability «з коробки» на рівні платформ, вендори (як Atlassian) пропонують для масового ринку не глибокі ШІ-інтеграції, а поверхневі «маркетингові фічі». ШІ просто ні на що спертися в хаосі реальних даних, щоб дати валідний результат, а не галюцинацію.

Відповісти
Підтримати
Alexander P
Alexander P 07.01.2026 16:50
в реальному світі.

в реальном мире те, кто так не делают, те не выживают. я в индустрии коммерческой разработки ПО с 1999 года, видел всякое. плохие процессы закрываются людьми, потому что узкое место всегда было одно и то же — конкретное рутинное кодирование. вот сейчас это узкое место расшивается и те, у кого с процесами все в порядке, получают невиданный ранее буст. а те, кто привык,что у них документация держится только в головах мидлов — ну что, посочувствуем им.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 17:00

Олександре, тут я змушений не погодитись із вашим визначенням «вузького місця».

1. Щодо «пляшкового горлечка» (Bottleneck).
За всі роки існування Software Engineering (і ви з досвідом з 1999 року це точно бачили) вузьким місцем було не «рутинне кодування» (набір синтаксису), а боротьба з невизначеністю: збір вимог, комунікація та архітектурне узгодження.
ШІ дійсно «розшив» кодування. Але він ніяк не вирішив проблему невизначеності. Якщо у вас хаос на вході (вимоги), то ШІ просто швидше згенерує хаос на виході (код). Це не буст, це прискорення ентропії.

2. Щодо «у кого з процесами все в порядку».
Ви говорите про ідеальний світ. Але об’єктивні звіти за 2024 рік (від Gartner, Deloitte та звітів самих техногігантів) показують іншу картину.
Головна причина провалу пілотних проектів з GenAI у Enterprise — це не відсутність інструментів, а **Data Quality** та **Data Governance**.
З’ясувалося, що навіть у Fortune 500 компаній, де «процеси мали б бути в порядку», документація, вимоги та код живуть у різних, незв’язаних силосах (Silos). ШІ не може побудувати контекст, бо дані фрагментовані.

Тобто: навіть гіганти з їхніми бюджетами та комплаєнсом виявилися не готовими до вимог ШІ щодо зв’язності даних. Сказати «поспівчуваємо тим, хто не впорався» — це поспівчувати 90% індустрії, включаючи лідерів ринку. Проблема не в ліні («погані процеси»), а в тому, що стандарти документування для *людей* і для *ШІ* — це різні речі. І індустрія тільки зараз починає це розуміти.

Відповісти
Підтримати
Alexander P
Микола Сидоренко 06.01.2026 21:10

Хороша стаття! Нарешті все це розкладено по поличках.
Очікую коментарів від нашого місцевого Трампа. ))

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 00:03

Дякую. Вас може зацікавити і мій проект. Або інші статті. Вони всі в такому ж стилі, доволі багато фреймів та аналітики. Правда і статті є доволі великі

Відповісти
Підтримати
Микола Сидоренко
Donald Trump 07.01.2026 06:59

Так а що тут нового? Тут очевидні речі про які і так всі знають і говорять, поки не перекручується журналістами і ШІ дисидентами в жовті заголовки, типу цього:

Наратив про те, що AI дозволить компаніям негайно урізати інженерні бюджети на 20–30%, є не просто оптимістичним; він структурно небезпечний.

Цей наратив придумують автори, які такі статті пишуть ). Ну і журналісти щоб було про що писати. Насправді ніхто про негайні бенефіти і скорочення бюджету не говорить.

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

Карпати про це влучно сказав:
x.com/...​tatus/2004607146781278521

Но мало хто прочитає що там реально написано, прочитають те що хочуть побачити і напишуть жовті заголовки

Відповісти
Підтримати
Микола Сидоренко
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 08:52

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

Власне, про це і стаття. Проблема не в тому, що AI поганий, а в тому, що бізнес (а не журналісти) часто купує ілюзію «легкої економії».

Щодо тези «ніхто не говорить про скорочення» — на жаль, це фактологічна помилка. Ринок переповнений саме такими рішеннями від C-level:
— IBM відкрито заявили про план замінити 7800 робочих місць на AI протягом 5 років.
— Klarna заморозила найм, звітуючи про те, що AI-бот замінив роботу 700 людей.
— BT Group (British Telecom) оголосили про план скоротити 55 000 робочих місць до 2030 року, замінивши 10 000 з них на AI.

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

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

Відповісти
Підтримати
Donald Trump
Donald Trump 07.01.2026 10:41
Проблема не в тому, що AI поганий, а в тому, що бізнес (а не журналісти) часто купує ілюзію «легкої економії».

Я думаю що бізнес якраз і розуміє і ніхто ніяких ілюзій не строїть і не очікує миттєвих результатів. Хоча... менеджери різні бувають

— IBM відкрито заявили про план замінити 7800 робочих місць на AI протягом 5 років.
BT Group (British Telecom) оголосили про план скоротити 55 000 робочих місць до 2030 року, замінивши 10 000 з них на AI.

Ну, і де тут наратив «що AI дозволить компаніям негайно урізати інженерні бюджети на 20–30%»? Чи 5 років це «негайно»? Хоча на мою думку доволі консервативний сценарій. Вже через 1-2 роки будуть економію отримувати, якщо тупити не будуть.

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 11:14

Формально ви праві: IBM та BT озвучили довгострокові плани. Але теза про те, що «ніхто не ріже одразу», на жаль, хибна. Ми вже маємо приклади дій, а не планів, за останні 18 місяців:

1. Dropbox (квітень 2023): скоротили 16% штату (500 людей). CEO прямо заявив, що «ера ШІ вимагає іншого міксу навичок», фактично замінюючи одних людей іншими.
2. Duolingo (січень 2024): скоротили 10% контриб’юторів, прямо вказавши, що їхню роботу тепер робить ШІ.
3. Intuit (червень 2024): звільнили 1800 людей (10%), щоб «прискорити інвестиції в ШІ».

Тобто «логіка Excel» працює вже зараз: звільнити одних, щоб нібито вивільнити бюджет на ШІ.

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

Логічне питання: навіщо звільняти першу групу? Ці люди — носії інституційної пам’яті. Найрозумніше рішення — це довчити їх (Reskilling), щоб вони будували нове покоління продуктів, спираючись на знання бізнесу. Якщо ж компанія обирає шлях «звільнити старих — найняти нових (або замінити ботом)», то це банальна оптимізація витрат, яка ігнорує цінність доменної експертизи. І саме це я називаю небезпечною ілюзією.

Відповісти
Підтримати
Donald Trump
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 11:20

І наостанок, важливе уточнення. У статті я спираюсь не лише на власні тези, а й на об’єктивні галузеві дані, доступні на цьому етапі. Зокрема, на звіт GitClear щодо різкого зростання Code Churn.

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

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

Відповісти
Підтримати
Vitalii Oborskyi
Oleksii Kraievyi 06.01.2026 16:32
Але він не вирішив складних завдань: розуміння архітектури системи, управління залежностями та забезпечення відповідності бізнес-логіки потребам користувача.

Нажаль це не зовсім правда, є вже спеціалізовані інструменти як sourcegraph deepsearch які дозволяють це проаналізувати і робити пропозиції на підставі цього, інше діло що там все одно треба валідувати результат, але це вже ± допомогає вкатитися у новий проект

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 16:50

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

Є два бар’єри, які «коробковий» ШІ, найімовірніше, не подолає ніколи:
1. Бізнес-контекст. Архітектура завжди прив’язана до бізнес-цілей та вимог користувача. ШІ-асистент не «бачить» цього зв’язку, він працює лише з кодом.
2. Розрив експертизи. Навіть якщо ШІ генерує ідеальний складний код, в команді є джуніори та мідли, які часто не здатні його верифікувати чи підтримувати. Це призводить до зростання Code Churn (за даними GitClear), бо код стає некерованим.

Але давайте уявімо на секунду, що ці проблеми вирішені: ШІ знає бізнес-вимоги і пише ідеальний код. Тоді ми потрапляємо в утопію, де не потрібні ні інженери, ні менеджери, ні C-level. Ринок наповнений ШІ-компаніями, які створюють продукти для інших ШІ. Звучить абсурдно? Саме так. Тому десь у цьому ланцюгу припущень про «всемогутність» інструментів є фундаментальна помилка.

Відповісти
Підтримати
Oleksii Kraievyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 16:56

І додатково — все ж таки я описував період 2024-2025 коли інструменти були не такими потужними. А рішення приймались — як описано. Це на мій погляд не змінює логіки і я описав свій аргумент вище. І з вами я згоден що інструменти стають краще і повторю основну думку статті — щоб перейти на новий рівень створення цінності зараз компаніям треба активно інвестувати та розвиватись. Купляти ліцензії, нову інфтрастуктуру, нові тули, навчати своїх людей, трансформуватись. І це — додаткові інвестиції і ніяк не скорочення хедкаунта.
Мені здається ваш приклад Sourcegraph скоріше про це. Його недостатньо купити — його треба адаптувати на рівні організації. Це потребує інвестицій.

Відповісти
Підтримати
Vitalii Oborskyi
Oleksii Kraievyi 06.01.2026 17:27

Зараз задача будь-якої компанії з грошима — це взяти коробковий ШІ і дати йому свій контекст через MCP, RAG ітд, але це все одно лише допоміжний інструмент

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 17:31

І навіть це — інвестиції. Тобто у нас наче тут консенсус. А от різати команди та щось трохи купити але не системно а ще 0 затрат на адаптацію та навчання — як робили часто 2 останні роки це не просто помилка. Це стратегічне самогубство. Просто мрець ще в курсі що вже помер

Відповісти
Підтримати
Oleksii Kraievyi
Oleksii Kraievyi 06.01.2026 17:33

Ну зараз вже не перший місяць йде розмова про «ШІ-бульбашку», коли один СЕО ШІ-компанії підживлює хайп щоб не бути не в тренді і питання до чого це призведе. Я ставлю на те що буде щось типу нового клауда для ШІ (як було після кризи доткомів) + дешевша електроенергія бо побудують електростанції для дата центрів які будуть не потрібні і той кількості

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 17:45

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

Історія бізнесу — це кладовище гігантів, які вирішили, що технологічний зсув — це тимчасова мода. Згадайте Blockbuster, який мав шанс купити Netflix, але відмовився, бо не вірив у цифрову дистрибуцію. Або Kodak, який фактично винайшов цифрову камеру, але побоявся вбити свій плівковий бізнес. Вони теж мали солідні позиції, були «розумними» та «обережними».

Де вони зараз? Їхні ринки забрали ті, хто не побоявся інвестувати та адаптуватися.

Сьогодні ми в тій самій точці. ШІ — це настільки руйнівна (disruptive) технологія, що відсидітися осторонь не вийде. Ви або ризикуєте: йдете вперед, інвестуєте, помиляєтесь і постійно корегуєте стратегію (і це важко). Або просто зникаєте.
До речі, коли ви востаннє чули про успішні нові продукти від Blockbuster?

Відповісти
Підтримати
Oleksii Kraievyi
Donald Trump 07.01.2026 08:26

Та не тільки це. Із статті складається враження що ШІ тільки код пише. Насправді:
— зрозуміти проекти, архітектуру, код які ти бачиш перший раз чи який не бачив пів року — ШІ
— знайти потрібний функціонал в тисячах файлах коду — ШІ
— знайти баг в коді — ШІ (якщо не знайде, то ідеї підкине)
— знайти релевантну внутрішню документацію — ШІ
— розібратися з кастомер тікетом — ШІ (розбереться що хоче кастомер, знайде потрібну документацію, знайде потрібний код, полистає логи, в 50% випадках знайде проблему чи відповідь відразу, і це за 5-10 хв)
— проревьювити код — ШІ
— робота з документами — ШІ

Це те що на вскидку в голову приходить.

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

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

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

Відповісти
Підтримати
Oleksii Kraievyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 07.01.2026 09:11

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

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

Саме для вирішення цієї проблеми ми з групою однодумців розробляємо концепцію «Архітектури Невизначеності». Це спроба систематизувати цей перехід:
github.com/...​/uncertainty-architecture

Відповісти
Підтримати
Donald Trump
Oleksandr Viter Senior Software Engineer в SoftServe 06.01.2026 13:25
AI зробив найпростішу частину розробки — генерацію синтаксису — фактично безкоштовною

Це мені нагадує відому історію про «Загальна вартість послуг інженера — 10 000$. 1$ — за удар молоточком, 9999$ — за знання правильного місця і сили удару». Так само й у нашій сфері (software engineering): фактичне написання коду — це лише мала частина роботи і цінності програміста, а основне value, яке має програміст — це розуміння контексту проєкту, домену, особливостей проєкту, замовників, користувачів і т.д. А це все те, що поки що важко дається АІ. Тобто АІ поки що гарно та швидко вміє «стукати молоточком», але погано та неточно обирає місця і силу для ударів.

З іншого боку, якщо подивитися на попередні революційні технології: парові машини, автомобілі, літаки, електродвигуни і т.д. — їм знадобилися десятки років, щоб перейти від перших прототипів до реально крутезних масових виробів з високою якістю. На такому ж початковому етапі зараз знаходиться й АІ та робототехніка, які реально активно почали розвиватися лише декілька років тому (до цього вони розвивалися дуже пасивно). Тож дамо цим технологіям років 20 і подивимось, у що вони еволюціонують. А те, що вони точно еволюціонують ми можемо бачити на прикладі іншої технології, яка стартанула трохи раніше — електромобілі. Перші Тесли почали продаватися у 2008 — майже 20 років тому. А зараз вже півсвіту пересідає на електромобілі. Перші AI coding assistance почали активно використовуватися десь у 2019, тож можемо очікувати що приблизно у 2035-2040 роках вони будуть так само кращі за поточних, як і поточні електромобілі кращі за екземпляри 2010-х років.

Відповісти
Підтримати
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 14:56

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

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

J-Curve ніхто не скасовував: трансформація потребує інвестицій. Компанії, які зараз обирають шлях сліпого скорочення, ризикують не просто не дійти до «Горизонту 2», а взагалі перестати існувати. ШІ кардинально трансформує ланцюг створення цінності, і це вимагає ресурсів, а не урізання бюджетів.

Відповісти
Підтримати
Oleksandr Viter
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 15:10

Наведу конкретний приклад того, що я називаю «трансформацією ланцюга створення цінності».

Візьмемо негласний стандарт індустрії — співвідношення Senior-інженерів до менш досвідчених колег. Зазвичай це було 1 до 3–5. Тобто один експерт міг ефективно валідувати якість роботи групи.

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

Але найгірше те, що через генеративний код навантаження на рев’ю для сіньйора зросло критично. Фактично, щоб втримати якість, коефіцієнт має бути ледь не 1 до 1. Щоб це виправити без скорочення штату, потрібні інвестиції, а не економія. Наприклад — розробка власних AI-агентів для Code Review, навчених на базі знань конкретного проєкту. Це дозволить розвантажити людей.

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

Відповісти
Підтримати
Vitalii Oborskyi
Vitalii Oborskyi PMO&amp;Delivery Head в Developex 06.01.2026 16:11

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

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

1. Розрив інтересів. Вендори AI-тулів зацікавлені у продажу ліцензій та масовій адаптації. Їх не хвилює специфіка вашого бізнесу чи ваші ризики. Адаптація інструменту під ваші реалії — це виключно ваша проблема.

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

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

Відповісти
Підтримати
Vitalii Oborskyi

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.