П'ять фіч для створення коду відвантажили між 2 та 16 квітня 2026 року. Нуль фіч для підтримки. Це співвідношення каже все про те, де насправді перебуває ринок AI-кодингу — і що він відмовляється чесно оцінювати.

Cursor 3 (2 квітня) запустив паралельні Agent Tabs — кілька AI-агентів пишуть код одночасно в окремих гілках. GitHub Copilot (4 квітня) додав Autopilot mode — агенти самі підтверджують свої виклики інструментів, не питаючи тебе. Windsurf 2.0 (10 квітня) відвантажив Agent Command Center. Claude Code (14 квітня) представив Routines — заплановані фонові агенти, що генерують код за тригерами. Codex від OpenAI (16 квітня) отримав multi-agent workflows. Жоден анонс не згадує, що відбувається з кодом після того, як він потрапляє в прод.

Це не недогляд. Це продуктова стратегія.

60%, які ніхто не продає

Баррі Боем встановив у 1976 році, що підтримка з'їдає 60–80% загальної вартості життєвого циклу софту. IBM підтверджувала це неодноразово протягом наступних десятиліть. Ніщо за п'ятдесят років софтверної інженерії не спростувало це співвідношення.

AI, схоже, його лише збільшує.

Дослідження, опубліковане на arXiv 8 квітня 2026 року, проаналізувало десять великих проєктів, згенерованих Cursor, у середньому по 17 000 рядків коду кожен. Функціональна коректність: 91% — код працював. CodeScene, інструмент аналізу здоров'я коду, знайшов 1 305 проблем проєктування в цих проєктах: 28,4% дубльованого коду, методи в середньому по 171 рядок (хороша практика обмежує 20–30), а цикломатична складність — кількість шляхів розгалуження через функцію — в середньому 17, майже вдвічі більше за рекомендовану стелю.

Демо їде. Кодова база структурно ворожа до будь-кого, хто торкнеться її наступним — включаючи AI, який її написав.

Кожен великий бенчмарк AI-кодингу підтримує цю сліпу зону. SWE-bench тестує виправлення багів. HumanEval тестує генерацію функцій. Жоден бенчмарк не запитує: «Чи може ця модель безпечно додати фічу до заплутаної кодової бази, яку вона згенерувала три місяці тому без жодної проєктної документації?» Без такого бенчмарку у вендорів нуль ринкового стимулу оптимізувати те, що насправді коштує грошей.

Чому AI структурно не здатний підтримувати те, що створює

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

Поточні AI-інструменти провалюються у всіх трьох.

Кожна нова сесія стартує з нульовою пам'яттю попередніх проєктних рішень. Модель генерує будь-який паттерн, що пасує поточному промпту, а не той, що вона використала минулого вівторка. Ось чому дослідження на arXiv виявило 28,4% дублювання — AI розв'язує ту саму задачу по-різному щоразу, бо не пам'ятає, що вже її розв'язував.

Рандомізоване контрольоване дослідження METR — опубліковане в липні 2025-го, досі єдине контрольоване дослідження такого типу — кількісно оцінило розрив між сприйняттям та реальністю: 16 досвідчених розробників на своїх власних репозиторіях працювали на 19% повільніше з AI-інструментами, але при цьому вірили, що на 20% швидше. Дельта в 39 процентних пунктів між тим, що розробники думають, і тим, що відбувається насправді. На знайомих кодових базах. На незнайомому AI-згенерованому коді цього ніхто не вимірював, бо ніхто не побудував відповідний бенчмарк.

Як би виглядав інструмент, орієнтований на підтримку

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

Обґрунтування проєктних рішень як метадані. Не просто що робить код — чому він структурований саме так. Кожна AI-згенерована функція повинна нести запис обмежень, розглянутих альтернатив та проєктних рішень, що її породили. CLAUDE.md у Claude Code — найближче наближення: стійкий контекст проєкту між сесіями. Але це текстовий файл, який ти ведеш руками, а не автоматизований архітектурний запис.

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

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

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

Лонгітюдне дослідження JetBrains, опубліковане 14 квітня 2026 року, відстежило 800 розробників за 151,9 мільйона залогованих подій і виявило сигнал, на який жоден інструмент для кодингу зараз не реагує: розробники витрачають понад третину часу на перевірку AI-пропозицій, і вони скасовують приблизно кожне п'яте прийняте доповнення, видаляючи код пізніше. Цей патерн видалення — безкоштовний тренувальний сигнал — корпус із «модель вважала, що це правильно, людина довела, що ні» — лежить у телеметрії кожної IDE. Хтось міг би побудувати зворотний зв'язок, що інгестить ці скасування і вчиться генерувати підтримуваний код одразу. Ніхто цього не зробив, бо демо створення продається. 30-секундний скрінкаст, де агент піднімає застосунок з промпту, збирає мільйони переглядів. Скрінкаст, де агент акуратно розкладає метод на 171 рядок у шість чистих функцій, збирає доповідь на конференції — може бути.

Цінова реальність

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

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

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