Как работать с разработчиком над приложением, созданным с помощью ИИ

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

Многие создают первую версию приложения с ИИ, а потом привлекают разработчика — чтобы добавить платежи, исправить то, что ИИ постоянно делает неправильно, провести проверку безопасности или взять приложение на поддержку по мере роста. Если вы ещё решаете, нанимать ли вообще, см. нанять разработчика или создать с помощью ИИ. Это руководство предполагает, что решение принято, и вы хотите, чтобы сотрудничество прошло гладко.

Когда разработчик нужен

Частые причины привлечь специалиста:

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

Ясность в том, какая из этих причин у вас, определяет всё дальнейшее.

Шаг 1: Переместите код туда, где им можно поделиться

Разработчики работают с Git-репозиториями. Прежде чем с кем-то связываться:

1. Подключите проект к приватному репозиторию на GitHub (или аналогичном сервисе) или экспортируйте его.
2. Убедитесь, что в коде и истории нет секретов. См. как хранить API-ключи в безопасности.
3. Проверьте, что проект запускается из свежей копии — попросите ИИ написать шаги установки.

Напиши README для разработчика, который присоединяется к проекту: что делает приложение, стек, как установить и запустить его локально, какие переменные окружения нужны (только имена), структуру папок и всё хрупкое или необычное.

Если Git для вас новый, как пользоваться Git с приложением, созданным с помощью ИИ объясняет основы.

Шаг 2: Напишите бриф на одну страницу

Разработчик не читал вашу переписку с ИИ. Дайте ему контекст на одной странице:

• Что делает приложение, для кого и сколько людей им пользуются.
• Что важнее всего — сценарии, которые никогда не должны ломаться.
• Известные проблемы и то, что вы уже пробовали.
• Задача и то, как вы поймёте, что она выполнена.
• Ограничения: бюджет, срок, то, что нельзя менять.

Хорошее «определение готовности» поддаётся проверке: «Вошедший пользователь может оплатить месячный тариф через Stripe Checkout, тариф появляется на странице его аккаунта, а отмена в портале клиента понижает тариф в конце периода». А не «разобраться с платежами».

Шаг 3: Выдайте доступ безопасно

• Код: добавьте разработчика соавтором в репозиторий. Не пересылайте ZIP-архивы туда и обратно, когда работа уже идёт.
• Конструктор: если ваш конструктор с ИИ поддерживает участников команды, пригласите его в рабочее пространство, содержащее только этот проект.
• Секреты: добавляйте их в настройки хостинга или передавайте через менеджер паролей. Никогда не вставляйте ключи в email или чат.
• Тестовые аккаунты: создавайте их с тестовыми данными, а не давайте свой вход.
• Производственные данные: только если им действительно нужно, и только то, что необходимо.

Репозиторий, домен и аккаунты хостинга держите на своё имя. Добавляйте людей, а не передавайте аккаунты.

Шаг 4: Договоритесь, кто что меняет

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

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

Шаг 5: Общайтесь письменно

• Описывайте проблемы с шагами, ожидаемым и фактическим результатом. См. как написать хороший отчёт об ошибке.
• Храните решения в одном месте: трекер задач, общий документ или комментарии к pull request.
• Попросите объяснять изменения простым языком в каждом pull request.
• Договоритесь, как часто будете созваниваться.

Шаг 6: Проверяйте их работу

Чтобы проверить работу, не нужно читать код. Смотрите:

• Делает ли она то, что написано в брифе, в предпросмотре или на тестовой копии.
• Ничего ли другого не сломалось — проверьте ключевые сценарии.
• Объяснили ли они, что изменили и почему.
• Не появились ли секреты в коде.

Для более глубокой проверки в как проверять код, сгенерированный ИИ есть чек-лист, который подходит и для кода, написанного людьми. Также можно попросить ваш конструктор с ИИ объяснить вам pull request разработчика простыми словами.

Шаг 7: Сохраняйте ясное владение

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

Примеры запросов

Разработчик изменил код оплаты в последнем pull request. Объясни простым языком, что он изменил и зависит ли от этого что-то ещё в приложении.

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

Я передаю платежи разработчику. С этого момента не трогай файлы в src/payments и маршруты /api/billing. Если изменение требует их, сообщи мне вместо этого.

Частые ошибки

• Нет брифа. Разработчик тратит оплачиваемые часы на то, чтобы понять, чего вы хотели.
• Размытый объём работ, например «исправить баги» или «сделать готовым к продакшену».
• Одновременное редактирование обеими сторонами без предварительного pull, а потом потеря работы из-за конфликтов.
• Передача своего логина или вставка ключей в чат.
• Аккаунты на имя разработчика, из-за чего трудно расстаться.
• Забыть удалить доступ и перевыпустить ключи после завершения работы.

Чек-лист

• Код находится в приватном репозитории на моё имя, без секретов.
• README объясняет установку; бриф на одну страницу описывает приложение и задачу.
• У задачи есть проверяемое определение готовности.
• Доступ выдан через приглашения соавторов, секреты — через настройки или менеджер паролей.
• Мы договорились, кто что меняет, и я делаю pull перед запросом.
• Работа проверяется по брифу и ключевым сценариям.
• Владение закреплено в письменном виде; по окончании работы доступ удаляется, а ключи перевыпускаются.

Работа с разработчиком в Mythex

• Пригласите его в рабочее пространство. Владельцы могут приглашать неограниченное число соавторов без платы за место; участники работают с проектами рабочего пространства. Используйте отдельное рабочее пространство, чтобы они видели только этот проект. Кредиты за опубликованные приложения списываются с владельца рабочего пространства. См. Приглашения.
• Синхронизация с GitHub и экспорт (Pro). Подключите репозиторий и отправляйте/получайте изменения, либо экспортируйте проект без секретов. См. GitHub, экспорт и импорт.
• Поделитесь ссылкой на предпросмотр, чтобы показать незавершённую работу человеку без аккаунта Mythex; удалите её, когда закончите.
• Режим «Вопросы» отвечает на вопросы о коде, не меняя его, — полезно, чтобы разобраться в изменениях разработчика.

Если разработчик будет запускать приложение в другом месте, см. как экспортировать приложение, созданное с помощью ИИ, и развернуть его у себя.

Вопросы