Vibe coding убивает твои шансы на собесе — и ты этого не замечаешь

55% больше кода за неделю. В 2–3 раза больше багов в продакшне. 318 уязвимостей в 100 приложениях, написанных "на вайбах". Vibe coding — самый быстрый способ написать код, который ты не сможешь объяснить на собесе.

Что такое vibe coding и почему все подсели

Vibe coding — это когда ты открываешь Claude, Copilot или Cursor, описываешь что хочешь, принимаешь результат и шипишь. Без чтения кода. Без понимания архитектуры. Просто вайбы.

И это работает. Серьёзно. Полный CRUD API за 20 минут. Целый SaaS за выходные. Один стартап поднял auth-систему целиком на AI — она прошла все тесты, код был чистым. Четыре месяца в продакшне.

А потом обнаружили, что AI добавил debug-логирование и четыре месяца хранил пароли в plaintext в таблице логов. Никто не заметил, потому что никто не читал код (по данным Venture Magazine).

Цифры, от которых хочется закрыть IDE

Исследователь просканировал 100 приложений, собранных через Lovable, Bolt.new, Cursor и v0.dev (по данным DEV Community). Результаты:

• 65% приложений содержали уязвимости
• 58% — хотя бы одну критическую
• 70% — без CSRF-защиты
• 41% — API-ключи в открытом виде
• 21% — эндпоинты вообще без аутентификации
• 318 уязвимостей суммарно, 89 из них критических

Средняя оценка безопасности — 65 из 100. Это оценка D — "не сдал".

По данным GitHub, разработчики с AI-ассистентами пишут на 55% больше кода в неделю. Но баг-рейт в таких кодбазах в 2–3 раза выше — и это не синтаксические ошибки, а логические: неправильное поведение под нагрузкой, с реальными пользователями. А по данным WOWHOW, 63% разработчиков тратят БОЛЬШЕ времени на отладку AI-кода, чем сэкономили на его генерации.

Как vibe coder сыпется на собесе

Типичная ситуация. Кандидат прошёл скрининг. Решил тестовое — код чистый, тесты зелёные, всё работает. Его зовут на техническое интервью.

Интервьюер: "Объясни, почему ты здесь используешь useCallback?"

Кандидат: молчание.

Он не писал этот код. Он описал задачу Claude, принял результат и отправил. Код работает — но кандидат не понимает, зачем конкретная строка существует.

Разработчики из DEV Community описывают этот паттерн: "Код работает. Тесты проходят. Автор может объяснить что он делает обычным языком. Но спроси его, зачем конкретная строка — и получишь взгляд в тысячу ярдов."

На собесе это смерть. Потому что хороший интервьюер не проверяет, работает ли твой код. Он проверяет, понимаешь ли ты, ПОЧЕМУ он работает.

Три момента, на которых горят vibe coder'ы:

Дебаггинг. Попроси AI сгенерировать код — легко. Попроси AI отладить heisenbug в распределённой системе в 3 часа ночи — получишь уверенные, но неправильные советы. Дебаггинг требует ментальной модели системы, которую vibe coding не строит. Это ключевой навык, который проверяют на live-coding.

"Почему, а не что." Собес — это не демо твоего кода. Это разговор о компромиссах. Почему здесь WeakMap, а не обычный объект? Почему retry с exponential backoff, а не линейный? Если ты не принимал решение — ты не объяснишь его.

Edge cases. AI оптимизирует на "работает". Собес проверяет "а что если?". Что если concurrent write? Что если timeout на третьем retry? Что если input — пустой массив? Vibe coder не думал об этом — он принял первый работающий вариант.

Comprehension debt — долг, который дороже технического

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

Кодбаза растёт, а команда теряет ментальную карту собственной системы. Код существует, но никто не понимает, почему он именно такой. Через 6–12 месяцев vibe coding velocity падает — PR'ы ревьюятся дольше, простые изменения ломают неожиданные вещи.

Компании проводят 5 раундов собеседований, проверяя глубокие знания — а потом ставят тех же инженеров шипить фичи через vibe coding, которые никто не ревьюит. Это ровно те ошибки, которые выдают, что ты не умеешь работать с AI-инструментами.

Как использовать AI и не стать vibe coder'ом

Vibe coding — проблема не инструмента, а подхода. Claude, Copilot, Cursor — они делают ровно то, что ты просишь. Проблема в том, что ты перестаёшь думать.

Rubber duck на каждый AI-вывод. Перед тем как принять сгенерированный код — объясни вслух, что он делает. Если не можешь за 30 секунд — ты ещё не владеешь этим кодом.

"Почему?" на каждое решение. Не принимай первый вариант. Спроси AI: "почему ты выбрал эту структуру данных?", "какие альтернативы?", "что сломается если X?". Это подход builder'а, а не validator'а — и именно его ждут на собесе.

Дебажь руками. Когда что-то ломается — не проси AI починить. Открой DevTools, поставь breakpoint, прочитай stack trace. Это мышца, которая атрофируется если её не качать.

Code review как ритуал. Относись к AI-выводу как к PR от джуниора: ревьюй каждую строку. Тот стартап с plaintext-паролями — никто не сделал code review на AI-код.

Навык, который AI не заменит

AI генерирует код быстрее тебя. Но AI не может объяснить, почему он выбрал конкретное решение в контексте твоей системы. Не может дебажить проблему, которая проявляется только под нагрузкой. Не может ответить на follow-up вопрос интервьюера.

Если ты готовишься к собеседованию — используй AI как тренажёр, а не как костыль. Sobes AI не пишет код за тебя — он задаёт тебе вопросы, которые задаст интервьюер. И если ты не сможешь объяснить свой код — лучше узнать это сейчас, а не на собесе.