Субпрайм-криза коду: чому AI-асистенти роблять нас повільнішими — і дані це доводять
«Питання не в адопції AI, а у виживанні операційної моделі.»
Попередня моя стаття «Ілюзія економії: чому заміна розробників на AI — це шлях до технічного дефолту» була присвячена критиці стратегії скорочення штату інженерів, аргументуючи такий крок наявністю куплених ліцензій ШІ-асистентів (8000+ переглядів, 230+ коментарів).
Але як робота над статтею, так і дискусії з читачами змусили мене самого уважніше придивитись до наявних цифр. Ця стаття — логічне продовження, мета якого — проаналізувати: а чи взагалі ШІ код-асистенти є доказово корисними? Чи дають вони збільшення швидкості делівері загально? Чи є вони надійною технологією на
Спойлер: ні, не дають і не є надійними. Тож запрошую вас до ознайомлення з анатомією Субпрайм-бульбашки коду.
Ми фіксуємо системний збій, що розгортається в реальному часі. Поки ринок святкує «AI Productivity Boom», об’єктивні метрики доставки розповідають іншу історію. Це не революція цінності — це надування Субпрайм-бульбашки коду. Ця стаття — перша з серії, що аналізує механіку цього збою на основі незалежних досліджень.
Що таке «Субпрайм-криза коду»?
Цей термін є прямою відсилкою до фінансової кризи 2008 року. Щоб зрозуміти, що відбувається в IT сьогодні, варто згадати механіку того колапсу:
1. Токсичні активи: Тоді банки видавали кредити людям, які не могли їх повернути (subprime mortgages). Сьогодні ми маємо «дешевий синтаксис» — величезні обсяги коду, згенерованого ШІ, який виглядає робочим, але має низьку якість та високу приховану складність.
2. Ілюзія надійності: У
2008-му сміттєві кредити упаковували в складні фінансові інструменти та позначали як «надійні активи класу ААА». Сьогодні бізнес упаковує низькоякісний ШІ-код у звіти про «зростання продуктивності на 55%», створюючи ілюзію швидкого прогресу на дашбордах.3. Системний ризик: Коли критична маса таких «токсичних активів» (неперевіреного, складного та дубльованого коду) накопичується в репозиторіях, настає момент технічного дефолту. Система стає настільки крихкою та дорогою в обслуговуванні, що будь-яка спроба змінити бодай щось призводить до колапсу.
Субпрайм-криза коду — це ситуація, коли ми пожертвували довгостроковою стабільністю системи заради короткострокової ілюзії швидкості. Ми «купуємо» рядки коду за безцінь сьогодні, щоб заплатити за них мільйонами доларів на підтримку та виправлення дефектів завтра.
Глава 1. Велика ілюзія: чому ми відчуваємо швидкість, а дані показують уповільнення
Запитайте будь-якого розробника, як йому працюється з AI Code Assistant, і ви почуєте одне слово: потужно. «Синдром чистого аркуша» мертвий. Бойлерплейт генерується за мілісекунди. Суб’єктивно тертя зникло — і виникає відчуття, що ми рухаємось у 10 разів швидше.
Але якщо відійти від IDE і подивитись на метрики доставки, виникає тривожний парадокс. Якщо кожен інженер «швидший» — чому Time-to-Market не обвалився? Чому релізи фіч буксують?
Щоб зрозуміти це, потрібно дивитись на холодні дані незалежних досліджень, а не на маркетинг вендорів.
«Штраф для сеньйорів»: підтверджено на масштабі
Найшкідливіший міф ери AI — що він перетворює джунів на сеньйорів, а сеньйорів на «10x» архітекторів. Реальність складніша. Зараз у нас є докази з двох незалежних векторів: контрольований експеримент і масштабне лонгітюдне дослідження.
1. Механіка уповільнення (METR, липень 2025):
У рандомізованому контрольованому дослідженні вимірювали вплив AI на досвідчених open-source розробників, які працювали у власних репозиторіях.
- Результат: З використанням frontier AI-асистентів (Cursor Pro з Claude 3.5/3.7) розробники виконували завдання на 19% повільніше, ніж без них.
- Суб’єктивна ілюзія: Попри реальне уповільнення, розробники вірили, що AI зробив їх швидшими. Вони прогнозували прискорення на 24% і навіть після експерименту оцінювали свій виграш у 20%.
Перечитайте це ще раз: люди стали на 19% повільніше і при цьому були впевнені, що стали на 20% швидше. Розрив між відчуттям і реальністю — ось де починається криза.
2. Валідація на масштабі (Xu et al., 2025):
Критики часто відкидають контрольовані дослідження як «занадто малі». Але Xu et al. проаналізували телеметрію від понад 10 000 розробників у різних enterprise-середовищах і незалежно підтвердили «Штраф для сеньйорів» на масштабі.
- Перерозподіл праці: Периферійні контриб’ютори (джуни) вибухнули продуктивністю (+43.5% комітів), а Core Contributors (сеньйори) побачили колапс свого кодового виходу (-19% комітів).
- Пастка підтримки: Замість того щоб писати код, сеньйори були змушені перейти до його рев’ю — їхнє навантаження на рев’ю зросло на +6.5%. І критично: AI-згенерований код потребував на 2.4% більше переробок на кожен PR, щоб відповідати стандартам якості.
Чому такий розрив?
AI змістив роль сеньйора з «Автора» на «Рев’юера/Дебагера». Сеньйори не зекономили час на написанні — вони втратили час на розплутування машинної складності.
Когнітивний податок: складність та попередження
Якщо ми друкуємо швидше, що саме ми виробляємо? Agarwal et al. (2026) провели глибокий структурний аналіз AI-згенерованих кодових баз порівняно з написаними людьми. Результати пояснюють, чому тягар підтримки вибухає:
- Попередження статичного аналізу (+18%): AI-агенти систематично вносять тонкі порушення правил лінтингу та best practices, які людські сеньйори зазвичай фільтрують інстинктивно.
- Когнітивна складність (+39%): Це вбивча метрика. Код, згенерований AI, функціонально коректний, але структурно заплутаний. Йому бракує елегантності та читабельності людської логіки.
Ми не просто генеруємо код — ми генеруємо технічний борг зі швидкістю +39% складності на кожну фічу. Саме тому Code Review стає новим вузьким місцем.
Дані: криза якості (GitClear)
Коли ми накладаємо дані про складність (Agarwal) на дані про обсяг (GitClear), картина стає повною. Аналіз 211 мільйонів рядків коду відносно базової лінії 2022 року:
Ілюзія продуктивності (метрики активності):
- Додано рядків коду: +131.1% — обсяг сирого синтаксису більш ніж подвоївся. Ми генеруємо код у промисловому масштабі.
- Вибух дублювання (~10x): Коміти з дубльованим кодом зросли з 0.70% (2020) до 6.66% (2025). Замість рефакторингу ми копіпастимо через AI.
- Смерть перевикористання: Перевикористання коду («Moved» рядки) впало з ~25% до <10%. AI просто генерує нові версії існуючих функцій.
Реальність прогресу (метрики цінності):
- Чистий приріст продуктивності (зважена медіана): ~9.0% — усереднюючи медіанні Commit Counts (+6.1%) та значущі зміни коду (Diff Delta +14.1%), ми отримуємо чистий приріст приблизно
9-10%.
Це збігається з публічними заявами керівництва Google. Наприкінці 2025 року CEO Сундар Пічаї розкрив внутрішній вимір інженерної швидкості: «Наші оцінки — це число зараз на рівні 10%.» Хоча це неаудитована заява, її скромність примітна — враховуючи, що Google має стимул звітувати про вищі показники, і враховуючи мільярди доларів внутрішньої інфраструктури, які роблять навіть ці 10% можливими (див. Главу 2).
Визнання позитивних доказів
Наукова чесність вимагає розглянути знахідки, які, здається, суперечать нашій тезі.
Ми не заперечуємо, що AI прискорює ізольовані завдання кодування, особливо для менш досвідчених розробників. Докази цього надійні. Peng et al. (2023) провели рандомізоване контрольоване дослідження (n = 196), яке показало прискорення на 55.8% на greenfield-завданнях. Xu et al. (2025) — те саме дослідження, яке ми цитуємо вище — підтверджує, що периферійні контриб’ютори побачили зростання на +43.5% в обсязі комітів. Окремі розробники, особливо джуни, дійсно пишуть код швидше з AI.
Наше занепокоєння інше: ці локальні виграші не транслюються в системне покращення продуктивності — і можуть активно його деградувати. Дослідження Peng et al. вимірювало ізольоване виконання завдань у greenfield-середовищі — написання маленьких програм з нуля. Це має обмежену релевантність для brownfield enterprise-інженерії, де
Питання не в тому, чи AI робить друкування швидшим. Робить. Питання в тому, чи швидше друкування робить систему швидшою. Дані кажуть — ні.
«Фактор страху» в продуктивності
Є ще темніша інтерпретація скромного ~10% чистого приросту продуктивності. Чи є цей приріст технологічним — чи психологічним?
Наратив «AI робить кодування безкоштовним» дійшов до кожного спонсора проєкту. Це створило координований, імпліцитний тиск на інженерні команди доставляти швидше.
Ми зазначаємо це як неперевірену гіпотезу, що потребує окремого дослідження:
Розробники не просто використовують AI — вони працюють більше, щоб відповідати роздутим очікуванням. Значна частина цього «приросту» може бути результатом збільшених робочих годин та підвищеного стресу, спричинених страхом бути заміненим або виглядати «повільним» в еру AI. Ранні дані опитувань фіксують зростання тривожності серед розробників щодо витіснення AI (Stack Overflow Developer Survey, 2024). Можливо, ми плутаємо «ефективність» з «виснаженням».
Прогалина в доказах: коли маркетингові «вайби» замінюють операційні дані
Будь-який сеньйор-інженер, читаючи це, має відчути скепсис: чи об’єктивно будувати кризовий наратив на кількох джерелах?
У здоровій інженерній культурі ми б вимагали десяток незалежних точок даних. Ми б хотіли порівняти ці негативні знахідки з лонгітюдною телеметрією від самих вендорів.
Але ми змушені спиратись на ці обмежені сигнали з однієї тривожної причини: даних від вендорів не існує.
Три роки «AI-революції» — і компанії, які продають це майбутнє, які сидять на найбільшому датасеті інженерної поведінки в історії людства, досі не опублікували жодного ригористичного, незалежного дослідження, яке б демонструвало, що AI знижує Total Cost of Ownership або Defect Rates у реальному Enterprise-середовищі.
Замість операційних доказів публічний наратив домінується тим, що можна назвати лише «Плацебо-аналітикою»:
- Патерн опитувань: Вендори часто цитують цифри на кшталт «88% розробників відчувають себе продуктивнішими.» Але, як показали METR та Xu et al., суб’єктивна впевненість — поганий проксі для реальної продуктивності. Ці опитування вимірюють настрій щодо адопції («Вам подобається інструмент?»), а не результати доставки («Система доставила цінність швидше?»).
- Патерн синтетичних бенчмарків: Заяви на кшталт "55% швидша розробка«походять з Greenfield — написання маленького коду з нуля. Ці виграші реальні, але вузькі. Вони мають обмежену релевантність для Brownfield — підтримки великих, legacy-кодових баз, що становить
80-90% enterprise-інженерії.
Фалація «Ви неправильно тримаєте»
Ми передбачаємо стандартний захист від вендорів: «Якщо розробники мерджать поганий код — це помилка користувача, а не інструменту. Ви неправильно використовуєте асистент.»
Цей захист недостатній.
Якщо «режим за замовчуванням» використання по всьому ринку — спричинений власними маркетинговими обіцянками вендорів про «швидкість» — призводить до деградації кодових баз, це не просто помилка користувача. Це системний провал дизайну та позиціонування. Коли електроінструмент агресивно продається споживачам без адекватних інструкцій з безпеки, без захисного обладнання, і з маркетингом, що підкреслює швидкість замість обережності — ми не звинувачуємо лише користувача, коли зростає кількість травм. Ми притягуємо виробника до відповідальності за продаж потужності без адекватних запобіжників.
Відповідальність вендорів — змістити основні метрики AI Code Assistants з «Acceptance Rate» (як часто ви натискаєте Tab) на «Defect Reduction» та «Maintainability».
Висновок: конвеєр одноразового коду
Дані ведуть до неминучого висновку: ми сплутали Швидкість Друку з Інженерною Швидкістю.
Ми побудували високошвидкісний конвеєр для одноразового коду. Знизивши вартість генерації синтаксису до майже нуля, ми затопили наш SDLC низькоякісним (+18% попереджень), високоскладним (+39%) кодом. Ми відчуваємо швидкість, бо менше друкуємо, але доставляємо повільніше, бо тонемо в шумі, який самі створили.
Ми не прискорили software engineering — ми прискорили створення технічного боргу.
Джерела до Глави 1:
METR (липень 2025): «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» — RCT з 246 завданнями, 16 розробниками. AI-асистенти роблять досвідчених розробників на 19% повільнішими. Розробники вірять, що стали на 20% швидшими. metr.org
Xu et al. (arXiv, 2025): «AI-Assisted Programming Decreases the Productivity of Experienced Developers» — Аналіз 10 000+ розробників: +6.5% навантаження на рев’ю, +2.4% переробок для сеньйорів, —19% кодового виходу Core Contributors. +43.5% комітів для периферійних контриб’юторів. arxiv.org
Agarwal et al. (arXiv, 2026): «AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents» — AI-згенерований код: +18% попереджень статичного аналізу, +39% когнітивної складності. arxiv.org
Peng et al. (arXiv, 2023): «The Impact of AI on Developer Productivity: Evidence from GitHub Copilot» — RCT (n = 196): прискорення на 55.8% на greenfield-завданнях, переважно для менш досвідчених розробників. arxiv.org
GitClear (2025): «AI Assistant Code Quality 2025 Research» — Дублювання коду зросло у ~10 разів, перевикористання впало з ~25% до <10%. Датасет: 211 млн змінених рядків. gitclear.com
Stack Overflow Developer Survey (2024): Зростання тривожності розробників щодо витіснення AI. survey.stackoverflow.co
Глава 2. Прихований цінник: реальна вартість того, щоб AI працював
Попередня глава показала, що бачать інженери на землі. Ця глава про те, що ці дані означають для бізнесу — конкретно, для керівників та фінансових директорів, які затверджують AI-бюджети без видимості повної вартості того, щоб ці бюджети стали продуктивними.
Великі технологічні компанії часто зазначають, що вони успішно використовують ці інструменти всередині. Немає підстав сумніватися в цьому. Але те, про що рідко говорять — це повна структура витрат за цим успіхом.
Такі організації працюють з виключною інженерною зрілістю. Вони роками інвестували у внутрішні платформи, архітектурне управління та автоматизацію рев’ю, які поглинають додаткову складність, привнесену AI. Це не дрібна операційна деталь. Це фундамент, на якому побудований будь-який «приріст продуктивності від AI».
Невидима інфраструктура
Розгляньте інженерну інфраструктуру, яка існувала в Google до того, як був написаний хоча б один рядок AI-асистованого коду:
- Blaze/Bazel: Система збірки, яку інженерили понад десятиліття для роботи з монорепо на мільярди рядків коду.
- TAP (Test Automation Platform): Інфраструктура, що виконує приблизно 4.2 мільярди тестових запусків на день — система, на створення та підтримку якої пішло понад 15 років і, за розумними оцінками, значно більше $1 мільярда.
- Critique: Внутрішня платформа для code review з глибокою інтеграцією статичного аналізу, перевірки стилю та автоматичних чеків — яка замінює потребу людини ловити ті самі «правдоподібні брехні», які генерує AI.
- Tricorder: Фреймворк статичного аналізу, який автоматично позначає проблеми до того, як рев’юер побачить код.
Ці системи детально задокументовані у власних інженерних публікаціях Google. Вони представляють кумулятивну інвестицію
Microsoft підтримує 1ES (One Engineering System) та CodeFlow. Meta перебудовувала свою внутрішню платформу розробки кілька разів. Витрати на R&D, що фінансують ці системи, вражають:
| Компанія | Річний R&D (CY2024) | Річний CapEx (CY2024) | Плани CapEx (2025) |
|---|---|---|---|
| Alphabet (Google) | $45.4B | $52.5B | ~$75B |
| Meta | $44.4B | $39.2B | $60—65B |
| Microsoft | $29.5B (FY2024) | $44.5B (FY2024) | ~$80B |
Джерела: Alphabet
Коли Сундар Пічаї каже інвесторам, що AI дає «10% приросту продуктивності», цей приріст вимірюється поверх цього мультимільярдного фундаменту. Це не приріст від самої ліцензії на AI. Це приріст від ліцензії плюс десятиліття інфраструктурних інвестицій, які роблять безпечну адопцію можливою.
Мультиплікатор трансформації
Коли ті самі AI-інструменти продаються зовні — організаціям, які не мають цієї оточуючої операційної моделі — ринок створює небезпечну ілюзію: що порівнянних результатів можна досягти переважно через купівлю ліцензій.
Давайте кількісно оцінимо цю ілюзію. Пряма вартість AI-інструментів для середнього enterprise (1
GitHub Copilot Business: $19/користувач/місяць ≈ $228K/рік для 1 000 інженерів.
Тепер розгляньте реальну вартість побудови інфраструктури, необхідної для безпечного поглинання складності, яку привносить AI. Наступні оцінки базуються на аналізі публічно доступних витрат на інфраструктуру, галузевих бенчмарках та кейсах enterprise-трансформацій. Це порядки величин, а не точні цифри:
| Компонент трансформації | Орієнтовна вартість | Терміни |
|---|---|---|
| Модернізація CI/CD та автоматичні quality gates | $2—10M | |
| Сканування якості коду та безпеки (SonarQube, Semgrep) | $500K—2M | |
| RAG-інфраструктура для контекстного AI-рев’ю | $1—5M | |
| Навчання розробників та редизайн процесів | $1—3M/рік | Постійно |
| Додаткові сеньйор-інженери для рев’ю-потужності | $2—5M/рік | Постійно |
| Архітектурне управління та compliance-фреймворки | $500K—2M | |
| Разом (Рік 1) | $7—27M | — |
Це дає співвідношення, яке має стривожити будь-якого CFO:
Мультиплікатор трансформації = Реальна вартість / Вартість ліцензій = $7—27M / $228K ≈ 30—120x
Ліцензія — це
1–3% реальної вартості того, щоб AI працював безпечно. Решта97–99% — рахунок за трансформацію — невидимий на кожній презентації вендора.
Парадокс Джевонса для AI-коду
Ситуація гірша за одноразовий рахунок. Дані про enterprise-витрати на AI виявляють тривожну динаміку: навіть коли вартість одиниці AI падає, загальні витрати прискорюються.
За ринковими даними 2025 року, enterprise-витрати на генеративний AI зросли з $11.5B (2024) до $37B (2025) — зростання на 320% — попри те, що вартість інференсу за токен впала приблизно в 1 000 разів за той самий період. Середній місячний AI-бюджет на організацію зріс на 36% до $85 521/місяць, причому 45% організацій тепер витрачають понад $100K/місяць.
Це класичний Парадокс Джевонса: дешевший AI за одиницю → більше AI споживається → більше інфраструктури потрібно для управління ним → вищі загальні витрати. «Економія» від дешевших токенів поглинається — а потім перевищується — зростаючим радіусом ураження AI-згенерованої складності по всій організації.
Ліцензія видима. Рахунок за трансформацію — ні.
Ця асиметрія — двигун кризи. Коли Борд затверджує AI-бюджет, вони бачать рядок:
✅ AI-ліцензії: $228K/рік — Затверджено.
Чого вони не бачать — це операційний борг, який вони імпліцитно авторизують:
❌ Інфраструктура для безпечного поглинання AI-виходу: $7—27M — Не запитано. Не профінансовано. Не обговорено.
Вендор не має стимулу показувати цю вартість. CTO може не повністю її розуміти. CFO не має фреймворку для її розрахунку. І організація розгортає інструмент, який множить обсяг коду на 2x, у пайплайн, спроєктований для 1x — і дивується, чому через 18 місяців бюджет на підтримку вибухнув, а сеньйор-інженери вигорають.
Поки індустрія не розробить прозорі TCO-моделі для AI-асистованої розробки — моделі, що включають повну вартість управління, верифікації та трансформації процесів — кожен розрахунок «AI ROI», представлений Борду, є в кращому випадку неповним, а в гіршому — фікцією.
Виклик вендорам
Якщо AI Code Assistants настільки зрілі та універсально корисні, як стверджує поточний маркетинг, шлях вперед має бути простим.
Замість того щоб інвестувати переважно в кампанії адопції, ми кидаємо виклик вендорам виділити капітал на незалежні, об’єктивні дослідження. Профінансуйте університетські або нейтральні галузеві групи для вивчення реальних команд, що працюють над реальними беклогами, вимірюючи конкретні показники — cycle time, defect rates, rework та вартість підтримки — у різних організаціях протягом тривалого періоду.
Відсутність таких доказів не означає злий намір. Але вона залишає індустрію в критичній прогалині доказів. Поки ригористичні, незалежні дані не будуть доступні, обережний висновок залишається неминучим:
Без відповідних змін в операційній моделі, AI Code Assistants навряд чи дадуть чистий позитивний результат на системному рівні — і можуть активно збільшити довгострокову вартість та ризик.
Джерела до Глави 2
Google Software Engineering (O’Reilly): «Software Engineering at Google» — Детальна документація внутрішньої інфраструктури Google (Blaze, TAP, Critique, Tricorder), побудованої за 15+ років, що представляє мільярди інвестицій у платформну інженерію. abseil.io
Alphabet
10-K (CY2024): R&D $45.4B, CapEx $52.5B. Прогноз CapEx на 2025 ~$75B. sec.govMeta
10-K (CY2024): R&D $44.4B, CapEx $39.2B. Прогноз CapEx на 2025 $60—65B. investor.fb.comMicrosoft
10-K (FY2024): R&D $29.5B, CapEx $44.5B. Прогноз CapEx на 2025 ~$80B. microsoft.com/investorBig Tech AI Spending (2025): Amazon, Meta, Microsoft та Alphabet планують сукупний CapEx понад $320B у 2025, зростання з $246B у 2024. delo.ua / Financial Times
Enterprise AI Spending (2025): «The Inference Cost Paradox» — Парадокс Джевонса в дії: вартість за токен впала в 1000x, загальні enterprise-витрати зросли з $11.5B до $37B. Середній місячний AI-бюджет на організацію: $85 521. arturmarkus.com
Enterprise AI TCO (2025): Фреймворк прихованих витрат за межами API-рахунків: data engineering, RAG-інфраструктура, MLOps, governance, compliance. xenoss.io
Frontier Model Training Costs: Витрати на тренування зростають у 2.4x/рік; найбільші запуски прогнозуються на рівні >$1B до 2027. epoch.ai
Глава 3. Пастка «безкоштовного обіду»: чому Борд обирає стратегію деградації
Якщо дані з Глави 1 настільки тривожні — сеньйори уповільнюються, code churn вибухає — і якщо реальна вартість трансформації в
Відповідь лежить не в інженерії, а в ринковому тиску. Ми спостерігаємо класичне зіткнення між Gartner Hype Cycle та реальністю корпоративного бюджетування.
Механіка «Мандату на виконання»
Катастрофа починається задовго до того, як розробник встановить AI Code Assistant. Вона починається з інвесторів.
Під впливом звітів, що обіцяють «55% приросту продуктивності» та «демократизацію кодування», інвестори тиснуть на Борди, щоб ті продемонстрували AI-стратегію зараз. Повідомлення для CEO однозначне: «Впроваджуй AI або стань нерелевантним.»
Але Борд стикається з дилемою. Вони вимагають адопції AI, але не мають чіткого розуміння ROI чи складності необхідної трансформації. Вони сприймають AI як інструмент (на кшталт швидшої IDE), а не як зміну операційної моделі.
Відповідно, вони відмовляються виділяти бюджет на глибоку трансформацію (нові ролі, перебудова процесів, тренування агентів). Натомість вони видають те, що ми називаємо «Мандатом на виконання»:
«Впроваджуйте AI. Ось бюджет на ліцензії. Ось невеликий бюджет на воркшоп з промпт-інженерії. Вперед.»
Це виглядає як «безпечна» стратегія. Низька вартість (CapEx), легко впровадити. Але насправді це стратегічна помилка масивних пропорцій. Фінансуючи генерацію коду без фінансування управління кодом, Борд авторизував стійке збільшення обсягу, що значно перевищує пропускну здатність їхньої інженерної команди — без жодного плану закрити цей розрив.
Розрив між адопцією та впливом: 88% увійшли, 6% отримали результат
Масштаб цього розриву не теоретичний. Він вже вимірюваний на макрорівні.
Глобальне опитування McKinsey 2025 року щодо стану AI в enterprise виявило, що 88% організацій впровадили AI у тій чи іншій формі. Але лише 6% звітують про значущий вплив на EBIT — метрику, яка реально відображає, чи AI створює бізнес-цінність, а не просто активність.
Це «Мандат на виконання», відображений в агрегованих даних. Майже дев’ять з десяти компаній купили ліцензії. Менше ніж одна з п’ятнадцяти може продемонструвати, що інвестиція окупається.
Сліпота масштабу: вертикальні криві vs горизонтальне планування
Цей розрив між планами керівництва та технічною реальністю визнають навіть ті, хто очолює AI-«Ренесанс».
Андреас Хорн, Head of AIOps в IBM, нещодавно зазначив, що розробка ПЗ перетнула лінію, з-за якої немає повернення. Хоча він виступає за потужність цих інструментів, він підкреслює вражаючий розрив у плануванні керівництва. Це коментар у соцмережах, а не рецензоване дослідження, але спостереження від старшого AI-практика у великому вендорі примітне саме тому, що воно звучить зсередини індустрії:
«Крива йде вертикально. Більшість планування досі горизонтальне.»
Ось де Субпрайм-криза спалахує. Прихильники на кшталт Хорна бачать вертикальну криву можливостей і прогнозують, що частка ручних кодерів буде «меншою, ніж хтось у boardroom зараз планує.» Але коли ми перетинаємо цю «вертикальну криву» з даними METR за березень 2025 про надійність (50% рівень невдач для завдань, що потребують 7 годин експертної людської роботи), небезпека стає очевидною.
Boardroom’и планують лінійне, «горизонтальне» зростання ефективності. Тим часом технологія доставляє вертикальний стрибок неверифікованої складності. Попередження Хорна про «vibe coding», що призводить до «клаптикового коду, який швидко старіє», підтверджує нашу тезу: без тотальної перебудови SDLC ми не прискорюємо інженерію — ми прискорюємо ентропію.
Парадокс стартапу vs enterprise
«Мандат на виконання» особливо небезпечний, бо ігнорує контекст.
Для стартапу на ранній стадії ця стратегія може реально працювати. Стартапи працюють за моделлю «fail fast». Їхня мета — валідувати гіпотезу до того, як закінчаться гроші. Якщо код брудний, але продукт знайшов product-market fit — вони виживають і переписують.
Для Enterprise, однак, ця стратегія токсична.
У зрілій організації вартість ПЗ не в його написанні — а в його підтримці. Галузеві стандарти свідчать, що 80% Total Cost of Ownership (TCO) програмного забезпечення припадає на період після деплою.
Коли Enterprise приймає «Стартап-стратегію» AI (максимальна швидкість, мінімум процесів), він затоплює свою довгострокову кодову базу «одноразовим» кодом. Але на відміну від стартапу, він не може його викинути. Він має підтримувати його роками. Економлячи копійки на генерації коду сьогодні, Борд гарантує мільйони збільшених витрат на підтримку завтра.
Для українського контексту це ще гостріше. Типова аутсорс-компанія на 500+ розробників працює під тиском клієнтів, які вже прочитали про «AI-революцію» і очікують миттєвого прискорення. Але ці клієнти не збільшують бюджет на якість — вони зменшують таймлайни. Результат: команда генерує більше коду під більшим тиском з меншим часом на рев’ю. Класичний рецепт для технічного банкрутства.
Сліпа зона дашборду
Чому
Більшість executive-дашбордів вимірюють Активність, а не Здоров’я.
- Вони бачать: Кількість комітів (Зростає), Фічі випущені (Стабільно), AI Adoption Rate (100%).
- Вони не бачать: Складність коду (Злітає), Technical Debt Ratio (Критичний), Maintainability Index (Падає).
Дані McKinsey підсилюють це: дашборд показує 88% адопції. Він не показує, що лише 6% отримують реальну цінність. Корабель набирає воду, але Капітан дивиться лише на спідометр.
З даними METR за 2025 рік, що показують лише 50% надійності навіть найкращих агентів на суттєвих проєктах, «Активність» на дашбордах все більше відірвана від цінності. Половина тієї «швидкості» — це просто швидке накопичення токсичних активів.
Enterprise-опитування Deloitte за 2025 рік підтверджує цей зсув: організації переходять від експериментів до вимоги вимірюваного ROI — імпліцитне визнання того, що початкова стратегія «спочатку впровадь, потім вимірюй» не виправдала очікувань.
Висновок: стратегія деградації
Пастка «безкоштовного обіду» — це віра в те, що можна отримати переваги AI (швидкість) без оплати ціни (трансформація процесів).
Борд успішно оптимізував найдешевшу частину SDLC — друкування — ігноруючи найдорожчу частину — мислення. Поки керівництво не зрозуміє, що AI вимагає фундаментального зсуву в тому, як ми будуємо, а не лише якими інструментамикористуємось, вони продовжуватимуть фінансувати деградацію власних активів.
Джерела до Глави 3
McKinsey & Company (2025): «The state of AI in early 2025» — Глобальне опитування: 88% організацій звітують про адопцію AI; лише 6% звітують про значущий вплив на EBIT. mckinsey.com
METR (березень 2025): «Measuring AI Ability to Complete Long Tasks» — Горизонти AI-завдань подвоюються кожні 7 місяців; GPT-5.2 обробляє
7-годинні завдання з 50% надійністю. metr.orgAndreas Horn, IBM (лютий 2026): «The most important chart in AI» — Коментар старшого AI-практика IBM про розрив між вертикальними кривими можливостей AI та горизонтальним плануванням boardroom’ів. linkedin.com
Andreas Horn, IBM (лютий 2026): «AI writes code faster than teams can keep up with» — Аналіз «клаптикового коду» та прискорення ентропії в enterprise-кодових базах. linkedin.com
Deloitte (2025): «Now decides next: Insights from the leading edge of generative AI adoption» — Enterprise-опитування, що документує зсув від AI-експериментів до вимоги ROI-підзвітності. deloitte.com
Microsoft (2025): FY25 Q2 Financial Results — Рекордний дохід від Copilot підкреслює ринковий «Мандат на виконання» та структуру стимулів на стороні вендора. microsoft.com/investor
Глава 4. Анатомія зламу: як «безпечний сценарій» вбиває SDLC
Ми встановили, що Борд видав мандат на стратегію «високого обсягу» (Глава 3), профінансовану на
Щоб зрозуміти катастрофу, що розгортається в інженерних командах, не потрібні складні AI-теорії. Достатньо базової фізики виробництва — а саме, Теорії обмеженьЕліяху Голдратта.
Фізика доставки ПЗ
Кожен виробничий процес, включаючи розробку ПЗ — це ланцюг подій. Загальний вихід системи (Throughput) визначається рівно однією річчю: швидкістю найповільнішої ланки (Вузького місця).
Класичний SDLC (Software Development Life Cycle) був спроєктований для світу людської швидкості:
- Кодування (Обмеження): Писати код було важко, повільно і ментально виснажливо. Це було природне вузьке місце.
- Рев’ю та QA (Потужність): Оскільки кодування було повільним, наступні кроки (Рев’ю, QA) мали достатню потужність для обробки потоку.
Система була збалансована. «Повільність» написання коду діяла як природний клапан контролю потоку. Це не вада, яку треба оптимізувати — це конструктивна особливість стабільної системи доставки.
Зламаний клапан
Впровадження AI Code Assistants прибрало клапан контролю потоку.
Раптово фаза «Кодування» більше не є обмеженням. Джуніор-розробник з AI Code Assistant може генерувати код швидше, ніж здатен його прочитати. Як показано в Главі 1, обсяг коду, що входить у пайплайн, більш ніж подвоївся (+131% доданих рядків), тоді як його структурна якість значно деградувала (+39% когнітивної складності, +18% попереджень статичного аналізу).
Але ось «Анатомія зламу»: ми змінили вхідні параметри системи, не змінивши архітектуру вузлів обробки.
Ми качаємо пожежний шланг води (AI-згенерований код) у садовий шланг (Людське рев’ю).
Згідно з Теорією обмежень, коли ви збільшуєте потік вище за вузьке місце, ви не отримуєте більше throughput. Ви отримуєте Інвентар.
Проблема інвентарю
У виробництві інвентар, що лежить на підлозі заводу — це відома вартість: він займає місце, зв’язує капітал і деградує з часом. У ПЗ еквівалент ще токсичніший, бо він невидимий:
- WIP (Work In Progress): Вибухає, створюючи пекло перемикання контексту. Xu et al. (2025) кількісно це оцінили: навантаження на рев’ю сеньйорів зросло на +6.5%, тоді як їхній власний кодовий вихід впав на —19%. Вони більше не будують — вони тріажать.
- Merge-конфлікти: Зростають експоненційно, коли PR’и довше стоять у черзі. Те, що було
10-хвилинним мерджем, стає2-годинною археологічною експедицією. - Когнітивне навантаження: Рев’юери змушені дебажити код, який вони не писали і не розуміють. Як показали Agarwal et al. (2026), AI-згенерований код несе +39% вищу когнітивну складність — тобто кожне рев’ю потребує непропорційно більше ментальних зусиль, ніж еквівалентний код, написаний людиною.
- Застарілий контекст: До моменту, коли PR дістається до початку черги, кодова база вже змінилась. Рев’юер тепер має оцінювати код відносно стану, який більше не існує.
Це не теоретичне занепокоєння. Галузевий аналіз підтверджує, що AI-згенерований код потребує у
Бінарний вибір у вузькому місці
Коли сеньйор-інженер стикається з чергою з 30 AI-згенерованих PR’ів і дедлайном спринту, у нього рівно два варіанти:
Варіант A: Глибоке рев’ю (Повільно, Безпечно) — Прочитати кожен рядок. Зрозуміти логіку. Перевірити edge cases. Відхилити те, що не відповідає стандартам. Це правильна інженерна практика — але при AI-згенерованих обсягах вона створює вузьке місце доставки, через яке команда виглядає «повільною» для менеджменту.
Варіант B: Rubber Stamp (Швидко, Небезпечно) — Проглянути PR. Перевірити, що тести проходять. Довіритись AI. Затвердити. Це тримає дашборд зеленим і sprint velocity високим — але це механізм, яким неверифікована складність потрапляє в продакшн.
Під тиском «Мандату на виконання», описаного в Главі 3, Варіант B стає раціональним індивідуальним вибором, хоча він є катастрофічним системним вибором. Сеньйор-інженер не лінивий і не недбалий — він реагує на систему, яка карає ретельність і винагороджує швидкість.
Це Пастка Rubber Stamp: структурний стимул затверджувати код, який ви не повністю перевірили, створений не індивідуальним провалом, а системою, що генерує код швидше, ніж люди здатні його оцінити.
Ілюзія «безпечної» адопції
Ось чому «Безпечний сценарій» — купівля ліцензій без зміни процесу — насправді є найнебезпечнішою доступною стратегією.
Зберігаючи старий процес (де люди мають вручну рев’юїти кожен рядок коду) при драматичному збільшенні обсягу та складності цього коду, організації перетворили своїх сеньйор-інженерів на нове вузьке місце без надання їм жодних нових інструментів чи потужностей для обробки навантаження.
«Безпечний» сценарій безпечний лише для бюджетного рядка. Для інженерної системи це повільний колапс:
- Обсяг подвоюється (Глава 1: +131% доданих рядків)
- Складність зростає (Глава 1: +39% когнітивної складності на одиницю)
- Потужність рев’ю залишається сталою (жодних нових сеньйорів, жодної автоматизованої інфраструктури рев’ю)
- Черга зростає → Контекст деградує → Rubber stamps збільшуються → Дефекти проникають
- Витрати на підтримку вибухають → Сеньйори вигорають → Потужність рев’ю скорочується
Це петля позитивного зворотного зв’язку — спіраль смерті, де кожен цикл деградує систему далі. Черга стає довшою, рев’ю — поверхневішим, баги — глибшими, а виправлення — дорожчими.
Висновок: затор на дорозі
Уявіть автостраду, де ми раптово даємо кожній машині двигун Ferrari (AI), але не додаємо жодних нових смуг і залишаємо ту саму єдину пропускну будку (Рев’ю) в кінці.
Машини швидші. Рев двигунів гучніший. Але затор біля пропускної будки тепер тягнеться на кілометри.
Ми не побудували швидшу автостраду. Ми просто побудували швидший спосіб дістатись до затору.
Теорія обмежень каже нам, що оптимізація будь-якого кроку окрім вузького місця не просто марна — вона активно шкідлива, бо затоплює вузьке місце більшим обсягом роботи, ніж воно здатне обробити. AI Code Assistants оптимізували єдиний крок у SDLC, який не потребував оптимізації (швидкість друку), ігноруючи кроки, які реально обмежують доставку (рев’ю, інтеграція, верифікація).
Поки організації не інвестують у розширення вузького місця — через автоматизовану інфраструктуру рев’ю, AI-асистовану верифікацію, архітектурне управління та планування потужності сеньйорів — вони не прискорюють доставку. Вони прискорюють накопичення ризику.
Джерела до Глави 4
Goldratt, E. M. (1984): The Goal: A Process of Ongoing Improvement. North River Press. — Фундаментальний текст з Теорії обмежень: оптимізація не-вузьких місць збільшує інвентар без покращення throughput.
Theory of Constraints in Software Development: «Finding and Fixing the Real Bottleneck» — Прикладний аналіз того, як AI зміщує вузьке місце кодування на потужність людського рев’ю. theagilemindset.co.uk
AI Code Review Paradox (2025): «Why AI Coding Speed Gains Disappear in Code Reviews» — Галузевий аналіз, що підтверджує: AI-код потребує у
2–3 рази довшого рев’ю через правдоподібні баги, сховані за елегантним синтаксисом. softwareseni.comПерехресні посилання: Ця глава синтезує дані з Глав
1–2. Первинні джерела щодо обсягу (+131%), складності (+39%), навантаження на рев’ю (+6.5%) та переробок (+2.4%) — див. Джерела до Глави 1 (METR, Xu et al., Agarwal et al., GitClear).
Про проєкт: від діагнозу до дії
Ця стаття — адаптація перших чотирьох глав відкритого аналітичного звіту «The Subprime Code Crisis», який я створив на GitHub.
Мета проєкту — не просто попередити про кризу, а дати інженерному ком’юніті конкретні інструменти для протидії:
- 📉 Повний звіт (10 глав) — data-driven аналіз того, як AI-асистенти надувають бульбашку технічного боргу
- 🛡️ Операційні протоколи — конкретні захисні заходи для вашої кодової бази
- 📚 Повна бібліографія — кожна цифра перевіряється
Проєкт ліцензований під CC-BY-SA 4.0 і відкритий для контриб’юцій.
Одна дія, яка має значення
Якщо цей аналіз резонує з вашим досвідом — поставте зірку на репозиторії. Це не vanity metric. Це сигнал, що ком’юніті бачить проблему і вимагає зміни наративу. Чим більше нас — тим важче це ігнорувати.
Наступна стаття серії: «Зламана механіка» — смерть Code Review, чому AI-агенти не врятують, і ланцюгова реакція по всьому Value Stream.
Author: Vitalii Oborskyi — Head of Delivery & Ops | Creator of «Uncertainty Architecture» (AI Control Theory)
AI Governance Framework(AI Reliability = Actuators + Sensors + Controller): github.com/.../uncertainty-architecture
LinkedIn: www.linkedin.com/in/vitaliioborskyi
Sergey Lysak
Дід Панас
yvs2014
Bot Bot
Donald Trump
OleksandrP
Dr Alban
Vitalii Oborskyi
Віталій Мартиник
Serhii
Viktor Zhurbenko
Jan Haring
Donald Trump
Сергій Городілов
Serhii
Просто Анон
Олег Дорожко
Олег Дорожко
Eugene Nuribekov
Undisclosed User
Viacheslav
Viacheslav
Вова Москаленко
Sergey Lysak
Andrii
Олександр Шпак
Jan Haring
Hanna Hryhorieva
Bohdan Pomazan
Stanislav Katkov
Петтинг Пудинга
flyman
Дмитро Дем'яненко
flyman
Артем Бебик
Vadym Dobrohurskyi
NoName
Oleksandr Nechyporenko
Andrii Sevastianov
Вова Москаленко
Дмитрий Мирошник
Дмитрий Мирошник
Volodymyr
Просто Анон
Lex Luthor
Артур Шевченко
Viktor Zhurbenko
Włodzimierz Rożkow
Bot Bot
Станіслав Алексєєв
Олекса Мащиць
Чорний Список Юджина
Volodymyr Dvernytskyi
Макс Романов
Dmytro Riabov
Dr Alban
Артур Шевченко
Alexander Dyachenko
Виталий Котивский
Eduard Voloshyn
Denys Poltorak
Найкращі коментарі пропустити