Как да работите с разработчик по приложение, създадено с ИИ

За да работите добре с разработчик по приложение, създадено с ИИ, му дайте кода в 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, експорт и импорт.
• Споделете линк за преглед, за да покажете работа в процес на някого без акаунт в Mythex; изтрийте го, когато приключите.
• Режимът за въпроси отговаря на въпроси за кода, без да го променя — полезен за разбиране на промените на разработчика.

Ако разработчикът ще пуска приложението някъде другаде, вижте как да експортирате и хоствате сами приложение, създадено с ИИ.

Въпроси