Så tar du en AI-prototyp till produktion

För att ta en AI-prototyp till produktion stänger du gapet mellan ”den fungerar när jag provar den” och ”den fortsätter fungera när andra använder den”. I praktiken betyder det fem saker: testa huvudflödena varje gång du ändrar något, lås ner vem som får se och ändra vad, se till att du får veta om fel innan dina användare säger det till dig, säkerhetskopiera data och bevisa att du kan återställa den, och håll appen tillräckligt snabb på en telefon. Inget av det kräver en omskrivning — det är en checklista som du går igenom tillsammans med samma AI som byggde prototypen.

Prototyp kontra produktion: vad som faktiskt ändras

En prototyp har en försiktig användare: dig. Du vet vilka knappar du ska trycka på, du skriver rimlig inmatning, och om något går sönder ryser du på axlarna och ber AI:n att fixa det. Produktion har många slarviga användare, några nyfikna och ibland en fientlig. Koden behöver inte bli ”företagsklass”; den behöver klara situationer som en prototyp aldrig möter.

Resten av guiden går igenom varje rad.

Steg 1: Frys omfattningen och skriv ner huvudflödena

Innan du härdar något, bestäm vad version ett är. Lista de tre till sex flöden som är viktigast — till exempel ”registrera dig, skapa ett projekt, bjud in en kollega, betala”. Dessa blir ditt testmanus, dina övervakningsmål och det du kontrollerar efter varje ändring.

Allt som inte står på listan antingen skärs bort eller märks tydligt som beta. Det är mycket enklare att göra fyra flöden tillförlitliga än fjorton.

Steg 2: Testa som en främling, gör sedan testningen upprepningsbar

AI-byggare är bra på att skapa kod som fungerar på den lyckliga vägen. Produktionsproblemen finns på de olyckliga vägarna. Testa varje huvudflöde med:

• Felaktig inmatning: tomma obligatoriska fält, ett namn med 5 000 tecken, en e-postadress utan @, ett negativt antal, ett datum i det förflutna.
• Uppdateringar och tillbakaknappen: ladda om mitt i kassan; tryck på bakåt efter att du skickat ett formulär. Skapas något två gånger?
• Två flikar, två användare: logga in med två olika konton och försök öppna varandras sidor genom att ändra ID:t i webbadressen.
• Långsamt och litet: en skärm i telefonstorlek och en strypt uppkoppling (webbläsarens utvecklarverktyg kan simulera en sådan).
• Tomma lägen: ett helt nytt konto utan data. Prototyper byggs ofta med exempeldata och ser trasiga ut utan den.

Gör sedan kontrollen upprepningsbar. Minst ska du ha en skriftlig checklista och köra den före varje release. Ännu bättre är att be AI:n skriva automatiska tester för de flöden som är viktigast:

Lägg till automatiska end-to-end-tester för dessa flöden: registrera dig med e-post, skapa ett projekt, bjud in en andra användare och slutför köpet i Stripes testläge. Lägg även till tester som bekräftar att en användare inte kan se eller ändra ett annat användares projekt genom att ändra webbadressen.

Tester som bevisar att en användare inte kan göra något är de som prototyper oftast saknar.

Steg 3: Säkerhetsgrunderna som prototyper hoppar över

De flesta säkerhetsproblem i AI-byggda appar är inte exotiska. De är saknade kontroller. Gå igenom den här listan, och se den mer fullständiga säkerhetschecklistan för AI-byggda appar:

• Behörighet på servern. Att dölja en knapp är inte säkerhet. Varje förfrågan som läser eller ändrar data måste kontrollera på servern att den inloggade användaren får göra det. Om din app använder en databas med radnivåregler, kontrollera att de är påslagna och testade.
• Hemligheter bort från webbläsaren. API-nycklar för betalningar, e-post eller AI-leverantörer hör hemma i miljövariabler på servern, aldrig i frontend-kod. Om du är osäker på vad det betyder, läs vad miljövariabler och hemligheter är.
• Validering på servern. Webbläsaren kan kringgås, så upprepa varje kontroll som är viktig på servern.
• Inloggning gjord ordentligt. Använd ett väl testat autentiseringsbibliotek eller en tjänst i stället för egen lagring av lösenord. Vår guide om hur du lägger till inloggning i din app går igenom alternativen.
• Hastighetsbegränsningar på inloggning, registrering, återställning av lösenord och allt som skickar e-post eller anropar ett betalt API.
• Vänliga felmeddelanden. Användare ska se ”något gick fel”; detaljerna går till dina loggar, inte till skärmen.
• Byt ut allt som läckt. Om en skarp nyckel någonsin klistrats in i en chatt, en commit eller en skärmbild, ersätt den hos leverantören.

En prompt som täcker mycket på en gång:

Granska den här appen för säkerhet i produktion. Kontrollera att varje API-rutt verifierar att den inloggade användaren äger posten den läser eller ändrar, att inga hemliga nycklar skickas till webbläsaren, att indata valideras på servern och att inloggning och återställning av lösenord har hastighetsbegränsning. Lista vad du hittar innan du ändrar något.

Att be om en lista först låter dig se problemen och bestämma ordningen, i stället för att få en enorm ändring på en gång.

Steg 4: Veta när något går sönder — loggning och övervakning

I förhandsvisningen ser du fel när de uppstår. I produktion behöver appen säga till. Tre lager, från billigast till mest användbart:

1. Serverloggar. Se till att fel loggas med tillräckligt sammanhang för att kunna återskapas: vilken rutt, vilket användar-ID (inte lösenord eller kortnummer), hur indata såg ut. Be AI:n lägga till strukturerad loggning om appen bara skriver till konsolen.
2. Felspårning. En tjänst som Sentry eller ett liknande verktyg fångar undantag i frontend och backend, grupperar dem och skickar dig e-post. För en liten app räcker ofta gratisnivåerna för dessa tjänster; kontrollera aktuella gränser på deras webbplatser.
3. Uppetidskontroller. En extern tjänst som laddar din startsida och en viktig API-rutt var några minuter och larmar om de misslyckas. Den fångar problemen som hindrar appen från att logga alls.

Lägg till en vana till: efter varje release, öppna den levande appen och kör din huvudflödeschecklista på den riktiga webbadressen, inte bara i förhandsvisningen.

Steg 5: Backuper och en väg tillbaka

Det finns två olika saker som behöver skyddas, och de är lätta att blanda ihop.

• Kod. Håll projektet i versionshantering så att varje ändring kan ångras. Många AI-byggare sparar kontrollpunkter av dina filer; synk till ett Git-repo ger dig en kopia utanför byggaren också.
• Data. Att rulla tillbaka koden rullar inte tillbaka databasen. En dålig migrering eller en buggig raderingsknapp kan förstöra rader som ingen kodkontrollpunkt kan återställa.

För data, ställ in regelbundna backuper som lagras någon annanstans än appens egen hosting — för en Postgres-databas är ett schemalagt pg_dump till separat lagring det vanliga sättet, och många hanterade databasleverantörer erbjuder automatiska backuper eller återställning till en viss tidpunkt. Gör sedan steget som de flesta hoppar över: återställ en backup till en tillfällig databas och kontrollera att datan finns där.

Be också AI:n göra destruktiva åtgärder säkrare: ett bekräftelsesteg för radering och ”mjuk radering” (att markera rader som borttagna i stället för att ta bort dem) för allt användare kan vilja få tillbaka.

Steg 6: Prestanda som håller på en telefon

Prototyper känns snabba eftersom du är den enda användaren och datamängden är liten. Före lansering:

• Ladda data i verklig storlek. Be AI:n fylla på några tusen rader och se vilka sidor som blir långsamma. Listor behöver oftast paginering, och databasen behöver oftast index på de kolumner du filtrerar och sorterar på.
• Krymp bilder. För stora bilder är den vanligaste orsaken till långsamma sidor. Be om omskalade, komprimerade bilder och lazy loading under fold-linjen.
• Mät. Kör Lighthouse i Chromes utvecklarverktyg på den levande webbadressen i mobilläge. Googles Core Web Vitals är ett förnuftigt mål: Largest Contentful Paint inom 2,5 sekunder, Interaction to Next Paint på 200 ms eller mindre och Cumulative Layout Shift på 0,1 eller mindre.
• Se upp för ”väckningsfördröjningar”. Hosting som sover när den är inaktiv sparar pengar men gör första besöket efter en lugn period långsammare. Det är ofta en bra avvägning för en ny app; var medveten om att det händer.

Projektsidan är långsam med 5 000 rader. Lägg till serverpaginering (25 per sida), lägg till databasindex för kolumnerna vi filtrerar och sorterar på, och visa ett laddningsläge medan nästa sida laddas.

Steg 7: Driftsgrunder

Några små saker skiljer en hobbyapp från en app som människor litar på:

• En egen domän med HTTPS. Se hur du kopplar en egen domän.
• Transaktionell e-post från en verifierad domän för bekräftelser vid registrering och återställning av lösenord — beskrivs i hur du skickar e-post från din app.
• Integritetspolicy och villkor som beskriver vad du faktiskt samlar in. Kopiera inte efterlevnadspåståenden som du inte har förtjänat.
• En supportkanal — även en övervakad e-postadress.
• Separata test- och skarpa nycklar för betalningar och e-post, och en tydlig anteckning om vilken miljö som använder vilka.

Steg 8: En ren överlämning

För eller senare kommer någon annan att arbeta med appen: en frilansare, en ny medgrundare eller du själv om sex månader. Gör det enkelt:

• En README som beskriver hur man kör appen, vilka miljövariabler den behöver (endast namn, aldrig värden) och hur den publiceras.
• Huvudflödeschecklistan och de automatiska testerna.
• En kort arkitekturnotering: frontend, backend, databas, tredjepartstjänster och var vart och ett hostas.
• Åtkomstlista: vem som har adminåtkomst till domänen, hostingen, databasen, betalnings- och e-postkontona. Lägg dessa konton under en företagsadress, inte en personlig.
• Koden i Git, helst synkad till ett repo du äger. Om du kan flytta hostingen senare, läs hur du exporterar och själv hostar en AI-byggd app.

AI:n kan utkasta det mesta av detta åt dig:

Skriv en README för det här projektet för en utvecklare som aldrig sett det: vad appen gör, teknikstacken, hur man kör den lokalt, varje miljövariabel den läser (endast namn och syfte), hur databasschemat är organiserat och hur den publiceras.

Checklista för produktionsberedskap

• Huvudflöden nedskrivna och testade, inklusive ”kan inte komma åt någon annans data”
• Behörighet och validering på servern för varje datarutt
• Inga hemliga nycklar i frontend-kod; läckta nycklar roterade
• Hastighetsbegränsningar på autentisering och allt som kostar pengar
• Felspårning och uppetidslarm som pekar på en inkorg du läser
• Databasbackuper utanför appens hosting, med en lyckad teståterställning
• Paginering och index kontrollerade med realistisk data
• Egen domän, verifierad avsändardomän, integritetspolicy
• README och åtkomstlista för nästa person

Göra det med Mythex

Om du byggde prototypen i Mythex är de flesta av dessa steg prompter i samma projekt. Skriv /test så klickar Mythex igenom den levande förhandsvisningen som en användare och rapporterar trasiga flöden — se App Testing. Nycklar läggs i projektets hemligheter i stället för i chatten, varje lyckad agentomgång sparar en kontrollpunkt av dina filer som du kan återgå till, och publicering ger dig en live-URL med hosting och databas som debiteras från samma kreditsaldo (gränser för hosting förklarar hur appar och databaser somnar och vaknar). Kontrollpunkter omfattar filer, inte databasrader, så planera fortfarande för databasbackuper. På Pro kan du koppla en egen domän och exportera koden eller synka den till ditt eget GitHub-repo för en överlämning.

Frågor