Проклятие легких побед: как вайбкодинг убивает волю к решению проблем

«Вайбкодинг» ‑ это просто ролевая игра для парней, которые хотят чувствовать себя хакерами, не делая сложной работы, или это мощный инструмент, меняющий процессы даже ML-инженера? Я думал, что это просто игрушка, пока не попробовал.

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

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

Как я решил начать

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

Наверняка вы видели сотни видосов на ютубе “я создал стартап с нуля за неделю при помощи Claude Code” или “я настроил 20 MCP в Codex и теперь он сам закрывает все таски”, и у меня они постоянно вызывали FOMO. Мол, я что, зря стараюсь? Вот я пишу код, а через 5 лет все поголовно будут вайбкодить, зачем кому-то мои навыки?

Да, я использовал LLM в качестве ассистентов и до этого, но только через UI интерфейс или автодополнение Cursor. Доверить машине самостоятельное решение задачи я всегда опасался, т. к. не верил в ее способности.

Но человек я достаточно азартный, интерес и потенциальный выигрыш перевесили опасения и я решился.

Первый опыт

RAG с нуля на Swift за неделю

Это был пет-проект, RAG до этого я никогда не встречал, как и разработку под MacOS. Выбрал связку Swift (front) + Python (back) + Pinecone (DB, retrieval) + GPT (generation). Я использовал:

• Claude Desktop с подключенными MCP для формирования PRD

• Claude Code для основной разработки, планирования спринтов и ведения документации модулей; использовал по максимуму mcp, commands, hooks, subagents

• Cursor вместо VSCode, иногда для точечных фиксов и автодополнения

• Web Claude, Web GPT для “взгляда со стороны”

В общем, все по лучшим традициям на момент августа 2025. Было невероятно приятно заниматься верхнеуровневым планированием, постоянное ощущение себя “создателем”, а не просто рабочим разрабом. В процессе я даже что-то узнал про Swift. Проект дошел до MVP, имел простую функциональность: добавление/удаление файлов из индекса, автообновление индексов и чанкования в фоне, получение ответа на запрос, исходя из контента чанков.

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

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

UI Aналитическая платформа

Это был уже кейс с работы, за несколько дней создал MVP платформу для удобного показа результатов исследований. Заказчики могли по кнопке получать предсказания нескольких моделей и кучу аналитики. Чистый Python, а для UI — всеми нелюбимый streamlit. Деплой был в кластере по сути локально, даже без отдельного пода и сервиса.

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

Что интересно — заказчикам и менеджерам понравилось больше всех. Это был хороший такой “плюсик” в карму, мол, заботишься об удобстве → ускоряешь проверки → экономишь деньги → молодец!

Заказчики видят результат, а не твои внутренние struggles. Демки готовятся раньше, обсуждаются амбициозные планы: докрутить так, добавить это. Все начинают мыслить не задачами, а желаниями.

И в этот момент я решил, что готов делать так всё.

Опыт в работе

Задача была следующая: обучить модель генерации для RAG. Сильно углубляться не буду, но надо было:

1. собрать, разметить данные и обучить несколько QLoRA-адаптеров моделей-ассессоров

2. создать методом nucleus sampling много генераций и разметить их моделями-асессорами

3. отобрать пары и обучить модель генерации через DPO

4. повторить пункты 2–3 несколько раз

Метод называется RAG-DDR. Сначала все было замечательно, но чем больше разрастался проект…

• стоп, он не может написать рабочую параллелизацию? зачем мне ThreadPoolExecutor если достаточно async?

• эм, а че у меня лосс не падает, “claude find issues” и так уже 5 часов

• tensor_parallel=8 в vllm не ускорит в 8 раз, клод, не надо меня обманывать

• сам пожалуйста оптимизируй параметры, ты же умная модель

• почему у меня метод predict уже в третьем файле? очень надеюсь в этот раз он все правильно нагенерирует, а я пока тикток гляну

Каким-то я раздражительным стал… Мои агенты-ревьюеры и дебаггеры уже 5 часов подряд не помогают, лезть в код? Не хочется. Наверное плохие промпты, пойду их улучшу. И субагентов побольше дам. И токенов еще куплю.

Но ладно, такие проблемы бывают и у простого кодинга. Фух, задача закрыта. Хоть сейчас и 11 часов вечера. Что-то я вымотался, пойду поиграю в доту. Уже нет сил что-то продуктивное делать, всё-таки рабочий день был, я заслужил.

Бухгалтерия вайбкодера

Итак, что мы получаем, если поддаемся вайбу в долгосрочной перспективе.

Дебет

• Быстрые гипотезы

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

• Рост насмотренности

Видишь корректное использование незнакомых библиотек, языков, паттернов. В свое время я так познакомился со Swift и научился правильно использовать Pydantic.

• Снижение когнитивной нагрузки

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

• Усиление исследовательского мышления

Код перестает быть барьером, ты начинаешь мыслить не “как сделать?”, а “что сделать?”. Это в целом хорошее мышление по жизни, единственный нюанс — иногда оно сопровождается отсутствием сопротивления и дешевому получению желаемого. Но для full-time работы это, кажется, только плюс)

• Рост креативности

Возможно мгновенно воплощать гипотезы, UI, тестировать то, до чего раньше руки бы не дошли.

• Эйфория от работающего кода

Ты получаешь огромное количество дофамина, когда закрываешь двухдневную задачу двумя промптами.

Кредит

• Уменьшение когнитивной выносливости

Пока ты пишешь код сам, ты входишь в режим “потока”. Когда за тебя код пишет Claude — ты в бесконечном ревью. А проверять LLM психологически затратнее, после 4х часов такого ревью ты чувствуешь себя как выжатый лимон. Мозг вынужден переплачивать ресурсами за постоянный контекст-свитчинг между твоей задумкой и генерацией агента. Ты становишься более раздражительным. Ты не чувствуешь, что хорошо поработал и получил ценный опыт сегодня. Ты чувствуешь, что позанимался какой-то херней и тебе повезло, что она сработала правильно. У меня такое ощущение было постоянно на поздних стадиях любого проекта, когда надо было очень аккуратно использовать агентов.

• Атрофия problem solving

“Claude, why loss is not converging? fix pls” в какой-то момент настигает любого вайбкодера. Инстинкты инженера понимают, что сейчас надо лезть в формирование сэмплов, искать ошибки в расчете лосса и т. д. Но Claude так много раз тебя выручал, пусть и сейчас сам просмотрит все и найдет. В какой-то момент ты заметишь, что уже месяц не пытался решать сам проблемы в коде. Ты как будто становишься мягче, проблемы самому решать уже труднее и хочется их избегать. Это проявляется и в реальной жизни: решения принимаются быстрее, но поверхностнее. Ты предпочитаешь не сильно себя напрягать, постоянно хочется мгновенную подсказку. Комфорт начинает преобладать над ростом.

• Аутсорсинг критического мышления

Пункт тесно связан с предыдущим. Даже в задачах ML возникает соблазн скормить агенту графики обучения и попросить подтюнить гиперпараметры, чтобы метрики были выше. Ты начинаешь просить LLM придумывать гипотезы, а потом просишь их проверять. При этом агент практически всегда бесполезен. Когда нужно локализовать улучшение или проблему — он выдает только похожую на правду гипотезу. Мне это напоминает оправдания, мол, я проверил это и это, ниче не сработало, но я старался. И если ты не садишься самостоятельно выявлять проблемы или улучшать пайплайны — ценность тебя как инженера теряется.

• Усиление СДВГ

Пока Claude генерирует тебе очередной шедевр, ты просто вынужден ждать. Но ты ведь эффективная личность, поэтому хочешь максимально продуктивно провести рабочий день, чтобы в следующий раз работы было меньше. Ты переключаешься на другую задачу. А потом обратно, когда Claude закончил. И снова. И снова. Ты делаешь так 5 раз, а потом мозг перегревается. Ты говоришь себе: “ладно, я не Цезарь, мозг у меня однопоточный, поэтому буду выполнять задачки последовательно”. Вкидываешь промпт и сидишь ждешь. Ждать просто так скучно, но и снова перегреться ты не хочешь. Тогда “на помощь” приходят соцсети, рилсы, тиктоки, ютуб. И работа превращается в промпт-скроллинг. Думаю, не надо объяснять, что контекст проекта теряется, раздражительность от багов усиливается, как и усталость от работы. Полноценный Lock In возможен только у вайбкодеров с ютуба, продающих тебе свой же SaaS.

• Токсичная креативность

Креативность была плюсом, но она же и минус. LLM — это бесконечный раб, беспрекословно выполняющий любые твои указания. Так почему бы мне не разойтись как следует? Сделаем удобно: по кнопке загрузка данных, по кнопке запуск обучения. Самому было бы тупо лень, но тут такая возможность, нельзя упускать. И ты начинаешь городить абстракции там, где нужен простой скрипт, зато чувствуешь себя создателем. Через день вайб пропадает, а куча переусложненного кода остается. Этот оверинжиниринг мало того, что добавляет тебе сложностей в проекте в будущем, так еще ты тратишь весь свой креативный потенциал на “всем нужные фичи”. А мог бы создать свой блог или написать проект за рамками работы, если уж так хочется повайбить.

• Непрогнозируемость

Все твои time estimates превращаются в казино. Когда ты ориентируешься в проекте ты знаешь, что эта задача на 20 минут. В вайбкодинге время становится квантовым. Ты можешь решить задачу одним промптом за 20 секунд, а можешь потратить 5 часов, перезапуская пол проекта, потому что умная LLM не сохранила очевидно нужное поле в одной из начальных таблиц. Иногда это выливается в переработки. Кто бы мог подумать?

• Бонус: гемблинг-зависимость

Аналогия тут очень к месту. Результат каждого промпта непредсказуем, мозг каждый раз предвкушает положительный исход. Будто дергаешь за рычаг “однорукого бандита”. И мозг вырабатывает чудовищное количество дофамина. В детали вдаваться не буду, есть отличные лекции Владимира Алипова на ютубе. Но факт остается фактом: вайбкодинг превращает инжиниринг в лудоманию. Ты проигрываешь 5 часов времени, надеясь “отыграться” следующим промптом. И когда получается — ты чувствуешь невероятный кайф, который обычным кодингом уже получить не способен. Ты подсел.

Вайбкодинг — убийство

Итак. Самое опасное в вайбкодинге — не ошибки и не галлюцинации модели. Самое опасное — исчезновение сопротивления.

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

Через год такого режима ты внезапно обнаружишь, что стал быстрее принимать решения, но медленнее думать. Парадокс. Твой мозг, который эволюционно был создан для решения сложнейших задач, начинает лениться и требовать мгновенного дофамина от кнопки Enter. Ты становишься “мягким”. Ты останавливаешься в развитии. Хорошо еще, если у тебя был хороший бэкграунд и несколько лет опыта — есть на чем строить.

Рано или поздно ты решаешь вернуться на грешную “невайбовую” землю. Но обнаруживаешь, что все это время ты будто бежал на беговой дорожке: пота много, а дистанция до реальных экспертных знаний сильно не сократилась. Это довольно страшное чувство — понять, что ты не улучшился как инженер. И новую такую же задачку тебе снова придется дотошно объяснять LLM, контролируя каждый шаг, потому что у тебя не появилась нужная экспертиза для ее самостоятельного решения. А была бы — решил бы в 5 раз быстрее, чем ИИ. И без гемблинга.

Я понял, что по кайфу кодинг только MVP, а все за пределами — по прежнему тяжелая работа. Да, легкие вещи сейчас стали доступны всем. Но тяжелые всплывают как сливки. И постепенно это понимают все. Иначе бы 80% стартапов не платили сотни тысяч долларов на чистку вайбкода.

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

Везде, где цена ошибки большая.

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

• будет нагрузка и нужно масштабирование — сразу мимо, LLM с этими задачами справляется хуже всего, проверено лично на практике

• продакшен системы — использовать AI в качестве ассистента — да, но не вайбкод; каждое решение надо перепроверять и лучше не делегировать LLM большие куски проекта

• длительный проект — лучше потратить в 5 раз больше времени на старте, чем в 15 раз больше через полгода

Кстати, RAG из примера выше не воспроизводился с репозитория. А UI интерфейс выдерживал одновременно только одного пользователя. Но об этом, разумеется, на этапе MVP можно умолчать.

Где уместно

Везде, где цена ошибки маленькая.

Есть места, где повайбкодить можно и часто это упрощает работу:

• небольшие пет проекты — особенно круто настраивать сети агентов именно в них, чистая воля воображения; в больших не стоит полностью делегировать свой мозг ИИ

• хакатоны / стартапы / кейс MVP на работе — идеальный кейс, отлично подходит под концепцию looks finished; но только если вы будете готовы переписывать все полностью для продолжения

• визуал / UI / фронтенд, сайты (с точки зрения MLщика) — ТОЛЬКО для внутреннего пользования

• тест гипотез / sql — одноразовые микро скрипты, которые не требуют включения в кодовую базу проекта

• работа с данными — единоразово построить графики, посчитать статистики, смерджить, сгруппировать, почистить

• тулзы для работы — одна несложная задача, результат предсказуем

Что в итоге? Все-таки писать код?

Нет. В статье шла речь про ВАЙБкодинг, а не про кодинг с ассистентом. AI можно и нужно использовать в работе и ML-инженеру тоже. Надо дробить задачу самому на маленькие атомарные таски и писать их с помощью LLM, но всю картину проекта так или иначе хранить в своей голове, а не в файлах PLAN.md и директории docs/. И все решения принимать самому, даже если не хочется и даже если есть уверенность в том, что агент решит все правильно. Поддашься соблазну — и, как я говорил выше, налог придется заплатить большой.

Вайбкодинг. Нет короткого пути к тяжелой работе.