Мнение: в вайб-кодинге недостаточно сказать ИИ «сделай красиво» и нажать Enter — всё равно нужны знания и опыт
Потому что генерации нередко как карточный домик: на вид стоит, но один порыв ветра — и конструкция рушится.
Текущие ИИ-ассистенты — «джуны», которым нужно чёткое ТЗ
Термин ввёл сооснователь OpenAI Андрей Карпатый, пошутив, что теперь самый модный язык программирования — это английский. Учёный «скармливает» нейросетям нужные для задания данные и сразу запускает получившийся код, а правки вносит уже постфактум.
Скептики считают: истинные вайб-кодеры — «энтузиасты, которые клепают приложения с помощью ИИ, мало что понимая в программировании». И такие действительно есть.
Сперва они «гордятся», что с помощью двух запросов сгенерировали продукт за 15 минут, а потом — «вдруг» — сталкиваются с ошибками и не понимают, почему система перестала работать или пользователи начали «обходить авторизацию и тратить весь их бюджет на API», говорит автор Telegram-канала «Блоgnot», бывший руководитель украинского офиса «Яндекса» и основатель Searchengines.ru Сергей Петренко.
По его словам, вайб-кодинг в чистом виде — «когда не надо смотреть, что делает система», — едва ли возможен на данном этапе. Недостаточно сказать нейросети: «Сделай чудо и чтоб красиво». Ей нужен контекст. Например, когда автор собрался автоматизировать публикацию заметок в свой канал, он «расписал [модели] пунктов десять» на «несколько абзацев»: откуда и что он берёт, что делает следом, какие именно шаги рассчитывает автоматизировать.
[Текущие ИИ-ассистенты], которые пишут код, эквивалентны тому, что называется «джун-программист». «Джун» может знать много кода, много писать, но он плохо ориентируется в проекте и не способен проектировать. Он может выполнить условную задачу, написать функцию, участок, модуль. Но увязка всего этого вместе вызывает проблемы. Не хватает квалификации. Надо несколько лет понимать, что из множества поставленных кирпичей вырастает стена, а из стены — здание. И понимать, как эту стену [строить], чтобы здание не завалилось.
Сейчас он готовит полноценные техзадания — зачастую с моделью o1-pro в ChatGPT, отдавая ей «вообще всё»: не только техдокументацию, но и «обрывки мыслей». А после предлагает обсудить данные и набросать задание для разработки с описанием интерфейсов и стеков, «что как использовать» и зачем, в каком формате и куда сохранять. И для этого нужна «определённая квалификация».
Всё, что вы не детализируете в ТЗ, [языковая модель] детализирует по-своему. А она не знает, как надо, и подставит наиболее вероятные варианты. <...> Ей надо описать, что на входе, что на выходе, что вы хотите получить из одного в другое. И даже в этом случае она, скорее всего, ошибётся или что-то додумает. Вы это запустите, увидите. Но если не написали никакого техзадания, что вы увидите — вообще непонятно.
Иногда «инициативные» нейросети ломают то, что работает, и не чинят сломанное
Так как модель будет предполагать, будут и «галлюцинации». «Яркий пример — работа с API», — говорит Петренко. Например, однажды он передал Claude массив текстовых файлов и попросил разрезать их на «чанки», получить «эмбеддинги» из OpenAI и «положить» в векторную базу.
Модель указала на превышение максимального объёма запроса в 8000 токенов. Петренко знал, что «чанки» обычно не превышали и 4000 токенов. Пока разбирался, увидел, что Claude «оптимизировал» процесс и слал запросы пакетами из десяти кусков, которые в сумме действительно превышали лимит. Автор объяснил боту, «как пишутся пакеты», но тот «нафантазировал» «эндпойнты» в API, из-за чего запросы перестали проходить. Петренко указывал на ошибку, но бот в одном месте правил конечную точку, а в другом — нет.
В ещё одном примере ИИ-ассистент решил, что модели GPT-4o mini, которая требовалась Петренко, не существует и потому исправила название на более дорогую и менее подходящую ему модель GPT-4. Если это упустить, можно так никогда и не понять, почему и результат не оправдывает ожиданий, и денег уходит больше.
Однажды модель также вызывала несуществующую таблицу в базе данных автора, хотя схема базы была расписана — «в нескольких местах», включая документацию и скрипты. Если за вайб-кодинг берётся пользователь без знаний, он может и не думать, что у баз данных вообще бывают схемы.
Починка багов — тоже целое приключение. Иногда, чтобы избавиться от новых ошибок, бот возвращает старую версию с прежними багами. Или считает свежие проблемы важнее выявленных ранее, хотя это не всегда так. Что-то может оставить на усмотрение человеку, который этого не ожидает. А порой так вообще — чинит баги как пингвин из «Мадагаскара»: просто отключая проблемную функциональность.
Помните, во второй части, когда пингвины летели на самолёте, [один из них] говорит: «У нас проблема, горит лампочка минимального уровня топлива». Командир берёт книжку, бьёт по лампочке, та тухнет, и он говорит: «Лампочка погасла, проблемы нет».
ИИ в состоянии автоматизировать рутину, но не обещает качество
Петренко не отрицает, что вайб-кодинг неплох, когда речь идёт об «одноходовых» задачах «без ветвления в логике»: сверстать лендинг, написать примитивную анимацию, арканоид или спрайтовый шутер, который работает целиком на JavaScript и только в браузере.
Но «когда возникает вопрос с дополнительной логикой» — «загрузить, подождать или выключиться и перезапуститься с проверкой статуса», — у нейросети нередко «начинаются проблемы». Петренко убеждён: «Человек, гордо рассказывающий, что ничего в этом не понимает, не сможет добиться нужного результата. А если добьётся, то случайно, и оно в итоге развалится».
В случае с опытными разработчиками я уверен, что они просто недооценивают степень своего внимания к задаче. Не понимают, что то, что для них как бы естественно, на самом деле требует определённого знания.
Руководитель команды разработки в Google Эдди Османи согласен, что ИИ может написать хороший код. Но отличить его от плохого в силах только опытный «кодер». По его словам, генерации нейросетей — это нередко карточные домики: они только выглядят завершёнными, а «под давлением реального мира рушатся».
Вайб-кодинг может помочь автоматизировать работу с шаблонными задачами, но, если конечный продукт должен быть качественным, он всё равно требует вовлечения человека. Во всяком случае на данном этапе развития ИИ, пишет Османи. По его мнению, даже вайб-кодить нужно с умом, поэтому он предлагает свод правил:
- Сгенерированный код нужно перепроверять, словно его писал недавно нанятый «джун». Если времени на проверку нет, то и от вайб-кодинга лучше отказаться.
- Следует указать нейросети «стандарты» проекта: архитектурные паттерны, стиль, привычные для команды подходы (например, к комментированию и тестам).
- Лучше считать ИИ «ускорителем», а не «системой автопилота». Он возьмёт на себя «хорошо понятные» задачи, но не должен думать за разработчика.
- Код нужно тестировать, потому что за правильность нейросеть не отвечает. Часть тестов можно написать с её же помощью, но и про ручное тестирование лучше не забывать. Особенно если речь идёт о разработке пользовательских интерфейсов.
- Принимать первую же генерацию за финальную не стоит — важен итеративный подход. Можно давать команды самой модели или самостоятельно «рефакторить» её черновики.
- Стоит помнить, что вайб-кодинг не универсален. Собрать таким образом прототип, чтобы быстро проверить концепцию, — одно. А разрабатывать критически важный модуль безопасности или же закладывать за счёт ИИ фундамент кодовой базы — это риск.
- Сгенерированному коду нужна документация. А если отдельные фрагменты могут вызвать вопросы у разработчиков, ещё и сопроводительные комментарии к ним.