Рефакторинг после вайб-кода: как сделать код поддерживаемым

Есть момент, когда проект на вайб-коде вроде бы работает, но любая новая функция занимает неделю, а ИИ всё чаще ходит по кругу. Обычно это значит, что код перестал быть понятным даже для ИИ. Рефакторинг возвращает проекту структуру, не меняя того, что видит пользователь. Если поломки уже идут каскадом, сначала прочитайте, почему вайб-код ломается и как это остановить.

Почему так происходит

• Каждый чат начинает с нуля. ИИ не помнит, как решили похожую задачу неделю назад, и пишет ещё один вариант.
• Всё в компонентах. Запросы к базе, расчёт цен и проверки прав живут прямо в коде кнопок и страниц.
• any и выключенные проверки. Чтобы ошибка ушла, ИИ ставит any, @ts-ignore или отключает правило линтера.
• Мёртвый код. Старые версии компонентов и функций остаются в проекте и путают и людей, и ИИ.
• Нет соглашений. Названия, структура папок и способ работы с данными меняются от файла к файлу.
• Зависимости без контроля. Каждый чат добавляет свою библиотеку для дат, запросов или форм, и в проекте оказывается по две-три библиотеки на одну задачу, часть из которых давно не используется.

Что проверить самому

1. Посчитайте any и подавления проверок:

grep -rn ": any\|@ts-ignore\|eslint-disable" src/ | wc -l

2. Проверьте, включён ли строгий режим в tsconfig.json ("strict": true).
3. Запустите поиск неиспользуемых файлов и экспортов, например:

npx knip

4. Найдите файлы длиннее 400 строк — это первые кандидаты на разделение.
5. Посмотрите, где считается важная логика, например цена заказа. Если в нескольких местах — это дубль, который однажды разойдётся.
6. Проверьте, может ли новый человек запустить проект по README за полчаса.

Когда звать разработчика. Самостоятельно стоит начинать с малого: включить проверку типов, удалить явно неиспользуемые файлы, вынести одну повторяющуюся функцию. Если же в проекте сотни any, несколько способов работы с базой, бизнес-логика размазана по компонентам, а тестов нет совсем, массовый рефакторинг силами ИИ почти гарантированно что-то сломает. Здесь нужен человек, который сначала поставит страховку тестами, а затем будет менять структуру по шагам, проверяя каждый.

Как чиним мы

Начинаем с диагностики и карты: что где лежит, какие модули меняются чаще всего и болят сильнее. Фиксируем поведение тестами на ключевые сценарии, включаем проверку типов и линтер в автоматический прогон. Затем постепенно выносим бизнес-логику и работу с данными в отдельный слой, объединяем дубли, удаляем мёртвый код и лишние зависимости, приводим имена и структуру к одному стилю. Каждый шаг — отдельный коммит, после которого проект работает. В конце пишем README и файл правил для ИИ. Подробнее — на странице «Аптечка вайб-кода».

Сколько стоит

Диагностика — 50 000 ₸, доработка и переработка кода — 80 000 ₸, итого от 130 000 ₸ для небольшого проекта. Для средних и больших проектов действует коэффициент размера, а работу можно разбить на этапы по модулям. Рассчитайте в калькуляторе.