Vibe Coding против реального кодинга

Последнее тестирование и обновление: Июнь 2026

В сессии vibe-coding вы описываете, чего хотите, позволяете ИИ написать это и нажимаете «Запустить». Кажется, что это легко, пока вы не попробуете выпустить продукт. Проект ломается в трех местах, баг не воспроизводится, и каждая «починка» создаёт ещё один выдуманный API. Вы потратили $40, не открыв запуск тестов.

Андрея Карпати назвал эту практику vibe coding в начале 2025 года. Это быстро, когда код одноразовый, и ужасно медленно, когда непроверенный прототип движется к производству. Этот урок помогает определить эту границу.

Этот урок рассматривает, когда виброкодинг является правильным инструментом, когда он не подходит и как эти два стиля комбинируются. См. L01: Программирование с Claude Code для примера.

Как каждый подход терпит неудачу

Различие становится яснее, когда вы смотрите на то, как каждый подход терпит неудачу.

Виброкодинг терпит неудачу, когда вы просите ИИ создать обработчик перетаскивания. Он создает обработчик перетаскивания, который выглядит правильно. Событие drop никогда не срабатывает, потому что никто не указал цель сброса. Вы тратите четыре попытки с фразой «нет, в другую сторону». ИИ рассуждает на основе неправильной модели проблемы.

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

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

Матрица стоимости проверки

Необходимая диаграмма — 2x2. Ось X — насколько серьёзно вы намерены выпускать: от «одноразового» слева до «долговременной продукции» справа. Ось Y — насколько строгий барьер качества: от «выглядит правильно» внизу до «проверено и протестировано» вверху.

Матрица 2x2: намерение отправки по оси X (одноразовое до долговременного), уровень качества по оси Y (выглядит правильно до проверенного и протестированного). Vibe coding выигрывает в нижней левой половине. Реальное кодирование выигрывает в верхней правой половине. Диагональ между ними — это ось «отгрузки реальной вещи».

Две диагонали на диаграмме представляют два спектра, по которым на самом деле движется большинство проектов. Ось «выпустить настоящий продукт»: отбрасываемый скрипт до базы кода в продакшене с CI. Ось «убить это в пятницу» идет в противоположном направлении.

Несколько конкретных примеров для закрепления квадрантов:

Внизу слева, «одноразовое + выглядит правильно»: одноразовый скрипт для переименования 200 файлов, личный cron, быстрый HTML-макет. Вайб кодинга. Запусти. Удали.
Внизу справа, «долговечное + легкая проверка»: внутренняя утилита, с которой вы будете работать год. Hermes здесь отличен: см. Hermes L01: Что такое агент Hermes?. Среда агента, плановое задание, легкая проверка того, что оно произвело.
Сверху слева, «отправлено + протестировано»: SaaS MVP, за которое вы планируете взимать деньги. Claude Code или Kilo Code, с настоящим тестовым комплектом, и вы читаете каждый diff перед слиянием.
В правом верхнем углу, «production + reviewed»: долго существующее веб-приложение, мобильное приложение, конвейер обработки данных, публичная библиотека. Настоящее кодирование, точка.

Решите, что должно продолжать работать

Два вопроса решают, к какому инструменту обращаться:

Будет ли этот код работать через три месяца?
Будет ли кто-то (включая тебя в будущем) отлаживать это в 2 часа ночи?

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

Когда кодить в режиме vibe

Кодинг в режиме vibe уместен, когда стоимость ошибки низка, а стоимость медлительности высока. Конкретные случаи:

Исследование. Пробуем 5 вариантов интерфейса, прежде чем выбрать один. Пробуем 3 схемы базы данных. Суть в том, чтобы выбросить большинство из них.
Одноразовые скрипты. Переименовать 200 файлов, собрать страницу, сгенерировать CSV. Запустить один раз и удалить.
Временные демонстрации. «Показать команде, как может выглядеть приложение для задач с интеграцией в Slack.» Никогда не попадет в продакшн.

Для всех этих случаев самым дешевым путем является кодинг в режиме vibe с моделью Tier 2. Используйте DeepSeek V4, Kimi K2.7 или локальный Qwen. Скорость побеждает. Качество «достаточно для кода, который вы выбросите». Держите дорогие модели в резерве для продакшена.

Когда доходит до настоящего кода

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

Всё, что взаимодействует с пользователем и поставляется. Веб-приложения, мобильные приложения, публичные API, публичные библиотеки. Используйте Claude Code или Kilo Code (описано в Л01) с полноценным набором тестов, рабочим процессом Git и код-ревью.
Всё, что связано с деньгами или данными. Платежные потоки, аутентификация, всё, что записывает в базу данных, с которой сложно откатить изменения.
Всё, что должно продолжать работать. Cron-задачи, запланированные задачи, автоматизации, которые должны разбудить вас, когда они ломаются.

Для всех этих случаев используйте среду для программирования, такую как Claude Code или Kilo Code с моделью уровня Sonnet или выше. Среда выполняет цикл, тесты предоставляют проверку, а ваш обзор обнаруживает то, что тесты пропускают.

Сочетание обоих (самый распространенный шаблон)

Большая часть производственной работы в 2026 году следует этому шаблону в следующем порядке:

Vibe кодирует прототип. Попробуйте 5 вариантов интерфейса. Выберите лучший. Вся задача здесь — выяснить, чего вы на самом деле хотите.
Напишите PRD в один абзац. Входные данные, выходные данные, крайние случаи. PRD — это артефакт, который позволяет переключиться с «ИИ предлагает» на «Я направляю».
Переключитесь на среду для программирования. Откройте Claude Code или Kilo Code на прототипе. Сообщите ему PRD, укажите код, пусть он пишет производственную версию с тестами.
Читайте каждый diff. Вы, а не тестовая оболочка. Оболочка предлагает; вы решаете.
Запустите тесты. Если они не проходят, оболочка делает итерацию. Если проходят, вы сливаете изменения.

Это «вибрация для исследований, реально для производства» шаблон. Фаза вибрации быстрая и свободная. Реальная фаза медленная и проверенная. Граница между ними — это PRD.

Hermes — это третья опция

Если «то, что должно продолжать работать», является внутренним инструментом, запланированной задачей или долгосрочной личной автоматизацией, вам может вообще не понадобиться программная оболочка. Используйте агентскую оболочку: Hermes, описанную в Hermes L01. Hermes запускает всё в фоновом режиме и сохраняется на протяжении всех сессий. Vibe coding + Hermes — это отличный стек для инструментов, которыми пользуется только ваша команда.

Распространённые режимы отказа

Четыре способа, как это может быть не так, в порядке того, как часто новички их наносят:

Vibe, пишет производственный код. Отправьте прототип. Он работает для 80% пользователей и ломается для остальных 20%. Исправление — это приведённый выше шаблон комбайна.
Настоящее программирование прототипа. Не тратьте день на тестирование кода, который уже ожидаете выбросить. Используйте vibe-кодирование для изучения, а затем переходите к реальному кодированию после PRD.
Пропускаю PRD. Без одного абзаца ИИ заполняет пробелы предположениями. Результат может выглядеть правильно, но не учитывая вашу истинную цель, и вам придётся исправлять его на протяжении четырёх раундов.
Сжигание токенов на каждой итерации. Попросите ИИ исправить баг. Исправление вводит новый баг. 20 итераций, потрачено $50. Инструмент для кодирования с тестовым набором обнаруживает регресс в первом раунде.

Сравните оба подхода

Потратьте по часу на каждый, затем сравните.

Упражнение

Выберите маленький проект на вашей машине: CLI-инструмент, одностраничное приложение, скрипт, что-то, что можно сделать за один день. Потратьте один час на кодинг по настроению. Не пишите PRD. Не запускайте тесты. Просто опишите, что хотите, и выпустите.

Затем откройте Claude Code (или Kilo Code, от Л01) на том же проекте. Потратьте один час время на его восстановление «по-настоящему»: сначала PRD, инструмент пишет код с тестами, вы читаете каждое изменение, запускаете тестовый набор после каждой правки.

В конце запишите своими словами:

Что было проще во время часа кодирования по настроению?
Что было проще во время часа реального кодирования?
Какую версию вы действительно отправили бы в производство?
Где PRD изменил то, что создал ИИ?

Если ваш ответ на вопрос 3 — «кодирование по настроению» и вы можете объяснить почему, вы правильно определили прототип на выброс. Если ваш ответ — «реальное кодирование» и вы можете объяснить почему, вы правильно определили продукт, который должен продолжать работать. Любой ответ приемлем. Суть в том, чтобы почувствовать разницу.

Что дальше

L01: Программирование с Claude Code: оболочка для кодирования.
L03: Создание реальных проектов с Hermes: паттерн «сначала по настроению, затем реально» на реальном проекте.
Hermes L01: Что такое агент Hermes?: агентская оболочка для внутренних инструментов.

Vibe Coding против настоящего программирования