Что такое Vibe Coding на самом деле?

Термин «vibe coding» распространился быстро в 2024-2025 потому что назвал то, что множество разработчиков уже делали скрытно: описывали на простом английском то, что им нужно, моделям вроде GPT-4, Claude или инструментам вроде Cursor и GitHub Copilot, и дали им сгенерировать большую часть реального кода. Программист остаётся в цикле, но цикл выглядит иначе, чем традиционное кодирование.

Точное определение

Андрей Карпатий придумал фразу, описав рабочий процесс, где вы «полностью подчиняетесь вибам» — вы даёте подсказку, принимаете предложения, запускаете код, видите, что сломалось, и даёте подсказку снова. Вы не читаете каждую строку diff построчно. Вы управляете по результату: делает ли приложение то, что нужно, проходит ли тест, корректно ли отрисовывается страница. Навык смещается от написания синтаксиса к ясному описанию намерения и узнаванию, когда выход неправилен.

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

Как выглядит реальная сессия

Типичный цикл vibe-coding с инструментом вроде Cursor или режима Agent в Replit выглядит примерно так:

1. Подсказка: «Добавь rate limiter к этому Express API, 100 запросов за 15 минут на IP, верни 429 с телом JSON ошибки».
2. Модель редактирует middleware/rateLimit.js, подключает в app.js, может потянуть express-rate-limit.
3. Ты запускаешь npm test или хитишь эндпоинт curl в цикле, чтобы проверить, что 429 действительно срабатывает.
4. Что-то не так — limiter сбрасывается при каждом деплою, потому что он in-memory. Ты об этом говоришь.
5. Модель меняет на хранилище, поддерживаемое Redis, добавляет зависимость ioredis, обновляет файл docker-compose.
6. Ты повторно тестируешь, работает, ты коммитишь.

Ни одна строка того middleware не была напечатана вручную. Но шесть или семь судебных решений были приняты человеком: какой должна быть лимит, что in-memory хранилище неправильно для production, что файл docker-compose тоже нужно было обновить.

Где это работает хорошо

Vibe coding силён в работе, перегруженной boilerplate: CRUD эндпоинты, валидация форм, scaffolding тестов, конфиг-файлы, клей между двумя API, которые ты уже понимаешь. Он также хорош для прототипирования — развёртывание рабочего демо идеи за час вместо дня, потом решение, стоит ли её строить правильно.

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

Где он ломается

Режим отказа, о котором люди не говорят достаточно: модели производят код, который работает, но тонко неправилен способами, которые не видны до позже. Сгенерированный SQL запрос может работать для happy path, но уязвим для инъекции, потому что конкатенация строк выглядела хорошо модели. Сгенерированная проверка auth может пройти тесты, но пропустить проверку role на одном маршруте. Если ты не читаешь код, ты это не поймаешь — ты просто увидишь, что тесты проходят, и шипишь это.

Это важнее в коде, чувствительном к безопасности, чем почти где-либо ещё. Саймон Виллисон и другие указали, что vibe-coded проекты с реальными данными пользователя нуждаются в той же строгости проверки, что и любой другой код, возможно, больше, потому что человек, который «написал» его, может быть не способен объяснить, что он делает построчно.

Сложные системы с большим неявным состоянием — параллелизм, распределённые транзакции, что-либо с тонкими ошибками timing — также плохо подходят. Модели обычно генерируют правдоподобный код для этих случаев, который отказывает способами, которые трудно отладить именно потому что никто, человек или модель, не смоделировал полностью edge cases вперёд.

Навык, который действительно важен сейчас

Если ты делаешь vibe coding, ценный навык не скорость печати, это спецификация. Расплывчатые подсказки получают расплывчатый, баггый код. Специфичные подсказки — с точными именами библиотек, ожиданиями обработки ошибок и выделенными edge cases — получают намного лучший выход. Второй по важности навык — это быстро читать код, чтобы поймать, что неправильно, что значит тебе всё ещё нужно понимать язык и домен даже если ты не печатаешь каждый символ.

Обращайся с AI-сгенерированным кодом так, как ты обращался бы с pull request от junior разработчика, который быстр, но иногда самоуверен: полезен, часто правилен, но стоит актуальной проверки прежде чем это коснётся production.

Хочешь глубже разобраться в написании кода с AI инструментами без потери контроля качества? Посмотри сегменты AI и Python в Korra Studio для пошаговых разборок.