Вайбкодинг — это способ писать программы, при котором вы формулируете задачу обычным языком, а код пишет языковая модель. Вы смотрите на поведение результата, а не на строки: запустил, посмотрел, сказал что не так, повторил.
Пишут по-разному — «вайбкодинг», «вайб-кодинг», «вайб кодинг», в оригинале vibe coding. Это одно и то же понятие, и дальше в тексте оно тоже одно.
Откуда взялся термин
Название придумал Андрей Карпаты в посте 2 февраля 2025 года. Формулировка была нарочито несерьёзной: «новый вид программирования, где ты полностью отдаёшься вайбу и забываешь, что код вообще существует». Он описывал свою манеру работы — надиктовывать задачи голосом и почти не читать то, что получилось.
За год слово ушло далеко за пределы отрасли: в ноябре 2025-го Collins назвал vibe coding словом года и определил его как «использование искусственного интеллекта, управляемого естественным языком, для написания программного кода».
Это не автодополнение
Инструменты, которые дописывают строку за вас, существуют давно, и к вайбкодингу отношения не имеют. Разница — в единице работы.
| Что вы делаете | Единица работы | Что проверяете |
|---|---|---|
| Автодополнение | строка, сигнатура функции | читаете каждую подсказку до принятия |
| Чат с моделью | фрагмент, который вы переносите руками | читаете фрагмент, вставляете сами |
| Вайбкодинг | изменение в проекте целиком | запускаете и смотрите на поведение |
Поэтому вайбкодинг стал массовым только тогда, когда модели научились не «предлагать текст», а править файлы, запускать команды и читать вывод ошибок. Подробнее про эту границу — в разборе чем ИИ-агент отличается от чата.
Как выглядит один рабочий цикл
Цикл всегда один и тот же, независимо от инструмента:
- Задача словами. Не «напиши код», а что должно получиться и как вы поймёте, что получилось.
- Модель правит проект. Создаёт и меняет файлы, ставит зависимости, запускает сборку.
- Запуск. Открываете результат и смотрите, что он делает.
- Обратная связь по поведению. «Кнопка не нажимается на телефоне», «после сохранения список не обновляется».
- Повтор, пока поведение не совпадёт с задуманным.
Пункт 1 определяет качество всего остального. Формулировка «сделай форму обратной связи» и формулировка «форма из трёх полей, при пустом email показывает ошибку под полем, при успехе очищается и пишет „отправлено“, данные уходят POST-запросом на /api/feedback» дают принципиально разный результат при одной и той же модели.
Пункт 4 — то место, где вайбкодинг отличается от обычной разработки сильнее всего. Вы описываете симптом, а не причину. Причину ищет модель: читает свой же код, добавляет вывод в консоль, воспроизводит.
Где вайбкодинг ломается
Три места, где подход стабильно перестаёт экономить время.
Большой знакомый проект
METR в июле 2025-го провела рандомизированный эксперимент: 16 опытных разработчиков открытых проектов, 246 реальных задач в репозиториях, с которыми они работали в среднем по пять лет. С доступом к ИИ-инструментам задачи заняли на 19% больше времени. При этом сами участники после эксперимента оценили, что ИИ ускорил их примерно на 20%.
Расхождение между ощущением и секундомером — главный вывод, который стоит забрать. На своём коде, который вы знаете наизусть, объяснение задачи модели может стоить дороже, чем сделать руками.
Доверие к результату
По опросу разработчиков Stack Overflow за 2025 год ИИ-инструментами пользуются или собираются пользоваться 84% респондентов, а доверяют точности их вывода только 29% — против 40% годом раньше. Самые осторожные — опытные разработчики.
Это не аргумент против инструментов. Это аргумент за то, что этап проверки нельзя выкидывать: чем больше кода вы не читали, тем важнее, чтобы его проверяло что-то кроме вашего впечатления.
Всё, что нельзя проверить запуском
Безопасность, права доступа, обработка денег, миграции данных, приватность — области, где «работает» и «правильно» не одно и то же. Форма отправляется, а токен лежит в открытом виде в репозитории. Оплата проходит, а повторный запрос списывает дважды. Здесь цикл «запустил — посмотрел» ничего не ловит.
Кому он подходит
По опыту трёх разных сценариев картина примерно такая:
- Человек без опыта разработки. Выигрыш максимальный: раньше порог входа был месяцами, теперь — вечером. Риск тоже максимальный: непонятно, что именно проверять. Отсюда пошаговый старт с контрольными точками.
- Разработчик на незнакомом стеке. Лучшее соотношение пользы и риска: вы знаете, что спросить и на что смотреть, но не тратите неделю на синтаксис чужой экосистемы.
- Разработчик на своём проекте. Выигрыш неочевиден и зависит от типа задачи. Рутина и повторяющиеся правки — да. Тонкая логика в коде, который вы держите в голове, — часто нет.
С чего начать сегодня
Минимальный набор — один инструмент и один проект, который не жалко.
- Выберите инструмент под задачу, а не по популярности: разбор типов есть в обзоре инструментов для вайбкодинга.
- Возьмите задачу, у которой видно результат: страница, скрипт, небольшая утилита. Так вы сразу увидите разницу между «модель сказала, что готово» и «оно работает».
- Заведите git с первого дня. Возможность вернуться на шаг назад одной командой — единственное, что отделяет эксперимент от потери работы.
- Держите ключи и пароли вне проекта. Модель читает файлы целиком и может процитировать любой из них.
Когда одиночных задач станет мало и захочется вести несколько дел параллельно — начинается отдельная тема: несколько агентов одновременно, где узкое место уже не модель, а общие файлы и ваше внимание.