# Технический долг в вайбкод-приложении: увидеть, оценить, выплатить

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

Published: 2026-03-22 · Source: https://subxcat.com/ru/articles/tech-debt-in-vibe-code · Author: SUBXCAT

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

## Как выглядит долг в вайбкоде

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

- **Один и тот же код в пяти местах.** Валидация формы, расчёт цены, проверка тарифа скопированы в каждый компонент, где понадобились, и уже немного разные.
- **Несколько способов на всё.** Данные загружаются тремя разными библиотеками, состояние живёт и в контексте, и в сторе, и в адресной строке — смотря какой промпт это писал.
- **Мёртвый код.** Брошенные варианты экранов, неиспользуемые функции, компоненты `PricingOld` и `PricingNew2`.
- **Нет границ.** Компоненты интерфейса ходят в базу напрямую, бизнес-правила живут в обработчиках кнопок, типы на границе с API — `any`.

## Где искать

Не пытайся описать весь долг сразу — его слишком много, и большая часть не мешает. Ищи там, где больно.

История изменений показывает, какие файлы правятся чаще всего:

```bash
git log --since="6 months ago" --format= --name-only \
  | sort | uniq -c | sort -rn | head -20
```

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

Дальше — спроси команду. Где оценки задач всегда оказываются заниженными? Какие места все обходят? Что приходится объяснять каждому новому человеку? Ответы обычно совпадают с тем, что показал git.

## Как оценить

Каждой позиции долга нужны две оценки: сколько стоит её исправить и сколько она стоит, пока не исправлена. Вторая важнее, и её чаще забывают.

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

Заведи простой реестр: что, где, чем мешает, сколько стоит исправить. Не больше двадцати позиций — длинный список никто не читает.

## Как выплачивать, не останавливая работу

Отдельный «спринт рефакторинга» почти никогда не работает: он откладывается, урезается, а потом его результат тонет в новых функциях. Работает другое.

- **Гаси долг там, где работаешь.** Задача касается расчёта цены — значит, в её рамках расчёт сводится в одно место. Долг гасится рядом с функциями, а не вместо них.
- **Постоянная доля.** Договорись, что заметная часть каждого цикла — скажем, пятая — уходит на позиции из реестра. Не «если останется время», а заранее.
- **Сначала то, что мешает чаще.** Сортируй реестр не по уродству, а по тому, как часто позиция встаёт на пути.
- **Удаляй.** Мёртвый код — самый дешёвый долг: его не надо переписывать, его надо убрать. Начни с этого, результат видно в тот же день.
- **Закрепляй.** Сведя логику в одно место, добавь тест и правило линтера, чтобы следующий промпт не размножил её снова.

## Как понять, что становится лучше

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

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