Вайб-кодинг: как создавать продукты с ИИ, даже если вы не разработчик

Вайб-кодинг звучит как мем, но за мемом стоит практическая вещь: создавать рабочие продукты с помощью ИИ, не будучи профессиональным разработчиком. В основе статьи — доклад Дмитрия Филиппова «Вайб-кодинг». Дмитрий более года создаёт продукты с ИИ, работает с микробизнесом в B2C/B2B, у него один международный и три сервиса в РФ, ещё два в разработке. В докладе — не «демо для сцены», а рабочая повестка соло-фаундера: от идеи до деплоя и продажи.

Сразу важная рамка: вайб-кодинг — не магия, где ИИ сам пишет идеальный продукт. Это способ сместить фокус с «как написать код» на «что именно нужно сделать, зачем и какой результат считается готовым». Слайды доклада — в конце статьи.

Определения без иллюзий

Вайб-кодинг — написание кода без глубоких знаний языка и без многолетнего опыта разработки. Но вторая строка из доклада важнее первой:

Разработка — это не только создание кода.

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

Ожидание vs реальность

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

• «Сделаешь приложение?» — и всё готово → на деле нужны ТЗ, ограничения, данные, дизайн, проверка.
• Ошибок нет, потому что «ИИ написал» → ошибки есть всегда, вопрос — кто их найдёт.
• Сэкономит команду разработчиков → сильно ускорит рутину и прототип, но не отменяет ответственность.
• Не нужно знать ничего про разработку → полезно понимать логи, консоль, деплой, структуру проекта.

Кому это вообще нужно

Не разработчику: ускорить работу (скрипты, обработка данных, автоматизация), создать своё ПО (сайт, приложение, сервис, игра), делегировать задачи (деплой, обслуживание сервера, типовые правки).

Разработчику: ускорить рутину — скрипты, анализ данных, миграции, генерация чернового кода; быстрее собирать своё ПО; перенести часть деплоя и обслуживания на агентов, оставив себе архитектуру и контроль.

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

Бизнес хочет заработать больше денег.

Поэтому внедрение ИИ начинается не с вопроса «какую модель купить», а с трёх вопросов: зачем внедрять, где внедрять (какой пилот), и какие метрики — сколько было до и после. Рабочий вариант — A/B-тест в команде: часть задач делается как раньше, часть — с ИИ, результат сравнивается по времени, качеству и деньгам.

С чего начать: выбрать инструмент

Условно все инструменты делятся на четыре класса:

• Чат — обычный диалог с моделью: идеи, ТЗ, разбор ошибок, черновики.
• Агенты — автономный ИИ, работающий до достижения цели: многошаговые задачи «собери, проверь, исправь».
• IDE — редактор кода с ИИ внутри: повседневная разработка в проекте.
• CLI — ИИ в терминале: автоматизация, правки файлов, серверные задачи.

Конкретно из доклада:

• Devin-подобные AI — быстрый старт, бесплатные лимиты, добрались до рабочих сценариев;
• Trae — кастомный API + индекс документов;
• opencode — хорошая подписка;
• Cursor — кастомный API + индексация документов (у нас есть статья про вайб-кодинг в Cursor бесплатно);
• ZED — кастомный API и скорость;
• VS Code — кастомный API и максимальная кастомизация.

Спикер отдельно отмечает, что не рекомендует для своей работы: GLM, QODER, KIMI, DeepSeek — по его опыту им мешают лимиты, отсутствие нужных фич или неподходящий формат CLI. Это субъективный опыт конкретного практика на момент доклада, а не запрет: у инструментов быстро меняются лимиты и функции. Подборку программ под разные сценарии собрали в статье «Программы для вайб-кодинга».

Что должен уметь инструмент — хороший минимум для рабочего вайб-кодинга:

• работа с проектом, а не только с одним файлом;
• индексация документации и кода;
• кастомный API — чтобы не упираться в одну подписку;
• доступ к терминалу и логам;
• работа по плану и критериям приёмки;
• подключение MCP и skills.

Какую модель выбрать для кодинга

Смотреть предлагается не на громкое имя, а на четыре параметра: результаты синтетических тестов, стоимость input/output, стоимость кэша, скорость генерации токенов.

Где смотреть: arena.ai и designarena.ai — сравнение моделей и предпочтений людей; llm-stats.com — сводные метрики; openrouter.ai, vercel.ai, api.vega.chat — цены и доступность.

По выбору спикера на момент доклада: лучший выбор для кодинга — Google Gemini 3.7 Flash (цена/скорость/качество в рабочей итерации), для дизайна — MoonshotAI Kimi K3.

Важно: рейтинги моделей быстро устаревают. Правильная привычка — не «запомнить лучшую модель навсегда», а уметь за 15 минут перепроверить: цену миллиона входных и выходных токенов, стоимость кэша, скорость генерации, лимиты провайдера и поведение модели на вашем типе задач — бэкенд, фронт, рефакторинг, дизайн, документация.

Промт — не «напиши красиво», а техническое задание

Два показательных примера из доклада.

Широкий промт:

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

Узкий промт:

Одностраничный сайт креативного медиа-агентства purga.media, которое работает в России и создаёт креативный медиа-контент для бизнеса: видео, фото, музыка, озвучка. Ярко, креативно. Белый фон и тёплые цвета. Обязательно должны быть hero, портфолио проектов (фото, видео), команда, контакты, блог и много креатива. Выработай единый фирменный стиль.

Второй вариант лучше не потому, что длиннее, а потому что в нём есть рынок (Россия), аудитория (B2B), услуги (видео, фото, музыка, озвучка), визуальные ограничения (белый фон, тёплые цвета), обязательная структура (hero, портфолио, команда, контакты, блог) и требование к результату (единый фирменный стиль).

Правило простое: чем дороже цена ошибки, тем конкретнее должен быть промт. Подробнее — в статье «Как писать промты для GPT».

Правила для агента: рабочий набор из доклада

Один из самых полезных фрагментов презентации — набор правил для агента, который можно адаптировать под свой проект:

1. Всегда пиши пользователю на русском языке.
2. Используй MCP и skills там, где они уместны.
3. В проектах на Node.js/Next.js используй pnpm.
4. Начинай работу с плана и критериев приёмки. Заканчивай проверкой плана, критериев и тестами.
5. Исправляй ошибки, даже если они не связаны с твоими изменениями.
6. Вместо npx используй pnpm dlx.
7. Для поиска документации используй deepwiki и context7.
8. Для поиска skills используй find-skills.
9. Помни: middleware — это proxy.ts в Next.js 16+.
10. Будь креативен в части дизайна, но важны UX и здравый смысл.

Это и есть «операционная система» вайб-кодинга: не один гениальный запрос, а устойчивые правила поведения агента.

MCP и skills: что это и зачем

MCP — коннектор к внешним ресурсам: документации, API, базам, сервисам. По сути — стандартный способ дать агенту «руки» и «глаза» во внешнем мире.

Skill — навык, который добавляет агенту конкретное умение: как работать с библиотекой, фреймворком или процессом.

Из доклада:

• context7.com — один из лучших вариантов MCP для актуальной документации;
• api.vega.chat — MCP-маркет;
• github.com/mcp — MCP-маркет на GitHub;
• find-skills — один из лучших способов искать skills;
• skills.sh — MCP/skills-маркет.

Практический смысл: вместо того чтобы агент «вспоминал» API по памяти и ошибался, лучше дать ему актуальную документацию и нужный навык.

Контекст важнее магии

Правила из доклада:

1. Новая задача → новый чат.
2. Продолжение задачи → чат не меняем.
3. Нужна документация → context7.com или deepwiki.com.
4. Нужен индекс документации → Trae, Cursor, Kilo Code + embeddings.

У модели конечный контекст: если смешать пять задач в один диалог, агент начнёт путать требования и «вспоминать» то, чего не было. Хороший ритуал старта задачи:

1. Вот цель.
Вот ограничения.
Вот критерии приёмки.
Вот что нельзя менять.
Сначала составь план — только потом кодь.

Как выглядит рабочий процесс

Цикл из доклада в виде шагов:

1. Идея или задача → уточнить цель и ограничения.
2. Попросить план и критерии приёмки → согласовать план.
3. Агент пишет код и правит ошибки.
4. Проверка: логи, консоль браузера, тесты.
5. Критерии выполнены? Нет — назад к шагу 3. Да — деплой и обратная связь.

Ключевой момент: «работает» — не равно «готово». Готово — это когда выполнены критерии приёмки, код проверен, ошибки исправлены, а результат можно показать пользователю.

Подписки и доступ из России

В докладе отдельно отмечены две боли: сложность купить подписку и сложность использовать её. Практический путь — сервисы, которые нормально работают из РФ и дают API-доступ:

• vega.chat — чат;
• api.vega.chat — API-доступ к моделям;
• imagic.vega.chat — генерация изображений.

API-подход особенно важен, если вы не хотите зависеть от одной подписки и одной модели. Он позволяет подключать модели к Cursor, VS Code, ZED и другим инструментам, быстро переключаться между ними, платить за фактическое использование и строить свои сервисы поверх ИИ. Про организацию доступа — в статье «Открываем доступ к AI в России» и конспекте доклада с WAW 2025.

Почему не локальные модели

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

Ваш конкурент не будет играть по правилам.

Пока вы месяцами поднимаете локальный контур, конкурент с облачными моделями уже выпускает версии продукта. Это не значит, что локальные модели бесполезны — для закрытых контуров, персональных данных и строгих требований безопасности они могут быть правильным выбором (кстати, у нас есть гайд: «Устанавливаем AI локально с Ollama»). Но как стартовая точка для соло-фаундера — редко оптимальны.

Бизнес: что внедрять и как измерять

Рабочая схема внедрения: цель (зачем внедрять) → пилотные проекты (где) → метрики (сколько было до и после). Главное — комплексный подход, A/B-тест в команде:

• команда A делает задачи как раньше;
• команда B использует ИИ;
• сравниваются сроки, количество багов, стоимость, удовлетворённость заказчика;
• после пилота — решение о масштабировании.

Метрики, которые реально показывают эффект: время от задачи до релиза, доля задач без возврата, стоимость одной фичи, количество инцидентов после релиза, скорость ответа на типовые запросы и выручка на команду — а не абстрактная «производительность».

Типичные ошибки

• Начинать с «сделай мне стартап» вместо одной понятной задачи.
• Не давать агенту критерии приёмки.
• Не смотреть логи и консоль браузера.
• Менять модели каждый час вместо стабильного рабочего процесса.
• Давать агенту права на деплой без проверки.
• Копировать чужие правила без адаптации под свою команду.
• Считать экономический эффект без до/после.
• Путать «ИИ написал код» с «продукт работает и продаётся».

Итог

Вайб-кодинг — это не «код без понимания», а разработка с ИИ в контуре ответственности человека. Инструмент выбирается под задачу (чат, агент, IDE или CLI), модель — по тестам, цене, кэшу и скорости, а не по бренду. ИИ — инструмент достижения ваших целей, а не ваш конкурент: конкурентом становится тот, кто внедрит его в реальный процесс быстрее и с измеримой пользой.

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

Презентация доклада

Слайды «AI-coding» — можно листать прямо здесь или скачать:

Скачать презентацию (PDF)

---

Материал основан на докладе Дмитрия Филиппова, CEO Getmyai. Канал автора — @getmyai, личный контакт — @ingeniare.