По-моему, вайб-кодинг — полезная фича, но я знаю, что многие его недолюбливают и считают, что AI генерит чушь, а не нормальный код. Ну тут я могу сказать как в той рекламе с гепардом: «Ты просто не умеешь их готовить».

Я начал заниматься вайб-кодингом 2 года назад (привет первая версия GPT Engineer), то есть еще до того, как ввели сам термин (он появился только в этом году). За это время у меня накопился опыт, который я переложил в небольшие рекомендации, возможно они помогут начинающим вайб-кодерам.

Вообще вайб-кодинг, это, конечно, огромная тема. Думаю, сделать серию из нескольких статей: здесь начну с теории, а потом покажу практику, как я настраиваю окружение и вообще весь процесс.

Что будет в статье:

• Что такое вайб-кодинг

• Почему разработчики недолюбливают вайб-кодинг

• Что можно и что не стоит вайб-кодить

• Навыки грамотного вайб-кодера

• Какую выбрать модель для вайб-кодинга

• Что писать в промпте и почему кодить без инструкций плохо

• Что дальше

Что такое вайб-кодинг

Вайб-кодинг — это «программирование на вибрациях», то есть разработка с помощью искусственного интеллекта, как говорят, на вайбе. Разработчик только озвучивает идею и принимает изменения, а весь код и правки разрабатывает AI-агент.

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

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

Обычно разработчики, когда вайб-кодят, не делают код-ревью, но я уверен, что это нужно. Задача разработчика тут сводится к тому, чтобы грамотно поставить задачу и ограничения, сделать ревью, посмотреть и протестировать код. Если появляется ошибка, он ее копирует и говорит модели: «вот проблема, иди почини».

В вайб-кодинге разработчик как коллаборатор, который ставит задачи для агента на обычном языке. Здесь очень высокий уровень абстракции: разработчик пишет, как будто он продакт, но ответственность за генерацию кода, планирование архитектуры и вообще решения полностью берет на себя AI. В таком сценарии не нужна очень глубокая экспертиза, достаточно понимать решаемую проблему и уметь направлять AI в нужную сторону.

Если посмотреть на AI-assisted engineering, то здесь уже требуется высококвалифицированный разработчик, который будет отвечать за код, может спроектировать архитектуру и задавать агенту точные узконаправленные запросы с грамотно выстроенным контекстом. А агент, в свою очередь, будет глубоко понимать кодовую базу и генерировать очень качественный код.

Разница в том, что в вайб-кодинге отладка того, что нагенерит искусственный интеллект, может занять много времени, плюс будет сложно долгосрочно поддерживать полученный код. А в AI-assisted engineering код можно поддерживать достаточно долго, выводить его в продакшн, делать решения любой сложности.

Почему разработчики недолюбливают вайб-кодинг

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

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

AI нас всех заменит. Есть те, кто думает, что их заменит искусственный интеллект, поэтому они принципиально им не пользуются. Еще три года назад, когда я выступал на конференциях и рассказывал про AI-ассистенты, очень мало разработчиков их использовали. Теперь некоторые начинают понимать, что их вытесняет не сам AI, а те, кто умеет правильно с ним работать.

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

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

Недоверие на уровне безопасности. Многие компании не доверяют вайб-кодингу из-за вопросов безопасности: данные могут утечь за границу, а модель будет дообучаться на корпоративном коде.

Что можно и что не стоит вайб-кодить

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

Вайб-кодинг POC- и MVP-проектов позволяет быстро протестировать гипотезу и вывести продукт с минимальными затратами, посмотреть на реакцию аудитории и решить, развивать его дальше или нет. Различные веб- и мобильные приложения, обучающие сервисы — все, где цена ошибки некритичная, можно спокойно вайб-кодить.

А вот банковские энтерпрайз-приложения, сервисы для медицины, платежные системы, в которых цена ошибки и строчки кода высокая, вайб-кодить не стоит. В такой разработке можно использовать AI, но делать это стоит очень осторожно и внимательно проверять каждую строчку кода.

Навыки грамотного вайб-кодера

Как я уже говорил, вайб-кодить может даже специалист, который не разбирается в программировании. Но тот, у кого есть этот навык, сделает это намного эффективнее. В идеале, если это будет тимлид, у которого есть опыт работы с командой:

• он понимает, что нужно сделать,

• умеет корректно поставить задачи с нужным количеством технического описания,

• грамотно выстроит архитектуру и поставит модель в сжатые рамки,

• проверит результат работы и сделает хорошее ревью.

Для начинающих разработчиков путь в вайб-кодинг начинается с освоения базовых принципов работы с LLM. Я бы посоветовал начать с изучения промпт-инжиниринга — научиться формулировать задачи так, чтобы модель понимала контекст и требования. И практиковаться на простых задачах: генерации небольших задач, написания юнит-тестов, генерации документации. Потом можно постепенно переходить к более сложным задачам, наблюдая, как инструмент генерирует код.

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

Какую выбрать модель для вайб-кодинга

Конечно, можно взять Cursor и работать с Claude 4.5. Подход отличный, но я не хочу сливать свой код компаниям заграницей, поэтому давайте посмотрим, что же там с open source.

В Hugging Face, например, есть много подходящих моделей для вайб-кодинга, но из них я бы выделил три:

• Qwen3-coder — большая, 408В, работает качественно;

• Qwen2.5-coder — поменьше, 32В, работает не так качественно, но дешевле и быстрее;

• GLM-4.5 — свежая китайская модель, которая уже успела себя зарекомендовать.

GLM-4.5 с показателем 63,2 стоит на третьем месте в мире. Это значит, что 63% кода, который она сгенерирует, будет идеальным. Модель конкурирует с о3 от OpenAI, Grock 4 и Claude Opus 4 от Anthropic. 

Пока писал эту статью, уже вышла GLM-4.6, которая существенно обходит прошлую версию по бенчмаркам.

Qwen3-coder тоже входит в десятку и конкурирует с топ-моделями. У самого Qwen есть свой бенчмарк, по которому видно, что в некоторых задачах Qwen3-coder обходит Claude Sonnet 4 и GPT-4.1.

Но даже несмотря на высокий бенчмарк, стоит помнить, что любая модель может галлюцинировать. В том числе поэтому не стоит вайб-кодить критические системы. Пока даже лучшая модель от OpenAI показывает 65%, то есть риск галлюцинаций равен 35%, значит, треть кода может быть неправильной.

Что писать в промпте и почему кодить без инструкций плохо

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

На GitHub большая коллекция промптов для вайб-кодинга — берите, дорабатывайте, используйте. У меня есть свой промпт, тоже там лежит, можете скачать и доделать под свою задачу. 

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

Что делает промпт: 

• задает роль сеньор-разработчика и формирует стиль работы — так модель будет понимать, как ей нужно с вами общаться; 

• перечисляет список технологий для использования (язык, библиотеки, фреймворки), чтобы AI сам ничего не выбирал; 

• дает инструкцию генерировать файлы фреймворка только через CLI, исключая написание шаблонного код, — это ускорит работу и позволит сэкономить токены, а качество кода будет при этом лучше; 

• обязывает запускать сборку, проверку линтеров и форматирование после изменения и устранять все замечания — так код будет чистым; 

• внедряет чистую архитектуру, строгие правила именования, типизации и низкой когнитивной сложности; 

• запрещает дублирование, to-do, тестовые данные и хардкорные конфигурации, чтобы модель не сказала «когда-нибудь потом реализую», будто она настоящий разработчик; 

• требует логировать ключевые действия; 

• требует делать ревью и устранять дубликаты кода, проблемы производительности и безопасности; 

• предполагает использование инструментов для бесшовной интеграции с существующим CI/CD; 

• любые специфические правила, требуемые для проекта: бизнес-логика, язык комментариев и так далее. 

Эти правила — результат не только моего опыта, но и огромного числа экспериментов и написанного кода.  

У каждого инструмента свой механизм, куда класть промпт, нужно читать документацию. Если работаете в Roo Code, то промпт нужно положить в директорию .roo. У этого расширения есть несколько режимов (архитектор, код) — под каждый из них нужен свой промпт в своей директории.  

Что дальше

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