Можно ли работать вдвоём над проектом в AI-билдере

Да, но не через общий курсор. Совместная работа в Zugo идёт через то, что производит сборка: опубликованную ссылку, которую открывает кто угодно, репозиторий на GitHub, куда можно добавить людей, и ваши собственные аккаунты Supabase, Stripe и Vercel. Один человек ведёт промпты, остальные смотрят и присылают правки текстом.

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

Что люди имеют в виду под «работать вместе»?

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

Zugo отвечает на них в обратном порядке по силе. Передача самая крепкая: проект принадлежит вам, код экспортируется в GitHub, а каждый коннектор работает на вашем аккаунте. Ревью тоже простое: проект публикуется на адрес вида имя-проекта.zugo.run, и ссылку открывает любой человек на любом устройстве.

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

Как двое реально работают над одним проектом?

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

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

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

У кого должен быть аккаунт?

У того, кто останется в проекте через полгода. Тарифы считаются на аккаунт: Free даёт 5 кредитов единоразово, Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц. Практическое следствие в том, что кредиты это общий кошелёк, и тратит его тот, у кого логин.

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

Коннекторы меняют расклад в хорошую сторону. Supabase держит базу и вход, Stripe держит деньги, Vercel может держать хостинг, и все три это аккаунты, которыми вы и так владеете. Даже если логин в билдере завтра сменит хозяина, данные, выплаты и цели деплоя за ним не уйдут. Как это настраивается, разобрано в статье AI-приложение с Supabase.

Сколько стоит совместная работа в кредитах?

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

Одностраничная сборка стоит 6 кредитов. Многостраничная платформа стоит 12 за первые три страницы и по 3 кредита за каждую следующую. Правка стоит 3 кредита, а режим Hi-Fi удваивает оба действия: правка 6, сборка 12.

Такая форма цены поощряет собирать замечания пачками, что и без того правильная дисциплина ревью. Трое рецензентов с тремя отдельными сообщениями это три правки. Те же три замечания, собранные в одну инструкцию, это одна. 200 кредитов Pro превращаются в 66 правок, если тратить их только на доводку, а это очень много кругов обсуждения для небольшого проекта.

Как передать проект разработчику?

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

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

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

Как договориться, чтобы не мешать друг другу?

Тремя правилами, которые стоит проговорить до первой сборки, а не после первого конфликта.

Один человек за рулём в один момент. Не «один навсегда», а один на текущий круг. Двое, отправляющие правки в один проект попеременно, получают результат, который никто из них не задумывал, потому что каждая правка применяется поверх чужой.

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

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

Три правила выглядят бюрократично для двоих, но именно двое чаще всего и наступают на все три сразу.

Где такая схема ломается?

В четырёх довольно предсказуемых местах, и ни одно из них не секрет.

• Совместное редактирование в реальном времени. Его нет. Если весь процесс команды держится на том, что двое одновременно правят один документ, здесь будет неудобно с первого дня.
• Слияние работы двух людей. Внутри билдера слияния не существует. Два варианта проекта остаются двумя вариантами, пока кто-то не пересоберёт руками или работа не переедет в репозиторий.
• Роли и права внутри сборки. Доступ к коннекторам управляется в Supabase, Stripe, GitHub и Vercel, у каждого свои правила. Единой модели прав вам никто не выдаёт.
• Сложный продукт с несколькими разработчиками. Zugo не заменяет команду разработки. Дальше определённого размера правильный ответ звучит так: билдер быстро сделал первую версию, дальше владеет команда.

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

Как настроить работу маленькой команды?

Четыре шага в таком порядке. Заведите аккаунт на почту, которой владеет команда. Подключите Supabase, Stripe и остальное на аккаунты компании, а не на личные. Публикуйте рано, потому что ссылка, которую можно открыть, делает удалённые замечания конкретными. Экспортируйте в GitHub, как только кто-то начал писать код руками.

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

Поэтому круг ревью всё равно нужен, и он как раз дешёвая часть. Откройте адрес, соберите замечания, отправьте их одной правкой, посмотрите снова. Что именно уезжает вместе с проектом при передаче, разобрано в статье можно ли забрать исходный код. А попробовать сам круг проще всего на маленькой сборке: соберите одну страницу на zugo.dev и отправьте ссылку человеку, чьё мнение вам действительно нужно.