Sådan arbejder du med en udvikler på en app bygget med AI

For at arbejde godt med en udvikler på en app, du har bygget med AI, skal du give dem koden i et Git-repository, en opsummering på én side af hvad appen gør og hvorfor, og en tydeligt afgrænset opgave med en definition af færdig. Aftal hvem der ændrer hvilke dele, så du og AI'en ikke overskriver deres arbejde, hold repositoryet og hosting-kontoerne i dit navn, og del hemmeligheder via ordentlige indstillinger frem for beskeder.

Mange bygger første version af en app med AI og henter derefter en udvikler ind — for at tilføje betalinger, rette noget AI'en konsekvent får galt, gennemgå sikkerheden eller overtage, når appen vokser. Hvis du stadig overvejer, om du overhovedet skal ansætte, se ansæt en udvikler eller byg med AI. Denne guide forudsætter, at du har besluttet dig, og gerne vil have samarbejdet til at fungere gnidningsfrit.

Hvornår en udvikler er det værd

Almindelige grunde til at hente en person ind:

• Et problem AI'en ikke kan knække efter flere klare forsøg og tilbagerulninger.
• Risikable områder: betalinger, tilladelser, følsomme data, databasemigreringer.
• En sikkerheds- eller kodegennemgang før lancering eller før du tager større kunder.
• Ydeevne når rigtig trafik kommer.
• Vækst: appen er blevet en forretning og har brug for en person, der ejer koden.

At være klar over, hvilken af disse det er, former alt nedenfor.

Trin 1: Få koden et sted, den kan deles

Udviklere arbejder ud fra Git-repositories. Før du kontakter nogen:

1. Forbind projektet til et privat GitHub-repository (eller lignende), eller eksportér det.
2. Sørg for at ingen hemmeligheder er i koden eller historikken. Se sådan holder du API-nøgler sikre.
3. Tjek at projektet kører fra en frisk kopi — bed AI'en om at skrive opsætningstrinene.

Skriv en README til en udvikler, der kommer ind i dette projekt: hvad appen gør, stakken, hvordan man installerer og kører den lokalt, de miljøvariabler den kræver (kun navne), mappestrukturen og alt skrøbeligt eller usædvanligt.

Hvis Git er nyt for dig, dækker sådan bruger du Git med en app bygget med AI det grundlæggende.

Trin 2: Skriv et brief på én side

Udvikleren sad ikke med i din chathistorik. Giv dem konteksten på én side:

• Hvad appen gør, for hvem, og hvor mange der bruger den.
• Hvad der betyder mest — de flows, der aldrig må gå i stykker.
• Kendte problemer og hvad du allerede har prøvet.
• Opgaven, og hvordan du ved, at den er færdig.
• Begrænsninger: budget, deadline, ting de ikke må ændre.

En god „definition af færdig“ er testbar: „En logget ind bruger kan betale for en månedlig plan med Stripe Checkout, planen vises på deres kontoside, og hvis de opsiger i kundeportalen, nedgraderes de ved periodens udløb.“ Ikke „ordn betalingerne“.

Trin 3: Giv adgang på en sikker måde

• Kode: tilføj dem som medarbejder på repositoryet. Send ikke ZIP-filer frem og tilbage, når arbejdet er i gang.
• Byggeværktøj: hvis din AI-appbygger understøtter teammedlemmer, så inviter dem til et workspace, der kun indeholder dette projekt.
• Hemmeligheder: tilføj dem i din hosts indstillinger, eller del via en adgangskodeadministrator. Indsæt aldrig nøgler i e-mail eller chat.
• Testkonti: opret dem med testdata, i stedet for at dele din egen login.
• Produktionsdata: kun hvis de virkelig har brug for det, og kun det de har brug for.

Hold repositoryet, domænet og hosting-kontoerne i dit navn. Tilføj personer; overdrag ikke konti.

Trin 4: Aftal hvem der ændrer hvad

Den største kilde til gnidninger er, at to parter — dig med en AI, og udvikleren — ændrer den samme kode på samme tid. Vælg en regel:

Uanset hvad du vælger: tag det seneste kodeudtræk før hver promptsession, og lav store ændringer på branches, den anden person kan gennemgå.

Trin 5: Kommuniker skriftligt

• Rapportér problemer med trin, forventet og faktisk resultat. Se sådan skriver du en god fejlrapport.
• Hold beslutninger ét sted: et sporingsværktøj, et fælles dokument eller kommentarer på pull requests.
• Bed dem forklare ændringer i almindeligt sprog i hver pull request.
• Aftal hvor ofte I tjekker ind.

Trin 6: Gennemgå deres arbejde

Du behøver ikke læse kode for at gennemgå arbejde. Tjek:

• At det gør det, briefet sagde, i forhåndsvisningen eller staging-kopien.
• At intet andet gik i stykker — kør dine kritiske flows.
• At de forklarede hvad de har ændret og hvorfor.
• At der ikke er dukket hemmeligheder op i koden.

Til et tættere kig, har sådan gennemgår du AI-genereret kode en tjekliste, der også virker til menneskeskrevet kode. Du kan også bede din AI-byggeværktøj forklare en udviklers pull request for dig med almindelige ord.

Trin 7: Hold ejerskabet klart

• Repositoryet, hosting, domænet og tredjepartskonti forbliver dine.
• Få ejerskabet af den kode, de skriver, skriftligt, før arbejdet starter. Tjek lokale regler eller en rådgiver for kontraktspørgsmål.
• Når arbejdet er slut, fjern deres adgang og skift alle nøgler, de har set.

Eksempelprompts

En udvikler ændrede checkout-koden i den seneste pull. Forklar med almindelige ord hvad de ændrede, og om andet i appen afhænger af det.

List de dele af denne app, der er mest komplekse eller risikable, så jeg kan fortælle en udvikler, hvor de skal fokusere en gennemgang.

Jeg overdrager betalinger til en udvikler. Rør ikke ved filer under src/payments eller /api/billing-rutene herfra. Hvis en ændring kræver dem, så fortæl mig det i stedet.

Almindelige fejl

• Intet brief. Udvikleren bruger betalte timer på at gætte, hvad du ville have.
• Vag afgrænsning som „ret fejlene“ eller „gør den klar til produktion“.
• At begge redigerer samtidig uden at tage pull først, og så mister arbejde i konflikter.
• At dele din egen login eller indsætte nøgler i chat.
• Konti i udviklerens navn, hvilket gør det svært at skilles.
• At glemme at fjerne adgang og skifte nøgler efter opgaven.

Tjekliste

• Koden ligger i et privat repository i mit navn, uden hemmeligheder i.
• En README forklarer opsætningen; et brief på én side forklarer appen og opgaven.
• Opgaven har en testbar definition af færdig.
• Adgang gives via medarbejderinvitationer, hemmeligheder via indstillinger eller en adgangskodeadministrator.
• Vi har aftalt hvem der ændrer hvad, og jeg tager pull før jeg prompter.
• Arbejdet gennemgås mod briefet og de kritiske flows.
• Ejerskabet er skriftligt; adgang fjernes og nøgler skiftes, når arbejdet slutter.

At arbejde med en udvikler på Mythex

• Inviter dem til et workspace. Ejere kan invitere ubegrænset med medarbejdere uden pris pr. plads; medlemmer arbejder på workspace'ets projekter. Brug et separat workspace, så de kun ser dette projekt. Kredit til publicerede apps faktureres workspace-ejeren. Se Invitationer.
• GitHub-synkronisering og eksport (Pro). Forbind et repository og push/pull, eller eksportér projektet med hemmeligheder udeladt. Se GitHub, eksport og import.
• Del et forhåndsvisningslink for at vise arbejde i fremdrift til en person uden Mythex-konto; slet det, når du er færdig.
• Spørg-tilstand besvarer spørgsmål om koden uden at ændre den — nyttigt til at forstå en udviklers ændringer.

Hvis udvikleren vil køre appen et andet sted, se sådan eksporterer og self-hoster du en app bygget med AI.

Spørgsmål