Массовая замена - старая мечта: поменять во всём коде один паттерн на другой одним движением. Обычный find and replace делает это буквально, но спотыкается там, где каждое место требует чуть иного решения. Vibe and Replace - развитие той же идеи: он находит точные текстовые совпадения и применяет к каждому AI-инструкцию, то есть меняет не по шаблону, а по смыслу места.
Наивный ход - задать инструкцию, распахнуть область на весь репозиторий и довериться модели: она умная, разберётся в каждом случае. Соблазн силён, потому что обещает закрыть скучную механическую задачу за один проход. И часто первые несколько замен действительно выглядят правильными, что укрепляет доверие ровно перед тем, как оно подведёт.
Ломается это на масштабе и на природе инструмента. Модель применяет инструкцию к каждому совпадению независимо и правдоподобно, но не гарантированно; на сотне мест несколько почти наверняка окажутся не такими, как остальные. Если область сразу широкая, эти несколько тонут в общем diff, который уже невозможно осмысленно просмотреть глазами. Мощность инструмента здесь оборачивается против проверяемости.
Профессиональный приём - двигаться от узкого к широкому и удерживать замену проверяемой на каждом шаге. Сначала ограничьте каталог и паттерн, посмотрите, сколько совпадений он даёт, примените инструкцию к малому набору и убедитесь, что результат ровно тот. Только после этого расширяйте область. Это не документированная кнопка, а инженерная дисциплина: продукт даёт замену по смыслу, а ответственность за размер шага остаётся на вас. Малый набор здесь не перестраховка, а способ увидеть худший случай раньше лучшего: если инструкция где-то ошибается, дешевле встретить эту ошибку на пяти местах, чем на пятистах.
Выбор режима - часть этой дисциплины. Fast использует более быструю модель и применяет изменения быстро; Smart - более медленную и осторожную. Переключаются между ними кнопкой рядом с полем инструкции. Fast уместен там, где правка однородна и механична и каждое место похоже на соседнее. Smart - там, где каждое совпадение требует понять контекст, и цена неверной правки выше выигрыша в скорости.
Почему инструмент намеренно оставляет суждение локальным, а не берёт всю миграцию на себя. Он силён ровно в одном: применить понятную инструкцию к множеству похожих мест. Он ничего не знает о том, что снаружи текста - о совместимости схемы, о контрактах публичного API, о вызывающих в других репозиториях. Свести к нему целую миграцию значило бы поручить текстовой замене решение, которое требует плана, а не переписывания строк.
Отсюда жёсткая граница: Vibe and Replace - не migration engine. Изменение схемы данных, публичного API или семантики поведения требует отдельного плана обратной совместимости, а не только замены во всех файлах. Массовая правка текста меняет то, как код выглядит, но сама по себе не доказывает, что миграция корректна и ничего не сломала за пределами изменённых строк.
Цена невнимания растёт линейно с областью. Одна неверная инструкция, применённая к пяти местам, - минутная правка вручную. Та же инструкция на пятистах местах - diff, который никто не прочитает целиком, с горстью тихих ошибок внутри, обнаруживаемых потом по одной. Чем шире был первый заход, тем дороже разбор последствий.
Оправдан инструмент там, где задача честно массовая и однородная: переименовать понятие, поправить единый стилистический паттерн, привести вызовы к новой сигнатуре, где различия между местами невелики. Чем сильнее каждое место отличается от других, тем меньше это работа для одного прохода и тем важнее либо Smart с узкой областью, либо обычный агентный цикл с планом. Полезный признак границы прост: если для правильной замены модели нужно знать про каждое место больше, чем видно в самом тексте совпадения, это уже не задача массовой замены.
Проверять результат нужно другим способом, чем делали. Замена шла по тексту - проверяйте не текстом, а поведением: повторно найдите старый паттерн (в идеале ноль совпадений там, где ждали замену), прогоните typecheck и тесты, просмотрите diff по границам области. Если старый паттерн ещё встречается или тесты покраснели, замена не завершена, как бы убедительно ни выглядели отдельные правки.
Типичный провал - принять размер diff за меру работы, а не риска: обрадоваться, что "заменилось везде", и закрыть задачу, не сузив первый заход и не сверив поведение. Признак прост: правку сдают по числу изменённых мест, а не по зелёному прогону и пустому повторному поиску. Начните с малого набора и проверьте поведением - тогда массовость станет силой инструмента, а не источником массовых же ошибок.