Переписать или пропатчить: что оставлять из кода быстрой ИИ-сборки

Прямой ответ

Патчьте, когда структура здравая, а проблемы локальны. Пересобирайте критический путь, когда auth, платежи или multi-tenant данные спутаны с сгенерированной лапшой. Маркетинговые страницы оставляйте, если они стабильны.

Полный rewrite «потому что ИИ писал» - дорогая привычка. Патч «поверх дыры в оплате» - ложная экономия.

Что это значит на практике

• Начинайте с карты реального процесса: вход, данные, деньги, доступы, исходящие.
• Опишите поведение простым языком, затем проверьте каждый путь, где ошибка стоит денег или репутации.
• Оставьте человека на нестандарте; не чините «ещё одним промптом» то, что должно быть инженерией.

Когда патч

• UI и layout ок, баги в одном модуле.
• Секреты уезжают на сервер одной границей.
• Добавляются rate limits, webhook signature, один middleware.
• Тесты можно повесить на узкий путь без сноса дерева.

Когда rewrite критического пути

• Auth, payments, multi-tenant и tool-вызовы переплетены в одном файле/промпте.
• Нет ясной модели заказа, tenant id, server price.
• Каждый фикс ломает соседний поток.
• Нет логов, нет владельца, нет способа остановить агента/checkout.

Как выглядит хорошо

• Чёткая граница: marketing shell vs hardened core.
• Стандарт / нестандарт маршруты до записи.
• Ключи только на сервере; логи и стоп-кнопка.
• Решение rewrite/patch зафиксировано письменно с критериями «готово».

Как выглядит плохо

• «В превью работает» = ship.
• Токены и webhook публичны «пока».
• Нет handoff человеку на исключениях.
• Полный rewrite ради перфекционизма, пока воронка не принимает оплаты.

Как Dali это ведёт

Берём быстрый ИИ-прототип всерьёз, затем укрепляем: иногда patch, иногда isolate + rebuild critical path. Vibe-code rescue, боевые агенты, точки контроля.