Вайб-кодинг приложения на 35 000 строк: что для этого реально нужно и что может пойти не так

Приложение рецептов с голосовыми функциями, заменой ингредиентов и пошаговыми инструкциями по приготовлению — созданное почти полностью с помощью промптов на естественном языке. Без традиционного проектирования архитектуры. Без ручного написания кода строка за строкой. Просто разработчик описывает, что он хочет, а ИИ пишет 35 000 строк кода. Это и есть вайб-кодинг в действии, и он ставит вопрос, который должен задать себе каждый бизнес: не приходится ли за такую скорость платить?

Что на самом деле означает вайб-кодинг

Если просто: вайб-кодинг — это создание программного обеспечения путём описания желаемого на обычном английском (или любом другом языке), после чего ИИ генерирует код. Роль разработчика смещается от написания синтаксиса к управлению промптами, проверке результатов и направлению ИИ к нужному результату.

Согласно обзору этой практики от Google Cloud, вайб-кодинг использует промпты на естественном языке для создания и запуска приложений, трансформируя подходы к разработке и развёртыванию программного обеспечения. Microsoft теперь предлагает обучающие модули по внедрению рабочих процессов вайб-кодинга с GitHub Copilot Agent.

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

Экосистема инструментов быстро повзрослела. Как задокументировано в подробном руководстве Modern Age Coders, основные игроки сейчас включают Cursor, Claude Code, Bolt.new, Lovable, Windsurf, v0.dev и Firebase Studio — каждый со своими сильными сторонами для разных типов проектов.

Реальные цифры: тот же источник сообщает о 92% adoption ИИ-инструментов для кодинга среди разработчиков, при этом 46% кода в индустрии уже генерируется ИИ. Это больше не маргинальные эксперименты.

Почему именно 35 000 строк — это интересная часть

Создать приложение со списком дел с помощью вайб-кодинга — тривиальная задача. Сотни разработчиков публикуют такие демо ежедневно. Приложение на 35 000 строк — это совсем другой зверь.

На таком масштабе несколько вещей становятся сложными:

Ограничения контекстного окна. ИИ-модели могут удерживать в памяти ограниченный объём кода одновременно. Проект на 35 тысяч строк означает, что ИИ не может «видеть» всю кодовую базу при генерации новых функций. Разработчику приходится вручную управлять тем, с какими файлами и каким контекстом ИИ работает — по сути, становясь проджект-менеджером для внимания ИИ.

Согласованность между модулями. Когда ИИ генерирует код изолированно, он склонен решать одну и ту же задачу по-разному каждый раз. Логика аутентификации в одном файле может следовать совершенно другому паттерну, чем логика аутентификации в другом. На протяжении 35 000 строк эти несоответствия накапливаются.

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

Честный взгляд: довести проект до 35 000 строк с помощью вайб-кодинга — впечатляющее достижение. Поддерживать и расширять эти 35 000 строк — вот где начинается настоящий вызов.

Бизнес-кейс для вайб-кодинга

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

2Point Agency отмечает, что вайб-кодинг значительно ускоряет разработку внутренних инструментов за счёт использования готовых компонентов и визуальных интерфейсов — позволяя командам с ограниченными инженерными ресурсами создавать кастомные приложения под конкретные бизнес-потребности.

Где вайб-кодинг даёт наибольшую отдачу от инвестиций:

• MVP и прототипы. Валидируйте продуктовую гипотезу, прежде чем выделять полноценные инженерные ресурсы. Прототип приложения рецептов, который в традиционной разработке обошёлся бы в $30 000–$50 000, можно набросать за малую долю этой суммы.
• Внутренние инструменты. Админ-панели, дата-пайплайны, интерфейсы отчётности — инструменты, где «достаточно хорошо» действительно достаточно хорошо.
• Исследование функций. Сгенерируйте три разных подхода к реализации функции, протестируйте каждый на пользователях, а затем передайте победителя старшему разработчику для доведения до продакшн-качества.

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

Проблема безопасности, о которой никто не хочет говорить

Вот часть, которая должна обеспокоить каждого основателя и технического директора. Руководство Modern Age Coders явно указывает на уязвимости из списка OWASP Top 10 как на известный риск в приложениях, созданных вайб-кодингом.

Сгенерированный ИИ код обычно идёт кратчайшим путём к работающему результату. Зачастую это означает:

• SQL-запросы, построенные через конкатенацию строк вместо параметризованных запросов — что открывает двери для инъекционных атак.
• API-ключи и секреты, захардкоженные в исходных файлах вместо хранения в переменных окружения.
• Отсутствие валидации ввода на пользовательских эндпоинтах — ИИ делает функцию работающей, но не думает о том, что произойдёт, если кто-то отправит вредоносный ввод.
• Чрезмерно разрешительные конфигурации CORS и аутентификации, которые отлично работают в разработке и создают дыры в безопасности на продакшне.

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

Вот что мы рекомендуем: любое приложение, созданное вайб-кодингом и предназначенное для реальных пользователей, нуждается в аудите безопасности перед запуском. Заложите это в бюджет с первого дня. Экономия на разработке ничего не значит, если устранение последствий утечки обойдётся в десять раз дороже.

Что на самом деле нужно для продакшн-версии

Переход вайб-кодированного приложения на 35 тысяч строк от стадии «работает на моей машине» к стадии «надёжно обслуживает тысячи пользователей» обычно требует:

Код-ревью и рефакторинг

Старший разработчик должен пройти через сгенерированный код, выявить несоответствия, консолидировать дублирующуюся логику и установить паттерны, которым кодовая база должна следовать в дальнейшем. По нашему опыту работы с 12 проектами, включающими сгенерированный ИИ код, этот этап ревью обычно занимает 30–40% от первоначального времени разработки.

Тестирование

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

Оптимизация производительности

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

Инфраструктура и DevOps

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

Когда вайб-кодинг уместен (а когда нет)

Хорошо подходит:

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

Плохо подходит:

• Приложениям, обрабатывающим конфиденциальные данные (медицина, финансы, юриспруденция), без специального аудита безопасности
• Системам, где надёжность не подлежит компромиссу (обработка платежей, управление инфраструктурой)
• Проектам со сложной, взаимосвязанной бизнес-логикой, требующей глубокого понимания предметной области
• Долгосрочным кодовым базам, которые множество разработчиков будут поддерживать годами

Настоящий урок приложения на 35 тысяч строк, созданного вайб-кодингом

История приложения рецептов на самом деле не про рецепты. Она про изменение экономики разработки программного обеспечения.

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

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

Ключевой вывод для бизнеса: вайб-кодинг меняет то, кто может создавать программное обеспечение и как быстро они могут это делать. Он не меняет того, что требует программное обеспечение продакшн-качества. Закладывайте бюджет на весь путь — ускоренный с помощью ИИ спринт до работающей версии плюс инженерная работа, чтобы сделать её надёжной, безопасной и поддерживаемой. Первый этап может стоить на 60–70% меньше, чем традиционная разработка. Второй этап стоит примерно столько же, сколько стоил всегда.

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

Часто задаваемые вопросы

Почему приложение рецептов с голосовыми функциями требует 35 000 строк кода?

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

Какие меры безопасности предусмотрены для приложений, разработанных так быстро и без традиционного планирования?

Как правило, очень немногие — и в этом основной риск. Сгенерированный ИИ код часто пропускает валидацию ввода, использует небезопасные настройки по умолчанию и может хардкодить конфиденциальные значения. Любое приложение, созданное вайб-кодингом и предназначенное для реальных пользователей, должно пройти специальный аудит безопасности, охватывающий OWASP Top 10, перед развёртыванием.

Может ли вайб-кодинг работать для приложений сложнее, чем менеджер рецептов?

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