Jak współpracować z programistą nad aplikacją zbudowaną przez AI

Aby dobrze współpracować z programistą nad aplikacją zbudowaną z AI, daj mu kod w repozytorium Git, jednostronicowe podsumowanie tego, co robi aplikacja i dlaczego, oraz jasno zakresowane zadanie z definicją ukończenia. Ustalcie, kto zmienia które części, żeby Ty i AI nie nadpisywaliście jego pracy, trzymaj repozytorium i konta hostingowe na swoje nazwisko, a sekrety przekazuj przez właściwe ustawienia, a nie w wiadomościach.

Wielu ludzi buduje pierwszą wersję aplikacji z AI, a potem zaprasza programistę, żeby dodać płatności, naprawić coś, z czym AI wciąż sobie nie radzi, przejrzeć bezpieczeństwo lub przejąć projekt w miarę jego rozwoju. Jeśli wciąż zastanawiasz się, czy w ogóle zatrudnić programistę, zobacz zatrudnić programistę czy budować z AI. Ten przewodnik zakłada, że już podjąłeś decyzję i chcesz, żeby współpraca przebiegała sprawnie.

Kiedy warto zatrudnić programistę

Najczęstsze powody, by wciągnąć kogoś do projektu:

• Problem, z którym AI nie radzi sobie mimo kilku jasnych prób i cofnięć zmian.
• Ryzykowne obszary: płatności, uprawnienia, wrażliwe dane, migracje bazy danych.
• Przegląd bezpieczeństwa lub kodu przed startem albo przed przyjęciem większych klientów.
• Wydajność, gdy pojawi się prawdziwy ruch.
• Rozwój: aplikacja stała się biznesem i potrzebuje kogoś, kto odpowiada za kod.

Jasne określenie, o który z tych przypadków chodzi, wpływa na wszystko poniżej.

Krok 1: Umieść kod w miejscu, które można udostępnić

Programiści pracują z repozytoriów Git. Zanim skontaktujesz się z kimkolwiek:

1. Połącz projekt z prywatnym repozytorium na GitHubie (lub podobnej usłudze) albo wyeksportuj go.
2. Upewnij się, że w kodzie ani w historii nie ma sekretów. Zobacz jak chronić klucze API.
3. Sprawdź, czy projekt uruchamia się z czystej kopii. Poproś AI o napisanie kroków konfiguracji.

Napisz README dla programisty dołączającego do tego projektu: co robi aplikacja, jaki jest stos technologiczny, jak zainstalować i uruchomić ją lokalnie, jakich zmiennych środowiskowych potrzebuje (same nazwy), jaka jest struktura folderów oraz co jest kruche lub nietypowe.

Jeśli Git jest dla Ciebie nowy, jak używać Gita z aplikacją zbudowaną przez AI omawia podstawy.

Krok 2: Napisz jednostronicowy brief

Programista nie czytał Twojej historii czatu. Przekaż mu kontekst na jednej stronie:

• Co robi aplikacja, dla kogo i ilu ludzi z niej korzysta.
• Co jest najważniejsze, czyli przepływy, które nigdy nie mogą się zepsuć.
• Znane problemy i to, czego już próbowałeś.
• Zadanie oraz to, po czym poznasz, że jest zrobione.
• Ograniczenia: budżet, termin, rzeczy, których nie wolno zmieniać.

Dobra „definicja ukończenia” da się przetestować: „Zalogowany użytkownik może opłacić miesięczny plan przez Stripe Checkout, plan pojawia się na jego stronie konta, a anulowanie w portalu klienta obniża jego plan na koniec okresu rozliczeniowego”. Nie: „ogarnij płatności”.

Krok 3: Bezpiecznie przydzielaj dostęp

• Kod: dodaj go jako współpracownika w repozytorium. Gdy praca się zacznie, nie wysyłaj tam i z powrotem plików ZIP.
• Kreator: jeśli Twój kreator AI obsługuje członków zespołu, zaproś go do przestrzeni roboczej zawierającej tylko ten projekt.
• Sekrety: dodaj je w ustawieniach hostingu albo udostępnij przez menedżer haseł. Nigdy nie wklejaj kluczy do e-maila ani czatu.
• Konta testowe: twórz je z danymi testowymi zamiast udostępniać własne logowanie.
• Dane produkcyjne: tylko wtedy, gdy są naprawdę potrzebne i tylko te, które są potrzebne.

Repozytorium, domenę i konta hostingowe trzymaj na swoje nazwisko. Dodawaj ludzi; nie przekazuj kont.

Krok 4: Ustalcie, kto co zmienia

Najwięcej tarć powstaje, gdy dwie strony, Ty z AI i programista, zmieniają ten sam kod jednocześnie. Wybierz zasadę:

Niezależnie od wyboru: przed każdą sesją poleceń pobieraj najnowszy kod i rób duże zmiany na gałęziach, które druga strona może zrecenzować.

Krok 5: Komunikuj się na piśmie

• Zgłaszaj problemy z krokami, oczekiwanym i rzeczywistym wynikiem. Zobacz jak napisać dobry raport o błędzie.
• Trzymaj decyzje w jednym miejscu: w systemie zgłoszeń, we wspólnym dokumencie lub w komentarzach do pull requestów.
• Poproś o wyjaśnienie zmian prostym językiem w każdym pull requeście.
• Uzgodnijcie, jak często się zsynchronizujecie.

Krok 6: Recenzuj jego pracę

Nie musisz czytać kodu, żeby recenzować pracę. Sprawdź:

• Czy robi to, co opisał brief, na podglądzie lub kopii stagingowej.
• Czy nic innego się nie zepsuło. Przetestuj kluczowe przepływy.
• Czy wyjaśnił, co zmienił i dlaczego.
• Czy w kodzie nie pojawiły się sekrety.

Dla dokładniejszego przeglądu jak recenzować kod wygenerowany przez AI zawiera listę kontrolną, która działa także dla kodu pisanego przez ludzi. Możesz też poprosić swój kreator AI, żeby wyjaśnił Ci pull request programisty prostymi słowami.

Krok 7: Jasno określ własność

• Repozytorium, hosting, domena i konta u dostawców zewnętrznych pozostają Twoje.
• Ustal na piśmie własność kodu, który napisze programista, zanim praca się zacznie. W kwestiach umownych sprawdź lokalne przepisy lub skonsultuj się z doradcą.
• Gdy praca się skończy, odbierz mu dostęp i wymień klucze, które widział.

Przykładowe polecenia

Programista zmienił kod kasy w ostatnim pull requeście. Wyjaśnij prostym językiem, co zmienił i czy coś innego w aplikacji od tego zależy.

Wypisz części tej aplikacji, które są najbardziej złożone lub ryzykowne, żebym mógł wskazać programiście, na czym skupić przegląd.

Przekazuję płatności programistie. Od teraz nie dotykaj plików w src/payments ani tras /api/billing. Jeśli zmiana ich wymaga, najpierw mi o tym powiedz.

Typowe błędy

• Brak briefu. Programista traci płatne godziny na odgadywanie, czego chciałeś.
• Niejasny zakres, np. „napraw błędy” albo „doprowadź do stanu produkcyjnego”.
• Edytowanie przez obie strony naraz bez wcześniejszego pobrania zmian, a potem utrata pracy przez konflikty.
• Udostępnianie własnego logowania albo wklejanie kluczy do czatu.
• Konta na nazwisko programisty, przez co trudno się rozstać.
• Zapominanie o odebraniu dostępu i wymianie kluczy po zakończeniu zlecenia.

Lista kontrolna

• Kod jest w prywatnym repozytorium na moje nazwisko, bez sekretów.
• README wyjaśnia konfigurację; jednostronicowy brief wyjaśnia aplikację i zadanie.
• Zadanie ma testowalną definicję ukończenia.
• Dostęp jest przez zaproszenia współpracowników, sekrety przez ustawienia lub menedżer haseł.
• Ustaliliśmy, kto co zmienia, a ja pobieram zmiany przed poleceniem.
• Praca jest recenzowana względem briefu i kluczowych przepływów.
• Własność jest na piśmie; po zakończeniu pracy dostęp jest odebrany, a klucze wymienione.

Współpraca z programistą w Mythex

• Zaproś go do przestrzeni roboczej. Właściciele mogą zapraszać nieograniczoną liczbę współpracowników bez opłat za miejsce; członkowie pracują nad projektami przestrzeni. Użyj osobnej przestrzeni, żeby widział tylko ten projekt. Kredyty za opublikowane aplikacje są rozliczane na właściciela przestrzeni. Zobacz Zaproszenia.
• Synchronizacja z GitHubem i eksport (Pro). Połącz repozytorium i wysyłaj oraz pobieraj zmiany albo wyeksportuj projekt bez sekretów. Zobacz GitHub, eksport i import.
• Udostępnij link podglądu, aby pokazać postęp pracy osobie bez konta w Mythex; po zakończeniu go usuń.
• Tryb pytań odpowiada na pytania o kod bez jego zmieniania. Przydaje się do zrozumienia zmian programisty.

Jeśli programista będzie uruchamiał aplikację gdzie indziej, zobacz jak wyeksportować aplikację zbudowaną przez AI i uruchomić ją na własnym serwerze.

Pytania