Вайб-кодинг это хорошо или плохо: ответ по данным

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

О чём на самом деле спорят

Слово появилось в феврале 2025 года как описание способа делать одноразовые вещи на выходных: принимать все правки не глядя, не читать код. Откуда оно взялось и как за год переехало в словари, я разбирал в статье про вайб-кодера. Здесь важнее другое: тот же человек через год сказал, что такой способ поднимает нижнюю планку для всех, а профессионалам предложил другое слово, инженерия с агентами: те же модели, но с проверкой и ответственностью за результат.

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

Есть и третья позиция, и принадлежит она автору самой границы. Инженер, который весной 2025 провёл черту «прочитал код или нет», через год признал, что сам уже не читает всё, что выкатывает, и перенёс упор на другое: ответственность за результат может нести только человек, у агента её нет. Так что граница проходит не столько по чтению каждой строки, сколько по тому, кто отвечает и умеет ли он проверить.

Три критерия вместо спора

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

Горизонт. Вечер, чтобы посмотреть. Полгода, чтобы пользоваться. Годы, чтобы сопровождать и менять.

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

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

Что говорят данные «за»

Замеров ускорения несколько, и у них одинаковое условие. В контролируемом эксперименте 2023 года на типовой задаче разработчики с ассистентом были быстрее на 56 процентов. В трёх полевых экспериментах на почти пяти тысячах разработчиков число закрытых задач выросло на 26 процентов, сильнее всего у менее опытных. А замер на шестнадцати опытных разработчиках в их собственных больших проектах показал замедление; я разбирал его в статье про цену часа разработчика. Условие читается так: нейросеть ускоряет типовое, а на большом и сложном проекте у опытного человека выигрыш пропадает или уходит в минус.

Крупные компании отчитываются о доле кода, написанного ИИ: у одного поисковика в апреле 2026 три четверти нового кода, у разработчика Claude больше 80 процентов кода, попавшего в прод в мае 2026. У обеих цифр одна оговорка, которую при пересказе обрезают: у поисковика код одобряют инженеры, у разработчика Claude каждое изменение проходит автоматическое ревью, которое, по их данным, ловит около трети опасных багов. Это данные за инженерию с агентами, не за «не читаю».

Порог входа упал по-настоящему. В марте 2025 у четверти стартапов одного известного акселератора 95 процентов кода было сгенерировано, и в акселераторе отдельно подчеркнули: все эти люди технические. Конструкторы сайтов растут: один из них летом 2026 сообщил о миллионе новых проектов в неделю. Это самоотчёт, аудита нет.

Мой опыт в ту же сторону: рутина выкладки приложения в магазин, на которую у меня уходила неделя, в сентябре 2026 заняла часы. Ускоряется то, где человек уже знает, как должен выглядеть результат. Волшебной кнопки за этим нет.

Что говорят данные «против»

Безопасность. Самый измеренный аргумент. Отчёт компании по безопасности кода летом 2025: из ста с лишним моделей на восьмидесяти задачах безопасными оказались 55 процентов решений. Весной 2026 те же авторы прогнали новейшие модели: снова около 55 процентов, и авторы пишут прямо, что за два года ничего не сдвинулось. Академический бенчмарк на 186 реальных задачах: даже у лучшей из двенадцати конфигураций агентов 57 процентов решений работают и только 11,8 процента безопасны. В небольшом тесте на пятнадцати приложениях от пяти агентов ни у одного не оказалось защиты от подделки запросов, когда чужой сайт нажимает кнопку в вашем от имени пользователя. Как это выглядит на реальных приложениях и утечках, я разбирал в статье про приложение нейросетью: там сканирование тысячи с лишним приложений и соцсеть с полутора миллионами открытых ключей.

Сопровождаемость. Системных замеров тут почти нет. Самый большой от компании, которая торгует инструментом оценки кода, так что читать его с поправкой. Анализ 623 миллионов изменений по отрасли в целом, без разметки, что писал человек, а что модель: дублированных блоков стало на 81 процент больше, доля перемещённого кода, то есть переделки старого, чтобы он стал понятнее, упала с 21 процента в 2022 году до 3,8 в 2026, а правка кода старше года сократилась на 74 процента. Если этому замеру верить, код стало проще добавлять и почти перестали улучшать. Это совпадает с тем, что я вижу в проектах, которые привожу в порядок: их можно только дописывать, пока не станет проще переписать.

Доверие. Опрос почти пятидесяти тысяч разработчиков в 2025 году: 84 процента используют ИИ или собираются, 46 процентов не доверяют точности его ответов, сильно доверяют 3 процента. Главная жалоба у двух третей: «почти правильно, но не совсем». Отчёт о состоянии отрасли того же года добавляет: вместе с ростом использования ИИ растут и пропускная способность команд, и нестабильность поставки. Оба источника опросные, то есть самооценка, но вектор у них один: ИИ усиливает то, что в команде уже есть, хорошее и плохое.

Ответственность. Летом 2026 крупный игровой движок с открытым кодом запретил вклад от автономных агентов и вайб-кодинг с формулировкой: ИИ не может нести ответственность, а тем, кто на него сильно полагается, нельзя доверить понимание кода настолько, чтобы его чинить. Хостинг открытого кода в июле 2026 голосованием запретил репозитории, состоящие в основном из ИИ-кода без надзора человека.

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

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

Не в первый вечер. Первый вечер как раз удаётся, и это сбивает с толку.

Первое место: правки. Пока изменений мало, каждая удаётся. Потом одна правка задевает то, что делали раньше, а без чтения кода не видно, что именно задето: остаётся просить починить и смотреть, что отвалится теперь. Это стадия, а не тупик; чем она заканчивается, разобрано в статье про три стадии работы с ИИ.

Второе: такой код нельзя передать. Когда проект приносят мне подхватить, вопрос всегда один: почему здесь так. Ответа нет ни у автора, ни в коде. Никто не может сказать, почему нейросеть написала именно так, поэтому и чинить некому. Что в таких проектах обычно застревает, перечислено в статье про вайб-кодера по ссылке выше.

Третье: чужие данные и деньги. Пока пользователь один, вопрос «кому что можно» не возникает. При тысяче он возникает сразу, и если решения нет, его не будет и в коде: модель права доступа за вас не придумывает. Что именно тут ломается, ниже, в разделе про безопасность.

Четвёртое: сопровождение. Из цифры про минус 74 процента правок старого кода следует практическое: проект, который нельзя улучшать, рано или поздно можно только переписывать, и переписывать его будет тот, кто читает.

Заменит ли вайб-кодинг программистов

Смотря что считать программистом.

Должность «вайб-кодер» на рынке почти не появилась, зато инструменты попали в требования обычных вакансий; замер по белорусскому сайту вакансий есть в статье про вайб-кодера. Вход в профессию сузился, и это измерено: в США у людей 22–25 лет в профессиях, которые ИИ затрагивает сильнее всего, занятость к лету 2026 на 19 процентов ниже, чем у сверстников в менее затронутых профессиях, и разница набирается на найме: новичков берут меньше, увольнений больше не стало. В Беларуси, по отраслевому опросу за 2025 год, доля ИТ-специалистов с опытом до двух лет упала с почти 20 процентов в 2022 году до 5, а на одну ИТ-вакансию приходится около 21 резюме при обычных шести-восьми. Причин у белорусских цифр несколько, и ИИ только одна из них. При этом прогноз бюро статистики труда США на десять лет вперёд: разработчиков станет больше на 16 процентов. Работа не исчезает. Исчезает та её часть, за которую платили новичкам, и меняется то, за что платят остальным.

Руководители крупных компаний в 2025 году обещали «инженера среднего уровня из ИИ» и половину начальных офисных позиций под нож. В конце мая 2026 один из них сформулировал иначе: если автоматизировать 90 процентов работы, каждый начинает делать оставшиеся 10, и эти 10 разрастаются до 100. Это совпадает с тем, что я вижу у себя: работа сместилась из набора кода в постановку задачи и проверку результата, и именно на них теперь уходит день. Так что меняется способ работы программиста; сама работа остаётся.

Безопасно ли это

Три вещи ломаются чаще всего, и все три видны в отчётах выше.

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

Ключи и пароли в коде. Это другие ключи, секретные: от платёжной системы, от почты, от сервера. Они попадают в репозиторий вместе с проектом и с ним же становятся публичными; первым признаком обычно бывает счёт от сервиса.

Действия агента в боевой среде. Удаление без подтверждения и без разделения на «тестовое» и «боевое», как в обоих инцидентах выше.

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

Как решить для себя

Шесть вопросов по трём критериям.

1. Зайдёт ли сюда кто-то, кроме вас, и с какими данными?
2. Будут ли внутри чужие данные или деньги?
3. Сколько это должно прожить: вечер, полгода, годы?
4. Кто и за чей счёт чинит первую поломку?
5. Сможете ли вы объяснить, что делает код, хотя бы в общих чертах?
6. Есть ли копия базы и отдельная среда для опытов?

Ответы на первые три ставят проект на шкалы задачи, горизонта и ответственности. Если хотя бы один ушёл вправо, вопросы 4 и 5 решают, кто будет читать код, а шестой, что случится при первой ошибке. Итог всех шести один: сколько непрочитанного кода вы можете себе позволить в этом проекте. Для инструмента на вечер ответ «весь». Для продукта с людьми «нисколько», и тогда остаётся один вопрос: кто читает.

Куда дальше

Ещё не пробовали: начните с одного вечера и своей задачи, план и инструменты в статье про вайб-кодинг.

Пробовали и злитесь: это третья стадия, и она проходит; как именно, в статье про три стадии по ссылке выше.

Выбираете подрядчика: спросите его про контур из раздела о безопасности по пунктам. Где лежит копия базы и когда её снимали. Где проверяют перед выкладкой. Кто увидит данные ваших клиентов при утечке пароля. Сможет ли другой человек подхватить проект через полгода. Ответа «модель хорошая, всё работает» недостаточно.

По шести вопросам вышло «для людей», а код никто не читал: путей два. Аудит и доработка того, что уже собрано, или менторинг, чтобы дальше отвечать за код самому; он для тех, у кого уже есть проект, в котором застряли. Опытному разработчику с вопросом про архитектуру подойдёт аудит на 4–8 часов.