Главная ловушка вайбкодинга: чем быстрее пишет ИИ, тем быстрее ломается ваш продукт

Кажется, я понял главную сложность работы с ИИ в разработке.

Он очень быстрый. И в этом ловушка.

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

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

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

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

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

Хороший план для задачи у меня содержит:

Изначальную проблему — что именно и почему меняем
Возможные решения — варианты, которые рассматривал
Выбранное решение — на чём остановился и почему
Чеклист шагов — этапы реализации по порядку
Final picture view — как выглядит итоговое изменение, чтобы заранее понимать, к чему идём
Влияние изменения — что поменяется для оператора (пользователя ИИ), а что для пользователей продукта
Краткое описание плана — проблема, решение и итог в паре строк, чтобы быстро схватить суть, когда деталей становится много

Но мало написать план один раз. По нему нужно пройти несколько раз — на каждом проходе всплывает то, что пропустил на предыдущем.

А ещё лучше — не проверять всё в одиночку. Я подключаю агентов, которые ревьюят план и контекст каждый под своим углом: безопасность, архитектура, продукт, баги, CI. Один смотрит на архитектурные риски, другой — на продуктовые последствия, третий — не сломается ли пайплайн. Так деталь ловится с разных сторон, а не только там, куда смотрел я сам.

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