Slik samarbeider du med en utvikler om en KI-bygget app

For å samarbeide godt med en utvikler om en app du har bygget med KI, gi dem koden i et Git-repositorium, en oppsummering på én side av hva appen gjør og hvorfor, og en tydelig avgrenset oppgave med en definisjon av ferdig. Bli enige om hvem som endrer hvilke deler, slik at du og KI-en ikke overskriver arbeidet deres. Behold repositoriet og hosting-kontoene i ditt navn, og del hemmeligheter via riktige innstillinger i stedet for i meldinger.

Mange lager den første versjonen av en app med KI og henter inn en utvikler senere, for å legge til betalinger, fikse noe KI-en stadig gjør feil, gjennomgå sikkerheten eller ta over når appen vokser. Hvis du fortsatt vurderer om du i det hele tatt skal ansette noen, se ansette en utvikler eller bygge med KI. Denne guiden forutsetter at du har bestemt deg, og vil at samarbeidet skal gå smidig.

Når en utvikler er verdt det

Vanlige grunner til å hente inn noen:

• Et problem KI-en ikke klarer etter flere tydelige forsøk og tilbakerullinger.
• Risikable områder: betalinger, tillatelser, sensitive data, databasemigreringer.
• En sikkerhets- eller kodegjennomgang før lansering eller før du tar på deg større kunder.
• Ytelse når det kommer ekte trafikk.
• Vekst: appen har blitt en virksomhet, og trenger noen som eier koden.

Å være tydelig på hvilken av disse det gjelder, former alt det som følger.

Steg 1: Få koden på et sted der den kan deles

Utviklere jobber fra Git-repositorier. Før du tar kontakt med noen:

1. Koble prosjektet til et privat repositorium på GitHub (eller tilsvarende), eller eksporter det.
2. Sørg for at ingen hemmeligheter ligger i koden eller historikken. Se slik holder du API-nøkler trygge.
3. Sjekk at prosjektet kjører fra en fersk kopi. Be KI-en skrive oppsettstegene.

Skriv en README for en utvikler som blir med i dette prosjektet: hva appen gjør, stacken, hvordan man installerer og kjører den lokalt, miljøvariablene den trenger (kun navn), mappestrukturen og alt som er skjørt eller uvanlig.

Hvis Git er nytt for deg, dekker slik bruker du Git med en KI-bygget app det grunnleggende.

Steg 2: Skriv en oppsummering på én side

Utvikleren har ikke vært med på hele chatloggen din. Gi dem konteksten på én side:

• Hva appen gjør, for hvem, og hvor mange som bruker den.
• Hva som betyr mest: flytene som aldri må gå i stykker.
• Kjente problemer og hva du allerede har prøvd.
• Oppgaven, og hvordan du vet at den er ferdig.
• Begrensninger: budsjett, frist og ting de ikke skal endre.

En god «definisjon av ferdig» kan testes: «En innlogget bruker kan betale for et månedlig abonnement med Stripe Checkout, abonnementet vises på kontosiden deres, og å si opp i kundeportalen nedgraderer dem ved slutten av perioden.» Ikke «fiks betalinger».

Steg 3: Gi tilgang på en trygg måte

• Kode: legg dem til som samarbeidspartner i repositoriet. Ikke send ZIP-filer frem og tilbake når arbeidet har startet.
• Byggeverktøy: hvis KI-appbyggeren din støtter teammedlemmer, inviter dem til et arbeidsområde som bare inneholder dette prosjektet.
• Hemmeligheter: legg dem inn i innstillingene til hosting-tjenesten, eller del via en passordbehandler. Lim aldri inn nøkler i e-post eller chat.
• Testkontoer: opprett dem med testdata, i stedet for å dele din egen innlogging.
• Produksjonsdata: bare hvis de virkelig trenger det, og bare det de trenger.

Behold repositoriet, domenet og hosting-kontoene i ditt navn. Legg til personer, ikke overlat kontoer.

Steg 4: Bli enige om hvem som endrer hva

Den største kilden til friksjon er at to parter, du med en KI og utvikleren, endrer den samme koden samtidig. Velg en regel:

Uansett hva du velger: hent den nyeste koden før hver promptøkt, og gjør store endringer på grener som den andre personen kan gjennomgå.

Steg 5: Kommuniser skriftlig

• Rapporter problemer med steg, forventet og faktisk resultat. Se slik skriver du en god feilrapport.
• Hold beslutninger på ett sted: en saksliste, et delt dokument eller kommentarer i pull requests.
• Be dem forklare endringene med enkle ord i hver pull request.
• Bli enige om hvor ofte dere skal sjekke inn.

Steg 6: Gjennomgå arbeidet deres

Du trenger ikke å lese kode for å gjennomgå arbeid. Sjekk:

• At det gjør det oppgaven beskrev, i forhåndsvisningen eller stagingkopien.
• At ingenting annet gikk i stykker: kjør de kritiske flytene dine.
• At de forklarte hva de endret og hvorfor.
• At ingen hemmeligheter havnet i koden.

For en grundigere gjennomgang har slik gjennomgår du KI-generert kode en sjekkliste som også fungerer for kode skrevet av mennesker. Du kan også be KI-byggeren din forklare en utviklers pull request med enkle ord.

Steg 7: Hold eierskapet tydelig

• Repositoriet, hosting, domenet og tredjepartskontoene forblir dine.
• Få eierskapet til koden de skriver nedfelt skriftlig før arbeidet starter. Sjekk lokale regler eller en rådgiver for kontraktsspørsmål.
• Når arbeidet er over, fjern tilgangen deres og bytt ut eventuelle nøkler de har sett.

Eksempelprompter

En utvikler endret checkout-koden i den siste pull requesten. Forklar med enkle ord hva de endret, og om noe annet i appen avhenger av det.

List opp de delene av appen som er mest komplekse eller risikable, slik at jeg kan si til en utvikler hvor de skal fokusere gjennomgangen.

Jeg overleverer betalinger til en utvikler. Ikke rør noen filer under src/payments eller /api/billing-rutene fra nå av. Hvis en endring krever dem, si fra til meg i stedet.

Vanlige feil

• Ingen oppsummering. Utvikleren bruker betalte timer på å finne ut hva du ønsket.
• Vag avgrensning, som «fiks feilene» eller «gjør den klar for produksjon».
• Begge redigerer samtidig uten å hente først, og så mister man arbeid i konflikter.
• Å dele din egen innlogging eller lime inn nøkler i chat.
• Kontoer i utviklerens navn, noe som gjør det vanskelig å skille lag.
• Å glemme å fjerne tilgang og bytte ut nøkler etter oppdraget.

Sjekkliste

• Koden ligger i et privat repositorium i mitt navn, uten hemmeligheter.
• En README forklarer oppsettet, og en oppsummering på én side forklarer appen og oppgaven.
• Oppgaven har en definisjon av ferdig som kan testes.
• Tilgang gis via invitasjoner til samarbeidspartnere, hemmeligheter via innstillinger eller en passordbehandler.
• Vi er enige om hvem som endrer hva, og jeg henter før jeg prompter.
• Arbeidet gjennomgås mot oppsummeringen og de kritiske flytene.
• Eierskapet er skriftlig, og tilgang fjernes og nøkler byttes når arbeidet er over.

Samarbeid med en utvikler på Mythex

• Inviter dem til et arbeidsområde. Eiere kan invitere ubegrenset med samarbeidspartnere uten kostnad per plass, og medlemmer jobber i arbeidsområdets prosjekter. Bruk et eget arbeidsområde slik at de bare ser dette prosjektet. Kreditt for publiserte apper belastes eieren av arbeidsområdet. Se Invitasjoner.
• GitHub-synkronisering og eksport (Pro). Koble til et repositorium og push/pull, eller eksporter prosjektet med hemmelighetene utelatt. Se GitHub, eksport og import.
• Del en forhåndsvisningslenke for å vise pågående arbeid til noen uten Mythex-konto, og slett den når du er ferdig.
• Spørremodus svarer på spørsmål om koden uten å endre den. Nyttig for å forstå en utviklers endringer.

Hvis utvikleren skal kjøre appen et annet sted, se slik eksporterer og selv-hoster du en KI-bygget app.

Spørsmål