Як працювати з розробником над застосунком, створеним ШІ

Щоб добре працювати з розробником над застосунком, створеним за допомогою ШІ, дайте йому код у Git-репозиторії, одну сторінку з описом того, що робить застосунок і навіщо, та чітко окреслене завдання з визначенням завершеності. Домовтеся, хто змінює які частини, щоб ви та ШІ не перезаписували його роботу, тримайте обліковий запис репозиторію та хостингу на своє ім'я, а секрети передавайте через належні налаштування, а не в повідомленнях.

Багато людей створюють першу версію застосунку за допомогою ШІ, а потім залучають розробника — щоб додати платежі, виправити те, що ШІ постійно робить неправильно, перевірити безпеку або взяти на себе застосунок, коли він зростає. Якщо ви ще вирішуєте, чи взагалі наймати, див. наймати розробника чи створювати з ШІ. Цей посібник припускає, що рішення вже ухвалено, і ви хочете, щоб співпраця пройшла гладко.

Коли розробник потрібен

Типові причини залучити когось:

• Проблема, яку ШІ не може розв'язати після кількох чітких спроб і відкатів.
• Ризиковані ділянки: платежі, дозволи, чутливі дані, міграції бази даних.
• Перевірка безпеки або коду перед запуском або перед роботою з більшими клієнтами.
• Продуктивність, коли з'являється реальний трафік.
• Зростання: застосунок став бізнесом і потребує людини, яка відповідає за код.

Чітке розуміння того, яка з цих причин ваша, визначає все подальше.

Крок 1: передайте код у зручному для спільного використання місці

Розробники працюють із Git-репозиторіями. Перш ніж звертатися до когось:

1. Під'єднайте проєкт до приватного репозиторію GitHub (або подібного) або експортуйте його.
2. Переконайтеся, що в коді та історії немає секретів. Див. як зберігати ключі API в безпеці.
3. Перевірте, що проєкт запускається зі свіжої копії — попросіть ШІ написати кроки налаштування.

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

Якщо Git для вас новий, як користуватися Git із застосунком, створеним ШІ описує основи.

Крок 2: напишіть короткий бриф на одну сторінку

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

• Що робить застосунок, для кого і скільки людей ним користуються.
• Що найважливіше — потоки, які ніколи не повинні ламатися.
• Відомі проблеми і те, що ви вже пробували.
• Завдання та те, як ви зрозумієте, що його виконано.
• Обмеження: бюджет, терміни, речі, які не можна змінювати.

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

Крок 3: безпечно надайте доступ

• Код: додайте розробника як співавтора до репозиторію. Не пересилайте ZIP-архіви туди-сюди, щойно почалася робота.
• Конструктор: якщо ваш конструктор ШІ підтримує членів команди, запросіть розробника в робочий простір, який містить лише цей проєкт.
• Секрети: додайте їх у налаштування хостингу або передайте через менеджер паролів. Ніколи не вставляйте ключі в електронні листи чи чат.
• Тестові акаунти: створіть їх із тестовими даними замість того, щоб ділитися своїм входом.
• Продакшн-дані: лише якщо це справді потрібно, і лише те, що необхідно.

Тримайте репозиторій, домен і облікові записи хостингу на своє ім'я. Додавайте людей, а не передавайте акаунти.

Крок 4: домовтеся, хто що змінює

Найбільше тертя виникає, коли двоє — ви з ШІ та розробник — змінюють той самий код одночасно. Оберіть правило:

Що б ви не обрали: оновлюйте код перед кожною сесією запитів і виконуйте великі зміни в гілках, які інша людина може переглянути.

Крок 5: спілкуйтеся письмово

• Описуйте проблеми з кроками, очікуваним і фактичним результатом. Див. як написати хороший звіт про помилку.
• Зберігайте рішення в одному місці: трекер завдань, спільний документ або коментарі до pull request.
• Просіть пояснювати зміни простою мовою в кожному pull request.
• Домовтеся, як часто ви будете звітувати одне одному.

Крок 6: перевіряйте їхню роботу

Щоб перевірити роботу, не обов'язково читати код. Перевірте:

• Чи вона відповідає брифу, у попередньому перегляді або тестовій копії.
• Чи нічого іншого не зламалося — пройдіть ваші критичні потоки.
• Чи вони пояснили, що змінили і чому.
• Чи немає секретів у коді.

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

Крок 7: тримайте право власності чітким

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

Приклади запитів

Розробник змінив код оплати в останньому pull. Поясни простою мовою, що він змінив і чи залежить від цього щось інше в застосунку.

Перелічи частини цього застосунку, які найскладніші або найризикованіші, щоб я міг сказати розробнику, на чому зосередити перевірку.

Я передаю платежі розробнику. Відтепер не чіпай жодні файли в src/payments або маршрути /api/billing. Якщо зміна їх потребує, скажи мені, а не змінюй.

Поширені помилки

• Немає брифу. Розробник витрачає оплачувані години на те, щоб відтворити, чого ви хотіли.
• Розпливчастий обсяг, як-от «виправ помилки» або «зроби готовим до продакшену».
• Редагування обома сторонами без оновлення, а потім втрата роботи через конфлікти.
• Передача власного входу або вставка ключів у чат.
• Облікові записи на ім'я розробника, через що важко розірвати співпрацю.
• Забути видалити доступ і замінити ключі після завершення роботи.

Чекліст

• Код знаходиться в приватному репозиторії на моє ім'я, без секретів.
• README пояснює налаштування; короткий бриф на одну сторінку пояснює застосунок і завдання.
• Завдання має перевірюване визначення завершеності.
• Доступ надано через запрошення співавторів, секрети — через налаштування або менеджер паролів.
• Ми домовилися, хто що змінює, і я оновлюю код перед запитами.
• Роботу перевіряють за брифом і критичними потоками.
• Право власності закріплено письмово; після завершення роботи доступ видалено, а ключі замінено.

Робота з розробником у Mythex

• Запросіть його в робочий простір. Власники можуть запрошувати необмежену кількість співавторів без плати за місце; учасники працюють над проєктами робочого простору. Використовуйте окремий робочий простір, щоб вони бачили лише цей проєкт. Кредити за опубліковані застосунки списуються з власника робочого простору. Див. Запрошення.
• Синхронізація з GitHub та експорт (Pro). Під'єднайте репозиторій і надсилайте або отримуйте зміни, або експортуйте проєкт без секретів. Див. GitHub, export, and import.
• Поділіться посиланням на попередній перегляд, щоб показати незавершену роботу людині без облікового запису Mythex; видаліть його, коли закінчите.
• Режим Ask відповідає на питання про код без його зміни — корисно, щоб зрозуміти зміни розробника.

Якщо розробник запускатиме застосунок деінде, див. як експортувати та самостійно розгорнути застосунок, створений ШІ.

Запитання