Почему вайб-кодинг не работает

Когда в экосистеме разработки стали массово появляться AI-агенты (Claude, Cursor), сам процесс написания кода ощутимо сдвинулся. Я, как и многие разработчики, увидел в этом возможность наконец-то вырваться из рутины, сосредоточившись на архитектуре и задачах верхнего уровня.

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

За один вечер я мог получить столько кода, сколько раньше писалось неделями. Обсуждаешь с AI идею, дорабатываешь концепт, пробрасываешь требования — и видишь, как на глазах растёт проект, состоящий из кода в тысячи строк. Вайб-кодинг дал ощущение, что ты создаёшь что угодно, легко и свободно, будто играешь в конструктор, детали собираются сами.

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

Но, как часто бывает в разработке, яркий старт — это только половина истории.

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

Первая проблема — замедление реакции агентов. То, что раньше занимало пару минут, теперь растягивается на десятки минут. AI всё чаще «зависает» на простых задачах, начинает предлагать переписать половину проекта, чтобы исправить незначительный баг. Причина проста: контекст растёт, модель начинает путаться в собственных же предложениях и не может удерживать в голове структуру проекта.

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

· God-объекты: классы и модули, которые знают о всей системе и участвуют в каждом процессе.

· Дублирование бизнес-логики, как будто проект пишет не один агент, а три, и каждый живёт своей жизнью.

· Громоздкие функции с десятком параметров, половина из которых просто прокидывается по цепочке без смысла.

Пока проект маленький, эти дефекты незаметны. Но по мере роста код превращается в «кашу, любое изменение тянет за собой десятки побочных эффектов. Это особенность вайб-кодинга: процесс ощущается продуктивным, пока проект не превышает когнитивный предел модели. Как только база становится слишком большой, структура начинает самопроизвольно расползаться.

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

После нескольких неудач, я пришёл к выводу: AI без чёткой архитектуры неизбежно разрушает проектную целостность. Модели прекрасно генерируют код «здесь и сейчас», но они не умеют удерживать архитектурный контекст, не отслеживают и не видят появление антипаттернов. Они создают работающие решения, но не устойчивые системы.

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

Только при наличии жёсткого «скелета» AI становится полезным инструментом. AI отлично пишет код, но только человек может создать архитектуру, в рамках которой этот код будет жить и развиваться.

Здесь я регулярно делюсь опытом разработки с AI.