Så arbetar du med en utvecklare på en AI-byggd app

För att arbeta bra med en utvecklare på en app du byggt med AI ger du dem koden i ett Git-förråd, en sammanfattning på en sida om vad appen gör och varför, och en tydligt avgränsad uppgift med en definition av klart. Kom överens om vem som ändrar vilka delar, så att du och AI:n inte skriver över deras arbete. Behåll förrådet och hostingkontona i ditt namn, och dela hemligheter via rätt inställningar i stället för i meddelanden.

Många börjar med att bygga den första versionen av en app med AI och tar sedan in en utvecklare för att lägga till betalningar, fixa något som AI:n hela tiden gör fel, granska säkerheten eller ta över när appen växer. Om du fortfarande funderar på om du ska anställa överhuvudtaget, se anlita en utvecklare eller bygg med AI. Den här guiden utgår från att du har bestämt dig och vill att samarbetet ska fungera smidigt.

När en utvecklare är värd det

Vanliga skäl att ta in någon:

• Ett problem AI:n inte klarar av efter flera tydliga försök och återställningar.
• Riskfyllda områden: betalningar, behörigheter, känslig data, databasmigreringar.
• En säkerhets- eller kodgranskning före lansering eller innan du tar på dig större kunder.
• Prestanda när verklig trafik kommer.
• Tillväxt: appen har blivit ett företag och behöver någon som äger koden.

Om du är tydlig med vilket av dessa det gäller påverkar allt nedan.

Steg 1: Få koden till en plats där den kan delas

Utvecklare arbetar från Git-förråd. Innan du kontaktar någon:

1. Koppla projektet till ett privat GitHub-förråd (eller liknande), eller exportera det.
2. Se till att inga hemligheter finns i koden eller historiken. Se hur du håller API-nycklar säkra.
3. Kontrollera att projektet går att köra från en ny kopia. Be AI:n skriva installationsstegen.

Skriv en README för en utvecklare som ansluter till projektet: vad appen gör, stacken, hur man installerar och kör den lokalt, de miljövariabler den behöver (endast namn), mappstrukturen och allt som är bräckligt eller ovanligt.

Om Git är nytt för dig, täcker hur du använder Git med en AI-byggd app grunderna.

Steg 2: Skriv en briefing på en sida

Utvecklaren har inte suttit igenom din chatthistorik. Ge dem sammanhanget på en sida:

• Vad appen gör, för vem och hur många som använder den.
• Vad som betyder mest: de flöden som aldrig får gå sönder.
• Kända problem och vad du redan har provat.
• Uppgiften, och hur du ska veta att den är klar.
• Begränsningar: budget, deadline, saker de inte ska ändra.

En bra "definition av klart" går att testa: "En inloggad användare kan betala för en månadsplan med Stripe Checkout, planen syns på kontosidan, och en uppsägning i kundportalen nedgraderar användaren i slutet av perioden." Inte "fixa betalningarna".

Steg 3: Ge åtkomst på ett säkert sätt

• Kod: lägg till dem som medarbetare i förrådet. Skicka inte ZIP-filer fram och tillbaka när arbetet har börjat.
• Byggare: om din AI-appbyggare stödjer teammedlemmar, bjud in dem till en arbetsyta som bara innehåller det här projektet.
• Hemligheter: lägg till dem i din hostings inställningar, eller dela via en lösenordshanterare. Klistra aldrig in nycklar i e-post eller chatt.
• Testkonton: skapa dem med testdata, i stället för att dela ditt eget inlogg.
• Produktionsdata: endast om de verkligen behöver den, och endast det de behöver.

Behåll förrådet, domänen och hostingkontona i ditt namn. Lägg till personer; lämna inte över konton.

Steg 4: Kom överens om vem som ändrar vad

Den största källan till friktion är att två parter, du med en AI och utvecklaren, ändrar samma kod samtidigt. Välj en regel:

Oavsett vad du väljer: hämta den senaste koden före varje prompt-session, och gör stora ändringar på branches som den andra personen kan granska.

Steg 5: Kommunicera skriftligt

• Rapportera problem med steg, förväntat och faktiskt resultat. Se hur du skriver en bra buggrapport.
• Håll besluten på ett ställe: en ärendelista, ett delat dokument eller kommentarer i pull requests.
• Be dem förklara ändringarna med vanliga ord i varje pull request.
• Kom överens om hur ofta ni ska stämma av.

Steg 6: Granska deras arbete

Du behöver inte läsa kod för att granska arbete. Kontrollera:

• Att det gör det briefen sa, i förhandsvisningen eller stagingkopian.
• Att inget annat gick sönder. Kör dina kritiska flöden.
• Att de förklarade vad de ändrat och varför.
• Att inga hemligheter dök upp i koden.

För en närmare titt har hur du granskar AI-genererad kod en checklista som också fungerar för kod skriven av människor. Du kan också be din AI-byggare förklara en utvecklares pull request för dig med enkla ord.

Steg 7: Håll ägandet tydligt

• Förrådet, hostingen, domänen och tredjepartskonton förblir dina.
• Skriv ned ägandet av koden de skriver innan arbetet börjar. Kontrollera lokala regler eller en rådgivare för avtalsfrågor.
• När arbetet är slut, ta bort deras åtkomst och byt ut alla nycklar de har sett.

Exempelprompter

En utvecklare ändrade kassakoden i den senaste pull requesten. Förklara med enkla ord vad de ändrade, och om något annat i appen beror på det.

Lista de delar av appen som är mest komplexa eller riskfyllda, så att jag kan säga till en utvecklare var granskningen ska fokusera.

Jag lämnar över betalningarna till en utvecklare. Ändra inga filer under src/payments eller /api/billing-rutterna från och med nu. Om en ändring kräver dem, säg det till mig i stället.

Vanliga misstag

• Ingen briefing. Utvecklaren lägger betalda timmar på att räkna ut vad du menade.
• Vag omfattning som "fixa buggarna" eller "gör den produktionsredo".
• Att båda redigerar samtidigt utan att pulla först, och sedan förlorar arbete i konflikter.
• Att dela ditt eget inlogg eller klistra in nycklar i chatten.
• Konton i utvecklarens namn, vilket gör det svårt att skiljas åt.
• Att glömma ta bort åtkomst och byta ut nycklar efter uppdraget.

Checklista

• Koden ligger i ett privat förråd i mitt namn, utan hemligheter i den.
• En README förklarar installationen; en briefing på en sida förklarar appen och uppgiften.
• Uppgiften har en testbar definition av klart.
• Åtkomst sker via medarbetarinbjudningar, hemligheter via inställningar eller en lösenordshanterare.
• Vi har kommit överens om vem som ändrar vad, och jag pullar innan jag prompter.
• Arbetet granskas mot briefen och de kritiska flödena.
• Ägandet är skriftligt; åtkomst tas bort och nycklar byts ut när arbetet är slut.

Arbeta med en utvecklare på Mythex

• Bjud in dem till en arbetsyta. Ägare kan bjuda in obegränsat många medarbetare utan avgift per plats; medlemmar arbetar i arbetsytans projekt. Använd en separat arbetsyta så att de bara ser detta projekt. Krediter för publicerade appar faktureras arbetsytans ägare. Se Inbjudningar.
• GitHub-synk och export (Pro). Koppla ett förråd och pusha/pulla, eller exportera projektet med hemligheter borttagna. Se GitHub, export och import.
• Dela en förhandsvisningslänk för att visa pågående arbete för någon utan Mythex-konto; ta bort den när du är klar.
• Ask mode besvarar frågor om koden utan att ändra den, vilket är användbart för att förstå en utvecklares ändringar.

Om utvecklaren ska köra appen någon annanstans, se hur du exporterar och self-hostar en AI-byggd app.

Frågor