Android-приложение с полусотней экранов, сложной анимацией, поддержкой десяти языков и кастомной клавиатурой. Полноценный нативный клиент на Kotlin. 200 000 строк исходного кода. И только 0.1% из них написал человек. Остальное - результат vibe-кодинга, подхода, при котором код генерирует AI, а разработчик превращается в архитектора, постановщика задач и ревьюера. Этот кейс - не гипотетический сценарий, а реальный проект, доведённый до сборки за восемь месяцев с прямыми затратами на AI-сервисы до $20.
Vibe-кодинг меняет экономику разработки, но не отменяет инженерное мышление. Напротив, он требует его в гипертрофированной форме: 90% времени уходит на составление спецификаций и только 10% - на ревью сгенерированного кода. Разберём методологию, которая позволила получить работающее приложение, не написав ни строчки руками, и определим границы применимости этого подхода.
Что такое vibe-кодинг и почему о нем говорят
Vibe-кодинг - это методология разработки, при которой программист описывает задачу на естественном языке, а языковая модель генерирует готовый код. Термин закрепился в 2024–2025 годах с ростом возможностей LLM и появлением специализированных инструментов для генерации кода. Отличие от классического использования AI-ассистентов - в масштабе: разработчик не запрашивает отдельную функцию или метод, а описывает целый экран, модуль или сценарий взаимодействия с API.
Рост популярности подхода подогревается двумя факторами. Первый - информационный хаос в сфере AI: новые модели, техники и инструменты появляются ежедневно, и разработчики ищут способы не отстать. Второй - экономическое давление: стоимость опытного инженера растёт, а сроки вывода продукта на рынок сжимаются. Vibe-кодинг обещает радикальное ускорение при минимальных прямых затратах на инструменты. Кейс с Android-приложением на 200 000 строк кода показывает, что обещание может быть выполнено, но с жёсткими условиями.
Кейс: Android-приложение, созданное AI от спецификации до сборки
Проект представляет собой нативное Android-приложение на Kotlin. Функциональный охват - 50+ экранов, включая онбординг, профиль пользователя, каталог, корзину, оформление заказа, историю операций и административную панель. Технические характеристики: кастомная анимация переходов между экранами, мультиязычность с поддержкой десяти языков, собственная клавиатура с предиктивным вводом и обработкой жестов, синхронизация локальных данных с сервером через REST API, фоновая обработка конфликтов.
Общий объём кодовой базы - 200 000 строк на Kotlin. Из них руками написано менее 200 строк: конфигурация сборки Gradle, несколько критичных участков в интеграции с ffmpeg и правки орфографии в UI-строках. Всё остальное - результат работы AI-моделей. Проект разрабатывался восемь месяцев одним человеком, который совмещал роли архитектора, технического писателя и ревьюера. Прямые затраты на доступ к AI-сервисам не превысили $20 за весь период.
Этот результат ставит под вопрос традиционные оценки стоимости мобильной разработки. Аналогичный проект, выполненный командой из двух-трёх разработчиков, занял бы от шести до двенадцати месяцев с бюджетом на зарплаты от $60 000 до $150 000 в зависимости от региона. Разрыв на три-четыре порядка по прямым затратам требует объяснения - оно кроется в методологии.
Методология: 90% времени на спецификации, 10% на ревью
Ключевой принцип успешного vibe-кодинга - инверсия привычного распределения усилий. В классической разработке программист тратит основное время на написание кода и его отладку. В vibe-кодинге написание кода делегировано AI, а фокус смещается на два этапа: детальное описание того, что должно быть сделано, и проверку того, что получилось. Соотношение 90/10 означает, что из восьми месяцев проекта около семи ушло на создание и уточнение спецификаций, и лишь один - на интеграцию, ревью и исправление сгенерированного кода.
Процесс выстроен вокруг текстовых файлов со спецификациями. На каждый экран приложения создавался отдельный документ, описывающий: назначение экрана, входные данные и их источники, все UI-элементы с их состояниями и поведением, переходы на другие экраны, обработку ошибок, краевые случаи. Для API-слоя писались спецификации эндпоинтов: URL, метод, заголовки, тело запроса, структура ответа, коды ошибок, логика повторных попыток.
Объём спецификаций в пересчёте на строку кода даёт ориентир: одна страница детального текстового описания порождает примерно 500 строк Kotlin-кода. Для приложения в 200 000 строк потребовалось около 400 страниц спецификаций. Это сопоставимо с объёмом технической документации, который создаётся для крупного проекта в любом случае, но здесь документация становится не артефактом, а непосредственным инструментом производства.
Как писать спецификации, понятные AI
Формулировки должны быть однозначными. AI-модель интерпретирует текст буквально, поэтому любая двусмысленность приводит к ошибкам в коде. Правило: если спецификацию можно понять двумя способами, AI выберет третий, неверный. Практические приёмы, выработанные на этом проекте:
- Описывайте входные данные с указанием типов, допустимых диапазонов и форматов. Например: «Поле email принимает строку, соответствующую RFC 5322, длина не более 254 символов».
- Для каждого UI-элемента указывайте все возможные состояния: начальное, загрузка, ошибка, пустой список, заполненный список, недоступность.
- Переходы между экранами описывайте явно: «При нажатии кнопки 'Оплатить' и успешном ответе 200 OK от POST /api/payment происходит переход на экран OrderConfirmation с параметром orderId из тела ответа».
- Используйте псевдокод для сложной логики. Модель преобразует его в синтаксически корректный Kotlin увереннее, чем прозаическое описание.
- Примеры данных в формате JSON помогают AI правильно построить модели и парсеры.
Роль человека в этом процессе - архитектурные решения и валидация логики. AI не выбирает паттерны проектирования, не оценивает компромиссы между производительностью и читаемостью, не предвидит узкие места. Эти решения принимает разработчик и фиксирует их в спецификациях. Затем модель генерирует код, который человек проверяет на соответствие задуманному. Тестирование остаётся полностью ручным - автоматические тесты тоже можно генерировать, но их корректность требует отдельной верификации.
Экономика vibe-кодинга: $20 за 8 месяцев разработки
Прямые затраты на AI-сервисы за восемь месяцев составили до $20. Использовались публично доступные модели с бесплатными тарифами и ограниченные платные запросы для сложных случаев. Основной объём генерации выполнялся на бесплатных квотах. Это радикально контрастирует с расходами на корпоративные AI-инструменты: внедрение AI-агентов в компаниях может стоить от $10 000 до $500 000 за настройку и интеграцию. Одиночный разработчик с грамотно выстроенным процессом получает сопоставимый результат за сумму, меньшую стоимости обеда.
Сравнение с традиционной разработкой требует учёта скрытых затрат. Семь месяцев работы над спецификациями - это человеко-часы. Если оценить их по рыночной ставке Android-разработчика уровня senior ($40–80/час), то затраты составят от $45 000 до $90 000. Это сопоставимо с нижней границей стоимости ручной разработки аналогичного проекта. Экономия возникает не на трудозатратах, а на необходимости содержать команду: один человек с AI заменяет двух-трёх разработчиков, но работает столько же времени.
Финансовый профиль vibe-кодинга выглядит так: прямые расходы на инструменты стремятся к нулю, затраты на труд концентрируются на высокоуровневых задачах, а совокупная стоимость проекта снижается за счёт сокращения команды. Для стартапов и инди-разработчиков это открывает возможность создавать сложные продукты без привлечения инвестиций на зарплаты. Для крупных компаний - перераспределять бюджеты с написания кода на архитектуру и продуктовые решения.
Однако экономия на написании кода может обернуться ростом затрат на поддержку. Технический долг в эпоху AI не исчезает, а переходит в стоимость токенов и время на верификацию. Сгенерированный код, не прошедший тщательного ревью, накапливает архитектурную энтропию, и каждое последующее изменение требует больше контекста и больше запросов к модели.
Где AI справляется идеально, а где проваливается
Опыт проекта позволяет провести чёткую границу между задачами, которые AI решает с первого запроса, и теми, где он беспомощен. Граница проходит не по сложности задачи, а по её природе: изолированные, хорошо специфицируемые модули - зона уверенной генерации; системные задачи с глубоким контекстом - зона провала.
Идеальные задачи для AI: клавиатура и синхронизация
Кастомная клавиатура с поддержкой десяти языков была сгенерирована полностью. AI создал раскладки для каждого языка, обработку жестов (свайп, долгое нажатие), предиктивный ввод на основе частотного словаря и переключение между языками. Причина успеха - задача декомпозируется на повторяющиеся паттерны: раскладка для любого языка описывается одинаковой структурой данных, меняется только набор символов. Спецификация заняла три страницы и содержала таблицу символов для каждого языка, правила автозамены и описание жестов в терминах координат и временных порогов.
Скрипты синхронизации локальных данных с сервером - второй пример идеальной работы AI. Логика синхронизации включает: загрузку изменений с сервера, разрешение конфликтов по временным меткам, отправку локальных изменений, обработку сетевых ошибок с экспоненциальной задержкой повторных попыток. Это рутинная задача с чёткими правилами, которые легко формализовать в спецификации. AI сгенерировал работающий код для всех сценариев, включая краевые случаи вроде одновременного изменения одной записи на двух устройствах.
Общий признак идеальных задач: высокая повторяемость паттернов, низкая связность с остальной системой, возможность полного описания поведения в терминах входных и выходных данных.
Провалы AI: ffmpeg и правописание
Портирование ffmpeg для обработки видео на устройстве стало главной точкой отказа AI. Задача требовала: настройки кросс-компиляции нативной библиотеки под Android NDK, управления памятью при работе с видеопотоками, оптимизации производительности под конкретные архитектуры процессоров. AI генерировал синтаксически корректный код, который либо не компилировался из-за несовместимости версий NDK, либо компилировался, но падал с ошибками сегментации при обработке видео. Проблема в том, что модель не обладает системным пониманием: она не знает, какие версии библиотек совместимы, не может протестировать код в реальном окружении и не учитывает ограничения мобильных устройств по памяти. В итоге интеграцию ffmpeg пришлось писать вручную - те самые 0.1% кода.
Правописание в UI-строках - неожиданный провал. AI генерировал грамматически безупречные предложения, которые оказывались семантически неверными в контексте приложения. Например, кнопка «Удалить аккаунт» в английской версии превращалась в «Delete account», но в контексте экрана настроек требовалось «Delete account» с уточнением «and all data». Модель не улавливала разницу, потому что не имела доступа к полному контексту пользовательского пути. Это потребовало ручной вычистки всех строковых ресурсов.
Вывод: AI проваливается там, где требуется целостное понимание системы, а не генерация изолированного фрагмента. Системная интеграция, низкоуровневые оптимизации, контекстно-зависимый контент остаются зоной ответственности человека.
Риски и этика: почему Codeberg запретил AI-проекты
В начале 2026 года некоммерческий хостинг кода Codeberg объявил о запрете проектов, созданных и поддерживаемых преимущественно AI-агентами. Причина - не идеологическая, а сугубо практическая: нагрузка на инфраструктуру. Стоимость SSD-накопителя, который несколько лет назад обходился в €700, выросла до €3700. Рост связывают с лавинообразным увеличением объёмов AI-сгенерированного кода, который заливается в репозитории без должной фильтрации. Затраты на CI/CD также выросли кратно: каждый AI-проект генерирует множество коммитов с минимальными изменениями, нагружая системы сборки и тестирования.
Codeberg сформулировал и этическую позицию: проекты, созданные AI без существенного человеческого вклада, наносят вред FLOSS-сообществу. Они зашумляют поисковую выдачу, создают иллюзию активности и затрудняют поиск качественных проектов с реальным человеческим участием. Это частный случай более широкой проблемы: лавина сгенерированного кода разрушает понимание кодовой базы и создаёт когнитивную ловушку для команд, которые теряют контроль над архитектурой.
Юридические риски AI-кода пока находятся в серой зоне. Вопрос авторства сгенерированного кода не урегулирован в большинстве юрисдикций. Если модель обучилась на коде с ограничительной лицензией и воспроизвела его фрагменты, проект может нести риски нарушения авторских прав. Пока прецедентов массовых исков нет, но страховые компании уже начинают включать оговорки об AI-генерации в полисы профессиональной ответственности разработчиков.
Минимизировать риски можно тремя способами: тщательное ревью каждого сгенерированного фрагмента, автоматическое тестирование с высоким покрытием и документирование процесса генерации - какие спецификации подавались, какая модель использовалась, какие правки вносились вручную. Это создаёт аудиторский след и снижает вероятность пропуска уязвимости или лицензионно-нечистого кода в релиз.
Когда vibe-кодинг оправдан, а когда без архитектурного мышления не обойтись
Критерии применимости vibe-кодинга вытекают из анализа успехов и провалов в проекте. Подход оправдан для: изолированных модулей с чёткими границами, прототипирования и MVP, рутинных задач с повторяющимися паттернами, генерации boilerplate-кода и UI-компонентов по дизайн-системе. В этих сценариях качество спецификации напрямую определяет качество результата, а затраты на ревью минимальны.
Архитектурное мышление необходимо для: проектирования общей структуры приложения, интеграции сложных систем и нативных библиотек, оптимизации производительности, обеспечения безопасности, принятия решений о технологическом стеке. Это задачи, где цена ошибки высока, а последствия проявляются не сразу, а через месяцы эксплуатации. AI не может нести ответственность за архитектурное решение - ответственность всегда лежит на человеке.
Продуктовое мышление остаётся исключительно человеческой компетенцией. Понимание потребностей пользователей, приоритизация функций, дизайн пользовательского опыта - всё это требует эмпатии, контекста рынка и стратегического видения. AI может предложить варианты, но не может принять решение о том, какую проблему пользователя решать в первую очередь.
Vibe-кодинг как инструмент, а не замена разработчику
AI в vibe-кодинге - это продвинутый генератор кода, а не замена инженеру. Аналогия: экскаватор заменяет десяток землекопов с лопатами, но требует квалифицированного оператора, который знает, где копать, на какую глубину и как не повредить коммуникации. Так же и AI-генератор кода требует оператора, который понимает архитектуру, умеет писать спецификации и способен отличить рабочий код от правдоподобного.
Навыки, критически важные для vibe-разработчика: системное мышление, умение декомпозировать сложные задачи на изолированные компоненты, навык написания однозначных спецификаций, компетенции в код-ревью и тестировании. ИИ-ассистенты ускоряют разработку на 55% на шаблонных задачах, но замедляют на 19% на сложных, и эта статистика подчёркивает: инструмент эффективен ровно настолько, насколько квалифицирован его пользователь.
Будущее vibe-кодинга - в углублении симбиоза человека и AI. Модели будут лучше понимать контекст, поддерживать большие объёмы спецификаций, генерировать тесты одновременно с кодом. Но фундаментальное ограничение сохранится: AI оперирует вероятностными предсказаниями, а разработка требует детерминированных решений с предсказуемыми последствиями. Мост между этими мирами строит человек - спецификациями, ревью и архитектурными решениями.
Проект с 200 000 строк сгенерированного кода доказывает: создать работающее приложение без единой написанной руками строчки возможно. Но за этим результатом стоят сотни часов человеческого труда по спецификации, верификации и принятию решений. Vibe-кодинг не устраняет разработчика - он меняет его роль с писателя кода на архитектора и контролёра качества. И в этой роли инженерное мышление важнее, чем когда-либо.