Hogyan dolgozz fejlesztővel AI-val épített appon

Ahhoz, hogy jól dolgozz egy fejlesztővel az AI-val épített appodon, adj neki a kódot egy Git-tárolóban, egyoldalas összefoglalót arról, mit csinál az app és miért, valamint egyértelműen behatárolt feladatot a kész állapot meghatározásával. Egyeztessétek, ki melyik részt módosítja, hogy te és az AI ne írjátok felül a munkáját, a tárolót és a hosztolási fiókokat a te nevedön tartsd, a titkokat pedig a megfelelő beállításokon keresztül oszd meg, nem üzenetben.

Sokan AI-val építik meg az app első verzióját, majd fejlesztőt hívnak be – fizetések hozzáadásához, egy hiba javításához, amelyet az AI újra meg újra elront, biztonsági átnézéshez, vagy azért, mert az app nőttével valakinek át kell vennie. Ha még nem döntötted el, hogy kell-e fejlesztőt fogadnod, nézd meg: fogadj fejlesztőt, vagy építs AI-val. Ez az útmutató feltételezi, hogy már döntöttél, és azt szeretnéd, hogy az együttműködés zökkenőmentes legyen.

Mikor éri meg fejlesztőt bevonni

Gyakori okok, amiért valakit bevonsz:

• Olyan probléma, amelyet az AI nem old meg, több világos próbálkozás és visszaállítás után.
• Kockázatos területek: fizetések, jogosultságok, érzékeny adatok, adatbázis-migrációk.
• Biztonsági vagy kódátnézés indítás előtt, vagy nagyobb ügyfelek vállalása előtt.
• Teljesítmény, amint valódi forgalom érkezik.
• Növekedés: az app vállalkozássá vált, és valakinek a kódért felelősnek kell lennie.

Az, hogy tisztán látod, melyik esetről van szó, meghatározza mindent, ami alább következik.

1. lépés: Tedd a kódot megosztható helyre

A fejlesztők Git-tárolókból dolgoznak. Mielőtt bárkihez fordulnál:

1. Kösd a projektet egy privát GitHub- (vagy hasonló) tárolóhoz, vagy exportáld.
2. Győződj meg róla, hogy nincs titok a kódban vagy az előzményekben. Lásd: hogyan őrizd biztonságban az API-kulcsaidat.
3. Ellenőrizd, hogy a projekt friss másolatból is fut-e – kérd meg az AI-t, hogy írja le a beállítás lépéseit.

Írj egy README-t egy új fejlesztőnek, aki csatlakozik ehhez a projekthez: mit csinál az app, milyen technológiai alapon készült, hogyan telepítse és futtassa helyben, milyen környezeti változókra van szüksége (csak a nevek), a mappaszerkezet, és minden törékeny vagy szokatlan dolog.

Ha a Git új neked, a hogyan használd a Gitet AI-val épített appnál útmutató elmondja az alapokat.

2. lépés: Írj egyoldalas összefoglalót

A fejlesztő nem ült végig a csevegési előzményeidet. Egy oldalon add meg neki a kontextust:

• Mit csinál az app, kinek, és hány ember használja.
• Mi a legfontosabb – azok a folyamatok, amelyeknek soha nem szabad elromlaniuk.
• Ismert problémák és az, amit már kipróbáltál.
• A feladat, és az, hogyan fogod tudni, hogy kész.
• Korlátok: költségvetés, határidő, amit nem szabad megváltoztatni.

A jó „kész” meghatározás ellenőrizhető: „Egy bejelentkezett felhasználó havi csomagot tud fizetni a Stripe Checkouttal, a csomag megjelenik a fiókoldalán, és az ügyfélportálon történő lemondás a periódus végén visszaminősíti.” Nem pedig az, hogy „intézd el a fizetéseket”.

3. lépés: Adj hozzáférést biztonságosan

• Kód: add munkatársként a tárolóhoz. Miután a munka elkezdődött, ne küldözgess ZIP-fájlokat.
• Builder: ha az AI app-építőd támogatja a csapattagokat, hívd meg egy olyan munkaterületre, amely csak ezt a projektet tartalmazza.
• Titkok: add meg őket a hosztolód beállításaiban, vagy oszd meg jelszókezelőn keresztül. Soha ne illessz be kulcsokat e-mailbe vagy csevegésbe.
• Teszt-fiókok: teszt adatokkal hozz létre fiókokat, ahelyett hogy a saját belépésedet adnád meg.
• Éles adatok: csak akkor, ha valóban szükségük van rájuk, és csak azt, amire szükségük van.

A tárolót, a domaint és a hosztolási fiókokat a te nevedön tartsd. Embereket adj hozzá; fiókokat ne adj át.

4. lépés: Egyeztessétek, ki mit változtat

A legnagyobb súrlódást az okozza, ha két fél – te az AI-val és a fejlesztő – ugyanabban az időben változtatja ugyanazt a kódot. Válassz egy szabályt:

Bármelyiket választod: minden promptolási alkalom előtt húzd le a legfrissebb kódot, a nagy változtatásokat pedig olyan ágakon végezzétek, amelyeket a másik fél átnézhet.

5. lépés: Kommunikálj írásban

• A problémákat lépésekkel, a várt és a tényleges eredménnyel jelentsd. Lásd: hogyan írj jó hibajelentést.
• A döntéseket egy helyen tartsd: egy hibakövető rendszerben, egy közös dokumentumban vagy a pull request-ek kommentjeiben.
• Kérd meg őket, hogy minden pull requestben egyszerű nyelven magyarázzák el a változtatásokat.
• Egyezzetek meg, milyen gyakran egyeztettek.

6. lépés: Nézd át a munkájukat

A munka átnézéséhez nem kell kódot olvasnod. Ellenőrizd:

• Azt csinálja-e, amit az összefoglaló kért, az előnézeten vagy a staging-másolaton.
• Nem romlott-e el semmi más – futtasd le a kritikus folyamataidat.
• Elmagyarázták-e, mit változtattak és miért.
• Nem került-e titok a kódba.

Közelebbi vizsgálathoz a hogyan nézd át az AI által generált kódot útmutató ellenőrzőlistát ad, amely emberek által írt kódra is működik. Kérheted azt is, hogy az AI-építőd egyszerű szavakkal magyarázza el a fejlesztő pull requestjét.

7. lépés: Tartsd tisztán a tulajdonjogot

• A tároló, a hosztolás, a domain és a harmadik fél fiókjai a tieid maradnak.
• A munka tulajdonjogát, amelyet ők írnak, még a munka kezdete előtt rögzítsd írásban. A szerződéses kérdéseknél nézd meg a helyi szabályokat, vagy kérj tanácsot szakértőtől.
• Amikor a munka véget ér, vond vissza a hozzáférésüket, és cseréld le azokat a kulcsokat, amelyeket láttak.

Példa promptok

A fejlesztő az utolsó pull requestben módosította a fizetési kódot. Egyszerű nyelven magyarázd el, mit változtatott, és hogy függ-e tőle az appban bármi más.

Sorold fel az app legösszetettebb vagy legkockázatosabb részeit, hogy meg tudjam mondani a fejlesztőnek, hol érdemes elmélyedni az átnézésben.

A fizetéseket átadom egy fejlesztőnek. Mostantól ne nyúlj a src/payments alatti fájlokhoz vagy a /api/billing útvonalakhoz. Ha egy változtatáshoz szükség van rájuk, inkább szólj nekem.

Gyakori hibák

• Nincs összefoglaló. A fejlesztő fizetett órákat tölt azzal, hogy visszafejtse, mit szerettél volna.
• Homályos terjedelem, például „javítsd a hibákat” vagy „tedd élesítésre késznek”.
• Mindketten egyszerre szerkesztenek húzás nélkül, majd konfliktusokban elvész a munka.
• A saját belépés megosztása vagy kulcsok beillesztése a csevegésbe.
• Fiókok a fejlesztő nevén, ami megnehezíti a szétválást.
• Elfelejteni visszavonni a hozzáférést és lecserélni a kulcsokat a munka végén.

Ellenőrzőlista

• A kód egy privát tárolóban van, az én nevemen, titok nélkül.
• Egy README magyarázza a beállítást; egy egyoldalas összefoglaló írja le az appot és a feladatot.
• A feladatnak van ellenőrizhető „kész” meghatározása.
• A hozzáférés munkatárs-meghívókon, a titkok a beállításokon vagy jelszókezelőn keresztül mennek.
• Megegyeztünk, ki mit változtat, és promptolás előtt húzok.
• A munkát az összefoglaló és a kritikus folyamatok alapján nézem át.
• A tulajdonjog írásban van; a munka végén a hozzáférés visszavonva, a kulcsok lecserélve.

Együttműködés a Mythexszel

• Hívd meg őket egy munkaterületre. A tulajdonosok korlátlan számú munkatársat hívhatnak meg, ülésenkénti díj nélkül; a tagok a munkaterület projektjein dolgoznak. Használj külön munkaterületet, hogy csak ezt a projektet lássák. A közzétett appok kreditjeit a munkaterület tulajdonosa fizeti. Lásd: Meghívók.
• GitHub-szinkronizálás és exportálás (Pro). Kösz össze egy tárolót és húzz/tölts fel, vagy exportáld a projektet úgy, hogy a titkok kimaradnak. Lásd: GitHub, exportálás és importálás.
• Megosztott előnézeti link, hogy folyamatban lévő munkát mutass valakinek Mythex-fiók nélkül; ha végeztél, töröld.
• Ask mode válaszol a kóddal kapcsolatos kérdésekre anélkül, hogy megváltoztatná – hasznos a fejlesztő változtatásainak megértéséhez.

Ha a fejlesztő máshol futtatja majd az appot, lásd: hogyan exportáld és futtasd saját szerveren az AI-val épített appot.

Kérdések