Вайбкодинг — это способ писать программы, при котором вы формулируете задачу обычным языком, а код пишет языковая модель. Вы смотрите на поведение результата, а не на строки: запустил, посмотрел, сказал что не так, повторил.

Пишут по-разному — «вайбкодинг», «вайб-кодинг», «вайб кодинг», в оригинале vibe coding. Это одно и то же понятие, и дальше в тексте оно тоже одно.

Откуда взялся термин

Название придумал Андрей Карпаты в посте 2 февраля 2025 года. Формулировка была нарочито несерьёзной: «новый вид программирования, где ты полностью отдаёшься вайбу и забываешь, что код вообще существует». Он описывал свою манеру работы — надиктовывать задачи голосом и почти не читать то, что получилось.

За год слово ушло далеко за пределы отрасли: в ноябре 2025-го Collins назвал vibe coding словом года и определил его как «использование искусственного интеллекта, управляемого естественным языком, для написания программного кода».

Важная оговорка. Исходная формулировка Карпаты — про личные проекты выходного дня, где «код можно не читать». Индустрия растащила термин на всё подряд, включая продакшн. Дальше в статье вайбкодингом называется сам способ работы (задача словами → код от модели → проверка по поведению), а не обещание, что читать код больше не придётся.

Это не автодополнение

Инструменты, которые дописывают строку за вас, существуют давно, и к вайбкодингу отношения не имеют. Разница — в единице работы.

Что вы делаетеЕдиница работыЧто проверяете
Автодополнениестрока, сигнатура функциичитаете каждую подсказку до принятия
Чат с модельюфрагмент, который вы переносите рукамичитаете фрагмент, вставляете сами
Вайбкодингизменение в проекте целикомзапускаете и смотрите на поведение

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

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

Цикл всегда один и тот же, независимо от инструмента:

  1. Задача словами. Не «напиши код», а что должно получиться и как вы поймёте, что получилось.
  2. Модель правит проект. Создаёт и меняет файлы, ставит зависимости, запускает сборку.
  3. Запуск. Открываете результат и смотрите, что он делает.
  4. Обратная связь по поведению. «Кнопка не нажимается на телефоне», «после сохранения список не обновляется».
  5. Повтор, пока поведение не совпадёт с задуманным.

Пункт 1 определяет качество всего остального. Формулировка «сделай форму обратной связи» и формулировка «форма из трёх полей, при пустом email показывает ошибку под полем, при успехе очищается и пишет „отправлено“, данные уходят POST-запросом на /api/feedback» дают принципиально разный результат при одной и той же модели.

Пункт 4 — то место, где вайбкодинг отличается от обычной разработки сильнее всего. Вы описываете симптом, а не причину. Причину ищет модель: читает свой же код, добавляет вывод в консоль, воспроизводит.

Где вайбкодинг ломается

Три места, где подход стабильно перестаёт экономить время.

Большой знакомый проект

METR в июле 2025-го провела рандомизированный эксперимент: 16 опытных разработчиков открытых проектов, 246 реальных задач в репозиториях, с которыми они работали в среднем по пять лет. С доступом к ИИ-инструментам задачи заняли на 19% больше времени. При этом сами участники после эксперимента оценили, что ИИ ускорил их примерно на 20%.

Расхождение между ощущением и секундомером — главный вывод, который стоит забрать. На своём коде, который вы знаете наизусть, объяснение задачи модели может стоить дороже, чем сделать руками.

Доверие к результату

По опросу разработчиков Stack Overflow за 2025 год ИИ-инструментами пользуются или собираются пользоваться 84% респондентов, а доверяют точности их вывода только 29% — против 40% годом раньше. Самые осторожные — опытные разработчики.

Это не аргумент против инструментов. Это аргумент за то, что этап проверки нельзя выкидывать: чем больше кода вы не читали, тем важнее, чтобы его проверяло что-то кроме вашего впечатления.

Всё, что нельзя проверить запуском

Безопасность, права доступа, обработка денег, миграции данных, приватность — области, где «работает» и «правильно» не одно и то же. Форма отправляется, а токен лежит в открытом виде в репозитории. Оплата проходит, а повторный запрос списывает дважды. Здесь цикл «запустил — посмотрел» ничего не ловит.

Кому он подходит

По опыту трёх разных сценариев картина примерно такая:

  • Человек без опыта разработки. Выигрыш максимальный: раньше порог входа был месяцами, теперь — вечером. Риск тоже максимальный: непонятно, что именно проверять. Отсюда пошаговый старт с контрольными точками.
  • Разработчик на незнакомом стеке. Лучшее соотношение пользы и риска: вы знаете, что спросить и на что смотреть, но не тратите неделю на синтаксис чужой экосистемы.
  • Разработчик на своём проекте. Выигрыш неочевиден и зависит от типа задачи. Рутина и повторяющиеся правки — да. Тонкая логика в коде, который вы держите в голове, — часто нет.

С чего начать сегодня

Минимальный набор — один инструмент и один проект, который не жалко.

  1. Выберите инструмент под задачу, а не по популярности: разбор типов есть в обзоре инструментов для вайбкодинга.
  2. Возьмите задачу, у которой видно результат: страница, скрипт, небольшая утилита. Так вы сразу увидите разницу между «модель сказала, что готово» и «оно работает».
  3. Заведите git с первого дня. Возможность вернуться на шаг назад одной командой — единственное, что отделяет эксперимент от потери работы.
  4. Держите ключи и пароли вне проекта. Модель читает файлы целиком и может процитировать любой из них.

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