Создание производственного приложения на 200 тысяч строк кода с помощью виб-кодирования с телефона

Разработчик провёл эксперимент, чтобы проверить, справится ли «вайб-кодинг» с проектом высокой сложности, создав профессиональный мобильный инструмент для этого под названием Vibe Remote (теперь доступен бесплатно в App Store). Инструмент позволяет программировать на ходу без настройки Tailscale — пользователи сканируют QR-код и начинают писать код прямо с телефона.

Технологический стек и процесс разработки

Проект использует кроссплатформенную архитектуру: CLI, веб (https://vibe-remote.com), бэкенд на Go и нативные iOS/macOS на Swift. В нём есть глобальные узлы, безопасные пользовательские протоколы и TUI-интерфейсы.

Ограничение было простым: создать инструмент с помощью самого инструмента. После того как первая версия смогла общаться, разработчик полностью перестал использовать ноутбук. Более 95% кода было написано путём отправки сообщений Claude Code через приложение, пока он занимался своими делами в повседневной жизни.

Ежедневный рабочий процесс и решения

Ежедневная рутина включала накопление 5–10 точек изменений в нескольких параллельных сессиях дома, после чего разработчик просил ИИ вызвать пользовательский навык deploy-to-iphone, чтобы запустить сборку. Пока ИИ работал, разработчик смотрел короткие дорамы. В парке он накапливал изменения для iOS для последующего развёртывания дома, но для бэкенда на Go и SSR-сайта он просил ИИ перезапустить локальный сервер.

Чтобы решить проблему «я не вижу свои локальные изменения в парке», он поручил ИИ встроить браузер и прокси-туннель в само приложение, что позволило просматривать localhost:3000 с домашнего компьютера прямо на телефоне через безопасный протокол.

Объём кода и скорость разработки

• Всего строк: ~200 000 (140k Go, 60k Swift)
• Кривая скорости: За первые 3 недели было создано 150k строк. Скорость упала с 10k строк/день до 1k, а затем до 100–300 строк точных исправлений в день на этапе полировки.
• Истощение: Фаза «тонкой настройки» была более утомительной, чем первоначальная сборка, требуя постоянной проверки мелких деталей UX с высокой умственной нагрузкой от «тестирования» через чат.

Ключевые уроки

Проблема DRY

Когда проект становится огромным, ИИ перестаёт находить существующие реализации и начинает дублировать логику. Решение: относиться к инструкциям в claude.md как к «юридическим статутам» и явно указывать: «Мы уже делали похожую логику для функции X; найди её, абстрагируй и используй повторно. Не перереализовывай». Без этого появляется «зомби-код», где исправление бага в одном месте оставляет его в дублирующих реализациях.

Ловушка TDD

Изначально использовался строгий TDD-подход (модульные + сквозные тесты) с каждым тестом, описывающим функциональную ветку: сначала падающим, затем проходящим. Хотя Opus 4.6 отлично с этим справляется, сквозные тесты стали узким местом — ожидание полного прогона набора E2E-тестов убивало эффективность. В итоге разработчик отказался от E2E в пользу высокоплотных модульных тестов, чтобы сохранить «вайб» быстрым.

Отказ от «суперсильных» инструментов

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

Перестаньте беспокоиться о Git Worktrees

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