Прочитал статью Программисты против вайбкодеров и решил поделиться собственным опытом вайб-кодинга, но уже без рекламы ТГ-каналов и бесполезных цитат авторитетных источников. Пока писал, появилась еще одна статья Революция вайб-кодинга отменяется, но уже с противоположным мнением.
Но теория без практики так и остается теорией, именно поэтому мне и захотелось рассказать о практическом применении вайб-кодинга в реальном проекте с конкретными фактами, а не маркетинговыми лозунгами.
Эта статья - подведение итогов небольшого эксперимента (над собой) по использованию вайб-кодинга в С++ проекте, что для программиста с 30-летним стажем работы стало практически вызовом и серьезным выходом из зоны комфорта. Но сейчас все проблемы решены, и в соответствии с Хабрахаком я решил оформить полученные выводы в письменном виде для их систематизации, а заодно и для получения обратной связи.
Что такое вайб-кодинг?
На вики написано, что термин Вайб-кодинг – это способ программирования с помощью нейросетей, который позволяет создавать ПО, даже не имея глубоких навыков в кодировании.
Как по мне, то это определение в корне ошибочно, так как термин Вайб-кодинг - пошел от англицизма vibes («вибрации»), под которым принято понимать сильные эмоции, которые испытываются по отношению к чему либо. В контексте термина "вайб-кодинг" или "вайб-программирование" этот термин должен означать сильные эмоции по отношению к процессу написания кода с помощью нейросети.
Поэтому, считать вайб-кодинг "программированием", которое еще и позволяет создавать ПО не имея глубоких навыков в разработке, в корне не верно. Вайб-кодинг, это больше про эмоции от самого процесса разработки, а не про полученный результат.
Организация рабочего места для вайб-кодинга
Свой первый опыт разработки с помощью нейросетей я получил совсем недавно на мероприятии C++ Zero Cost Conf 2025 в Москве, про которое уже писал на Хабре. Там был мастер-класс по использованию вайб-программирования, после посещения которого я вдохновился и решил повторить всё это шаманство дома в спокойной обстановке.
Для экспериментов я развернул на домашнем сервере с GPU 4090 и большим ОЗУ LM Studio, к которой подключил VSCode и с помощью плагина Roo Code и MCP сервера Contex7 сделал свое рабочее место.
Однако уже первые эксперименты показали, что размера контекста катастрофически не хватает для реальной работы. Локально можно проверить синтаксис, исправить опечатки в статье, но на качественный результат программирования с локальной LLM моделью, кроме самых простых и начальных задач, можно даже и не надеяться.
Но возня с локальным запуском LLM в LM Studio позволила наработать опыт настройки рабочего места (если будет интересно, потом могу более подробно про это написать), после чего было принято стратегическое решение использовать облачные LLM. И вот тут можно сделать первый вывод для желающих заняться вейб-программированием.
Для профессиональной работы или для рефакторинга объемного кода, локальные сети подходят плохо. Все работает очень медленно, а небольшой размер контекста не позволяет учитывать информацию из рабочего окружения, которая только увеличивается по мере выполнения новых запросов.
Выбор провайдера и стоимость вайб кодирования
Может показаться очень странным, но я не хочу рекомендовать никакую из генеративных сетей для разработки кода. И связано это не с её качеством, а с текущими реалиями в России. Оплатить запросы к нейросети или просто подключиться к провайдеру без VPN может стать отдельным и очень серьезным квестом. И это не говоря уже про то, что самих провайдеров куча (ChatGPT, Claude, Gemini, Deepseek, Grok, Qwen, Mistal, Copilot, Amazon и т.д.) - и у каждого из них может быть несколько нейросетей на выбор, а для подключения средств разработки может использоваться свой собственный формат API.
Поэтому я решил не ломать голову с оплатой через иностранную пластиковую карту, а просто зарегистрировался в одном из агрегаторов нейросетей, который принимает оплату в рублях. Это дает возможность работать из одного места с любой нейросетью от любого провайдера по разумным расценкам.
Чем еще хорош агрегатор - с ним можно работать не только через API, но и через обычный чат на сайте (например для обработки графики), а расценки могут быть даже ниже, чем цены у самих провайдеров, так как он покупает запросы по оптовым расценкам.
В результате по стоимости у меня вышло: генерация полутора десятка картинок для дочки - около 60 рублей, на простую программу "привет мир" на С++ было потрачено 3 рубля и порядка 80 рублей за вот такой проект парсера настроек. Причем в последнем случае я не написал ни строчки кода (кроме самого промта), а сам процесс длился чуть менее 10 минут. За это время было исправлено 4 или 5 ошибок, которые нейросеть сама же и нашла при запуске тестов и сама исправила после нескольких итераций.
Вайб-кодинг в реальном проекте
Но "привет мир" и парсер настроек, это все очень простые примеры, а не реальные задачи разработчика, тогда как меня интересует как раз прикладная сторона вайб-кодирования. Что может этот инструмент в реальных примерах, насколько им удобно пользоваться, насколько это дорого и прочие организационно-технические вопросы.
В качестве подопытного я решил использовать свой небольшой пет-проект с контроллером батареи ИБП на базе модуля ESP32-C3, в котором требуется код прошивки на С++. Изначально я сразу решил, что не хочу негативить и искать сценарии, где нейросети не смогут заменить человека (хотя без примеров косяков все равно не обойтись). Но лучше я буду "позитивить" и искать возможности и области применения генеративных нейросетей, где они могут помочь уже сейчас.
Для отладки функционала решил сделать на базе модуля ESP32-C3 сервер WiFi с отображением логов микроконтроллера и тестового сообщения.

Как я уже говорил, "негативить" мне очень не хотелось, но без небольшого казуса все же не обошлось.
После одного из тестов компилятор выдал предупреждение, что размер буфера переменной char filepath[128]
может быть недостаточен при вызове функции snprintf
и нейросеть решила его увеличить до 300 (почему до такого размера, не знаю).

Но после внесения изменений, кроме увеличения размера буфера почему то была изменена и строка формата, где вместо "%s%s"
появился китайский иероглиф, после которого была пропущена закрывающая кавычка.

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

Была еще одна ошибка, которая потребовала ручной правки, но не в кода, а в конфигурации сборки проекта (была установлена неправильная аппаратная платформа), и вместо ESP32-C3 проект в какой-то момент начал собираться под ESP32. Но это не ошибка в работе LLM, а недостаточность размера контекста, так как тип аппаратной платформы я задавал в самом начале работы, и к концу он уже перестал попадать в текущий контекст, а во время попытки починить ошибку с незакрытой текстовой строкой нейросеть полностью очистила опции конфигурации.
После нескольких небольших правок (в основном синтаксические ошибки), прошивка успешно собралась, WiFi-сервер запустился, компьютер сеть увидел и сумел к ней подключиться. Правда никакой странички с логами не было и в помине.

Опять пришлось самостоятельно анализировать исходный код, в результате выяснилась интересная вещь. В постановке задачи я указал, что нужно сделать Wi-Fi сервер со статической HTML-страницей, на которой требуется обновлять только поле с логами. Однако LLM поняла, что нужно сделать HTML-файл во флеш-памяти, что в возможно и верно (статический html файл), но не то, что хотелось сделать мне. Опять пришлось вручную корректировать код, чтобы удалить HTML-файл из флеш-памяти и вместо него подключать динамически генерируемую форму главной страницы.

Еще несколько фоток с этапами приведения кода в работоспособное состояние и добавлением функционала



Через полтора часа я устал ждать завершения работы нейросети и полез править код руками. К этому времени на запросы к LLM было потрачено чуть менее 300 рублей и я решил дальше работать по старинке, так как костяк проекта был успешно сделан, а исправить мелкие огрехи руками оказалось проще и быстрее, чем ждать ответа от LLM (причём без гарантии его корректности).
"Вибрации" от использования генеративных нейросетей в реальной разработке
Несмотря на то, что даже при вайб-программировании у меня не получилось полностью отказаться от ручного написания и анализа кода, тем не менее, я считаю, что даже такой результат - это очень большой успех и хорошая помощь, так как серьезно сократилось время создания заготовок проектов с использованием различных примеров из интернета.
Ведь нельзя быть отличным специалистом сразу во всём. Например, у меня недостаточно опыта в веб-программировании. Однако буквально за вечер, не напрягаясь (то есть действительно почувствовав вайб от процесса), я получил худо-бедно работающий пример кода с нужным функционалом. В продакшен его не отправишь, и это уже отредактированная версия, но как заготовка и отправная точка для проекта - более чем достаточно.
Если раньше приходилось очень много лазить по сайтам с документацией и различным форумам в попытке найти нужные примеры кода, а потом пытаться скомбинировать их в одном приложении, то сейчас все это взял на себя нейросетевой помощник, который самостоятельно собрал найденные фрагменты и сумел сформировать из них логически законченный файл приложения.
И пусть программа сейчас не имеет всей нужной функциональности и обязательно требуется ручная чистка кода (ведь генеративные нейросети отнюдь не искусственный интеллект, и у них нет понимания того, что нужно получить в конечном итоге), но даже такая работа на уровне копипаста разрозненных фрагментов в одно приложение очень сильно снижает объем ручной работы.
Сам процесс создания промтов для нейросетей вызвал у меня дежавю, потому что он очень напомнил поиск с помощью указания точных фильтров в запросах раннего Яндекса, когда можно было находить информацию без рекламного мусора, просто добавляя к запросу обязательные и исключаемые из результатов поиска термины, кода за три-пять итераций удавалось получить нужные данные.
Еще промты для нейросетей чем то похожи на нечеткие запросы к базам данных: нельзя быть уверенным, что нужный результат получится с первого раза, но за несколько попыток с уточнениями можно добиться вполне приемлемого результата. К сожалению, один и тот же промт в разных нейросетях может давать совершенно разные результаты - по крайней мере, пока в вывод LLM не начнут принудительно встраивать рекламу :-).
LLM бесполезны для бездумного рефакторинга легаси-кода, особенно в больших объемах. Хотя, думаю, при желании можно провести и рефакторинг с помощью нейросетей, просто придется идти долгим и более правильным путем. Сначала придется покрыть тестами все критические участки кода, после чего разбить рефакторинг на отдельные небольшие фрагменты.
И хотя такой подход будет мало чем отличаться от обычного процесса разработки, он все равно может оказаться проще, чем переписать весь код с нуля, так как уже есть рабочие тесты, а старый легаси-код служит своего рода документацией (очень подробным ТЗ) для описания нужной функциональности на входе LLM.
Насчет неправильного определения термина "вайб-кодинг"
Почему я не согласен с определением термина "вайб-кодинг" на Вики, так это из-за утверждения, что программировать с помощью нейросетей можно, даже не имея глубоких навыков в кодинге. Это неправда. Если не разбираться в программировании и просто соглашаться со всеми правками, то такой подход будет работать только в очень простых случаях, но он будет не работоспособен в случае работы с реальным кодом. Именно поэтому термин вайб-кодинг - это не про результат программирования, а про эмоции от процесса программирования, так как разбираться в теме всё равно необходимо, иначе возможны любые казусы.
Например, у меня при правке в C++ коде с динамическим контекстом для веб-страницы нейросеть не смогла различить код на C++ и код в JavaScript-строках, из-за чего несколько раз пыталась создать функцию на C++, хотя она была нужна в JavaScript. После этого проект собирается, но в результате ничего не работает (ошибка в C++ коде), нейросеть снова добавляет функцию (опять в C++), снова вылетает ошибка при сборке, и так по кругу. Поскольку цикл довольно длинный и включает несколько шагов, анализатор не может обнаружить зацикливание, и нейросеть продолжает счастливо генерировать код (у меня получилось шесть предварительных определений одной и той же функции, пока я не понял, что что-то идёт не так).
Подводя итоги вайб-кодинга
Оказалось очень удобно использовать нейросеть для создания начального прототипа, особенно если задача из смежной области, к которой ты имеешь не слишком глубокое представление. В моем случае это была динамическая генерация главной страницы сервера с выводом логов и обычных сообщений в окно со скроллом + несколько кнопок на форме.
Полученный результат нельзя назвать идеальным, но надеюсь, что качество генерации со временем будет улучшаться по мере развития генеративных моделей и инструментов разработки, но уже сейчас можно сделать определенные выводы:
Для вайб-программирования требуются серьезные навыки в постановке и формализации задач, знания предметной области и умение разбираться в генерируемом коде.
Стоимость запросов к нейросети в процессе работы растет из-за постоянной увеличения объема передаваемого контекста, а потом начинает падать качество генерируемого результата из-за переполнения контекста выше определенного порога, который зависит от конкретной модели (было бы полезно учитывать этот момент в инструментах разработки).
У LLM-моделей есть серьезные проблемы с интеграцией и рефакторингом существующего исходного кода. Даже исправление одной небольшой ошибки может привести к серьезным проблемам и нарушить уже рабочую логику.
Нет смысла поручать нейросети мелкие и понятные правки в коде, время выполнения которых сопоставимо с ручным внесением изменений (например, добавление кнопки в разметку страницы или указание кодировки UTF-8 для поддержки русских букв). Проблема не только в том, что даже небольшой запрос требует передачи всего контекста (а значит, и затрат), но и в том, что есть ненулевая вероятность все сломать.
Как системный архитектор я могу упростить себе работу, делая упор на детальных требованиях к тестированию кода без погружения в его реализацию. Это однозначно повысит качество результата за счет увеличения количества тестов и снизит трудоемкость их разработки, поскольку такие задачи легко делегировать генеративным нейросетям.
Становится крайне важно создавать корректные сообщения об ошибках - это помогает ИИ быстрее выявлять их причины и упрощает исправление с минимальным участием человека. Причем это касается как ошибок компилятора, так и ошибок во время выполнения приложения или тестирования.
Подумываю ввести в свои стандарты кодирования маркировку кода, написанного нейросетью. Что-то вроде венгерской, а точнее уже ИИ-нотации, чтобы визуально выделять сгенерированные LLM интерфейсы и фрагменты в исходных текстах программы.
-
Кроме непосредственного влияния на процесс программирования, вайб-кодинг обязательно будет иметь и организационно-социальные последствия. Например, временами у меня бывает большая загрузка по работе, но говорить с генеральным о найме еще одного штатного сотрудника мне в помощь смысла не имеет - нет реального объема работ для полноценной ставки. Но с появлением вайб-кодинга возникает хороший повод оплачивать сотрудникам доступ к нейросетям за счет работодателя (или обсудить с начальством повышение зарплаты для самостоятельной оплаты доступа к нейросетям)
В принципе на этом все.
Если кто хочет немного улыбнуться, посмотрите картинки, которые созданы по промпту:
Обычный программист и вайб-программист спорят насчет кода. Обычный программист сидит за ноутбуком с кружкой кофе и надписью С++. Вайб-кодер в очках виртуальной реальности и вейбом. На картинке должно быть изображено только верхняя половина программистов вместе с рабочим столом (ноги не видны).

Это политкорректный Midjourney, правда он не понял про ноги (что они не видны), но сами картинки вроде в порядке (у людей две руки и две ноги у стола четыре ножки и т.д.)

Stable-Diffusion тоже не понял про ноги, но стол висит в воздухе, ноги у вайб-программиста какие-то непонятные и неясно, что у него с левой рукой.

DALL-E отжигает. Вроде все правильно, но напрягает вейп пистолета у вайб-программиста афро-американца :-)

GPR-image понял промпт лучше всех, но с надписями просто беда.
Комментарии (7)
domix32
22.08.2025 09:07А чего у вас кнопка PrtScr сломалась?
rsashka Автор
22.08.2025 09:07Не понял вопроса :-(
domix32
22.08.2025 09:07Почему у вас фотографии монитора, а не снимки экрана?
rsashka Автор
22.08.2025 09:07Я решил фоткать только часть экрана, а не весь экран, чтобы потом не пришлось вырезать интересный фрагмент в графическом редакторе из всего принтскрина (я работаю на двух мониторах одновременно) .
antperetz
22.08.2025 09:07размер буфера переменной
char filepath[128]
может быть недостаточен при вызове функцииsnprintf
А вы знаете, что будет, если буфер вдруг действительно окажется недостаточен для snprintf ?
Я это узнал только недавно и после этого стандартную snprintf стараюсь не использовать.rsashka Автор
22.08.2025 09:07У snprintf указывается максимальный размер буфера для выходной строки, чтобы не возникло его переполнения. Или вы что-то другое имели ввиду?
rsashka Автор
Судя по тенденции голосования (пример настроек рабочего места не требуются), то в дальнейшей работе над проектом я не буду фиксировать значимые моменты для новой статьи, так как это отнимает время от основной продуктивной работы. Если что, просто напишу итоговый вывод, но без подробностей и скриншотов.