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

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

Эта статья - подведение итогов небольшого эксперимента (над собой) по использованию вайб-кодинга в С++ проекте, что для программиста с 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)


  1. rsashka Автор
    22.08.2025 09:07

    Судя по тенденции голосования (пример настроек рабочего места не требуются), то в дальнейшей работе над проектом я не буду фиксировать значимые моменты для новой статьи, так как это отнимает время от основной продуктивной работы. Если что, просто напишу итоговый вывод, но без подробностей и скриншотов.


  1. domix32
    22.08.2025 09:07

    А чего у вас кнопка PrtScr сломалась?


    1. rsashka Автор
      22.08.2025 09:07

      Не понял вопроса :-(


      1. domix32
        22.08.2025 09:07

        Почему у вас фотографии монитора, а не снимки экрана?


        1. rsashka Автор
          22.08.2025 09:07

          Я решил фоткать только часть экрана, а не весь экран, чтобы потом не пришлось вырезать интересный фрагмент в графическом редакторе из всего принтскрина (я работаю на двух мониторах одновременно) .


  1. antperetz
    22.08.2025 09:07

    размер буфера переменной char filepath[128] может быть недостаточен при вызове функции snprintf

    А вы знаете, что будет, если буфер вдруг действительно окажется недостаточен для snprintf ?
    Я это узнал только недавно и после этого стандартную snprintf стараюсь не использовать.


    1. rsashka Автор
      22.08.2025 09:07

      У snprintf указывается максимальный размер буфера для выходной строки, чтобы не возникло его переполнения. Или вы что-то другое имели ввиду?