Vibe Coding в 2026 году: что говорят данные за 16 месяцев

Кратко

• Andrej Karpathy придумал термин «vibe coding» 2 февраля 2025 года. К середине 2026 года он считает его устаревшим и перешёл к новому подходу.
• Исследование METR в июле 2025 года показало, что опытные разработчики работают на 19% медленнее с инструментами ИИ, хотя сами ожидали ускорения на 24%.
• 91,5% приложений, созданных в стиле vibe coding, содержат хотя бы одну уязвимость безопасности — по данным анализа за первый квартал 2026 года на основе пяти независимых исследований.
• Vibe coding хорошо работает для: MVP, внутренних инструментов и людей без технического опыта, которые хотят быстро проверить идею.
• Он стабильно даёт сбои при работе с: аутентификацией, платежами или пользовательскими данными без проверки специалистом.
• Профессиональная эволюция — это «agentic engineering»: те же инструменты, но инженер читает каждый diff и сохраняет ответственность за результат.

2 февраля 2025 года Andrej Karpathy написал то, что сам позже назвал «мимолётным твитом в потоке мыслей»: «Есть новый вид программирования, который я называю vibe coding: ты полностью отдаёшься вайбу, принимаешь экспоненциальный рост и перестаёшь думать о том, что код вообще существует».

Этот твит стал Словом года по версии Collins Dictionary за 2025 год. Рынок, выросший вокруг этой идеи, оценивается сегодня в 4,7 миллиарда долларов. Lovable — один из ведущих инструментов — к середине 2026 года достиг ARR в 200 млн долларов и оценки в 6,6 млрд долларов. В зимнем наборе Y Combinator 2025 года 25% стартапов работали на кодовых базах, где 95% кода было сгенерировано ИИ.

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

Цифры производительности рассказывают не всю историю

Заголовочные показатели легко найти: завершение проектов на 55% быстрее, разработка приложений в 5,8 раза быстрее, 74% разработчиков сообщают о росте производительности. Но в этих сводках последовательно упускают исследование METR от июля 2025 года.

В нём тестировались опытные разработчики на реальных задачах — с инструментами ИИ и без. Результат: они работали на 19% медленнее с ИИ-помощником, хотя уверенно предсказывали ускорение на 24%. Разрыв между ожиданием и реальностью составил 43 процентных пункта — и не в ту сторону.

Это не аргумент против ИИ-инструментов. Это сигнал о том, кому они на самом деле помогают. Прирост производительности реален, но крайне неравномерен:

• Старшие разработчики с опытом 3+ лет сообщают об ускорении на 40–81% в задачах, измеренных третьими сторонами
• У junior-разработчиков статистически значимого роста выработки не обнаружено
• Люди без технического опыта — а это 63% активных пользователей vibe coding (менеджеры по продукту, основатели, дизайнеры) — получают нечто принципиально иное: доступ к возможностям, которых у них раньше не было

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

Инструмент действительно полезен. Просто не для всех одинаково.

Проблема безопасности носит структурный, а не случайный характер

Статистика уязвимостей берётся из множества независимых источников и приходит к схожим выводам. OX Security сообщает, что 62% кода, написанного ИИ, содержит уязвимости безопасности. Анализ за первый квартал 2026 года, опубликованный SoftwareSeni, показал: 91,5% приложений, созданных в стиле vibe coding, имеют хотя бы одну уязвимость — по данным пяти независимых исследований. Escape.tech проанализировал 5 600 публично доступных vibe-coded приложений и зафиксировал более 2 000 критических уязвимостей, 400+ незащищённых секретов и 175 случаев утечки персональных данных в действующих продакшн-системах.

Цифра 91,5% звучит тревожно. Это так. Но понять почему — полезнее, чем просто испугаться.

ИИ генерирует код на основе того, о чём вы его просите. Когда вы пишете «создай приложение-список задач с аккаунтами пользователей», ИИ делает рабочую авторизацию. Он не добавит защиту от SQL-инъекций, ограничение на количество попыток входа или CSRF-токены, если вы об этом специально не попросите. Для применения этих уровней безопасности нужно знать, что они существуют.

Escape.tech прямо указал на эту закономерность: сбои в vibe coding, как правило, носят структурный характер — целые слои защиты просто не были реализованы, потому что ИИ никто не попросил их реализовать. Это отличается от ситуации, когда ИИ пишет неправильный код. ИИ написал именно то, о чём его попросили. Недостающие части никто не запрашивал.

Это можно исправить — если знать, о чём спрашивать. Без этих знаний надеяться, что ИИ сам со всем справится, не получится.

Анализ CodeRabbit за декабрь 2025 года показал, что код, написанный в соавторстве с ИИ, содержит примерно в 1,7 раза больше «серьёзных» проблем по сравнению с кодом, написанным человеком, в том числе в 2,74 раза выше частота уязвимостей безопасности. Эти данные охватывают весь код с участием ИИ, а не только чистые vibe coding приложения — что говорит о том, что проблема усиливается по мере снижения уровня контроля.

Понимание спектра инструментов

«Vibe coding» стал синонимом любой разработки на основе промптов, что порождает путаницу — ведь инструменты ориентированы на очень разных пользователей.

No-code AI конструкторы (Lovable, Bolt.new, Replit Agent) позволяют описать желаемое на обычном языке. Платформа генерирует, хостит и управляет кодом. Вы никогда не видите файлы. Они созданы для людей без технического опыта и для быстрой проверки идей.

AI редакторы кода (Cursor, Windsurf, Claude Code) требуют знания программирования. Они генерируют код прямо в вашей среде разработки, где вы читаете и проверяете каждое изменение перед коммитом. ИИ здесь — очень быстрый, иногда ненадёжный соавтор, а не самостоятельный строитель.

Типичная ошибка команд: начинают с Lovable, доходят до 80% рабочего MVP, а затем пытаются масштабировать его в продакшн-систему, не понимая, что было построено под капотом. Кодовые базы, сгенерированные no-code инструментами, нередко содержат паттерны, оптимизированные под генератор, а не под долгосрочную поддержку.

Практический фреймворк для выбора:

Karpathy уже пошёл дальше

Человек, придумавший этот термин, теперь называет его устаревшим.

На Sequoia Ascent 2026 Karpathy представил подход, который называет «agentic engineering». Его тезис: к декабрю 2025 года надёжность моделей улучшилась настолько, что настоящее узкое место сместилось. Вопрос больше не в том, может ли ИИ писать код. Вопрос в том, способны ли люди сохранять осмысленный контроль над системами, написанными ИИ.

Различие, которое он проводит:

Vibe coding поднимает нижнюю планку. Любой может создать что-то работающее. Качество кода Karpathy часто описывает как «раздутое, с кучей копипаста, со странными абстракциями, которые ломаются». Оно выходит в продакшн, и это ценно. Низкая ответственность уместна, потому что ставки невысоки.

Agentic engineering поднимает верхнюю планку. Профессиональные разработчики оркестрируют ИИ-агентов, сохраняя полную ответственность. Они пишут спецификации перед промптингом, проверяют диффы перед мерджем, пишут тесты, выстраивают циклы оценки и тщательно управляют разрешениями.

Самая цитируемая фраза из доклада: «Можно делегировать мышление, но нельзя делегировать понимание».

На практике граница между двумя подходами — это не то, каким инструментом вы пользуетесь. Это то, что вы делаете после того, как ИИ сгенерировал код. Разработчик, который использует Cursor и принимает все предложения без проверки, занимается vibe coding. Разработчик, который относится к каждому сгенерированному диффу как к pull request от junior-разработчика — читает построчно и отказывается принимать то, что не может объяснить, — занимается agentic engineering. Один инструмент. Разная дисциплина.

Что всегда нужно писать или проверять самому

На основе задокументированных паттернов сбоев некоторые категории кода никогда не должны попадать в продакшн без проверки человеком — вне зависимости от подхода:

• Логика аутентификации: хеширование паролей, управление сессиями, валидация токенов
• Обработка платежей: обработка вебхуков, ключи идемпотентности, восстановление после ошибок
• Запросы к базе данных с пользовательским вводом: любой код, который строит запросы из внешних данных
• Проверки авторизации: кто может читать, записывать или удалять какие записи
• Работа с секретами: переменные окружения, ротация API-ключей, хранение токенов

Всё остальное вполне может быть сгенерировано ИИ при условии проверки. Именно в этих пяти категориях концентрируются структурные сбои.

Часто задаваемые вопросы

Могут ли люди без технического опыта реально выпускать продакшн-приложения с помощью vibe coding?

Да — но важно понимать, что означает «продакшн». Внутренний инструмент для 5 человек принципиально отличается от потребительского приложения, которое хранит платёжные данные 5 000 пользователей. Первую категорию нетехнические люди уже успешно создают и запускают. Для второй — консенсус исследователей безопасности в 2026 году таков: проверьте идею с помощью vibe coding, затем попросите разработчика проверить критически важные с точки зрения безопасности части кода, прежде чем работать с реальными пользователями и реальными данными.

В чём реальная разница между Lovable и Cursor?

Lovable полностью скрывает код. Вы описываете — оно строит, вы запускаете, вы никогда не трогаете файлы. Cursor — это редактор кода, где ИИ помогает писать быстрее, но вы остаётесь в кодовой базе, читаете и коммитите каждое изменение. Правильный выбор зависит от того, умеете ли вы читать код — а не от того, у какого инструмента лучше отзывы. Для разработчиков — Cursor. Для всех остальных, кто только начинает, — Lovable или Bolt.

Vibe coding умер?

Как практика — нет, он стал мейнстримом. GitHub сообщает, что 46% нового кода теперь генерируется ИИ. Как термин, точно описывающий то, что опытные инженеры делают с этими инструментами, — он уходит. Сам Karpathy от него отошёл. Инструменты те же; изменились профессиональные ожидания в отношении контроля.

Сколько стоит начать работу с vibe coding?

Платный план Lovable начинается от 25 долларов в месяц (по состоянию на июнь 2026 года). Cursor Pro — 20 долларов в месяц. Bolt.new имеет бесплатный тариф с ограниченным количеством токенов в день. Claude Code работает на основе потребления API и тарифицируется через Anthropic API. Соло-основатель, создающий MVP, как правило, укладывается в 50 долларов в месяц при небольшой нагрузке. Продакшн-нагрузки на крупных кодовых базах могут обходиться в 200–500 долларов в месяц в зависимости от интенсивности использования токенозатратных операций.

Итоговый вывод

Vibe coding — это не мошенничество и не замена программной инженерии. Это спектр: на одном конце — нетехнические люди, впервые создающие что-то реальное; на другом — опытные инженеры, использующие ИИ как высокоскоростного соавтора, сохраняя при этом ответственность за то, что выходит в продакшн.

Сбои предсказуемы. Они следуют одному паттерну: принимать большие объёмы сгенерированного кода, не читая его; пропускать уровни безопасности, которые никто не запрашивал; пытаться масштабировать no-code прототип в продакшн-систему, не понимая лежащей в основе архитектуры.

Люди, получающие максимум от этих инструментов к середине 2026 года, — не те, кто «полностью отдаётся вайбу». Это те, кто точно знает, когда делегировать задачу ИИ, и точно знает, что проверять, когда она возвращается.

Обзор всего ландшафта инструментов для ИИ-программирования — в нашем руководстве по лучшим ИИ-ассистентам для кодинга, где рассматривается полный спектр от Cursor до GitHub Copilot с актуальными ценами на 2026 год.

Если вы начинаете выстраивать агентные рабочие процессы за пределами простой генерации кода, руководство по использованию ИИ-агентов охватывает практические паттерны оркестрации, которые отличают разовую генерацию от повторяемых автоматизированных систем.