Людмил Пелов, старший менеджер по продуктам генеративного ИИ в Oracle Cloud, рассказывает на портале The New Stack о пяти уроках, которые он извлек в ходе проекта по вайб-кодингу (vibe-coding), направленного на создание плагина для решения проблемы слишком большого количества открытых вкладок браузера.

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

Пробуждение силы

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

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

Просто введя в ChatGPT подсказки о желаемой функциональности и пользовательском опыте, я быстро, в течение 30 минут, создал первую версию своего плагина. Хотя мой опыт кодирования был полезен, около 95% кода было сгенерировано с помощью большой языковой модели (LLM).

Экспансия

Я хотел большего, что требовало интегрированной среды разработки (IDE), в которой я мог бы лучше использовать возможности вайб-кодинга для своего проекта без необходимости копировать и вставлять код из ChatGPT в VS Studio. После изучения вариантов я остановился на Trae, которая предлагается бесплатно и обеспечивает хорошие возможности. Хотя все IDE используют одни и те же базовые модели для кодирования, с помощью нескольких простых настроек пользовательского опыта они становятся значительно лучше.

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

LLM наносит ответный удар

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

Одна проблема бросалась в глаза: плагин ненадежно обнаруживал дубликаты. Например, если ссылка менялась, а содержимое страницы оставалось прежним, плагин не распознавал это изменение. Вы можете переместить страницу в другое место, но даже если содержимое остается идентичным, URL меняется. Я хотел, чтобы плагин отлавливал такие случаи, проверяя независимо и URL, и заголовок страницы.

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

Проверка реальностью

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

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

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

Повышение продуктивности

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

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

Уроки на будущее

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

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

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

Для тех, кто хочет начать использовать вайб-кодинг для себя, вот пять вещей, о которых вы должны знать:

  1. Выбирайте IDE в зависимости от ваших потребностей. Поскольку проекты быстро масштабируются, оценивайте варианты в соответствии с вашими уникальными требованиями. Я использовал Trae, но плагины для VS Code также стали очень эффективными, поэтому попробуйте несколько вариантов, прежде чем остановиться на одном.
  2. Пишите четкие подсказки и постоянно обновляйте контекст. Не ожидайте, что LLM полностью поймет ваш проект или требования, просто прочитав ваш код.
  3. Валидируйте все. Не принимайте предложения по коду вслепую; убедитесь, что вы сами все проверили, иначе у вас будут проблемы.
  4. Навыки кодирования очень важны. Чем лучше вы умеете кодировать, тем больше пользы вы получите от вайб-кодинга. Если вы не уверены в своих навыках кодирования, вы станете «узким местом», неспособным проанализировать, отладить или эффективно направить модель, когда что-то пойдет не так.
  5. Воспользуйтесь неожиданными преимуществами. Одно из неожиданных преимуществ было связано с пользовательским опытом. Мне никогда не нравилось работать с CSS и стилями, особенно из-за головной боли, связанной с обеспечением кроссбраузерной совместимости. Однако благодаря мультимодальным моделям я теперь могу создать макет и получить пригодный для использования результат. Уже одно это позволило мне сэкономить часы утомительной работы.