Si të punosh me një zhvillues mbi një aplikacion të ndërtuar me AI

Për të punuar mirë me një zhvillues mbi një aplikacion të ndërtuar me AI, jepi kodin në një depo Git, një përmbledhje të një faqeje për atë që bën aplikacioni dhe pse, dhe një detyrë të qartë të kufizuar me një përkufizim të përfundimit. Bini dakord kush ndryshon cilat pjesë, që ti dhe AI të mos e mbishkruani punën e tij, mbaj depon dhe llogaritë e hostimit me emrin tënd, dhe ndaj sekretet përmes cilësimeve të duhura, jo përmes mesazheve.

Shumë njerëz e ndërtojnë versionin e parë të një aplikacioni me AI, dhe pastaj sjellin një zhvillues — për të shtuar pagesa, për të rregulluar diçka që AI vazhdon ta bëjë keq, për të kontrolluar sigurinë, ose për ta marrë përsipër ndërsa aplikacioni rritet. Nëse akoma po vendos nëse do të punësosh fare, shih punëso një zhvillues ose ndërto me AI. Ky udhëzues supozon që ke vendosur dhe dëshiron që bashkëpunimi të shkojë mirë.

Kur ia vlen një zhvillues

Arsyet e zakonshme për ta sjellë dikë:

• Një problem që AI nuk e zgjidh pas disa përpjekjeve të qarta dhe rikthimeve.
• Zona të rrezikshme: pagesa, leje, të dhëna të ndjeshme, migrime të bazës së të dhënave.
• Një kontroll sigurie ose kodi përpara lansimit ose përpara se të marrësh klientë më të mëdhenj.
• Performanca kur të arrijë trafiku real.
• Rritja: aplikacioni është bërë biznes dhe ka nevojë për dikë që e zotëron kodin.

Të jesh i qartë për cilin prej këtyre është, formëson gjithçka më poshtë.

Hapi 1: Vendos kodin në një vend të ndarshëm

Zhvilluesit punojnë nga depo Git. Përpara se të kontaktosh dikë:

1. Lidh projektin me një depo private në GitHub (ose të ngjashme), ose eksportoje.
2. Sigurohu që asnjë sekret nuk është në kod ose në histori. Shih si t'i mbash çelësat API të sigurt.
3. Kontrollo që projekti funksionon nga një kopje e re — kërko nga AI të shkruajë hapat e konfigurimit.

Shkruaj një README për një zhvillues që bashkohet me këtë projekt: çfarë bën aplikacioni, stack-u, si instalohet dhe ekzekutohet lokalisht, variablat e mjedisit që i duhen (vetëm emrat), struktura e folderëve, dhe çdo gjë delikate ose e pazakontë.

Nëse Git është i ri për ty, si të përdorësh Git me një aplikacion të ndërtuar me AI mbulon bazat.

Hapi 2: Shkruaj një përmbledhje të një faqeje

Zhvilluesi nuk e ka ndjekur historikun e bisedës tënde. Jepi kontekstin në një faqe:

• Çfarë bën aplikacioni, për kë, dhe sa persona e përdorin.
• Çfarë ka më shumë rëndësi — rrjedhat që nuk duhet kurrë të prishen.
• Problemet e njohura dhe çfarë ke provuar tashmë.
• Detyra, dhe si do ta dish që është përfunduar.
• Kufizimet: buxheti, afati, gjërat që nuk duhet t'i ndryshojë.

Një "përkufizim i mirë i përfundimit" është i testueshëm: "Një përdorues i kyçur mund të paguajë për një plan mujor me Stripe Checkout, plani shfaqet në faqen e llogarisë së tij, dhe anulimi në portalin e klientit e zbret planin në fund të periudhës." Jo "rregullo pagesat".

Hapi 3: Jep akses në mënyrë të sigurt

• Kodi: shtoje si bashkëpunëtor në depo. Mos dërgo skedarë ZIP përpara e mbrapa pasi puna të ketë filluar.
• Builder-i: nëse builder-i yt AI mbështet anëtarë ekipi, fto në një hapësirë pune që përmban vetëm këtë projekt.
• Sekretet: shtoi në cilësimet e hostit tënd, ose ndaji përmes një menaxheri fjalëkalimesh. Kurrë mos ngjit çelësa në email ose bisedë.
• Llogaritë e testimit: krijoji me të dhëna testimi, në vend që të ndash hyrjen tënde.
• Të dhënat e prodhimit: vetëm nëse i duhen vërtet, dhe vetëm ato që u duhen.

Mbaj depon, domain-in dhe llogaritë e hostimit me emrin tënd. Shto njerëz; mos u jep llogari.

Hapi 4: Bini dakord kush ndryshon çfarë

Burimi më i madh i fërkimit është kur dy palë — ti me një AI, dhe zhvilluesi — ndryshojnë të njëjtin kod në të njëjtën kohë. Zgjidh një rregull:

Çfarëdo që zgjedhësh: bëj pull të kodit më të fundit përpara çdo sesioni kërkesash, dhe bëj ndryshimet e mëdha në degë që personi tjetër mund t'i shqyrtojë.

Hapi 5: Komuniko me shkrim

• Raporto problemet me hapa, rezultatin e pritur dhe atë aktual. Shih si të shkruash një raport të mirë gabimi.
• Mbaj vendimet në një vend: një gjurmues çështjesh, një dokument të përbashkët, ose komentet e pull request-eve.
• Kërkoji që të shpjegojë ndryshimet me gjuhë të thjeshtë në çdo pull request.
• Bini dakord sa shpesh do të kontrolloheni.

Hapi 6: Shqyrto punën e tij

Nuk të duhet të lexosh kod për të shqyrtuar punën. Kontrollo:

• Bën atë që thoshte përmbledhja, në preview ose kopjen e stacionimit.
• Asgjë tjetër nuk u prish — provo rrjedhat e tua kritike.
• Shpjegoi çfarë ndryshoi dhe pse.
• Asnjë sekret nuk u shfaq në kod.

Për një vështrim më të afërt, si të shqyrtosh kodin e gjeneruar nga AI ka një listë kontrolli që funksionon edhe për kodin e shkruar nga njerëz. Mund t'i kërkosh edhe builder-it AI të të shpjegojë pull request-in e zhvilluesit me terma të thjeshtë.

Hapi 7: Mbaj pronësinë të qartë

• Depoja, hostimi, domain-i dhe llogaritë e palëve të treta mbeten të tuat.
• Vendos me shkrim pronësinë e kodit që shkruan përpara se puna të fillojë. Kontrollo rregullat lokale ose një këshilltar për pyetjet kontraktuale.
• Kur puna të mbarojë, hiq aksesin e tij dhe rrotullo çdo çelës që pa.

Shembuj komandash

Një zhvillues ndryshoi kodin e pagesës në pull-in e fundit. Shpjego me gjuhë të thjeshtë çfarë ndryshoi dhe nëse ka diçka tjetër në aplikacion që varet prej tij.

Listo pjesët e këtij aplikacioni që janë më komplekse ose më të rrezikshme, që t'i tregoj një zhvilluesi ku të fokusojë shqyrtimin.

Po ia jap pagesat një zhvilluesi. Nga tani mos prek asnjë skedar nën src/payments ose rrugët /api/billing. Nëse një ndryshim kërkon t'i prekësh, më thuaj mua në vend të kësaj.

Gabimet e zakonshme

• Pa përmbledhje. Zhvilluesi shpenzon orë të paguara duke rikonstruktuar çfarë donit.
• Fushë e paqartë si "rregullo gabimet" ose "bëje gati për prodhim".
• Të dy duke redaktuar njëkohësisht pa bërë pull së pari, dhe pastaj duke humbur punë në konflikte.
• Ndarja e llogarisë tënde ose ngjitja e çelësave në bisedë.
• Llogari në emër të zhvilluesit, që e bën të vështirë ndarjen e rrugëve.
• Harrimi i heqjes së aksesit dhe rrotullimit të çelësave pas punës.

Lista kontrolluese

• Kodi është në një depo private në emrin tim, pa sekrete brenda.
• Një README shpjegon konfigurimin; një përmbledhje e një faqeje shpjegon aplikacionin dhe detyrën.
• Detyra ka një përkufizim të përfundimit të testueshëm.
• Aksesi jepet me ftesa bashkëpunëtorësh, sekretet përmes cilësimeve ose një menaxheri fjalëkalimesh.
• Jemi pajtuar kush ndryshon çfarë, dhe bëj pull përpara se të kërkoj.
• Puna shqyrtohet sipas përmbledhjes dhe rrjedhave kritike.
• Pronësia është me shkrim; aksesi hiqet dhe çelësat rrotullohen kur puna mbaron.

Punë me një zhvillues në Mythex

• Fto në një hapësirë pune. Pronarët mund të ftojnë bashkëpunëtorë pa limit, pa tarifa për vend; anëtarët punojnë në projektet e hapësirës. Përdor një hapësirë të veçantë që të shohë vetëm këtë projekt. Kreditet për aplikacionet e publikuara i faturohen pronarit të hapësirës. Shih Ftesat.
• Sinkronizimi me GitHub dhe eksportimi (Pro). Lidh një depo dhe bëj push/pull, ose eksporto projektin me sekretet jashtë. Shih GitHub, eksporti dhe importi.
• Ndaj një lidhje preview për të treguar punën në progres te dikush pa llogari Mythex; fshije kur të mbarosh.
• Modaliteti Ask përgjigjet pyetjeve për kodin pa e ndryshuar atë — i dobishëm për të kuptuar ndryshimet e një zhvilluesi.

Nëse zhvilluesi do ta ekzekutojë aplikacionin diku tjetër, shih si të eksportosh dhe vetë-strehosh një aplikacion të ndërtuar me AI.

Pyetje