Мне подключили доступ к Вайбкрафту от Яндекса. Это сервис веб-кодинга внутри экосистемы SourceCraft: описываешь задачу обычным языком, агент пишет код, показывает предпросмотр, исправляет ошибки и помогает довести идею до опубликованной страницы.
Я решил не делать тест в стиле «кнопка, текст и зелёный квадрат». Собрал маленькую интерактивную страницу Clock Battle: Generations. Это такая битва стрелочных и цифровых часов, где нужно крутить время кнопками и понимать, куда показывает циферблат.
Рабочая версия здесь: Clock Battle: Generations на SourceCraft Sites. Сам сервис Вайбкрафта: sourcecraft.dev/vibe-app.
Сразу главное впечатление: как быстрый прототип это очень интересно. Но есть нюанс. Агент сначала норовит сделать полноценное приложение на Next.js и развернуться куда-нибудь в облако. Для простой страницы с часами это, мягко говоря, как поднимать Kubernetes ради кнопки «О нас». Поэтому я попросил не городить лишнее и сделать статическую версию.
Что такое Вайбкрафт в моём понимании
Вайбкрафт это не просто чат, который выдаёт кусок HTML. Это браузерная среда, где AI-агент работает рядом с проектом: составляет план, пишет файлы, запускает проверки, показывает предпросмотр и публикует результат.
По ощущениям это ближе к маленькой IDE с агентом. Слева виден план и ход задачи, справа предпросмотр страницы. Не нужно вручную копировать код из чата, создавать файлы, запускать локальный сервер и потом полчаса выяснять, почему оно «у модели работало».
Вайб-кодинг здесь выглядит так: человек задаёт направление, агент собирает черновую реализацию, человек смотрит результат и уточняет. Это не отменяет разработчика. Просто разработчик меньше возится с пустым экраном и быстрее получает первый работающий вариант.
Но радоваться нужно аккуратно. Вайб-кодинг не превращает любой промпт в хороший продукт. Он быстро даёт основу. А дальше начинается нормальная инженерная рутина: проверить, сломать, поправить, снова проверить.
Что я собрал: Clock Battle
Я сделал страницу Clock Battle: Generations. В центре аналоговые часы, рядом цифровое время и кнопки управления: плюс час, минус час, плюс 5 минут, минус 5 минут, сброс.
Смысл простой: пользователь видит время, нажимает кнопки и следит, как меняются стрелки и цифровой таймер. Получилась маленькая веб-игрушка на тему вечной битвы поколений: одни спокойно читают стрелочные часы, другие смотрят на циферблат как на приборную панель НЛО.
Для теста сервиса это удачная задача. Тут есть состояние, анимация, кнопки, визуальная логика, адаптивность и необходимость проверять крайние случаи. То есть это уже не просто красивая статичная картинка.
Первый важный момент: агент любит Next.js
Самое интересное началось не с дизайна, а с архитектуры. Агент сначала пошёл по привычной дорожке: Next.js, веб-приложение, деплой в Яндекс Облако. И для какого-нибудь сервиса с API, базой, авторизацией и серверной логикой это нормально.
Но для моей задачи это было лишним. Clock Battle в текущем виде спокойно живёт как статическая страница: HTML, CSS, JavaScript. Никакой базы данных, никакой авторизации, никакого backend, никакой серверной магии. Просто страница, которая работает в браузере.
Поэтому я бы сформулировал так: AI-агенту нужно сразу объяснять, какой тип проекта нужен. Иначе он может начать строить маленький дата-центр там, где достаточно одного статического сайта.
Для лендинга, портфолио, документации, демо-страницы, промо-блока или такой мини-игры статический вариант обычно лучше. Он проще, дешевле, быстрее и понятнее в сопровождении.
А вот Node.js и облачный деплой нужны, когда есть реальная серверная часть: API, база данных, личные кабинеты, авторизация, платежи, генерация данных на сервере, фоновые задачи. Просто потому что «так современно» — плохая причина тащить серверную инфраструктуру.
Статика: не революция, но удобно
В итоге опубликованная версия живёт на SourceCraft Sites. Это статический хостинг из репозитория. Если смотреть сухо, сама идея не новая: GitHub Pages, Netlify, Vercel и похожие решения мы уже видели много раз.
Поэтому если кто-то скажет «статический сайт из репозитория, ну и что?», я пойму. В 2026 году этим уже трудно удивить. Сам по себе статический хостинг не выглядит как технологическое откровение с небес.
Но интерес Вайбкрафта не в том, что он просто публикует статику. Интерес в связке: агент пишет проект, показывает предпросмотр, помогает исправлять ошибки и сразу даёт путь к публикации. То есть не отдельный чат, не отдельный редактор, не отдельный хостинг, а один рабочий поток.
Вот это уже полезно. Особенно для быстрых прототипов, учебных проектов, демо-страниц, мини-лендингов и проверки идей. Не революция, но хорошее сокращение расстояния от «а что если сделать» до «вот ссылка, можно открыть».
Как я бы правильно ставил задачу агенту
После этого теста я бы сразу писал в промпте, что проект должен быть статическим, если backend не нужен. Иначе агент может выбрать более тяжёлую архитектуру по умолчанию.
Пример нормального стартового промпта:
Сделай статическую интерактивную страницу Clock Battle: Generations. Важно: не использовать backend; не делать Next.js сервер; не использовать базу данных; не разворачивать приложение в облако как серверный сервис; результат должен работать как статический сайт: HTML, CSS, JavaScript. Идея: мини-игра про сравнение стрелочных и цифровых часов. Интерфейс: тёмный, но не слишком мрачный фон; неоновая стилистика; крупный аналоговый циферблат; рядом цифровое время; кнопки управления временем. Кнопки: +1 час -1 час +5 минут -5 минут Сброс Логика: кнопки должны менять время на циферблате и в цифровом блоке; стрелки часов должны обновляться; минуты и часы должны корректно переходить через границы; добавь короткую подсказку игроку. Проверка: проверь работу кнопок; проверь мобильную версию; проверь, что нет ошибок в консоли.
Такой промпт сразу сужает коридор. Агент понимает, что ему не нужно тащить сервер, роутинг, API, окружение, переменные и прочую радость. Нужно сделать понятную интерактивную страницу.
Это важный навык работы с AI-кодингом: не просто просить «сделай красиво», а заранее ограничивать архитектуру. Иногда лучший код — тот, который агент не написал, потому что он вообще не нужен.
Что получилось хорошо
Первое — скорость. Получить рабочий прототип можно быстро. Не финальный продукт, но уже штуку, которую можно открыть, потыкать и показать.
Второе — наглядность. Предпросмотр рядом с задачей сильно помогает. Видно не абстрактный код, а результат. Если что-то выглядит криво, сразу просишь поправить.
Третье — публикация. Для демо важно, чтобы можно было не только посмотреть локально, но и отправить ссылку. SourceCraft Sites здесь закрывает простой сценарий: статическая страница из репозитория, HTTPS, публичный адрес.
Четвёртое — агентский цикл. В интерфейсе видно, что агент обновляет план, выполняет задачи, исправляет вёрстку, добавляет анимации и доводит страницу итерациями. Это намного полезнее, чем просто получить один большой ответ в чате и потом самому разгребать.
Что пока выглядит спорно
Главный спорный момент — склонность к усложнению. Если инструмент по умолчанию хочет сделать Node.js и деплой в облако, а задача спокойно решается статикой, это нужно контролировать.
Для Яндекса логично вести пользователя в свою облачную экосистему. Это нормальная продуктовая логика. Но как разработчик я смотрю проще: если странице не нужен сервер, значит сервер не нужен. Не надо платить сложностью там, где можно обойтись простым решением.
Второй момент — ощущение новизны. Если убрать AI-агента, статический хостинг из репозитория уже давно не удивляет. Поэтому сила продукта должна быть именно в качестве агента, удобстве итераций, связке с репозиторием и нормальном деплое, а не в одном факте публикации статики.
Третий момент — сопровождение. AI может быстро собрать проект, но если код потом трудно читать, развивать и чинить, это не победа. Это просто быстрый путь к новому легаси. Только раньше легаси писали люди годами, а теперь можно навайбкодить за вечер.
Статика или Next.js: как выбирать
Я бы разделял такие проекты очень просто.
Статика подходит, если у вас:
- лендинг;
- портфолио;
- документация;
- демо-страница;
- мини-игра без сохранения данных на сервере;
- калькулятор, который работает в браузере;
- страница для статьи или презентации;
- интерактивный блок без личных кабинетов и базы данных.
Next.js, backend и облачный деплой нужны, если есть:
- авторизация;
- личные кабинеты;
- серверное API;
- база данных;
- платежи;
- генерация контента на сервере;
- вебхуки;
- фоновые задачи;
- интеграции, где нельзя светить ключи в браузере.
Clock Battle из первой группы. Поэтому статическая публикация здесь нормальный выбор. Быстро, просто, без лишней инфраструктуры. Если потом захочется таблицу рекордов, авторизацию или мультиплеер, тогда да, разговор будет другой.
Как проверить опубликованную страницу
Если демо опубликовано, сначала можно проверить, отвечает ли страница:
curl -I https://krivoshein-slon.sourcecraft.site/clock-battle-generations/
Для более подробного вывода:
curl -vI https://krivoshein-slon.sourcecraft.site/clock-battle-generations/
Потом уже обычная ручная проверка в браузере:
- работают ли все кнопки;
- правильно ли двигаются стрелки;
- корректно ли меняется цифровое время;
- не ломаются ли минуты при переходе через 59;
- не ломаются ли часы при переходе через 12 или 24;
- понятно ли пользователю, что делать;
- не слишком ли мелкие кнопки на телефоне;
- нет ли ошибок в консоли браузера.
F12 → Console F12 → Network F12 → Lighthouse
Для такой страницы особенно важна мобильная проверка. На большом экране часы могут выглядеть эффектно, а на телефоне кнопки внезапно становятся тестом на ювелирную моторику пальцев.
Что проверять, если проект можно скачать
Если есть доступ к файлам, нужно смотреть не только на красивый предпросмотр. Красивый интерфейс и нормальный код — не всегда одно и то же.
Сначала структура проекта:
find . -maxdepth 3 -type f | sort | head -200
Если есть package.json, смотрим, что агент туда положил:
cat package.json
Если проект всё-таки на npm:
npm install npm run lint npm run build
Если используется bun:
bun install bun run lint bun run build
Если это чистая статика, проверяем проще: открываем страницу локально, смотрим консоль, прогоняем Lighthouse и убеждаемся, что нет битых путей к ассетам.
python3 -m http.server 8080
Потом открываем в браузере:
http://127.0.0.1:8080/
Да, это скучно. Зато потом меньше сюрпризов. AI любит сказать «готово», но браузерная консоль часто имеет своё мнение.
Где обычно ломается вайб-кодинг
Агент выбирает слишком тяжёлую архитектуру
Это как раз мой случай. Простая интерактивная страница может внезапно начать жить как полноценное приложение. Node.js, облако, сборка, окружение, деплой. Иногда это нужно. Часто нет.
Решение простое: сразу писать в задаче, что нужен статический сайт, если backend не требуется.
Логика работает только в простом сценарии
Например, кнопка «+5 минут» работает до 08:55, а дальше может получиться 08:60, если не обработать переход. В часах такие ошибки видно быстро.
Поэтому всегда проверяем крайние случаи: переход минут, переход часов, сброс, быстрые клики, мобильный экран.
Красиво, но непонятно
Неон, свечение, анимации и крупные эффекты легко создают ощущение «вау». Но если пользователь не понимает, что делать, это уже не интерфейс, а светомузыка. Для демо простительно, для реального продукта — нет.
Мобильная версия остаётся на потом
AI часто сначала делает красивый desktop. Потом выясняется, что на телефоне кнопки мелкие, блоки вылезают, а текст читается только после духовной подготовки. Поэтому мобильную версию нужно просить и проверять отдельно.
Код трудно сопровождать
Для прототипа агент может сложить всё в один большой файл. Оно работает, но развивать такой код неприятно. Если проект пойдёт дальше, его нужно приводить в порядок: логика отдельно, стили отдельно, данные отдельно, компоненты отдельно.
Безопасность: что нельзя давать агенту
В Вайбкрафт, как и в любой внешний AI-инструмент, не стоит отправлять всё подряд. Особенно если это клиентский проект или рабочая инфраструктура.
- Не отправляйте пароли.
- Не отправляйте API-ключи.
- Не отправляйте токены.
- Не отправляйте приватные .env-файлы.
- Не отправляйте дампы баз данных.
- Не отправляйте клиентские документы без необходимости.
- Не отправляйте реальные персональные данные.
- Не показывайте внутреннюю инфраструктуру, если это не нужно для задачи.
Для тестов лучше использовать обезличенные данные. Если нужен пример токена, пишем example_token. Если нужен домен, пишем example.com. Если нужен IP, используем безопасные адреса вроде 203.0.113.10.
AI-агент может быть полезным помощником, но он не должен становиться архивом ваших секретов. Секреты лучше хранить там, где им положено, а не в истории промптов.
Кому Вайбкрафт может пригодиться
Я вижу несколько нормальных сценариев.
- Быстро собрать лендинг.
- Проверить идею интерфейса.
- Сделать интерактивную демо-страницу.
- Собрать учебный проект.
- Подготовить мини-приложение для статьи.
- Сделать статическую страницу для портфолио.
- Набросать MVP без долгого старта.
- Проверить механику калькулятора, игры или виджета.
Для владельцев сайтов это может быть способом быстро проверить идею. Например, нужен калькулятор, промо-страница, интерактивный блок, мини-лендинг или визуальная демка для клиента. Сначала собираем прототип, потом решаем, переносить ли это в WordPress, отдельный шаблон или полноценное приложение.
Для разработчика это не замена нормальной IDE и опыта. Это ускоритель. Иногда очень полезный. Особенно когда нужно быстро увидеть форму идеи, а не неделю обсуждать, какой будет первый экран.
Что бы я доработал в Clock Battle дальше
Clock Battle можно оставить как демку, а можно развивать. Если делать из этого более полноценную страницу, я бы добавил:
- уровни сложности;
- счётчик правильных ответов;
- таймер раунда;
- режим обучения для детей;
- режим «проверь себя» для взрослых;
- сохранение результата в localStorage;
- понятную инструкцию;
- светлую тему;
- управление с клавиатуры;
- проверку доступности.
И обязательно проверил бы производительность. Неоновые эффекты и анимации красивы, но если слабый телефон начинает греться как маленькая духовка, лучше упростить. Сайт должен работать у людей, а не только в красивом предпросмотре.
Мой вывод
Первый тест Вайбкрафта мне понравился. Я получил доступ, зашёл в сервис, описал задачу и собрал рабочую интерактивную страницу. Не просто картинку, а опубликованное демо, которое можно открыть по ссылке.
Но главный вывод не «AI теперь всё сделает сам». Главный вывод другой: такие инструменты реально ускоряют путь к первому прототипу. Особенно если правильно ограничить задачу и не позволить агенту тащить лишнюю архитектуру.
Статический хостинг из репозитория сам по себе не новость. GitHub Pages и похожие сервисы мы давно видели. Но связка «описал идею — агент собрал — посмотрел предпросмотр — поправил — опубликовал» уже выглядит полезно.
Для простых лендингов, демо, интерактивных страниц и учебных проектов Вайбкрафт может быть хорошим инструментом. Для продакшена всё равно нужны проверка, сборка, безопасность, адаптивность и нормальная голова разработчика.
Короче, буду тестировать дальше. Инструмент интересный. Только, как обычно, не надо путать «навайбкодил за вечер» с «готово к бою». Между ними ещё есть скучный, но важный этап: проверить, привести в порядок и не сломать людям браузеры.
