Kuidas töötada arendajaga AI-ga ehitatud rakenduse kallal

Et arendajaga AI-ga ehitatud rakenduse kallal hästi töötada, anna talle kood Giti hoidlas, üheleheküljeline kokkuvõte sellest, mida rakendus teeb ja miks, ning selgelt piiritletud ülesanne koos valmis-oleku määratlusega. Lepi kokku, kes muudab millist osa, et sina ja AI ei kirjutaks tema tööd üle, hoia hoidla ja hostingu kontod enda nimel ning jaga saladusi korralike seadete kaudu, mitte sõnumitega.

Paljud inimesed ehitavad esimese versiooni rakendusest AI-ga ja kaasavad seejärel arendaja — makseid lisama, mõne asja parandama, mida AI pidevalt valesti teeb, turvalisust üle vaatama või kasvava rakenduse üle võtma. Kui sa alles mõtled, kas arendaja palgata, vaata palka arendaja või ehita AI-ga. See juhend eeldab, et oled otsuse teinud ja tahad, et koostöö sujuks.

Millal arendaja on väärt

Tavalised põhjused, miks kaasata keegi:

• Probleem, mida AI ei suuda lahendada pärast mitut selget katset ja tagasivõtmist.
• Riskantsed valdkonnad: maksed, õigused, tundlikud andmed, andmebaasi migratsioonid.
• Turvalisuse või koodi ülevaatus enne käivitamist või enne suuremate klientide vastuvõtmist.
• Jõudlus, kui päris liiklus saabub.
• Kasv: rakendusest on saanud äri ja see vajab kedagi, kes koodi omab.

Selge arusaam sellest, mis neist see on, kujundab kõike allpool.

Samm 1: too kood jagatavasse kohta

Arendajad töötavad Giti hoidlatest. Enne kellegagi ühendust võtmist:

1. Ühenda projekt privaatse GitHubi (või sarnase) hoidlaga või ekspordi see.
2. Veendu, et koodis ega ajaloos pole saladusi. Vaata kuidas hoida API-võtmeid turvaliselt.
3. Kontrolli, et projekt käivitub värskest koopiast — palu AI-l kirjutada paigaldusjuhised.

Kirjuta arendajale, kes selle projektiga liitub, README: mis rakendus teeb, millist tehnoloogiapinu kasutab, kuidas seda kohalikult paigaldada ja käivitada, millised keskkonnamuutujad vajalikud on (ainult nimed), kaustade struktuur ja kõik, mis on habras või ebatavaline.

Kui Git on sulle uus, käsitleb kuidas kasutada Giti AI-ga ehitatud rakendusega põhitõdesid.

Samm 2: kirjuta üheleheküljeline brief

Arendaja ei istunud sinu vestlusajaloo juures. Anna talle kontekst ühel leheküljel:

• Mida rakendus teeb, kellele ja kui palju inimesi seda kasutab.
• Mis on kõige olulisem — voog, mis ei tohi kunagi katkeda.
• Teadaolevad probleemid ja see, mida oled juba proovinud.
• Ülesanne ja see, kuidas teaksid, et see on tehtud.
• Piirangud: eelarve, tähtaeg, asjad, mida nad ei tohi muuta.

Hea „valmis-oleku määratlus“ on testitav: „Sisse logitud kasutaja saab Stripe Checkouti kaudu maksta kuutasu, plaan ilmub tema konto lehele ja kliendiportaalis tühistamine viib ta perioodi lõpus tasuta tasemele.“ Mitte „korralda maksed“.

Samm 3: anna juurdepääs turvaliselt

• Kood: lisa arendaja hoidla kaasautorina. Ära saada ZIP-faile edasi-tagasi, kui töö on alanud.
• Koostaja: kui sinu AI-rakenduse koostaja toetab meeskonnaliikmeid, kutsu ta töötuppa, mis sisaldab ainult seda projekti.
• Saladused: lisa need hostingu seadetesse või jaga paroolihalduri kaudu. Ära kleebi võtmeid e-kirja ega sõnumisse.
• Testkontod: loo need testandmetega, selle asemel et jagada oma sisselogimist.
• Tootmisandmed: ainult siis, kui neid tõesti vajatakse, ja ainult see, mida vaja on.

Hoia hoidla, domeeni ja hostingu kontod enda nimel. Lisa inimesi; ära anna kontosid üle.

Samm 4: lepi kokku, kes mida muudab

Suurim hõõrumise allikas on see, kui kaks poolt — sina koos AI-ga ja arendaja — muudavad sama koodi samal ajal. Vali reegel:

Mida iganes valid: tõmba enne iga käskimise sessiooni värskeim kood ning tee suured muudatused harudel, mida teine pool saab üle vaadata.

Samm 5: suhtle kirjalikult

• Kirjelda probleeme sammude, oodatud ja tegeliku tulemusega. Vaata kuidas kirjutada head veateadet.
• Hoia otsused ühes kohas: probleemide jälgija, jagatud dokument või pull request'i kommentaarid.
• Palu tal selgitada igas pull request'is muudatusi lihtsas keeles.
• Leppige kokku, kui tihti kontrollite üksteist.

Samm 6: vaata tema töö üle

Töö ülevaatamiseks ei pea koodi lugema. Kontrolli:

• Teeb seda, mida brief ütles, eelvaates või lavakoopias.
• Midagi muud ei katkenud — käivita oma kriitilised voog.
• Ta selgitas, mida ja miks muutis.
• Koodi ei ilmunud saladusi.

Lähema vaate jaoks vaata kuidas üle vaadata AI-ga genereeritud koodi — kontrollnimekiri sobib ka inimese kirjutatud koodile. Samuti võid paluda oma AI-koostajal selgitada arendaja pull request'i sinu jaoks lihtsates sõnades.

Samm 7: hoia omandiõigus selge

• Hoidla, hosting, domeen ja kolmandate osapoolte kontod jäävad sinu omaks.
• Pane omandiõigus arendaja kirjutatud koodile enne töö algust kirjalikult. Kontrolli kohalikke reegleid või nõustajat lepingu küsimustes.
• Kui töö lõpeb, eemalda tema juurdepääs ja vaheta välja kõik võtmed, mis ta nägi.

Näidisprompti

Arendaja muutis viimases pull request'is ostukorvi koodi. Selgita lihtsas keeles, mida ta muutis, ja kas rakenduse mõni teine osa sõltub sellest.

Loetle selle rakenduse kõige keerukamad või riskantsemad osad, et saaksin arendajale öelda, kuhu ülevaatus suunata.

Ma annan maksed arendajale. Alates praegusest ära puutu faile kaustas src/payments ega marsruute /api/billing. Kui muudatus neid vajab, ütle mulle, selle asemel et teha.

Levinud vead

• Briefi puudumine. Arendaja kulutab tasulisi tunde, et mõista, mida sa tahtsid.
• Ebamäärane ulatus, nagu „paranda vead“ või „tee tootmisvalmis“.
• Mõlemad muudavad korraga, ilma enne tõmbamata, ja kaotatakse töö konfliktides.
• Oma sisselogimise jagamine või võtmete kleepimine vestlusse.
• Kontod arendaja nime peal, mis teeb lahkumise keeruliseks.
• Juurdepääsu eemaldamata jätmine ja võtmete vahetamata jätmine pärast tööd.

Kontrollnimekiri

• Kood on privaatses hoidlas minu nime peal, ilma saladusteta.
• README selgitab paigaldust; üheleheküljeline brief selgitab rakendust ja ülesannet.
• Ülesandel on testitav valmis-oleku määratlus.
• Juurdepääs on antud kaasautori kutse kaudu, saladused seadete või paroolihalduri kaudu.
• Oleme kokku leppinud, kes mida muudab, ja tõmban enne käskimist.
• Tööd vaadatakse üle briefi ja kriitiliste voogude vastu.
• Omandiõigus on kirjas; juurdepääs eemaldatakse ja võtmed vahetatakse, kui töö lõpeb.

Töötamine arendajaga Mythexis

• Kutsu ta töötuppa. Omanikud saavad kutsuda piiramatult kaasautoreid ilma koha-tasuta; liikmed töötavad töötoa projektidega. Kasuta eraldi töötuba, et ta näeks ainult seda projekti. Avaldatud rakenduste krediidid arvestatakse töötoa omanikule. Vaata Kutsed.
• GitHubi sünkroon ja eksport (Pro). Ühenda hoidla ja tee push/pull või ekspordi projekt ilma saladusteta. Vaata GitHub, eksport ja import.
• Jaga eelvaate linki, et näidata töös olevat tööd inimesele, kellel pole Mythexi kontot; kustuta see, kui oled lõpetanud.
• Küsimusrežiim vastab küsimustele koodi kohta ilma seda muutmata — kasulik arendaja muudatuste mõistmiseks.

Kui arendaja käivitab rakendust mujal, vaata kuidas eksportida ja ise majutada AI-ga ehitatud rakendust.

Küsimused