Урок 11. Как спасти провалившийся vibe coding проект

Главный совет — всё, что нужно знать

Приложение сломалось. Вход, работавший вчера, перестал работать. Оплата списывается дважды. Каждое прикосновение к коду ломает что-то другое. Когда просишь ИИ «почини» — становится только хуже.

Не переписывай с нуля. Даже если перепишешь, через 3 месяца сломается в том же месте. Сначала зафиксируй текущее состояние.

Есть три структурных инструмента:

• codistill — Диагностика. Автоматически извлекает API endpoints, схему базы данных и поток аутентификации из существующего кода.
• huma — Фиксация. Добавляет regression tests на все endpoints для защиты текущего поведения.
• yongol — Конвертация. Генерирует новый backend из SSOT и доказывает идентичное поведение через существующие тесты.

Движение слева направо: диагностируй с codistill, фиксируй с huma, и когда готов — конвертируй с yongol.

Агенту: «Запусти codist scan для извлечения endpoints, схемы базы данных и потока аутентификации этого проекта.»

Появляется текущая картина. Видно, сколько из 25 endpoints живые, а сколько мёртвые.

Агенту: «Запусти huma verify для проверки статуса всех endpoints и напиши Hurl тест для каждого живого.»

Это и есть regression tests. Фиксируем то, что работает сейчас. Пока эти тесты проходят, существующее поведение не сломается, даже если агент изменит код.

Агенту: «Теперь исправь баг с авторизацией. Но все Hurl тесты должны пройти.»

Исправляешь баг, не ломая ничего другого. Ремонт выполняется при зафиксированном ratchet.

Пробный запуск

Можно попробовать даже без сломанного приложения. Пройди процесс «создать → сломать → спасти» за 3 минуты.

Шаг 1 — Создай приложение

В Claude Code:

«Создай простой API для списка задач. 5 endpoints: просмотр списка задач, добавление задачи, редактирование задачи, удаление задачи, отметка задачи выполненной. Запусти сервер.»

Шаг 2 — Диагностируй с codist

«Запусти codist scan для извлечения списка endpoints этого проекта.»

codist автоматически извлекает путь, метод и параметры каждого из 5 endpoints. Это текущая карта.

Шаг 3 — Зафиксируй с huma

«Запусти huma verify и напиши Hurl тесты для всех endpoints.»

Создаётся файл Hurl для каждого из 5 endpoints. Текущее поведение зафиксировано.

Шаг 4 — Намеренно сломай

«Измени формат ответа endpoint редактирования задачи. Переименуй поле title в name.»

После изменения:

«Запусти Hurl тесты.»

Тест не проходит. «Ожидался title, но пришёл name.» Drift обнаружен. Ratchet сработал.

Шаг 5 — Исправь при зафиксированном ratchet

«Измени код так, чтобы все Hurl тесты прошли. Но новую функциональность, использующую поле name, тоже нужно сохранить.»

Агент поддерживает обратную совместимость при изменении. Прохождение Hurl означает, что существующее поведение сохранено.

Это сокращённая версия codistill → huma → исправление. В реально сломанных приложениях этот процесс масштабируется до 25, 50 или 200 endpoints, но принцип тот же.

Почему нужно работать именно так

Вступление: настоящая причина, по которой сломалось твоё приложение

В 2025 году базы данных 170 приложений, созданных с Lovable, оказались полностью открытыми в интернете. Email-адреса, API ключи, платёжные данные. Причиной стал не баг в коде. ИИ создал приложения без политик безопасности, и никто не проверил.

В январе 2026 года из социальной сети Moltbook утекло 1,5 миллиона токенов API. Та же причина. ИИ создал, человек не проверил.

Это не чужая история. Каждый, кто создавал приложение с помощью vibe coding, сидит на той же структуре.

«Создай логин» — 30 секунд. «Добавь оплату» — 2 минуты. «Добавь панель администратора» — 5 минут. Через 3 месяца ИИ «наводит порядок» в логике оплаты и меняет расчёт скидок, добавление новой функции ломает аутентификацию, а страница, работавшая вчера, сегодня возвращает ошибку 500.

Перед тобой два варианта:

1. Переписать заново
2. Спасти

Переписать можно было 3 месяца назад. Проблема в том, что даже после переписывания тот же паттерн повторится. Drift — это структурная проблема, а не проблема кода.

Нужно научиться спасать.

Метод самоспасения выжившего — 5 этапов

Спасение сломанного приложения похоже на действия при потере ориентации в горах. Не беги. Определи текущее положение, обеспечь безопасность и двигайся шаг за шагом.

Этап 1. Диагностика — что ещё живо?

Первое, что нужно сделать — не исправлять код. А понять текущее состояние.

Агенту: «Просканируй все API endpoints этого проекта.
Отправь реальный запрос к каждому endpoint
и запиши код статуса ответа.
Оформи результаты в таблицу: путь, метод, код статуса, время ответа.»

Если 18 из 25 endpoints возвращают 200, 4 возвращают 401, а 3 возвращают 500 — это и есть текущая карта. Начинать ремонт без карты приводит к тому, что починенное место ломает другое.

codist scan от codistill автоматизирует эту работу. Извлекает из существующего кода endpoints, модели данных и потоки аутентификации.

Этап 2. Фиксация — сначала защити живое

После диагностики фиксируй живые endpoints.

Агенту: «Напиши Hurl тест для каждого
из 18 endpoints, возвращающих 200.
Используй текущий ответ как ожидаемые значения.
Для требующих аутентификации сначала выполни
последовательность входа для получения токена.»

Эти 18 Hurl файлов — страховочная сеть. Какие бы изменения ни вносились потом, прохождение этих тестов означает, что существующее поведение сохранено.

huma verify от huma систематизирует этот процесс. Отслеживает статус по каждому endpoint и выносит вердикт PASS/IMPROVE/FAIL.

Важно: частичная фиксация недопустима. Зафиксировать только 10 из 18 означает, что остальные 8 могут сломаться в процессе ремонта незаметно. Полная фиксация — это принцип.

Этап 3. Ремонт — исправляй при зафиксированном ratchet

Страховочная сеть готова, теперь можно исправлять баги.

Агенту: «Найди причину сбоя входа и исправь.
Но все Hurl тесты должны пройти.
Если хоть один не пройдёт, откати изменение.»

Это практическое применение Ratchet Pattern, изученного на Уроке 6. Исправляй не ломая. После каждого исправления запускай Hurl. Если прошёл — переходи к следующему багу. Если нет — откатывай.

3 endpoints, возвращающие 500, исправляются тем же способом. После исправления добавляются новые Hurl тесты. Ratchet фиксирует ещё один зубец.

Этап 4. Извлечение — достань логику из чёрного ящика

Вот где суть проблемы. Корневая причина краха приложения обычно здесь.

Если используешь Supabase:

• Политики RLS существуют только в dashboard, отсутствуют в коде
• Бизнес-логика скрыта в Edge Functions
• Логика аутентификации привязана к Supabase Auth

Если используешь Firebase:

• Security Rules существуют только в консоли
• Логика распределена по Cloud Functions

Какой бы BaaS ни использовался, структура одинакова. Бизнес-логика находится вне codebase.

Агенту: «Извлеки все политики RLS из Supabase.
Сохрани политики SELECT, INSERT, UPDATE и DELETE
каждой таблицы в SQL файлы. Сделай commit в git.»

Агенту: «Проанализируй бизнес-логику в Edge Functions.
Задокументируй, какие функции реализуют какие бизнес-правила.»

Цель — перенести логику из чёрного ящика в codebase. После переноса агент сможет читать её, тестировать и фиксировать через ratchet.

codist ddl от codistill извлекает DDL из существующей базы данных. codist scan извлекает SSOT из кода. Это инструменты перемещения из чёрного ящика в декларативный слой.

Этап 5. Конвертация — только когда готов

После завершения этапов 1-4 приложение находится в таком состоянии:

• Все endpoints имеют regression tests Hurl
• Баги исправлены
• Логика чёрного ящика задокументирована в codebase
• Ratchet зафиксирован, поэтому новые изменения не ломают существующее поведение

В этом состоянии принимается решение о конвертации. С Supabase на собственный backend, с Deno на Go, на что угодно.

Страховочная сеть конвертации — Hurl тесты, написанные на Этапе 2. Запусти тот же Hurl на новом сервере, и если все прошли — доказано, что он работает так же, как legacy.

Агенту: «Запусти yongol generate для создания Go+Gin backend.
Все существующие Hurl тесты должны пройти.»

Конвертация — это Этап 5, а не Этап 1. Попытка конвертации на Этапе 1 провалится. Это урок, подтверждённый реальными инцидентами онбординга.

Как выйти из Supabase

Самый частый случай на Уроке 11 — Supabase. Люди начинают с vibe coding, вкладывают всё в Supabase, а через 3 месяца всё рушится.

Порядок выхода:

1. Сохраняй базу данных и только применяй ratchet

Используй PostgreSQL от Supabase как есть. Смена базы данных — последнее.

codist ddl → извлеки DDL из существующих таблиц
huma verify → пойми текущее состояние endpoints
hurl → полностью зафиксируй все живые API

2. Перенеси логику в код

Политики RLS → файлы Rego. Edge Functions → аннотации SSaC. Из dashboard в codebase.

3. Отдели аутентификацию

Supabase Auth отделяется последним. Хэши паролей из auth.users извлечь невозможно, поэтому если ты на начальной стадии (без клиентов) — конвертируй немедленно; если клиенты есть — проводи период двойной аутентификации.

4. Подними новый сервер и проверь через Hurl

yongol generate → создай Go+Gin backend
полный запуск Hurl → докажи идентичность поведения с legacy

Если Hurl прошёл полностью — переключай трафик.

Почему нельзя переписывать с нуля

«Разве не проще переписать заново?»

Нет. Три причины:

1. Паттерн повторяется

Drift — структурная проблема, а не проблема кода. Переписать без ratchet — через 3 месяца рухнет в той же точке.

2. Знания захоронены в legacy

Бизнес-правила, накопленные за 3 месяца vibe coding, живут в коде. Переписать — значит восстанавливать эти правила по памяти. А память ошибается.

3. Клиенты уже могут быть

Есть момент, когда прототип становится production. Если есть хотя бы 1 пользователь, «переписать» означает миграцию данных, смену аутентификации и downtime.

Научиться спасать ценнее, чем научиться переписывать. Потому что legacy-код существует всегда, а новый код через 6 месяцев сам становится legacy.

Связь между Уроками 1-10 и Уроком 11

Те же инструменты, противоположное направление. Если Уроки 1-10 были «сверху вниз» (декларация → генерация), то Урок 11 — «снизу вверх» (существующий код → извлечение → декларация).

codistill автоматизирует это «снизу вверх». Выжимает SSOT из существующего кода.

От выжившего к спасателю

После завершения этого процесса у тебя будет два навыка:

1. Как строить с нуля (Уроки 1-10) — декларировать, валидировать, фиксировать, сохранять
2. Как спасать то, что сломалось (Урок 11) — диагностировать, фиксировать, чинить, извлекать, конвертировать

Большая часть кода в мире — это legacy. Проекты, создаваемые с нуля, редки. Навык спасения применяется чаще.

Vibe coding не закончился. Ты научился держать поводья.

Связанные материалы

• Supabase — это ловушка vibe coding — Теоретический контекст Урока 11. Почему BaaS рушится?
• Hurl предотвращает drift vibe coding — Детали шага фиксации на Этапе 2.
• codistill — выжимает SSOT из существующего кода — Инструмент диагностики на Этапе 1 и извлечения на Этапе 4.
• huma — ratchet, не пропускающий ни одного endpoint — Инструмент фиксации на Этапе 2.
• yongol — киль SaaS-разработки с ИИ — Инструмент конвертации на Этапе 5. Генерация fullstack из SSOT.
• Codebase, с которым может работать агент — Принцип превращения чёрного ящика в фабрику.
• tsma — рубеж защиты от регрессий в legacy-коде — Как чинить при зафиксированном ratchet.
• Построение систем, которыми могут управлять агенты — Как сделать зафиксированный legacy доступным для агента.

Все уроки Reins Engineering

Источники

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
• Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
• Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
• Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
• Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
• GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.