Мысли про вайбкодинг
0️⃣ Форматирование кода? Спасибо, не надо
В командной работе мы используем prettier / go fmt и прочие «format on save» линтеры, чтобы автоматически форматировать код в едином стиле. Это помогает не спорить про запятые и пробелы в код ревью. Но в агентном кодинге это вредит. Почему? Почти все агенты редактируют код через различные search-replace patch подходы, и если уже «запомненный» моделью код непрозрачно для неё переформатируется, это сбивает якоря, на которые LLM опиралась.
1️⃣ Режим жёсткой дисциплины
Поэтому у нас вместо косметики – жёсткая дисциплина.
Здесь статический анализ именно кода важен как нигде. Автоматический моментальный фидбек для модели, что сгенерированный код не совпадает с нашими ожиданиями. И в отличие от обычной работы в команде, где мы стараемся найти баланс, здесь нужны максимально строгие и упрямые правила. Буквально шаг влево, шаг вправо – и модель отправляется переделывать. Чем строже правила (full strict TS, dependency cruiser, eslint правила на цикломатическую сложность и т.д.) — тем меньше шансов, что спустя пять промптов у вас появится импорт-матрешка или inline-тип, о котором сам агент забудет через минуту.
2️⃣ Однопромптовый маркетинг
Все мы видели истории в духе «эту полноценную CRM систему GPT-5 сгенерировала всего за один промпт!». На практике же вайбкодинг в пустой директории в стиле «привет, создай мне простое приложение для…» оказывается путём в никуда. С каждым запросом растёт экспоненциальный хаос, и очень быстро в коде не можешь ориентироваться не только ты, но и сама модель уже слабо понимает, как код устроен и тем более как вносить в него сложные правки. MVP так и останется MVP навсегда, даже не факт, что рабочим.
3️⃣ Придется поработать
Получается теперь чтобы повайбкодить, еще до самого первого промпта нужно забутстрапить немаленький сетап. Сейчас для меня это
- супер строгая и максимально type-safe конфигурация TypeScript
- большой набор «людоедских» eslint правил (от max-lines-per-function до complexity < 10)
- dependency cruiser что следить за low coupling и high cohesion
- npm-package-json-lint для проверки package.json
- настроенный vitest, чтобы модель сразу понимала какие тесты и как писать
- и всякое другое по мелочи
И вот только после этого можно просить модель начать писать код с надеждой, что написанное будет хотя бы минимально поддерживаемо с течением времени.
4️⃣ Всё своё ношу с собой
Но только прежде чем кодить, нужно еще не забыть принести свои любимые кастомные правила для Copilot/Cline/Cursor. В каждый проект теперь «инсталлируется» последняя версия проверенных правил, которые позволяют агентам писать код чуть лучше чем из коробки. Интересное наблюдение: эти правила в каждом проекте со временем мутируют и обрастают уникальными дополнениями, релевантными только для конкретного контекста.
• • •
Чистый вайбкодинг — это дорога в хаос. Но и кайфовый способ быстро «пощупать» идею. А если хочется, чтобы проект дожил до завтрашнего утра и не стал легаси при рождении, придётся провести подготовительную работу.
0️⃣ Форматирование кода? Спасибо, не надо
В командной работе мы используем prettier / go fmt и прочие «format on save» линтеры, чтобы автоматически форматировать код в едином стиле. Это помогает не спорить про запятые и пробелы в код ревью. Но в агентном кодинге это вредит. Почему? Почти все агенты редактируют код через различные search-replace patch подходы, и если уже «запомненный» моделью код непрозрачно для неё переформатируется, это сбивает якоря, на которые LLM опиралась.
1️⃣ Режим жёсткой дисциплины
Поэтому у нас вместо косметики – жёсткая дисциплина.
Здесь статический анализ именно кода важен как нигде. Автоматический моментальный фидбек для модели, что сгенерированный код не совпадает с нашими ожиданиями. И в отличие от обычной работы в команде, где мы стараемся найти баланс, здесь нужны максимально строгие и упрямые правила. Буквально шаг влево, шаг вправо – и модель отправляется переделывать. Чем строже правила (full strict TS, dependency cruiser, eslint правила на цикломатическую сложность и т.д.) — тем меньше шансов, что спустя пять промптов у вас появится импорт-матрешка или inline-тип, о котором сам агент забудет через минуту.
2️⃣ Однопромптовый маркетинг
Все мы видели истории в духе «эту полноценную CRM систему GPT-5 сгенерировала всего за один промпт!». На практике же вайбкодинг в пустой директории в стиле «привет, создай мне простое приложение для…» оказывается путём в никуда. С каждым запросом растёт экспоненциальный хаос, и очень быстро в коде не можешь ориентироваться не только ты, но и сама модель уже слабо понимает, как код устроен и тем более как вносить в него сложные правки. MVP так и останется MVP навсегда, даже не факт, что рабочим.
3️⃣ Придется поработать
Получается теперь чтобы повайбкодить, еще до самого первого промпта нужно забутстрапить немаленький сетап. Сейчас для меня это
- супер строгая и максимально type-safe конфигурация TypeScript
- большой набор «людоедских» eslint правил (от max-lines-per-function до complexity < 10)
- dependency cruiser что следить за low coupling и high cohesion
- npm-package-json-lint для проверки package.json
- настроенный vitest, чтобы модель сразу понимала какие тесты и как писать
- и всякое другое по мелочи
И вот только после этого можно просить модель начать писать код с надеждой, что написанное будет хотя бы минимально поддерживаемо с течением времени.
4️⃣ Всё своё ношу с собой
Но только прежде чем кодить, нужно еще не забыть принести свои любимые кастомные правила для Copilot/Cline/Cursor. В каждый проект теперь «инсталлируется» последняя версия проверенных правил, которые позволяют агентам писать код чуть лучше чем из коробки. Интересное наблюдение: эти правила в каждом проекте со временем мутируют и обрастают уникальными дополнениями, релевантными только для конкретного контекста.
• • •
Чистый вайбкодинг — это дорога в хаос. Но и кайфовый способ быстро «пощупать» идею. А если хочется, чтобы проект дожил до завтрашнего утра и не стал легаси при рождении, придётся провести подготовительную работу.