Я давно пользуюсь кодогенерацией. Ещё во времена Yii фреймворка мне нравилось, что одним кликом мышки можно было сгенерировать CRUD с бэкендом, таблицами и формами. Backbone.js сразу из коробки обеспечивал REST API запросы и другие фичи. Между тем временем и нынешним днём — целый пласт инструментов для автоматизации, бутстрапинга и шаблонизации разработки. Приходилось и хрюкать, и глотать. То, что всё это, мягко говоря, так себе — уже отдельная история. Местами стало даже хуже. Хуже, чем когда вы неделю возились с конфигом Webpack.

В этой статье мы рассмотрим вайбкодинг. В чистом виде так сказать.

По ходу статьй у меня и "он" и "она" == модель ИИ, firebase, llm...

CTO который любит инновации

Сейчас в моде помощники, и они реально помогают. Я часто их использую, например, для описания этих нудных TypeScript типов. Или генерации каких-то мелочевых функций. Недавно даже придумал так называемое Sketch-программирование: описываешь новый язык или упрощённый синтаксис, а агенты при сохранении превращают это в валидный код. Эдакий LLM-транспилятор. Например, он позволяет заменить две переменные ради одной реактивной и автоматически накинуть типы. А то ведь есть проекты, где до сих пор архаичные фреймворки. А кто-то даже гордо заявляет: «Мы мигрируем на React.js!» Об этом, наверное, будет отдельная статья:

// @sketch:reactComponent
// @ext:tsx

Component Count

props add = 0
state count = 0

effect {
    console.log("Component mounted");
    
    cleanup {
        console.log("Cleanup");
    }
}

<div onclick="count += add"> Will add {add} </div>
<div>
    Current  count: {count}
</div>

import React, { useState, useEffect } from 'react';

interface Props {
    add?: number;
}

const CountComponent: React.FC<Props> = ({ add = 0 }) => {
    const [count, setCount] = useState<number>(0);

    useEffect(() => {
        console.log("Component mounted");

        return () => {
            console.log("Cleanup");
        };
    }, []);

    const handleClick = () => {
        setCount((prev: number) => prev + add);
    };

    return (
        <div>
            <div onClick={handleClick}> Will add {add} </div>
            <div>
                Current count: {count}
            </div>
        </div>
    );
};

export default CountComponent;

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

Оплатил нам Tabnine. И хоть не на каждом дейлике, но через раз спрашивает: как мы его используем, чем он нам помогает.

Смотрите, я прилинковал к нему Jira, указал тикет и он сделал его. А ведь я не шарю Javascript.
Вы знали об этом?

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

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

Вайбкодинг пришел

День за днём идёт, и я даже привязал Jira к Tabnine, чтобы быть объективным. Хочу попробовать инструмент, прежде чем заявлять, что это полная дичь. Информация из Jira — лишь контекст для промптов. Могу попросить подсказку, если проект незнаком, или сгенерировать константы из задачи. Но тикет за меня он сам не сделает. CTO же это понимает, правда?

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

Сделай проект генерации URL для рекламных компаний. С помощью Firebase.studio

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

15+ лет веб-разработки, сошлись на - повайбкодь плиз.

Но стоит отдать должное этому CTO, я бы так и не попробовал такие инструменты, и статьи бы этой не было. Так что в чём-то плюсы всё-таки есть. А ещё это работа, и за это платят. Хотите, чтобы я потратил неделю в попытках навайбкодить с риском всё выкинуть — окей. Любой каприз. Для кого-то это было бы даже круто и интересно. Просто я уже не то чтобы выгоревший разработчик, но кайфанул бы больше от создания приложения на Backbone.js и jQuery, чем от новомодного мирка сборных солянок и микрофронтов.

Что такое вайбкодинг?

Прежде чем перейдём к конкретике, нужно понимать, о чём вообще идёт речь.

Вайб-кодинг — это парадигма программирования, основанная на искусственном интеллекте (ИИ), при которой человек описывает задачу в нескольких предложениях в виде запроса к большой языковой модели (LLM), настроенной на написание кода. Модель генерирует программное обеспечение, а роль программиста сводится к направлению, тестированию и доработке сгенерированного ИИ кода. Сторонники вайб-кодинга утверждают, что он позволяет даже любителям создавать программы без глубоких навыков и обучения, необходимых для инженерии ПО. Термин был введён Андреем Карпатым в феврале 2025 года и в следующем месяце включён в словарь Merriam-Webster как «сленговое и трендовое» существительное.

А дальше уже есть несколько лагерей, что именно считать вайбкодингом. Например, что подразумевается под тестированием? Вы, как мануальный тестировщик, прокликиваете ваше приложение? Может быть, пишите какие-то тесты? Но если вы новичок, то скорее всего первое. А что с доработками? Правите код, или просите LLM внести изменения?

Ключевая часть определения вайб-кодинга заключается в том, что пользователь принимает код, не полностью понимая его. Исследователь ИИ Саймон Уиллисон сказал:

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

То есть для меня вайбкодинг, это когда я целиком и полностью сделал приложение за счёт ИИ, ну, может, с какими-то минимальными правками в коде, когда это сделать проще/быстрее, чем написать промпт. Прямо вот самая настоящая вера в то, что всё делает ИИ. Это не то же самое, что кодить в Cursor или пользоваться автокомплитом Copilot. Иначе зачем всё это?

День 0

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

На руках у меня документ на Google Drive, написанное далеко не по ГОСТ техническое задание. Разумеется, с ошибками и упрощениями. Всё, как мы любим. Был ещё один созвон для его ревью.

Приложение довольно простое: форма с параметрами, парсинг загруженного CSV-файла со странами, языками и т.д., обращение к стороннему API, генерация URL на основе полученных данных и создание CSV-файла с актуальными ссылками для рекламных кампаний.

В связи с NDA я, разумеется, не могу прямо всё показывать, но ТЗ выглядит примерно так:

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

Мы видим практически идеальный UI для приложения — даже лучше, чем я ожидал. Это React.js-приложение на Next.js с семантической разметкой, валидацией согласно ТЗ (возле каждого поля и общей плашкой) и даже тостами (всплывающими уведомлениями). Некоторые вещи я не просил — ИИ проявил инициативу. Условия проверок в ТЗ я, даже не читал.

Всё работает: он реально парсит файл и генерирует новый. Это было сделано буквально за минуты. Вот она, ИИврика!

Затем я начал тестировать — всё-таки я Senior Front-end Engineer, должен же что-то делать. Как писал выше, файл парсится, результат выдаётся, но иногда ничего не происходит. Видимо, ошибка или недочёт. Потребовалось 5–10 промптов, чтобы тосты, которые я похвалил, начали отображаться корректно. Они были прозрачными или перекрывались — пока не разобрался. Валидация тоже иногда не срабатывает.

У Firebase есть два режима, вот эти выше на скриншотах — полная магия, он даже не даёт мне ревьюить код. Просто в случае чего можно сделать ресет на предыдущие коммиты. Это очень важная фича.  

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

А там прямо все очень интересно. Несмотря на то, что промты пишу я, "разработкой" занимаюсь, все вытекающие ответственности на мне - код то не мой. Я смотрю на код в моём приложении, и это не моё. Это даже хуже, чем смотреть на чужой код. В случае работы в команде ваш коллега следует каким-то правилам компании, код другого разработчика легко читаем, а тут — просто инопланетянин.
Наверное, будто смотришь на ассемблер, на котором особо не писал. Стек знакомый, некоторые подходы могут быть знакомыми, например Tailwind, компоненты CVA, TypeScript, но всё остальное просто другое. Править это руками невозможно. Для дебага мне пришлось клонировать себе локально всё и запустить. Учитывая, что это Next.js с SSR, ещё придётся немного полюбиться.

Ещё интересного: у меня в компонентах какой-то Avatar.tsx и десяток совершенно левых и ненужных для приложения компонентов. Зачем, почему — загадка.

Как-то на своём джедайском пути у меня была задача — сделать тултип сверху кнопки, а в библиотеке общих компонентов был только справа. Как настоящий альтруист, я сделал тултип для всех сторон. Но на ревью мне заблочили: «Зачем? В требованиях нет тултипа на все стороны. Реализуя лишнюю логику, ты добавляешь кодовой базы, которую нужно будет поддерживать».
У меня тогда знатно пригорело, но, мне кажется, я чему-то научился.
Вернёмся к нашим баранам.

Я не хочу рыться в этом коде. Вайбкодинг — не про это, подумал я, и продолжил тестировать и писать промпты. Я довёл приложение до такого состояния, что оно буквально ушло в какой-то бесконечный цикл косяков — и ничего не работало.
Как оказалось, оно даже не ходило в сторонний API, а просто додумывало какой-то рандомный мусор и складывало это в CSV-файл.
Каким образом далекий от разработки человек поймет, делает ли приложение запрос на сервер?

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

Но вдруг он попробует — и у него получится?))
Я решил подойти к вопросу более трепетно. Ведь, опять же, это просто работа: хотите, чтобы я тратил время впустую — окей.
Подумал, что выводы мои поспешны. Может быть, мне стоит изучить тему? Вдруг я просто не умею вайбкодить… тьфу.

70 % чуда

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

ИИ может сделать за вас 70%, но последние 30% вызывают разочарование. Он делает шаг вперёд, но затем два шага назад из-за новых ошибок и проблем.

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

Где эти инструменты дают сбой? Опытные инженеры постоянно указывают на проблему «последней мили». ИИ может создать правдоподобное решение, но последние 30% — обработка частных случаев, доработка архитектуры и обеспечение поддержки — «требуют серьёзной человеческой экспертизы».

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

ИИ может выдавать убедительные, но кривые результаты. Он может нагенерить скрытых багов или «галлюцинировать» несуществующие функции и библиотеки (например Avatar.tsx или какое-то левое API поиска названия страны, хоть я ему дал валидный урл). Стив Йегге с иронией сравнивает современные LLM с «дико продуктивными джунами» — невероятно быстрыми энтузиастами, но «потенциально находящимися под воздействием изменяющих сознание веществ», склонными придумывать безумные или неработоспособные подходы.
Это буквально коммиты СТО, который пытается в фрондендера когда ему скучно.

По словам Йегге, LLM может выдавать код, который на первый взгляд выглядит хорошо, но если менее опытный разработчик наивно скажет «Выглядит нормально!» и начнёт его использовать, через пару недель может наступить веселье. ИИ не понимает проблему по-настоящему. Он сшивает шаблоны, которые обычно имеют смысл. Только человек может заметить, скрывает ли внешне нормальное решение долгосрочные косяки. Саймон Уиллисон подтвердил это, увидев, как ИИ предложил заманчиво хитроумный дизайн, который только старший инженер с глубоким пониманием проблемы мог распознать как ошибочный.

Уверенность ИИ значительно превышает его надёжность.

Критически важно, что современные ИИ не создают принципиально новых абстракций или стратегий за пределами своих данных. Они не изобретут новый алгоритм или инновационную архитектуру — они перерабатывают, то, что знают. Также они не берут на себя ответственность за решения. Как отметил один инженер: «ИИ не предлагает идей лучше, чем то, что содержится в их обучающих данных. Они не отвечают за свою работу».

Всё это означает, что творческое и аналитическое мышление — выбор, что строить, как это структурировать и почему — остаётся исключительно человеческой задачей. В итоге, ИИ — это инструмент для разработчиков, справляющийся с повторяющимися задачами и дающий буст производительности. Но он не панацея, заменяющая человека и тем более настоящего программиста. Оставшиеся 30% сложные части — по-прежнему требуют навыков, которые могут привнести только обученные, мыслящие разработчики. Это навыки, на которых стоит сосредоточиться.

ИИ — мощный инструмент, но не волшебное решение... человеческая экспертиза и знания разработки всё ещё необходимы

Это мне напоминает собесы, где кандидат вроде знает фреймворк, но не знает разницу между var, let, const самого языка. Он вроде где-то работал, но может ли он, что-то сделать - мега сомнительно. Нужен опытный человек в команде, который сможет исправить, поддерживать все это говно. Не сможет какой-то свитчер с левым образованием навайбкодить вам продукт. И хорошо если это на прод не попадет. Ведь там может быть, что угодно.

Варианты обуздания вайбкодинга

Я заметил два разных подхода, как команды используют ИИ для разработки: назовём их бутстраперы и итераторы. Оба помогают инженерам (и даже не техническим пользователям) сократить путь от идеи до реализации (или MVP).
Бутстраперы обычно запускают новый проект с нуля до MVP. Инструменты вроде Bolt, v0 и ИИ для преобразования скриншотов в код радикально меняют этот процесс. Такие команды обычно:

• Начинают с дизайна или грубой концепции

• Используют ИИ для генерации начальной кодовой базы

• Получают рабочий прототип за часы или дни вместо недель

• Фокусируются на быстрой валидации и итерациях

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

Итераторы используют инструменты вроде Cursor, Cline, Copilot и WindSurf в повседневной разработке. Это менее эффектно, но куда проще делать изменения. Такие разработчики:

• Используют ИИ для автокомплита кода и подсказок

• Применяют ИИ для сложного рефакторинга

• Генерируют тесты и документацию

• Используют ИИ как «парного программиста» для решения задач

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

Когда синьоры работают с инструментами вроде Cursor или Copilot, это выглядит как магия. Они могут создать целую функциональность за минуты, включая тесты и документацию. Но если присмотреться, заметно ключевое: они не просто позволяют ИИ генерировать код. Они постоянно рефакторят сгенерированный код. Они добавляют обработку ошибок, ловят edge кейсы, которые ИИ пропустил, усиливают типизацию и интерфейсы, а также ставят под сомнение архитектурные решения ИИ.
Иными словами, они применяют годы опыта, чтобы формировать и ограничивать вывод ИИ.
ИИ ускоряет реализацию, но их экспертиза обеспечивает поддержку проекта.

Ошибки при использовании ИИ

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

1. Вы пытаетесь исправить небольшую ошибку.

2. ИИ предлагает изменение, которое кажется разумным.

3. Это исправление ломает что-то другое.

4. Вы просите ИИ исправить новую проблему.

5. Это создаёт ещё две проблемы.

6. Цикл повторяется.

Этот цикл особенно болезненный для далеких от программирования людей, поскольку у них нет понимания того, что на самом деле идёт не так. Когда опытный разработчик сталкивается с ошибкой, он может рассуждать о возможных причинах и решениях, опираясь на годы опыта. Это и есть «парадокс знаний»: опытные программисты используют ИИ для ускорения того, что они уже умеют делать, в то время как джуны пытаются использовать его, чтобы научиться, что-то делать. Ну или даже не пытаются научиться, просто пытаются закрыть тикет. Привет Косте -

Под конец дня, я просто пытаюсь вставить код в разные места, вдруг заработает

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

День 1

Я не могу за один заход сгенерировать приложение — его потом нереально исправить.
Но я так же не хочу писать код в Cursor.
Зачем мне тогда вообще этот термин «вайбкодинг», и в чём суть задачи, если я и так как бы вайбкодил с автокомплитом?

Я хочу полноценный экспириенс от А до Я — хочу создать приложение только промптами.

Успокоился. Просто попробую ещё раз.
Решил попробовать инкрементный подход. Инкрементный — в смысле по чуть-чуть, не закидывать ИИ всем ТЗ сразу, а реализовывать так, как я бы это реально делал.

Начал с простого промпта.

Lets create an empty nextjs app with react and typescript, and storybook, then we will add needed functionality

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

Все супер, проект начат. Сторибук он правда не сделал. Меня терзают сомнения: не думает ли он, что это — проект пустого приложения, и поэтому все последующие промпты просто будут чередой багов?

Следующий промт с моим не самым бест ос зе бест английским (иногда думаю, может, из-за мелких ошибок его глючит):

Let's add form on a main page Website TPD Vertical: Hotels, Flights, Cars Language Campaign match type: cities, country, routes

Он верстает мне форму, я прошу внести изменения, но эти изменения по факту контекст к форме, я дополняю, а не изменяю:

The website input actually should be a dropdown with these options
перечисляю тут домены

И он делает все четко. Следует итерация из чистки навоза в виде Next.js, hydradion error.

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

the user should not see option in the vertical dropdown if the website doesn't have it
перечисляю сайты и вертикали

Попросил делать авто-выбор первого варианта вертикали, и всякое по мелочи, генерировало хорошо.

Прошу добавить кнопку загрузки:

Add button to the end of the form the button fill upload csv file for further processing csv structure: Country code State (optional) Location (city/airport) (optional)

Он добавил кнопку, добавил к ней так же описание. Тут стоит обратить внимание на Max 5MB. Я не просил его об этом. Но и не написал явно каких-либо требований.

Для себя я вывел следующее:

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

Я попросил его сделать кнопку загрузки файла, но не указал требований к файлу — он додумал. Потенциально — косяк.
И вот, забегая вперёд: все косяки, что были в приложении, — из-за плохо прописанных требований.

Если вы читали книгу «Совершенный код» — требования, их анализ, проектирование и т. д. и т. п. — это фундамент приложения.
И чем позже будут выявлены косяки, заложенные на этом этапе, тем дороже будет фикс.
Мне, как фронтенд-разработчику, крайне сложно делать веб-сайт без дизайна и чёткого UI/UX, без чётко описанного юзкейса пользователя.
И я прекрасно понимаю модельку, которая додумывает — а я потом на неё ругаюсь.
Пример с 5 МБ немного притянут за уши (просто не ставить на это валидацию — норм решение), но, повторюсь, все остальные баги были явно из-за плохих требований.

При первой попытке было сложно описать стороннее API — или, точнее, заставить его переосмыслить, зачем он вообще добавил себе в код какой-то левый API. Приложение просто его не вызывало.

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

App should know, that if user selects specific Vertical we will need to call diffrent api when processing uploaded file rows. Lets for now just add it

If user selects Hotels https://www.kayak.com/mvm/smartyv2/search?f=j&s=50&v=v1&lc=en&lc_cc=EN&where=[put location from the csv file, and state if row has it]

... для других вертикалей

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

Далее, я так же дал ей пример ответа этого API. Модель подготовило типы. Забавно, что не прописала его никуда, просто объявила.
Так же попросил сделать правки в типы и вот часть мыслей:

The user has provided additional information about the possible values for the loctype field in the LocationResponseItem type. To ensure type safety and accuracy, the type definition needs to be updated to reflect these values. By changing loctype: string; to loctype: 'city' | 'ap' | 'ctry';, we are explicitly defining the allowed values for this field, which can help prevent errors and improve code maintainability.

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

async function fetchLocationData(apiUrl: string): Promise<LocationResponse | null>

Используя такой вот подход инкрементной разработки, понимания того, как и что устроено внутри, как разрабатывает приложение настоящий разработчик, — я могу свести к минимуму глюки модели и баги.
Я, по факту, прораб LLM-модели. Я понимаю все процессы и как это должно выглядеть в итоге — чётко и постепенно говорю, что нужно сделать.
Своим английским, не на HTML, CSS, JS — а на обычном человеческом языке.
По факту, языком написания этого приложения стал английский.

Дальше я уже прошу добавить кнопку создания файла, где и описываю основной процесс:

Следует ряд правок, там где я упустил детали и он додумал

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

Double check the app doing this According to the Campaign match type, match the most relevant location from the results (according to “loctype” param) Cities = city Airport = ap (routes option in the Campaign match type dropdown) Country = ctry

you should take results from kayak response accordinly

Ведь в код я лезть не хочу — пусть сам убедится в этом. Тестирую — работает как надо.

И добавляю последние штрихи

Each website has it's own url structure, so we need to generate different urls for different website. lets start with https://besthotelsprices.com

Example of the url for https://besthotelsprices.com/ https://besthotelsprices.com/en?destCode=C:4096 So we need to set proper lang and code

travelpricedrops.com is a little bit different https://travelpricedrops.com/hotels/city/Zuidwolde?lng=it&destCode=C:17102 Structure is https://travelpricedrops.com/[vertical]/city/[city name]?lng=[lang]&destCode=[code is here]

Прошу его генерировать разные по формату URL для разных веб-сайтов, и, поскольку я сам не знаю всех форматов, прошу начать с конкретных двух — и на выходе получаю:

 // Generate URL based on website
    switch (website) {
        case 'https://besthotelsprices.com/':
            // Structure: https://besthotelsprices.com/[lang]?destCode=[code]
            // Only Hotels vertical is supported, so destCode is always used.
            // Assuming C:id is always correct for hotels on this site.
            return `${baseUrl}${langCode}?destCode=${locationCodeValue}`;

        case 'https://travelpricedrops.com/':
            // Structure: https://travelpricedrops.com/[vertical]/[loctype]/[location_name]?lng=[lang]&[code_param]=[code]
            return `${baseUrl}${verticalLower}/${locationType}/${locationName}?lng=${langCode}&${codeParamName}=${locationCodeValue}`;

        // Add cases for other specific websites here...
        // case 'https://therentalradar.com/':
        // case 'https://smarterflyer.com/':
        // case 'https://searchhotelprices.com/':
        // case 'https://bestflightsprices.com/':
        // case 'https://bestflightsrates.com/':
        //     // Implement their specific structures

        default:
            // Fallback to a generic or default structure if needed, or return empty/error
            console.warn(`URL generation not implemented for website: ${website}. Using default structure.`);
            // Example default structure (adjust as needed)
            return `${baseUrl}${langCode}/${verticalLower}/${locationType}/${locationName}?${codeParamName}=${locationCodeValue}`;
    }

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

Код вам не принадлежит

Еще один важный момент. Код, который генерируется, вам не понравится. Это чужой код, сложный, не по вашим стандартам и не по вашим привычкам. Если вы хотите следовать вайбкодингу, правки нужно делать через промты, а модель и среда — опять же не ваши. Нагенерить целый фуллстек-проект, а потом править его руками — не выйдет. Это вкус легаси, вкус нового места работы, где всё так, потому что так сложилось. Ментально это сложно. А как я писал выше — ответственность на вас и вашей команде.
Модель часто правит левые файлы, как джун, который решил понтануться и отрефакторить файлы не по задаче, а вы теперь ревьювите лишний код.

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

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

Выводы:

Задача была не просто использовать автокомплит, а реализовать полноценное приложение от А до Я.
Я получил приложение, в котором не написал ни строчки кода. Оно парсит файл, ходит на сторонний API, генерирует файл и несёт пользу бизнесу. В таком кейсе, возможно, вайбкодинг — это действительно круто. Но точно не инструмент для людей, которые не имеют опыта разработки, даже не инструмент для джунов.
Нужно буквально говорить с инструментом языком, граничащим с сухими требованиями и алгоритмами, понимая, где эта магия может облажаться.
Я занимаюсь разработкой уже много лет и не только фронтендом, но я едва ли смог обуздать этот инструмент и по-прежнему отношусь к нему с подозрением. В таких вот «а-ля давай попробуем быстренько накидать» — это самое то. Главное — наловчиться.

В исходниках, конечно, опять нагенерились лишние и неиспользуемые файлы. Если попросить убрать лишнее — он уберёт. Это опять же можно сделать промтами или, как минимум, в режиме написания кода, он предложит выполнить такую-то команду по их удалению. Таким образом, я первый раз двигал файлы по проекту.
Что будут генерить эти модели, если критическая масса датасета будет состоять из их же глюков? Ведь сейчас они хоть у людей набираются паттернов, а как дальше, с повышением абстракции — загадка.

Для меня, возможно, надежным в разработке более сложных систем будет подход, упомянутый в начале, — скетч-программинг. Пока я реализовал его только в виде плагина под VS Code. Это отдельная история. О нём я постараюсь написать свою следующую статью.

• Vibe coding

• The 70% Problem

• Sketch-programming

• firebase.studio

upd @redfox0, спасибо за правки по тексту