Почему вайбкодинг не заменяет разработчика: цена кода без архитектуры

Вайбкодинг даёт сильное ощущение скорости. Человек описывает идею, получает код, видит работающую кнопку и за вечер собирает то, на что раньше потребовалась бы неделя. Для прототипа это действительно полезно. Проблема начинается, когда визуально работающий результат принимают за готовый production-продукт.

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

Работающий экран ещё не означает работающую систему

Большинство быстрых демонстраций проверяют счастливый путь: пользователь ввёл правильные данные, сервис ответил вовремя, сеть не пропала, а два процесса не попытались изменить одну запись одновременно. Реальный сайт живёт в других условиях. У него есть роли, права, повторные запросы, пустые значения, таймауты, миграции и данные, которые нельзя потерять.

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

Контекст проекта не помещается в один запрос

Большой контекст помогает модели, но не передаёт ей опыт эксплуатации конкретного проекта. В кодовой базе есть неявные договорённости: как именуются сущности, где выполняется валидация, кто имеет право менять заказ, как откатывается обновление и какие внешние сервисы могут повторить запрос. Модель видит переданные файлы, но не обладает опытом эксплуатации именно этой системы.

При вайбкодинге без знаний человек обычно проверяет результат по интерфейсу. Если кнопка нажимается, код считается готовым. Разработчик проверяет границы: что произойдёт при пустом ответе API, двойном клике, истёкшем токене, недоступной базе или обновлении зависимости. Именно на этих границах чаще всего появляются дорогие проблемы.

Безопасность нельзя проверить ощущением

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

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

ИИ может напомнить этот список, но не гарантирует, что требования выполнены во всех точках. Нужны review, автоматические проверки и ручное тестирование критичных сценариев.

Зависимости ускоряют старт и создают обязательства

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

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

Код должен оставаться понятным после генерации

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

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

Без отката эксперимент становится риском

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

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

Где вайбкодинг действительно полезен

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

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

ИИ усиливает уровень того, кто им управляет

Человек без знаний получает быстрый, но непроверяемый результат. Разработчик с опытом получает ускоритель: он знает, что спросить, где модель может ошибиться и как подтвердить ответ. Опытный разработчик быстрее замечает ошибку модели и может подтвердить результат до публикации.

Я не спорю с инструментом и не романтизирую ручной набор кода. Если часть работы можно ускорить без потери качества, я это делаю. Заказчику нужна система, которая решает задачу, выдерживает реальные сценарии и остаётся управляемой после запуска. Количество сгенерированных строк на эту ценность не влияет.