Где заканчивается прототип и начинается инженерия, почему «работает у меня» не равно «готово для бизнеса», и за что на самом деле платят опытной команде.

Коротко. Vibe coding хорош для прототипа, но в production скорость генерации кода не заменяет архитектуру, security review,тестирование, наблюдаемость и эксплуатационную ответственность

За последний год я несколько раз слышал одну и ту же формулу: «Зачем мне команда разработки? Я найду человека, который умеет хорошо промптить, он за неделю соберет продукт в Cursor/Lovable/Replit, и мы сэкономим месяцы и бюджет».

На уровне демо это часто правда. Интерфейс открывается. Регистрация работает. Кнопка отправляет запрос. В базе появляется запись. Можно снять красивое видео, показать инвестору и даже получить первые регистрации.

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

Именно об этой территории обычно не знают люди, которые никогда не отвечали за production.

Я не против AI‑инструментов. Наоборот, мы используем их там, где они ускоряют работу: при исследовании, написании шаблонного кода, подготовке тестов, рефакторинге, поиске альтернатив, документации. Но AI‑assisted development и vibe coding не одно и то же. В первом случае инструмент ускоряет инженера. Во втором человек передает инструменту решения, которые сам не умеет проверить.

А вот это для бизнеса уже опасная разница.

1. Вайбкодинг не равен разработке с AI

Термин vibe coding в феврале 2025 года популяризировал Андрей Карпати. В исходном описании была важная деталь: разработчик перестает внимательно читать изменения, принимает сгенерированный код и двигается дальше, ориентируясь на то, что приложение визуально делает нужное [1].

С тех пор словом «вайбкодинг» начали называть почти любую разработку с LLM, и это только запутывает разговор. Если опытный разработчик попросил модель сгенерировать функцию, прочитал diff, проверил границы входных данных, написал тесты, прогнал статический анализ и понимает последствия решения, это обычная инженерная работа с более быстрым инструментом.

Vibe coding начинается там, где исчезает контроль. «Модель написала, тестовый сценарий прошел, значит можно выкатывать».

Для pet‑проекта это нормально. Для одноразового скрипта тоже. Для прототипа, который завтра можно выбросить, иногда даже идеально

Но production‑код отличается тем, что его нельзя оценивать только по счастливому сценарию.

2. Главная ловушка: демо показывает функцию, а не систему

Некоммерческий разработчик обычно видит задачу примерно так:
«Нужно сделать форму оплаты, авторизацию и личный кабинет».

Инженер с production‑опытом слышит в этой фразе десятки дополнительных вопросов.
Что будет, если платежный провайдер ответит дважды? Что будет, если webhook придет через 40 минут? Где хранится idempotency key? Можно ли повторно списать деньги? Как разделены authentication и authorization? Кто может читать чужие объекты? Что случится при недоступности внешнего API? Есть ли retry с ограничением? Что попадет в логи? Не окажется ли там токен или персональные данные? Как откатить релиз? Как восстановить базу? Как понять, что дегра‐ дация уже началась, если пользователи еще не написали в поддержку?

На демо все эти вопросы невидимы. Кнопка нажалась, страница открылась, кажется, что продукт готов на 90 процентов.

На практике видимая функция может быть только верхушкой работы.

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

3. «Он же работает» не означает «он безопасен»

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

В исследовании Veracode 2025 GenAI Code Security Report более 100 моделей тестировали на задачах, которые можно было решить безопасным или небезопасным способом. В 45 процентах случаев сгенерированный код провалил security‑проверку и содержал обнаружимую уязвимость из классов OWASP Top 10 [2].

Есть и более жесткие академические результаты. В работе 2025 года с 200 задачами на изменение реальных open‑source проектов один из протестированных агентов в конкретной конфигурации выдавал функционально корректное решение в 61 процентах случаев, но безопасным было только 10,5 процента решений [3]. Это не означает, что «LLM пишет уязвимости в 89,5 процента случаев» вообще. Это означает более важную вещь: функциональная корректность и безопасность могут очень сильно расходиться.

Если исполнитель не умеет сам распознать insecure direct object reference, слишком широкую RLS‑политику, SSRF, race condition или неправильную проверку подписи webhook, AI не превращает его в специалиста по AppSec. Он просто помогает быстрее получить код, который человек не способен полноценно проверить.

4. Кейс с RLS: одна настройка, которую не видно в интерфейсе

Хороший пример того, почему «все работает» недостаточно, появился вокруг Lovable и Supabase.

В NVD зарегистрирован CVE-2025-48757: недостаточная Row‑Level Security в сгенерированных сайтах могла позволять удаленному неаутентифицированному пользователю читать или изменять данные в таблицах. Запись помечена как disputed, поскольку поставщик платформы указывал на ответственность владельцев приложений за защиту данных [4].

Для меня здесь интересен даже не спор о распределении ответственности. Интересен сам класс ошибки.

Supabase anon key может легитимно находиться на клиенте. Само по себе это не секрет. Безопасность строится на корректных политиках доступа к строкам. Человек без опыта легко видит «в приложении есть login» и мысленно ставит галочку «авторизация готова». Но login отвечает на вопрос «кто ты?», а RLS отвечает на вопрос «какие именно данные тебе можно читать и менять?». Это разные слои.

Внешне приложение с правильным RLS и приложение с дырявым RLS могут выглядеть абсолютно одинаково.

Вот почему security review не заменяется ручным кликом по интерфейсу.

Кстати, даже в текущей документации Lovable прямо сказано, что встроенные сканеры не гарантируют полную безопасность, а для приложений с чувствительными данными или критичной функциональностью стоит рассматривать дополнительный профессиональный security review [6]. Это здравый подход. Инструмент может ускорять, но ответственность за production никуда не исчезает.

Есть еще один показательный эпизод. В апреле 2026 года Lovable сама описала инцидент, в котором backend‑регрессия повторно открыла доступ к chat history и исходному коду публичных проектов для других авторизованных пользователей, если у них была ссылка на проект. В разборе компания отдельно признала проблему процесса: несколько валидных отчетов исследователей были закрыты на triage из‑за устаревшей внутренней документации [5]. Это полезное напоминание: безопасность продукта живет не только в коде. Нужны процессы, ownership, актуальные правила, review и корректная эскалация. Если подобные вещи требуют системной работы даже от большой платформы, странно ожидать, что одиночный исполнитель без productionпрактики закроет их автоматически.

5. Самозванец не обязательно плохо пишет код

Под «самозванцем» я здесь не имею в виду джуна. Джун внутри нормальной команды, с ревью, наставником, тестированием и понятной зоной ответственности, это обычная и здоровая часть индустрии.

Проблема начинается, когда человек без коммерческого опыта продает себя как full‑stack, архитектора, DevOps, security engineer и технического директора одновременно, потому что теперь у него есть доступ к модели, способной генерировать любой из этих артефактов.

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

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

После первой миграции, которая не помещается в maintenance window. После внезапного роста очереди. После частичного отказа стороннего API. После изменения схемы данных, которое ломает старый мобильный клиент. После ситуации, когда «временный» feature flag живет два года. После восстановления бэкапа, который до аварии никто не проверял. После инцидента, где логирование есть, но нужного correlation id нет. После релиза в пятницу, который формально зеленый, но бизнес‑метрика уже падает.

Эти вещи трудно выучить по туториалам, потому что туториал почти всегда заканчивается на happy path.

6. Что обычно не попадает в «быструю разработку»

Когда случайный подрядчик обещает «сделать SaaS за две недели», я бы не спорил с оценкой по фронтенду. Я бы спросил, что именно входит в слово «сделать».

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

Безопасность. Threat model, секреты, права, multi‑tenancy, обработка пользовательского ввода, безопасная работа с файлами, rate limiting, защита административных функций, security headers, зависимости, аудит событий.

Тестирование. Unit‑тесты являются только одним уровнем. Нужны интеграционные сценарии, контрактные тесты, проверки миграций, негативные кейсы, регрессия, smoke после деплоя. Для части систем нужны нагрузочные и fault‑тесты.

Инфраструктура. CI/CD, окружения, конфигурация, секреты, IaC, мониторинг, алерты, резервные копии, процедуры восстановления, rollback, доступы. «Задеплоил на Vercel» может быть хорошим решением, но это не эксплуатационная стратегия само по себе.

Наблюдаемость. Логи, метрики и трассировка должны отвечать на вопросы бизнеса и эксплуатации. Сколько запросов падает? Где растет latency? Какой внешний сервис деградирует? Какая версия клиента создает ошибки? Сколько денег мы теряем прямо сейчас?

Поддерживаемость. Документация, соглашения, контроль зависимостей, понятная структура, ownership, code review. Код должен быть читаем не только моделью, которая его сгенерировала сегодня, но и инженером, который будет чинить его через год в 03:00.

Экономика. Иногда «быстро» означает очень дорогую инфраструктуру, лишние API‑вызовы или архитектуру, стоимость которой растет быстрее выручки. Production‑разработка включает инженерную экономику, а не только feature velocity.

7. Почему дешевый исполнитель часто оказывается дорогим

В начале проекта стоимость ошибки низкая. Схему можно поменять за час. API можно переименовать. Таблицу можно удалить.

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

Поэтому цена подрядчика и стоимость разработки не одно и то же.

Самый дорогой сценарий, который мы видим на рынке, выглядит так:

1. Компания экономит и отдает MVP человеку, который умеет быстро генерировать функциональность.

2. MVP начинает продаваться, значит «подход доказал эффективность».

3. В продукт добавляют еще 20 процентов функций поверх случайных решений

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

5. Приходит опытная команда и выясняет, что исправлять по месту дороже, чем часть системы переписать.

6. Компания платит второй раз, только теперь еще под давлением работающего бизнеса.

Проблема не в том, что первый исполнитель «плохо написал React». Проблема в том, что он принимал архитектурные и эксплуатационные решения, не зная, что именно решает.

8. AI усиливает компетентность, но усиливает и незнание

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

LLM резко снижает стоимость получения правдоподобного ответа. Но не снижает стоимость проверки этого ответа.

Иногда проверка дороже генерации на порядок. Модель за 20 секунд создаст Terraform, OAuth flow, миграцию и webhook handler. Чтобы убедиться, что все четыре фрагмента безопасны, совместимы с инфраструктурой, не ломают обратную совместимость и корректно ведут себя при сбоях, нужен специалист, который понимает предметную область.

Поэтому главный вопрос сегодня не «использует ли подрядчик AI?». Почти наверняка использует.

Главный вопрос: «Кто отвечает за решения, которые AI предложил, и достаточно ли у этого человека опыта, чтобы сказать модели нет?»

9. Чем отличается команда с коммерческим опытом

У нас довольно консервативное отношение к слову «готово».

Готово, это не когда задача закрыта в трекере. Готово, это когда решение понятно, проверяемо, наблюдаемо, разворачивается повторяемо, имеет предсказуемые failure modes и не превращает следующую задачу в раскопки.

Специалисты нашей команды имеют профильное образование и более 10 лет коммерческого опыта разработки. Проектами такого уровня мы занимаемся более 5 лет. Работаем в том числе с крупнейшими компаниями: как консультанты, как команда full cycle development и как инженерное усиление на отдельных направлениях.

Full cycle для нас означает не «мы умеем и фронтенд, и бэкенд». Это ответственность за жизненный цикл решения.

На старте это discovery, декомпозиция бизнес‑задачи, аудит ограничений, архитектура и выбор технологий без моды ради моды.

В разработке это backend, frontend, mobile при необходимости, интеграции, данные, тестирование, DevOps/DevSecOps, CI/CD, инфраструктура и security‑практики.

Перед запуском это нагрузка, observability, планы миграции, rollback, резервное копирование, контроль доступов и проверка критичных пользовательских сценариев.

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

Иногда клиенту не нужна full‑cycle команда. Нужен архитектурный review, независимый аудит кода, помощь с производительностью, DevOps, security, сложная интеграция или технический due diligence перед инвестиционным решением. Это тоже нормальный формат. Смысл зрелой команды не в том, чтобы продать максимальное количество разработчиков, а в том, чтобы правильно закрыть инженерный риск.

10. «Мы беремся за проекты любой сложности» не означает «обещаем всё»

Фраза «проекты любой сложности» легко звучит как маркетинг, поэтому поясню, что я под ней понимаю.

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

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

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

11. Когда вайбкодинг, наоборот, отличная идея

Чтобы не превращать текст в борьбу с прогрессом, зафиксирую: vibe coding бывает очень полезен.

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

Порог меняется, когда появляется хотя бы один из факторов:

• персональные или финансовые данные;

• деньги и платежные сценарии;

• несколько ролей и сложная модель доступа;

• B2B‑интеграции;

• обязательства по доступности;

• высокая нагрузка;

• регуляторные требования;

• бизнес зависит от корректности данных;

• продукт должен жить и развиваться несколько лет;

• стоимость простоя или утечки измеряется не стоимостью хостинга.

В этот момент «собрать» уже недостаточно. Нужно проектировать, проверять и отвечать за результат.

12. Как проверить подрядчика до того, как он получит ваш production

Я бы задал потенциальной команде несколько вопросов. Не про список технологий, а про ответственность.

Кто принимает архитектурные решения и как они документируются? Как устроен code review? Какие тесты обязательны перед релизом? Как проверяется модель авторизации? Где хранятся секреты? Как устроены окружения? Можно ли воспроизвести инфраструктуру? Что происходит при неуспешной миграции? Есть ли rollback? Как проверяется восстановление из резервной копии? Какие метрики и алерты появятся до запуска? Кто разбирает инцидент? Как вы передадите проект другой команде, если сотрудничество закончится?

Если в ответ звучит только «мы быстро пишем на Next.js, Supabase и AI», вы уже получили важную информацию.

Если подрядчик способен обсуждать trade‑offs, failure modes, эксплуатацию, безопасность и стоимость владения еще до того, как написал первую строчку, это гораздо более здоровый сигнал.

Вместо вывода

Вайбкодинг сделал разработку доступнее. Это хорошо. Он позволяет быстрее проверять идеи и сокращает рутину даже в профессиональных командах.

Но он же создал новый тип ложной уверенности: если человек способен получить работающий интерфейс, кажется, что он способен построить работающий бизнес‑продукт.

Это разные компетенции.

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

Именно поэтому я бы не отдавал production случайному человеку только потому, что он эффектно демонстрирует скорость с AI. Скорость имеет ценность только тогда, когда рядом есть инженерная ответственность.

Мы используем современные инструменты, включая AI, но не передаем им ответственность за решения. Ее несут специалисты с профильным образованием, более чем 10-летним коммерческим опытом и практикой сложных проектов на протяжении более 5 лет. От консультации и технического аудита до full cycle development и дальнейшей эксплуатации, мы берем на себя не только создание фич, но и инженерные последствия того, что создаем.

В production именно это обычно и отличает «приложение работает» от «на продукт можно положиться».

Источники и материалы

[1] Simon Willison, цитата Андрея Карпати о vibe coding, 6 февраля 2025

[2] Veracode, 2025 GenAI Code Security Report

[3] Zhao et al., Is Vibe Coding Safe? Benchmarking Vulnerability of Agent‑Generated Code in Real World Tasks, arXiv, 2025

[4] NVD, CVE-2025-48757

[5] Lovable, Our response to the April 2026 incident

[6] Lovable Documentation, Security overview