Dev-версия как навык вайбкодинга

Когда я только начинал вайбкодить, главным кайфом была скорость.

Сказал агенту, что нужно. Получил правку. Открыл, посмотрел, вроде работает. Поехали дальше.

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

В какой-то момент я понял простую вещь: мне уже мало быстро получать код. Мне нужен нормальный контур проверки.

Не тяжёлый корпоративный процесс. Не бесконечные согласования. Просто понятная dev-версия рядом с prod-версией.

Место, где можно дать агенту разогнаться, но не дать ему случайно сломать то, чем я уже пользуюсь.

Проблема не в модели

ИИ может быстро нарисовать экран, поправить кнопку, переделать форму, добавить режим, переписать кусок логики. Часто он делает это вполне прилично.

Проблема начинается дальше.

Я слишком легко могу поверить, что всё готово.

Когда код пишешь руками, ты чувствуешь вес изменения. Ты сам полез в файлы, сам ошибся, сам вернулся назад, сам помнишь: «я тут много трогал, надо проверить».

С вайбкодингом иначе. За вечер можно получить пачку изменений, которые выглядят уверенно. Агент всё объяснил. Сборка прошла. Интерфейс открылся. На первый взгляд красиво.

А потом выясняется, что на телефоне что-то уехало, привычный сценарий стал хуже или часть продукта сломалась не там, куда ты смотрел.

То есть слабое место не в генерации кода. Слабое место в допуске к prod.

Быстрый код нельзя сразу считать готовым кодом.

Нужна dev-версия

Я начал думать об этом как о двух состояниях продукта.

Есть prod. Это рабочая версия. Ей можно пользоваться. Она должна быть спокойной, предсказуемой и без сюрпризов.

А есть dev. Это черновая версия. Она почти такая же, но туда можно выкатывать изменения, которые ещё не заслужили доверия.

Мне нравится метафора примерочной. Витрина — это prod. Там уже лежит готовая вещь. Примерочная — это dev. Туда можно занести новую версию, покрутить перед зеркалом, понять, сидит или нет.

Если плохо — ничего страшного. В витрину она ещё не попала.

Вот это ощущение мне и было нужно в вайбкодинге.

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

Dev-версия ближе к реальности. Её можно открыть по нормальной ссылке, проверить с телефона, пройти привычный путь, посмотреть, как изменение ведёт себя почти как в жизни.

Черновик должен быть рядом

Dev должен быть рядом с prod, а не где-то в голове.

Рабочая версия остаётся рабочей. Черновая версия живёт отдельно. Агент может накидать изменений, я могу собрать dev, открыть его и проверить руками.

Это важный момент: я смотрю не только код. Я смотрю поведение.

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

Раньше любое крупное изменение ощущалось тревожно: если приму, вдруг сломаю то, чем пользуюсь каждый день.

Теперь изменение сначала попадает в dev. Там оно может быть кривым. Ему разрешено быть кривым.

Пока оно не прошло проверку, оно не идёт в prod.

Ветка — это не бюрократия

Раньше мне казалось, что ветки, dev/prod и отдельные проверки — это больше про команды, начальников и большие процессы.

Но в вайбкодинге всё наоборот.

Чем быстрее ты получаешь изменения, тем сильнее нужна простая дисциплина: где черновик, где проверка, где рабочая версия.

Я стал воспринимать ветку не как технический ритуал, а как отдельный стол для работы.

На этом столе агент может разложить детали. Что-то собрать. Что-то сломать. Что-то предложить. Я могу посмотреть и решить: оставляем, переделываем или выбрасываем.

Потом результат попадает в dev-версию. Там я уже смотрю не код, а продукт.

И только после этого оно идёт в prod.

Если сказать совсем просто, путь такой:

ветка → dev → проверка руками → prod.

Это не сложный процесс. Это минимальная гигиена для вайбкодинга.

Без неё легко получить поток быстрых решений, которые никто толком не успел прожевать.

Настоящие данные честнее игрушечных

Есть ещё один спорный момент.

Проверять можно на моках. Это безопаснее. Но моки часто слишком чистые.

Там три задачи, два пользователя, красивые названия, ровные сценарии. Всё как в демонстрации.

А жизнь грязнее.

У тебя старые записи, странные названия, длинные списки, привычки, которые ты сам уже не замечаешь. И именно на этом новая версия часто начинает вести себя иначе.

Поэтому для себя я выбрал более честный вариант: dev должен проверяться максимально близко к реальной жизни.

Это не значит, что там можно бездумно запускать опасные изменения. Наоборот. Чем ближе dev к настоящим данным, тем аккуратнее надо обращаться с действиями, которые могут что-то испортить.

Но для интерфейса, удобства, адаптива и привычных сценариев настоящая среда ценнее идеальной песочницы.

Моки показывают, что кнопка нажимается. Настоящие данные показывают, удобно ли этим жить.

Деплой должен быть скучным

Самая полезная часть всей этой истории — она скучная.

Есть понятный способ собрать dev. Есть понятный способ открыть dev. Есть понятный способ отправить проверенную версию в prod. Есть понятный способ откатиться назад, если что-то пошло не так.

Никакой магии. Никакого «сейчас вспомню, как я это делал в прошлый раз».

В вайбкодинге и так хватает неопределённости. Агент может не так понять задачу. Может поменять лишнее. Может уверенно объяснить ошибку, которой на самом деле нет.

Поэтому всё вокруг агента должно быть максимально простым и повторяемым.

Собрал. Открыл dev. Проверил. Выпустил в prod. Если плохо — откатил.

Чем скучнее этот путь, тем спокойнее можно экспериментировать.

Архитектура — это не схема

Я всё чаще думаю, что архитектура в вайбкодинге — это не только про то, как устроен код.

Архитектура — это ещё и путь изменения.

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

Это звучит менее эффектно, чем разговоры про модели, агентов и промпты. Но на практике это важнее.

ИИ резко снижает цену написания кода. Но он не снижает цену плохого изменения в живом продукте.

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

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

Что изменилось у меня

После появления dev-версии я стал спокойнее давать агенту крупные задачи.

Не потому что я стал безусловно ему доверять. Наоборот. Потому что я перестал пускать результат сразу в prod.

Плохая правка в ветке — это черновик.

Плохая правка в dev — это задача на исправление.

Плохая правка в prod — это уже проблема.

Разница огромная.

Dev превращает ошибку из аварии в обычную часть работы.

И это сильно меняет психологию. Ты меньше боишься пробовать. Но и меньше обманываешь себя, что «раз агент сделал, значит готово».

Мой вывод

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

Когда код пишется медленно, часть дисциплины появляется сама собой. Ты меньше меняешь, дольше думаешь, чаще чувствуешь риск руками.

Когда код пишется быстро, дисциплину приходится строить отдельно.

Dev-версия — маленькая вещь. Просто отдельное место, где можно проверить изменения до выпуска.

Но по смыслу это большой шаг.

Я перестал относиться к проверке как к финальному «ну вроде работает». Проверка стала отдельным слоем работы.

И мне кажется, это один из главных навыков вайбкодинга: строить не только продукт, но и безопасный путь, по которому продукт меняется.