Они не знали, что им навайбкодили.

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

Когда мы залезли в код, стало, в общем-то, понятно почему «всё сложно». Система была написана быстро, красиво на поверхности и абсолютно непредсказуемо внутри. Модули, которые не должны были знать друг о друге, были завязаны в клубок: любое изменение в одном месте аукалось в трёх других. Архитектуры как таковой не существовало — был набор решений, которые просто не успели подраться друг с другом. До поры.

Заказчик не знал, что это вайб-код. Он думал, что нанял людей, а не алгоритмы.

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

Cursor и Claude не предупреждают, когда начинают формировать систему вместо того чтобы помогать её строить. Они просто продолжают генерировать — уверенно, логично, без пауз. И если в этот момент нет жёсткого понимания границ и правил — система собирается сама по себе. Не как спроектированная, а как стихийно выросшая

В этом главная ловушка. Вайб-код не падает на второй день. Первые недели — всё летит. Функции появляются быстро, клиент доволен, дедлайны соблюдаются. Выглядит как победа.

А потом система начинает сопротивляться. Любое изменение затрагивает неожиданные части. Ломается то, что не должно было ломаться. Разобраться как это вообще работает становится отдельным проектом. Потому что ИИ, который писал это две недели назад, уже не помнит контекст. Он не проектировал систему — он генерировал ответы на вопросы. Один за другим. Без общей картины.

Это как строить дом, нанимая каждый день нового прораба, который не видел что делал предыдущий. Каждый по отдельности делает нормально. Вместе — получается то, что получается.

Генерация даёт скорость. Проектирование — управляемость. Внешне они могут выглядеть похоже. По последствиям — нет.

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

Сгенерированный код нужно проверять, встраивать в архитектуру, ограничивать и иногда просто выбрасывать. Это делает человек. Причём не джун, который «в целом разобрался» по YouTube. Это дорогой разработчик с опытом, который видит где система может полететь к чертям ещё до того, как это случилось.

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

В Elgrow Cursor, Claude и ChatGPT, Midjourney — часть рабочего процесса. Каждый день. Не использовать их сегодня — это примерно как продолжать писать код в блокноте и гордиться этим.

Но есть принципиальная разница в том, как именно это делается. ИИ у нас не проектирует архитектуру. Он разгребает рутину: документация, boilerplate, code review, коммерческие предложения. Всё что требует думать за систему целиком — делает человек.

Потому что ИИ не думает за систему. Он очень убедительно имитирует это — но не делает. И пока ты понимаешь разницу — инструмент работает на тебя. Когда перестаёшь понимать — начинаешь работать на него.

Мы провели аудит, показали где и почему система нестабильна, предложили план рефакторинга. Заказчик был в лёгком шоке — не от масштаба проблем, а от того, что предыдущая команда ни разу эту тему не подняла. Всё выглядело нормально. Спринты шли, задачи закрывались, деньги списывались.

Пока не перестало работать.

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

Масштабирование превращается в отдельный проект — система, которая работала на 100 пользователях, начинает сыпаться на 10 000, потому что никто не думал об этом на старте. Любое изменение стоит дорого — когда модули завязаны друг на друга без логики, добавить одну кнопку может занять неделю. Команду невозможно сменить — новый разработчик смотрит на код и не понимает как это работает, потому что это не спроектировано, это сгенерировано.Технический долг накапливается незаметно — до момента, когда дешевле переписать с нуля.

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

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

Если вам предлагают сделать систему «в три раза дешевле» — спросите как именно. Ответ на этот вопрос стоит дороже, чем вся сэкономленная сумма.