AI Technical Debt (Технічний борг генеративного коду)(Технічний борг генеративного коду)

1. Огляд концепції та системна проблема

Термін "технічний борг", запропонований Вордом Каннінгемом (Ward Cunningham), спочатку описував компроміс: випустити фічу швидше сьогодні, щоб отримати бізнес-фідбек, а завтра повернутися і переписати код якісно.

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

Коли стартап або ентерпрайз-команда захоплюється надвисокою початковою швидкістю ("ми написали бекенд за вихідні!"), вони беруть високопроцентний кредит:

• Швидкість перших релізів: 10x.
• Швидкість розробки через півроку: 0.1x.
• Будь-яка спроба оновити версію бібліотеки або додати нове бізнес-правило перетворюється на каскад незрозумілих поломок у непов'язаних кутках репозиторію.

Траєкторія швидкості розробки:
Швидкість
   ^
   |       /--- Здорова інженерна культура (Стабільна швидкість)
   |      /
   |  /\ /
   | /  X
   |/    \
   |      \___ Неконтрольований AI-техборг (Швидкий старт -> Архітектурний параліч)
   +----------------------------------------------------> Час (місяці)

2. Архітектурна таксономія та ментальна модель

Анатомія генеративного технічного боргу включає чотири рівні:

1. Когнітивний борг (Cognitive / Comprehension Debt):
   • Код працює, але ніхто в команді не розуміє внутрішньої механіки алгоритму.
   • Розробники бояться торкатися коду і при виникненні багів просто згодовують файл моделі з промптом "полагодь це", поглиблюючи борг ще більше.
2. Борг відсутності єдиного джерела істини (Single Source of Truth Decay):
   • Модель не пам'ятає, що валідація телефонного номера вже реалізована в пакеті @shared/validation, і створює власну реалізацію в модулі авторизації, а інша модель — у модулі замовлень.
   • Бізнес-правила починають розходитися.
3. Борг слабких або відсутніх інваріантів:
   • Використання слабких типів (any, unknown, Record<string, any>), ігнорування станів гонитви (Race Conditions) та блокувань транзакцій у БД.
4. Борг надлишкових залежностей (Dependency Creep):
   • Додавання сторонніх важких бібліотек заради виконання елементарних операцій, які вирішуються 3 рядками нативного коду поточної версії платформи.

3. Технічний пайплайн та внутрішня механіка

Порівняльна таблиця симптомів техборгу

Архітектурний пайплайн захисту від боргу

[Агент пропонує зміни]
         |
         v
[Крок 1: AST-аналіз цикломатичної складності (ESLint/Biome)]
         |
         v
[Крок 2: Перевірка архітектурних кордонів (Dependency Cruiser)]
         |
         v
[Крок 3: Тайпчекінг tsc --noEmit з прапорцем noImplicitAny]
         |
         v
[Крок 4: Запуск мутаційного тестування (Stryker Mutator)]
         |
         v
[Крок 5: Ручний архітектурний аудит: чи можна вирішити це видаленням коду?]

4. Практичні інженерні сценарії в продакшені

01. Ліквідація когнітивного боргу через рефакторинг "Delete-First"

Команда стикається з мікросервісом розрахунку знижок на 2500 рядків, написаним агентом під час хакатону. Сервіс містить десятки розгалужень, які ніколи не виконуються. Архітектор фіксує бізнес-вимоги у 15 лаконічних integration-тестах, повністю стирає старий файл і змушує агента згенерувати чисту табличну функцію (Lookup Table) на 120 рядків, ліквідувавши 95% непотрібного коду.

02. Виявлення циклічних залежностей за допомогою dependency-cruiser

Через хаотичні рекомендації агентів модулі проекту виявилися заплутаними у циклічні імпорти (A -> B -> C -> A), що викликало спонтанні помилки undefined при ініціалізації середовища в продакшені. Інженери налаштовують правило no-circular у CI, виправляють структуру на шарувату (Layered Architecture) і блокують подальші спроби агентів створювати перехресні зв'язки.

03. Аудит мікросервісних контрактів через Zod / OpenAPI

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

5. Підводні камені, типові помилки та безпека

1. "Fixing Slop with More Slop" (Лікування шлаку новим шлаком): Коли у згенерованому коді виникає помилка, найгірше, що можна зробити — це надіслати помилку моделі зі словами "виправ". Модель просто додасть ще один if або try-catch, створюючи "голий пластир" на гнилій архітектурі. Зупиніться, розберіться в першопричині (Root Cause) і спростіть початковий дизайн.
2. Ігнорування витоків ресурсів у фонових процесах: Згенеровані скрипти часто забувають закривати з'єднання з базою даних, файлові дескриптори або пули потоків. На локальній машині це непомітно, але під високим навантаженням сервер вичерпує ліміти відкритих файлів (Too many open files) і падає.
3. Помилкова оцінка продуктивності команди: Якщо менеджмент оцінює розробників за швидкістю закриття тасок або кількістю комітів, інженери переходять на неконтрольовану генерацію AI-коду. Вимірюйте стабільність релізів, кількість регресій та легкість модифікації системи, а не валовий обсяг написаного тексту.