#рецепт
Вайбкодить должен каждый ПМ, чтобы лучше понимать

Здравствуй, возмутившийся читатель!

Я не говорю про продвинутый дипкодинг, вайб-инжиниринг и AI-assisted coding path. Я говорю именно про вайбкодинг. Легко что-то сделать, чтобы получить быструю ценность не напрягаясь и вообще иногда с голосовым вводом

Тут ты скажешь: "На**га, автор? Ты вроде серьёзный человек. Нормальное и стабильное у неофита не выйдет. И вообще, мы же менеджеры, а не инженеры". Да, всё так

Но есть как минимум три способа, где вайбкодинг реально приносит пользу

1️⃣ Делать прототипы вместо презентаций и в дополнение к ТЗ
Если ты сядешь и начнёшь делать фичу сам, ты её очень хорошо продумаешь. Вылезут узкие места, потери в юзкейсах, просто неудобства. Тебе не нужен настроенный Claude Code с кучей плагинов, продуманными MCP и скиллами. Иногда антигравити более чем достаточно

2️⃣Делать простенькие автоматизации
До которых не хватает рук, времени или которые не позволяют текущие инструменты вроде Jira workflow. Пять лет назад нормально посчитать lead time в YouTrack было проблемой. Сейчас это вопрос одного скрипта и максимум 30 минут

3️⃣Воссоздавать рабочую среду
Думаешь, у вас просадки при ревью? Повайбкодь с автономным агентом: поревьюй его таски или дай ему поревьюить твои -> как на работе, с чеклистом и апрувами. Тимлид хочет усилить качество и ставит ruff + ещё 7 пакетов? Попробуй на себе. Думаешь про адаптивный регресс? Вперёд!

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

Я периодически вайбкожу для Twinby простенькие сервисы, а недавно начал делать прототипы. Однажды таким прототипом я нашёл причину просадки очень важной метрики (на уровне конверсии) в несколько раз и предложил решение, которое сейчас команда имплементирует