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

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

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

Комментарии (41)


  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. vak0
            22.08.2025 09:07

            Если вы на винде, то попробуйте Shift+Win+S


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

              У меня Ubuntu и Logitech Mx Keys на которой нет отдельной кнопки Print Screen.

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


              1. withoutuniverse
                22.08.2025 09:07

                Есть же всякие аналоги lightshot на линуксах. Фотографировать экран звучит как моветон, если это не какой-нибудь BIOS.


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

                  Фотографировать экран звучит как моветон, если это не какой-нибудь BIOS.

                  Ну пусть это будет не моветон, а олдскул :-)


                  1. pae174
                    22.08.2025 09:07

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


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

                      Пленочное фото, это не олдскул, а раритет :-)


              1. baisel
                22.08.2025 09:07

                Кажется кнопка слева умеет всё что нужно, сохраняя скриншот в буфер. Большинство WYSIWYG редакторов умеет загружать изображения из буфера. Хоть у меня нет Logitech Mx Keys, но третья клавиша справа в верхнем ряду выглядит как то что нужно.


  1. antperetz
    22.08.2025 09:07

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

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


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

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


  1. ASaasssaas
    22.08.2025 09:07

    "системный архитектор" не умеет в принтскрин...


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

      Это почему вы сделали такой вывод?


      1. slashfast
        22.08.2025 09:07

        Настолько лень для статьи сделать скрины? Видел Ваши комменты, что нет клавиши для скриншота, но на Вашей клавиатуре есть функциональные клавиши. Все биндится, если захочется, а если нет, то решается.


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

          Да, все решается, и я эту проблему решил с помощью фотографии интересного фрагмента экрана.

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


          1. Wesha
            22.08.2025 09:07

            Что же касается материала для статьи, то тут дело не в скринах, а контексте.

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


  1. markmondark
    22.08.2025 09:07

    Cчитать вайб-кодинг "программированием", которое еще и позволяет создавать ПО не имея глубоких навыков в разработке, в корне не верно. Вайб-кодинг, это больше про эмоции.

    Сильное утверждение… И позвольте мне с ним полностью не согласиться.

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

    И если сообщество настаивает, что "вайб-кодинг" - это что-то другое, то я не против, это не принципиально. А вот что принципиально - это то, что повальное использование кода без полного его понимания, должно иметь какое-то название. Так как масштаб проблемы - катастрофический.

    Если кто-то удивляется, почему я так говорю и думает, что я сгущаю краски. То вот ссылка на мое раннее сообщение, где я пытаюсь напомнить как проблема выглядит “по ту сторону”.

    https://habr.com/ru/articles/938440/#comment_28741978




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

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

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

      А вот что принципиально - это то, что повальное использование кода без полного его понимания, должно иметь какое-то название. Так как масштаб проблемы - катастрофический.

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

      AI-assisted development - это когда человек использует ИИ, чтобы сделать чужими руками то, что он вполне может делать своими. То есть, дополнительная пара рук, глаз и часов в сутках, чтобы работать существенно быстрее. Это офигенная вещь.

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


  1. gluck59
    22.08.2025 09:07

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

    Заметил примерно то же самое: не умею в bash и "навайбкодил" нужный мне функционал на одну страницу кода. Через множество ошибок и переделок, но функционал заработал...

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


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

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


      1. KanuTaH
        22.08.2025 09:07

        Все на свете тестами не покроешь, а разработка правильных тестов - это тоже своего рода искусство. Как простейший пример для баша - LLM не добавила кавычки "куда надо" (или, наоборот, добавила там где не надо), и в результате на одних данных скрипт будет работать, а на других нет. Нужно иметь представление о потенциальных подводных камнях, и разрабатывать тесты с их учётом, а это означает, что опять же нужны знания в предметной области.


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

          Знания предметной области - да, но для этого не нужно знать детали реализации.

          Вот например код тестов у парсера настроект. Он полностью сгенерирован LLM и на первый взгляд покрывает значительную часть потенциальных косяков. Когда тесты работали было заметно, что часть из них фейлилась после чего исходный код парсера исправлялся. Я не фиксировал промежуточные результаты, но общий итог мне понравился.

          Как конкретно bash тестировать, я не знаю но наверно есть способы. И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).


          1. KanuTaH
            22.08.2025 09:07

            И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).

            Вот именно что "по идее". Сгенерированное все равно потом потребуется проверить как минимум на предмет полноты и адекватности, и результат проверки вас вполне может неприятно удивить.


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

              Может удивить точно так же как и программист. Но если выбирать между галюцинирующей LLM и программистом, который может специально скрыть неправильно работающий код (были реальные прецеденты), я лучше выберу LLM.

              У нее нет умысла, она не желает достижения своих личных целей, выдает результат значительно быстрее человека и не возмущается на задачу в 10 или 20 раз переписать один и тот же код с учетом тех или иных изменений в требованиях :-)


              1. KanuTaH
                22.08.2025 09:07

                Ну я веду речь вообще-то про выбор между "написать самому или доверить LLM". LLM вряд ли принципиально лучше джуна или хитрожопого погромиста, а врать умеет даже, пожалуй, поубедительнее последнего. Впрочем, дело вкуса.


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

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

                  Что же кажется, доверять LLM или нет в случае реальной разработки, это вопрос трудозатрат, что кому выгоднее. Ведь для работы с LLM нужно орагнизовывать свое рабочее место, платить деньги провайдеру или ставить локальный сервер, ломать собственные сложившиеся привычки и пр. пр. пр.


      1. gluck59
        22.08.2025 09:07

        Тестами чего?


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

          Написанного кода (класса, функции, bash скрипта и т.д.)


          1. gluck59
            22.08.2025 09:07

            Т.е. этот код (класс, функцию, баш скрипт и т.д.) нужно сначала написать?


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

              Ну да, "навайбкодить". Ведь речь же идет о тестировании именно этого функционала.


              1. gluck59
                22.08.2025 09:07

                Нет, не о тестировании


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

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

                  Я думал, что у нас идет разговор о том, как убедится в корректности навайбкоженого решения. В противном случая я тогда не понял, что мы обсуждаем :-(


    1. Jijiki
      22.08.2025 09:07

      чтобы оценить как навайбкодила нейросеть надо открыть получившийся скрипт в вашем случае баш.

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

      в тот же момент из-за вашего погружения в части скрипта вы углубите уровень контекста и там уже увидите практики - например на sc и если повезет выберете лучшее, нейросеть всё равно будет что-то советовать, к тому моменту вы уже должны будете точно определиться что делаете


  1. KanuTaH
    22.08.2025 09:07

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


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

      Есть такая проблема и у меня тоже. Но думаю, что тесты должны помочь в этом случае. Главное не делать код слишком сложным (чтобы LLM не пришлось его серьезно анализировать).

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


  1. Tim_L
    22.08.2025 09:07

    Ну собственно, вывод напрашивается, как и в других статьях (более-менее разумных), один: llm использовать можно без особых знаний программирования для MVP и пэт-проектов. В прод идет только нормальных код, где llm помогает (!) грамотным программистам писать код.

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


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

      По итогам этой статьи пришел к выводу, что для нормального использования LLM нужно менять вообще весь подход к разработке. Сейчас пробую переделать проект, но вылезает очень много не очевидных нюансов, которые не заметны для Hello world, но сильно мешают в реальном проекте.