Вайбкодинг обещает нам будущее, где мы лишь «менеджеры кода», а всю работу делают нейросети. Я всегда скептически относился к этому, и суровая реальность деплоя лишь подтвердила мои опасения. Мой проект лег, процессор забился под 100%, а «самая умная» кодинг-модель Claude Opus 4.5 настойчиво предлагала единственное решение — снести мою БД. Рассказываю, как инженерное чутьё спасло проект от советов ИИ, и почему даже в 2025 году вайбкодинг не заменяет мозги.
Это моя первая публикация, и в ней я хочу поделиться историей о том, как вайбкодинг помог мне создать рабочий проект, а затем чуть не уничтожил всю накопленную БД. Я являюсь «технарем» по образованию и образу мышления: в студенчестве писал на Ассемблере и Паскале, но профессиональным разработчиком не стал, так как жизнь сложилась несколько иначе. Попытки «по-честному» выучить Python разбивались о нехватку времени, поэтому появление мощных LLM стало для меня идеальным поводом вернуться в код.
Откуда взялся проект
Мотивация была простая — в рамках своей текущей работы я столкнулся с крайне неудобным и неинформативным интерфейсом платформы в которой мне предстояло работать и я решил, что мне необходимо собственное решение, которое закроет все мои потребности. Так родилась идея классического CRUD-проекта. Очень удачно совпало, что в начале сентября в качестве эксперимента я приобрел подписку на GLM Coding Plan, и решил использовать именно эту задачу как полигон для проверки силы вайбкодинга на практике.
За три месяца вайбкодинга в свободное от работы время (по 2-4 часа в день с периодическим переключением на другие проекты, так что в целом на проект ушел примерно месяц работы) мне удалось довести его до пред-продакшн состояния. Весь проект (загрузка и обработка данных на Python, БД и Metabase для визуализации) я упаковал в единый docker-compose. Все шло идеально на машине на которой я кодил, пока я не решил перенести проект на другую машину. И вот тут «вайб» закончился, и началась суровая инженерная реальность.
Что же пошло не так?
Сценарий, как мне кажется, классический:
-
Есть рабочий проект на машине разработчика.
-
Разворачиваю его на «проде» — в моем случае это моя Raspberry Pi 5.
-
Запускаю docker
compose up -d.
Ожидание: проект приступает к автоматической загрузке данных по расписанию, БД активно наполняется новыми данными, Metabase рисует красивые графики статистики.
Реальность: Metabase не отвечает, все тормозит, CPU «малинки» забит под 100%.
К моменту деплоя я уже начал пользоваться Antigravity и предоставляемым там Claude Opus 4.5 Thinking и потому решил делегировать чтение логов именно ей, чтобы найти причину проблемы. Opus моментально нашел проблему: Metabase попал в CrashLoopBackOff из-за невозможности подключиться к базе данных в volume.
Вердикт ИИ звучал логично, но пугающе:
Выглядит так, что БД была создана в более новой версии Metabase, чем
latest. Скорее всего вы запускали Release Candidate или Enterprise версию, либо при pulllatestсистема загрузила какую-то старую стабильную версию релиза.Варианты действий:
Удалить БД и запустить Metabase с чистого листа
Попробовать загрузить конкретные версии Metabase в поиске необходимой версии
Т.е. все что мне предлагалось – либо снести все данные, либо начать “перебор” версий, в поиске необходимой, но казалось в предложенных вариантах не было предложено самого очевидного.
Решение
Я смотрел на совет удалить базу, которую собирал два месяца, и чувствовал подвох. Инженерное чутье из прошлого подсказало проверить самое банальное: версии. И не начать перебирать их, как предложил ИИ, не открывать и проверять конкретную версию на системе, где проект работал до этого, а просто напросто проверить: а был ли вообще выполнен pull latest?
Я просто набрал docker ps и увидел, что на Raspberry подтянулся старый образ Metabase, который остался там с моих древних тестов. А база в volume была уже от новой версии Metabase с основной машины. Старый софт пытался прочитать новую базу, падал, Docker его перезапускал — вот и причина 100% нагрузки на CPU.
Решение заняло буквально минуту:
docker compose pull
docker compose up -dПочему LLM провалилась?
Этот кейс отлично показывает разницу между «кодингом» и «инженерией».
-
Туннельное зрение: Модель видит ошибку «connection failed» и лечит именно её (пересоздай БД), но не видит контекста: «это новая машина, тут могут быть старые кэши».
-
Отсутствие хронологии: Человек помнит: «Я тут полгода назад что-то тестил». Модель видит только тот срез реальности, который вы ей дали в промпте.
-
Склонность к усложнению: LLM часто ищут ошибку в логике или данных, игнорируя процедурные банальности вроде устаревших образов.
Вывод
Вайбкодинг — это круто, пока всё работает и проблемы по большей части находятся в самом коде. LLM может создать unit-тесты, сделать проверку на edge кейсах. Но в тот момент, когда система ломается не на уровне синтаксиса, а на уровне окружения, вам всё еще нужен человек с инженерным чутьем, ведь если бы я слепо доверился «лучшей модели в мире», я бы мог лишиться всех накопленных данных. И тут не идет речь о том, что у меня не было бекапов, и как я мог допустить такое. Они были, речь скорее о том, что отправленный в свободное плавание ИИ-агент порой способен принимать самые неожиданные и радикальные решения и Human-in-the-loop все еще самое надежное решение.
LLM пока не заменит инженера, потому что инженерия — это не написание кода, это принятие решений в условиях неопределенности.
В следующих статьях я планирую разобрать, что о вайбкодинге думает Линус Торвальдс, и почему погоня за полностью автономными агентами — опасный путь.
Автор: MKreGGo
