Аналітика

Чому технічний борг росте швидше через AI і що нам з цим робити

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

Технічний борг в період нейромереж: прискорення замість сповільнення

Технічний борг — це не просто погано написаний код. Це відкладені компроміси. Кожного разу, коли ми обираємо «працює — не чіпай», ми беремо кредит під високі відсотки. Раніше цей борг накопичувався відносно повільно, бо розробники фізично не встигали писати достатньо коду за день. Тепер у нас є AI, котрий пише за людину 60–80% рутини. І ось тут починається іронія долі.

По-перше, швидкість породжує об’єм.

Коли розробник за допомогою Copilot, Cursor чи Claude може генерувати сотні рядків коду на годину, temptation (спокуса) величезна — «давай ще фічу». Продуктові менеджери в захваті. Беклог танцює. Але ніхто не враховує, що разом з фічою приходить нова порція неявних рішень: магічні константи, неочевидні залежності, автогенеровані SQL-запити, які працюють на тестових даних і падають на продакшені.

По-друге, AI чудово копіює шаблони, але погано розуміє контекст.

Модель навчається на мільярдах рядків коду з GitHub 2015–2023 років. Значна частина цього коду вже містила борг. А ШІ не просто пише код — він активно розповсюджує застарілі практики, антипатерни і «працює на моєму комп’ютері»-рішення. Особливо небезпечно, коли AI пропонує архітектурні рішення для складних систем: він може красиво намалювати мікросервісну конструкцію, котра на практиці перетворюється на розподілену монолітну кашу.

По-третє, втрата розуміння коду.

Коли 70% коду в пул-реквесті написано не вами, ви значно гірше розумієте, як саме працює система. Рефакторинг стає лотереєю. Тестування — формальністю. А коли приходить час мігрувати на нову версію бібліотеки або змінити підхід — команда опиняється в стані «хто це все писав і навіщо нам це прокляття?».

По-четверте, психологічний ефект.

AI створює ілюзію компетентності. Junior-розробник з Cursor виглядає як сеньйор. Сеньйор починає лінуватися думати. Архітектор перестає малювати діаграми, бо «AI все одно краще знає». В результаті якість архітектурних рішень падає, а борг росте експоненційно.

Реальні симптоми, котрі вже видно

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

Зростання часу на code review. Раніше ревьюер дивився на логіку та стиль. Тепер же йому доводиться додатково розгадувати «наміри» штучного інтелекту. Чому AI вирішив використати рекурсію там, де вистачило б простого циклу? Навіщо він додав три рівні абстракції для задачі, яку можна було вирішити в п’ять рядків? Чому він імпортував застарілу бібліотеку? І так далі. Тож тепер Code review перетворюється з швидкої перевірки на детективне розслідування, що з’їдає значно більше часу.

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

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

Зростання когнітивного навантаження. Тепер розробник мусить тримати в голові не лише бізнес-логіку та архітектуру, а й додатковий шар: «як це міг придумати LLM?». З’являється постійний ментальний overhead — спроба зрозуміти нелогічні, але «працюючі» рішення штучного інтелекту. Це особливо виснажує senior-розробників і архітекторів, котрі змушені постійно «перекладати» AI-код на людську мову. Втома накопичується, а якість рішень поступово падає. Біда.

Розмивання відповідальності. Коли щось йде не так, все частіше лунає фраза: «Це AI так написав». Команда підсвідомо перестає відчувати повну власність над кодом, що знижує загальну культуру відповідальності.

Технічний борг
Джерело: Medium

Що з цим робити? Тверезий підхід без релігійних війн

Не треба забороняти AI. Це так само безглуздо, як забороняти екскаватори і повертатися до лопат. Але екскаватор без грамотного і досвідченого оператора — це просто дорога до величезної ями.

1. Введіть «AI debt review» як обов’язковий етап.

Не просто code review, а спеціальний pass, де фокус на питаннях:

  • Чи можемо ми пояснити цей код людині через рік?
  • Які припущення зробив AI?
  • Чи є простіші/явніші рішення?

2. Зберігайте «золотий стандарт» архітектури.

Майте актуальну документацію (хоча б у вигляді ADR — Architecture Decision Records) і жорстко вимагайте, щоб генерований код їй відповідав. ШІ чудово пише код під конкретний стиль — просто дайте йому цей стиль у промпті.

3. Практикуйте «Human-in-the-loop» на рівні архітектури.

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

4. Інвестуйте в розуміння, а не в швидкість.

Регулярні «розбори польотів» з AI-генерованим кодом. Навчання команди писати якісні промпти. Розвиток навички рефакторингу. Компанії, які зараз виховують «AI-native» розробників, котрі вміють критично мислити поверх згенерованого коду, матимуть колосальну перевагу через 3–5 років.

5. Моніторте метрики боргу.

SonarQube, CodeScene, NDepend — не ігноруйте їх. Встановіть жорсткі пороги. Якщо після впровадження AI кількість smell-ів і complexity різко зросла — це не «все йде за планом», це червоний прапорець.

От такі справи

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

Найгірша стратегія — це наївне захоплення: «AI все зробить правильно». Друга за гіршістю — луддизм і заборона. Найрозумніша — тверезий цинізм досвідченого інженера: «Так, це прискорює розробку. Але відсотки за кредит все одно доведеться платити. Давайте хоча б зробимо так, щоб вони були не 300% річних». Бо врешті-решт технічний борг — це не про код. Це про те, наскільки чесно ми ставимося до майбутньої версії себе, яка цей код підтримуватиме. ШІ просто зробив таке майбутнє ближчим. І трохи страшнішим.

Back to top button