Один репозиторий, два агента и приложение, которое не развалилось по дороге

Сложный продукт начинается с границ, а не с промпта

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

Это уже не лендинг. Тут есть минимум 2 независимых контура: веб-часть и нативное приложение. У них разные экраны, зависимости и способы проверки. А в конце им надо обмениваться данными через общий сервер.

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

Агентам нужна не свобода, а чётко очерченная территория работы.

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

План снижает цену каждого следующего запроса

Для планирования использовали GPT-6 Astra в режиме Max, а реализацию поручали Astra 6 Medium. План описывал минимальный стек, структуру папок, этапы для сайта и macOS-приложения, вход по одноразовому коду и 2 режима распознавания: локальный и облачный.

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

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

Можно начать с такого файла:

Визуальный каркас нужен раньше интеграций

Сначала для сайта и приложения были подготовлены варианты визуального направления в виде изображений. После выбора стиля агент переносил его в лендинг и экраны приложения: диктовку, настройки, аккаунт и помощь.

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

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

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

Сначала проверяют путь пользователя, потом добавляют оплату

На веб-части быстро появился лендинг, вход по 6-значному коду и кабинет. Отправку кода проверили на настоящей почте. Для этого настроили домен, DNS-записи, сервер и изолированное развёртывание в Docker.

Важно, что проверка шла по цепочке, а не по скриншотам:

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

Для рабочих внутренних инструментов похожую логику можно использовать в ATLAS PANEL: сначала собрать прозрачный сценарий доступа и действий, а потом наращивать необязательные слои.

Локальная функция может оказаться важнее облачного плана

Ключевой функцией была диктовка. Сравнили Whisper и Parakeet v3 для локального распознавания и выбрали Parakeet v3 из-за скорости. При этом выбор модели сохранили в настройках, а не спрятали внутри приложения.

Затем проверяли не только качество текста. Интерфейс должен показывать реальное состояние микрофона. Результат должен попадать в буфер обмена. Нужны глобальная горячая клавиша и автоматическая вставка текста в активное приложение. Для последнего macOS запрашивает разрешение на универсальный доступ, и после его выдачи сценарий пришлось проверять повторно.

Облачное распознавание через DeepInfra тоже протестировали. Обработка занимала около 2,5 секунды. Этого оказалось достаточно, чтобы отказаться от облака, обязательного аккаунта, платной версии и подписки. В финальной логике осталась бесплатная локальная программа.

Агент пишет быстро, но ответственность за проверку остаётся у человека

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

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

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