Вайб-кодинг

Вайб-кодинг (от английского vibe coding) это способ делать программы, при котором человек описывает задачу обычными словами, код пишет языковая модель, а сам код человек не читает. О результате он судит по поведению программы: запускается, делает то, что просили, ошибок на экране нет. Появилась ошибка, её текст копируют обратно в модель и просят починить.

Слово придумал Андрей Карпатый в записи от 2 февраля 2025 года. Там же стоит фраза, которая и задаёт границу понятия: «I "Accept All" always, I don't read the diffs anymore», то есть автор принимает все правки подряд и правки эти больше не просматривает. Всё остальное в теме спорно, а этот признак не спорен: если сгенерированный код читают и правят руками, это работа с ИИ-помощником, и разговор о рисках у неё другой.

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

Чем отличается от соседних понятий

Границу проводит один вопрос: кто читает получившийся код и в какой момент.

Программирование с ИИ-помощником. Подсказку модели разработчик просматривает до того, как принять, и отвечает за неё как за свою строку. Инструменты те же самые, привычка другая. Обзор состояния темы, вышедший в августе 2026 года, разводит эти две практики именно по признаку проверки: в вайб-кодинге результат оценивают по запуску программы, и чтение кода из цикла выпадает.

Low-code и no-code. Там приложение собирают из готовых блоков на платформе, а исходный код либо не отдаётся совсем, либо выгружается на старшем тарифе за отдельные деньги: цена такой выгрузки названа в соседней статье. Здесь на выходе получается обычный код на обычном языке, со всеми последствиями: его надо где-то хранить, разворачивать и потом сопровождать.

Промпт-инжиниринг. Дисциплина про то, как сформулировать запрос. Вайб-кодинг это сценарий работы, в котором приёмы промптинга применяются, но предмет разговора другой.

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

RPA и автоматизация бизнес-процессов. Это про то, что автоматизируют. Вайб-кодинг про то, чем пишут.

Откуда взялось

Запись Андрея Карпатого опубликована 2 февраля 2025 года в 23:17 по Гринвичу: время стоит на самой странице, а идентификатор записи независимо декодируется в то же время до секунд. В тексте перечислен весь порядок работы, который потом и стали называть этим словом. Автор говорит с редактором голосом и просит «уменьшить отступ у боковой панели вдвое». Все изменения принимает подряд. Сообщения об ошибках вставляет без комментариев. Модель с ошибкой не справилась, значит её обходят или просят случайных правок, пока она не исчезнет. Про область применения там же сказано прямо: для выброшенных проектов выходного дня сойдёт.

Дальше слово разошлось за месяц. В марте 2025 года его внёс в раздел сленга словарь Merriam-Webster, а по итогам года словарь Collins назвал vibe coding словом года. Обе даты приведены по статье англоязычной Википедии, сверено 19.09.2026: сами словарные страницы при подготовке не открывались.

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

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

Как это устроено

Читателей у такого кода трое, и у каждого свой интерес к прочитанному

Цикл из трёх шагов

Описание задачи, генерация, запуск. Программа не собралась или повела себя не так, текст ошибки уходит обратно в модель, и круг повторяется. Мультивокальный обзор 47 источников описывает это как повторяющийся цикл «сгенерировать, оценить, переделать». Одним запросом с готовым ответом дело обходится редко. Вместе с циклом меняется и работа человека: он пишет требования, смотрит на поведение программы и решает, годится ли результат.

Отсюда первое практическое следствие. Качество упирается в то, чем именно вы оцениваете результат. «Запустилась и выглядит правильно» это слабая проверка: она ловит падение и не ловит ни тихую логическую ошибку, ни дыру в безопасности.

Где живёт код

Инструменты делятся на четыре вида, и от вида зависит, что происходит с вашим кодом.

• Чат общего назначения. Код приходит в окно диалога, человек переносит его к себе руками. Каждая строка проходит через руки, и времени это отнимает больше всего.
• Плагин в редакторе. Подсказки и правки приходят прямо в файл. В этом ряду Cursor, GitHub Copilot, SourceCraft Code Assistant от Яндекса.
• Агент в терминале или в среде разработки. Получает задачу целиком, сам ходит по файлам, запускает тесты и вносит правки. В этом ряду Antigravity, Claude Code, Codex.
• Платформа «из описания в работающее приложение». Собирает и сразу размещает веб-приложение. В этом ряду Lovable, Replit, v0.

Список дан по алфавиту внутри каждой строки и без рейтинга: сравнивать инструменты по качеству на сегодняшних данных нечем, об этом ниже. Цены здесь не приводятся намеренно, тарифы у всех перечисленных меняются в течение года, и смотреть их надо на тарифной странице поставщика в день расчёта. Из чего вообще складывается счёт за обращение к модели, разобрано в статье Большая языковая модель.

Что остаётся человеку

Работа смещается с набора кода на три другие вещи: сформулировать требования, надзирать за ходом, проверять результат. Мультивокальный обзор фиксирует этот сдвиг как общее место рассмотренных источников. Проблема в том, что вторая и третья вещи требуют квалификации не ниже прежней, а первая привлекает людей, у которых этой квалификации нет.

Что измерено про скорость и качество

Про скорость есть два ряда чисел, и они спорят друг с другом. Таблица собрана из работ, которые открыты и прочитаны при подготовке статьи, вместе с выборкой и принадлежностью авторов.

Работа и год	Что меряли	Выборка	Результат	Чья работа
Pearce H. и соавторы, 2021	долю уязвимых программ среди сгенерированных	89 сценариев, 1689 программ	около 40 % программ содержали уязвимость	исследователи Нью-Йоркского университета и университета Калгари
Peng S. и соавторы, 2023	время выполнения одной задачи с помощником и без	95 разработчиков, задача «написать HTTP-сервер на JavaScript»	группа с помощником справилась на 55,8 % быстрее	Microsoft Research, GitHub и Школа менеджмента Слоуна MIT, то есть продукт изучал в том числе его поставщик
Perry N. и соавторы, 2022, публикация 2023	безопасность кода, написанного с ИИ-помощником и без	47 участников, 33 в опытной группе и 14 в контрольной, пять задач, три языка	участники с доступом к помощнику писали заметно менее безопасный код и при этом чаще считали свой код безопасным	Стэнфордский университет
Becker J. и соавторы, 2025	время выполнения задач в зрелых проектах	16 опытных разработчиков открытого кода, 246 задач	разрешение пользоваться ИИ увеличило время выполнения на 19 %, тогда как сами участники до опыта ждали ускорения на 24 %	METR, организация, которая занимается оценкой моделей и инструменты не продаёт
Andročec D., 2026	влияет ли явная просьба о безопасности на результат	6 веб-приложений, по два варианта запроса, 12 программ, 75 подтверждённых находок из 85	в варианте с требованиями безопасности 24 находки против 51, критических и высоких нет вовсе	автор из Загребского университета, работа названа предварительной

Разброс объясним, и объяснение важнее самих процентов. Обзор 2026 года сводит три замера в одном месте. Рецензируемые полевые эксперименты дают прирост около 26 % задач в неделю. Независимые рандомизированные испытания дают замедление на 19 %. Телеметрия команд показывает рост времени на ревью кода на 441 %. Авторы обзора выдвигают проверяемое предположение: выигрыш реален на новом коде и сходит на нет или разворачивается в минус на зрелой кодовой базе. Это объясняет, почему опыт на пустом проекте и опыт в большой системе дают противоположные ощущения.

Отдельно стоит замер с безопасностью. Просьба «сделай безопасно», добавленная в запрос, снизила число подтверждённых находок вдвое с небольшим. Работа предварительная, каждый вариант сгенерирован по одному разу, авторы сами просят читать результат как наблюдение, а не как доказанный эффект. Но направление совпадает с тем, что показывали работы 2021 и 2022 годов: модель по умолчанию пишет то, что работает, а не то, что защищено.

Что делать на практике

Где подход уместен

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

Где он опасен

Тот же обзор называет и слабые места: промышленная эксплуатация, работа с большими объёмами данных, системы, где цена сбоя высока. К этому добавляются три случая, которые в русской практике стоят дороже всего: деньги (оплата, тарифы, начисления), вход в систему и права доступа, персональные данные клиентов. Что именно нельзя отдавать в облачную модель вместе с кодом, разобрано в статье Нейросети для бизнеса.

Порядок работы, который снимает часть риска

1. Решить заранее, выбрасываемая это программа или та, которую придётся сопровождать. От ответа зависит всё остальное.
2. Написать, что считается правильной работой: три-пять проверяемых условий. Без них «работает» проверяется на глаз.
3. Требования к безопасности класть в запрос явно, а не надеяться на умолчания.
4. Никаких ключей и паролей в коде и в переписке с моделью. Ключ, уехавший в публичный репозиторий, считается скомпрометированным и подлежит отзыву.
5. Прогонять готовый код автоматическими проверками: статический анализатор, проверка зависимостей, поиск секретов в репозитории.
6. Всё, что касается денег, входа и персональных данных, показывать человеку, который код читает.
7. Держать историю версий с первого дня. Возврат к рабочему состоянию это главный способ починки, когда модель сломала то, что работало.
8. Прежде чем ставить это на поток, посмотреть на порядок пилота и приёмки в статье Внедрение ИИ: программа, которую нельзя принять по измеримым признакам, потом не сопровождается.

Чем измеряют

• Доля кода, которую кто-то прочитал перед выпуском. Главная величина в этой теме и единственная, которая отличает вайб-кодинг от обычной разработки с ИИ.
• Находки статического анализатора на тысячу строк, отдельно критические и высокие.
• Секреты в репозитории: число найденных ключей и время от попадания до отзыва.
• Время на ревью в расчёте на задачу. По сводке обзора именно оно растёт сильнее всего.
• Доля задач, доведённых до конца без возврата, и доля тех, где пришлось откатываться.
• Стоимость задачи в рублях, вместе с оплатой токенов и часами человека, который проверял.
• Время до первой рабочей версии против времени до версии, которую приняли в эксплуатацию. Разрыв между этими двумя числами и есть цена подхода.

Кто отвечает за код

Ответственность за программу остаётся на том, кто её выпустил. Поставщики инструментов пишут это прямым текстом. В справке GitHub про ответственное использование подсказок сказано: все риски по сгенерированному коду принимает на себя пользователь. Названы три вида риска: уязвимости, ошибки, нарушение прав на интеллектуальную собственность. Сверено 19.09.2026. Там же описан механизм на случай, когда подсказка совпала с публично доступным кодом. Система обнаружения таких совпадений умеет либо заблокировать подсказку, либо показать репозиторий и лицензию, из которых она пришла.

Вопрос о правах на сам сгенерированный текст программы в России отдельной нормой не решён. Статья 1257 Гражданского кодекса признаёт автором гражданина, творческим трудом которого создано произведение. Статья 1261 относит программы для ЭВМ к объектам, которые охраняются как литературные произведения, и распространяет охрану на исходный текст и объектный код. Обе нормы сверены по КонсультантПлюс 19.09.2026, толкование их применительно к спору это работа юриста, а не справочной статьи.

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

Частые ошибки

• Прототип уезжает в эксплуатацию. Самый частый и самый дорогой случай: программа выходного дня начинает принимать заявки от живых людей, и никто не отмечает момент, когда правила поменялись.
• «Работает» считается проверкой. Запуск ловит падение и не ловит ни логическую ошибку, ни уязвимость.
• Ключи и доступы в переписке с моделью. Они попадают и в код, и в историю репозитория.
• Просьба о безопасности не сформулирована. В предварительном замере 2026 года явное требование сняло больше половины находок, а стоит оно одну строку в запросе.
• Нет истории версий. Модель переписала работавший кусок, вернуться некуда.
• Успех на новом проекте переносят на старую систему. По предположению авторов обзора это ровно тот случай, где выигрыш разворачивается в минус.

Ограничения и спорные места

Данных мало, и они молодые. Слову чуть больше полутора лет. Мультивокальный обзор отобрал 47 источников, из них рецензируемых 28, поиск охватывал период до октября 2025 года. Прирост производительности отмечен в 21 источнике из 47, а по сопровождению и долговременному качеству авторы прямо называют доказательства ограниченными.

Числа спорят между собой, и это не ошибка чьего-то замера. Прирост на 26 % задач в неделю и замедление на 19 % получены на разных выборках, в разных условиях и на разной длине наблюдения. Одно из этих чисел взять и перенести на свою команду нельзя.

Исследование поставщика это исследование поставщика. Работу с результатом «на 55,8 % быстрее» писали в том числе сотрудники Microsoft Research и GitHub, и мерила она их собственный продукт на одной учебной задаче. Это не повод её отбрасывать, это повод читать выборку.

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

Цифра про четверть стартапов. По теме ходит утверждение, что у 25 % компаний одного набора акселератора кодовая база на 95 % сгенерирована моделью. Первоисточник с методикой и выборкой открыть не удалось, поэтому числа в основном тексте статьи нет.

Бенчмарки растут быстрее, чем практика. Отчёт AI Index 2026 Стэнфордского института HAI сообщает, что на одном из ключевых наборов задач по программированию результат за год поднялся примерно с 60 % почти до 100 %. Набор задач это не ваша система: решённая задача из бенчмарка и принятая в работу правка живут по разным правилам.

Про русскоязычную практику замеров нет. Ни одна из прочитанных работ не мерила ни российские инструменты, ни задачи на русском языке. Все проценты выше получены за пределами этого контура.

Что здесь быстро устаревает

• Состав инструментов. Список четырёх видов держится дольше имён внутри него: продукты переименовываются и появляются каждый квартал. Проверять при ревизии.
• Все проценты. Они привязаны к версиям моделей 2021-2026 годов. Признак протухания: в свежем обзоре появились новые замеры, а здесь стоят старые.
• Норма о программах для ЭВМ. В статью 1261 Гражданского кодекса с 1 января 2027 года вносятся изменения федеральным законом от 04.08.2026 № 296-ФЗ, об этом стоит пометка на странице самой статьи.
• Условия поставщиков. Формулировки об ответственности и о совпадении с публичным кодом правятся без объявлений, дата сверки в тексте стоит намеренно.
• Статус слова. Термин попал в словари за год, и так же быстро может уйти в разряд исторических: рядом с ним уже появился разговор о разработке по спецификации, где требования описывают до генерации и держат отдельным документом.

См. также

• Искусственный интеллект
• Промпт-инжиниринг
• ИИ-агент
• Low-code и no-code
• Генеративный ИИ
• Нейросети для бизнеса
• Внедрение ИИ
• Автоматизация бизнес-процессов
• Услуга агентства Optimism: внедрение ИИ в процессы бизнеса

Источники

1. Andrej Karpathy. Запись в X от 02.02.2025, 23:17 UTC: первое употребление словосочетания vibe coding. Открыто и сверено 19.09.2026. https://x.com/karpathy/status/1886192184808149383
2. Vibe coding. Wikipedia, английский раздел. Даты: словарь Merriam-Webster в марте 2025 года, слово года Collins по итогам 2025 года. Сверено 19.09.2026. https://en.wikipedia.org/wiki/Vibe_coding
3. Pearce H., Ahmad B., Tan B., Dolan-Gavitt B., Karri R. Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. arXiv:2108.09293, препринт подан 20.08.2021, публикация IEEE Symposium on Security and Privacy 2022. 89 сценариев, 1689 программ, около 40 % уязвимых. https://arxiv.org/abs/2108.09293
4. Perry N., Srivastava M., Kumar D., Boneh D. Do Users Write More Insecure Code with AI Assistants? arXiv:2211.03622, препринт подан 07.11.2022, публикация ACM CCS 2023. 47 участников, пять задач, три языка. https://arxiv.org/abs/2211.03622
5. Peng S., Kalliamvakou E., Cihon P., Demirer M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590, препринт подан 13.02.2023. 95 разработчиков, результат 55,8 %. https://arxiv.org/abs/2302.06590
6. Becker J., Rush N., Barnes E., Rein D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089, препринт подан 12.07.2025. 16 разработчиков, 246 задач, замедление на 19 %. https://arxiv.org/abs/2507.09089
7. Siddeeq S., Waseem M., Kemell K.-K., Saari M., Rasku J., Abrahamsson P. Vibe Coding in Software Development: A Multivocal Literature Review. arXiv:2607.21652, препринт подан 22.07.2026. 47 источников, из них 28 рецензируемых. https://arxiv.org/abs/2607.21652
8. Michels D. L., Abu Ghazaleh M., Lazzari F., Kassem N., Klein J. Vibe Coding: Practice, Performance, Productivity, and Risk. A State-of-the-Art Review. arXiv:2608.20446, препринт подан 20.08.2026. Сводка расхождений: 26 %, 19 %, 441 %. https://arxiv.org/abs/2608.20446
9. Andročec D. Vibe Coding and Web Application Security: A Twin-Prompt Study. arXiv:2608.20963, препринт подан 21.08.2026. Шесть приложений, 12 программ, 24 находки против 51. https://arxiv.org/abs/2608.20963
10. da Mota G., Gama K. Comparing the Quality of Code Generated by Vibe Coding Tools. arXiv:2608.16302, препринт подан 17.08.2026. Три инструмента, девять приложений, статический анализ. https://arxiv.org/abs/2608.16302
11. GitHub. Responsible use of GitHub Copilot inline suggestions: ответственность пользователя за сгенерированный код, система обнаружения совпадений с публичным кодом. Сверено 19.09.2026. https://docs.github.com/en/copilot/responsible-use/inline-suggestions
12. Гражданский кодекс Российской Федерации (часть четвёртая) от 18.12.2006 № 230-ФЗ, статья 1257 «Автор произведения». КонсультантПлюс, сверено 19.09.2026. https://www.consultant.ru/document/cons_doc_LAW_64629/7dde8dbb10c5ce94297e5eb859712be091044d70/
13. Гражданский кодекс Российской Федерации (часть четвёртая), статья 1261 «Программы для ЭВМ», с пометкой об изменениях с 01.01.2027. КонсультантПлюс, сверено 19.09.2026. https://www.consultant.ru/document/cons_doc_LAW_64629/ce1359ed5b9bd99896d7a496c7887e7c223a2cbc/
14. Specification-Driven Development as the Foundation of AI-Native Enterprise Software Engineering. arXiv:2607.16680, препринт подан 18.07.2026. Разведение двух подходов: вайб-кодинг и разработка по спецификации. https://arxiv.org/abs/2607.16680
15. Stanford HAI. The 2026 AI Index Report, раздел главных выводов: результат на наборе задач по программированию SWE-bench Verified за год вырос с 60 % почти до 100 %. Сверено 19.09.2026. https://hai.stanford.edu/ai-index/2026-ai-index-report