Вайбкодинг — это когда вы описываете, что должно получиться, а код пишет
модель. Вы читаете не диф, а результат: запустилось, работает как задумано,
поехали дальше. Термин пустил в оборот Андрей Карпати в феврале 2025-го,
описывая собственную манеру работы: «полностью отдаться вайбам и забыть, что
код вообще существует».
Дальше слово разъехалось. Одни зовут вайбкодингом любое написание кода с
помощью ИИ, другие — только тот крайний случай, где человек не смотрит в код
вовсе. Разница принципиальная, и путаница из-за неё стоит дорого: спорящие
обсуждают разные вещи.
Полезнее считать, что есть шкала — по тому, сколько кода проходит через ваши
глаза.
| Что делает человек | Что читает | |
|---|---|---|
| Автодополнение | пишет сам, принимает подсказки | всё |
| Диалог | ставит задачу, правит результат | весь диф |
| Агент под присмотром | ставит задачу, проверяет по частям | ключевые места |
| Автономный агент | ставит задачу, проверяет итог | тесты и поведение |
Вайбкодинг в исходном смысле — две нижние строки. И вопрос не «хорошо это или
плохо», а «для какой задачи какая строка».
Прототипы и проверка идей. Когда цель — понять, стоит ли вообще это делать,
качество кода не имеет значения: он всё равно будет выброшен. Здесь вайбкодинг
даёт максимум — за вечер видно то, на что раньше уходила неделя.
Одноразовые скрипты. Разобрать выгрузку, переименовать три сотни файлов,
собрать график из логов. Живёт один запуск, ревьюить нечего.
Незнакомый стек. Написать первый в жизни Dockerfile или конфиг nginx
быстрее с моделью, чем с документацией: она сразу даёт рабочую заготовку,
а понимание приходит по ходу правок.
Обвязка. CRUD-ручки, DTO, фикстуры, миграции, парсинг аргументов. Кода
много, решений в нём ноль.
Тесты на существующий код. Модель хорошо видит, что можно сломать, и не
ленится описывать граничные случаи.
Код, которому жить годами. Модель оптимизирует «чтобы работало сейчас», а
не «чтобы это можно было менять через год». Получается рабочий код без
внутренней логики: пять почти одинаковых функций вместо одной, состояние
размазано, границы модулей случайны.
Неявные требования. Всё, чего вы не сказали, будет решено за вас — и
обычно не так. Часовые пояса, поведение при пустом списке, что считать
дубликатом, что делать при повторном запуске. Это не ошибки модели, это
ваши недоформулированные требования.
Производительность. Запрос в цикле вместо джойна, чтение файла целиком в
память, O(n²) там, где данных пока сто штук. Работает на демо, ложится на
проде.
Безопасность. Отдельная тема, см. Безопасность и секреты.
Чужая большая кодовая база. Без контекста модель напишет свой велосипед
рядом с вашим — не потому что глупая, а потому что не знала, что ваш есть.
Лечится не промптом, а настроенным контекстом проекта.
Написание кода перестало быть узким местом. Узким местом стало ревью — и это
главное следствие, из которого растёт всё остальное.
«Почти правильно» хуже, чем «не работает». Сломанный код виден сразу.
Код, который работает на ваших трёх примерах и разваливается на четвёртом,
живёт в проекте месяцами.
Знание кода не образуется. Написав функцию руками, вы помните, почему она
такая. Приняв её от модели — нет. Через полгода это чужой код, только чужой
тут вы.
Объём растёт быстрее внимания. Тысяча строк за час — это тысяча строк,
которые кто-то должен вычитать. Обычно не вычитывает никто.
npm test отвечает за десять секунд,