Slik tar du en AI-prototype til produksjon

For å ta en AI-prototype til produksjon lukker du gapet mellom «det fungerer når jeg prøver» og «det fungerer fortsatt når andre bruker det». I praksis betyr det fem ting: test hovedflytene hver gang du endrer noe, lås ned hvem som kan se og endre hva, sørg for at du hører om feil før brukerne dine forteller deg det, ta sikkerhetskopi av dataene og bevis at du kan gjenopprette dem, og hold appen rask nok på en telefon. Ingen av dette krever en omskriving – det er en sjekkliste du går gjennom sammen med samme AI som bygde prototypen.

Prototype kontra produksjon: hva som faktisk endrer seg

En prototype har én forsiktig bruker: deg. Du vet hvilke knapper du skal trykke på, du skriver fornuftig input, og hvis noe går i stykker, trekker du på skuldrene og ber AI-en fikse det. I produksjon har du mange uforsiktige brukere, noen nysgjerrige og av og til en fiendtlig. Koden trenger ikke bli «bedriftsklasse»; den må håndtere situasjonene en prototype aldri møter.

Resten av guiden går gjennom hver rad.

Steg 1: Frys omfanget og skriv ned hovedflytene

Før du herder noe, bestem hva versjon én er. List opp de tre til seks flytene som betyr mest – for eksempel «registrere seg, opprette et prosjekt, invitere en kollega, betale». Disse blir testskriptet ditt, målene for overvåkingen din og det du sjekker etter hver endring.

Alt som ikke står på listen, kuttes enten eller merkes tydelig som beta. Det er mye enklere å gjøre fire flyter pålitelige enn fjorten.

Steg 2: Test som en fremmed, og gjør det deretter repeterbart

AI-bygg er gode til å lage kode som virker på den gode veien. Produksjonsproblemer ligger på de dårlige veiene. Test hver hovedflyt med:

• Dårlig input: tomme obligatoriske felt, et navn på 5000 tegn, en e-post uten @, et negativt antall, en dato i fortiden.
• Oppdateringer og tilbake-knappen: last inn siden på nytt midt i kassen; trykk tilbake etter å ha sendt et skjema. Blir noe opprettet to ganger?
• To faner, to brukere: logg inn med to ulike kontoer og prøv å åpne hverandres sider ved å endre ID-en i adressen.
• Langsomt og lite: en skjerm på telefonstørrelse og en begrenset forbindelse (nettleserens utviklerverktøy kan simulere dette).
• Tomme tilstander: en helt ny konto uten data. Prototyper bygges ofte med eksempeldata og ser ødelagte ut uten dem.

Deretter gjør du sjekken repeterbar. Minst bør du ha en skriftlig sjekkliste og kjøre den før hver utgivelse. Enda bedre er å be AI-en skrive automatiserte tester for de viktigste flytene:

Legg til automatiserte ende-til-ende-tester for disse flytene: registrering med e-post, opprette et prosjekt, invitere en andre bruker og fullføre kassen i Stripes testmodus. Legg også til tester som bekrefter at en bruker ikke kan se eller endre et annet brukers prosjekt ved å endre adressen.

Tester som beviser at en bruker ikke kan gjøre noe, er de prototyper oftest mangler.

Steg 3: Sikkerhetsgrunnlaget prototyper hopper over

De fleste sikkerhetsproblemer i AI-bygde apper er ikke eksotiske. De er manglende sjekker. Gå gjennom denne listen, og se den utfyllende sikkerhetssjekklisten for AI-bygde apper:

• Autorisasjon på serveren. Å skjule en knapp er ikke sikkerhet. Hver forespørsel som leser eller endrer data må kontrollere på serveren at den innloggede brukeren har lov til det. Hvis appen din bruker en database med regler på radnivå, sjekk at de er slått på og testet.
• Hemmeligheter ut av nettleseren. API-nøkler for betaling, e-post eller AI-leverandører hører hjemme i miljøvariabler på serveren, aldri i kode på klientsiden. Hvis du er usikker på hva det betyr, les hva miljøvariabler og hemmeligheter er.
• Validering på serveren. Nettleseren kan omgås, så gjenta alle viktige sjekker på serveren.
• Innlogging gjort skikkelig. Bruk et godt testet autentiseringsbibliotek eller en tjeneste i stedet for egenlaget passordlagring. Vår guide om å legge til innlogging i appen din dekker alternativene.
• Begrensning av forespørsler på innlogging, registrering, tilbakestilling av passord og alt som sender e-post eller kaller et betalt API.
• Vennlige feilmeldinger. Brukere skal se «noe gikk galt»; detaljene går til loggene dine, ikke til skjermen.
• Roter alt som har lekket. Hvis en live-nøkkel noen gang er limt inn i en chat, en commit eller et skjermbilde, bytt den hos leverandøren.

En prompt som dekker mye på én gang:

Gjennomgå denne appen for sikkerhet i produksjon. Sjekk at hver API-rute bekrefter at den innloggede brukeren eier posten den leser eller endrer, at ingen hemmelige nøkler sendes til nettleseren, at input valideres på serveren, og at innlogging og tilbakestilling av passord har begrenset antall forsøk. List opp det du finner før du endrer noe.

Å be om en liste først lar deg se problemene og bestemme rekkefølgen, i stedet for å få én stor endring.

Steg 4: Vit når den går i stykker – logging og overvåking

I forhåndsvisningen ser du feil etter hvert som de skjer. I produksjon må appen si ifra. Tre lag, fra billigst til mest nyttig:

1. Serverlogger. Sørg for at feil logges med nok kontekst til å reprodusere dem: hvilken rute, hvilken bruker-ID (ikke passordet eller kortet deres), hvilken form input har. Be AI-en legge til strukturert logging hvis appen bare skriver til konsollen.
2. Feilsporing. En tjeneste som Sentry eller et lignende verktøy fanger opp unntak i klienten og på serveren, grupperer dem og sender deg e-post. For en liten app er gratisnivåene til disse tjenestene ofte nok; sjekk gjeldende grenser på nettstedene deres.
3. Oppetidskontroller. En ekstern tjeneste som laster hjemmesiden din og én viktig API-rute hvert par minutt og varsler deg hvis de feiler. Dette fanger opp problemene som gjør at appen ikke logger i det hele tatt.

Legg til én vane til: etter hver utgivelse, åpne den live appen og kjør sjekklisten for hovedflyter på den ekte adressen, ikke bare i forhåndsvisningen.

Steg 5: Sikkerhetskopier og en vei tilbake

To ulike ting må beskyttes, og de er lette å forveksle.

• Kode. Hold prosjektet i versjonskontroll, slik at en hvilken som helst endring kan angres. Mange AI-bygg lagrer sjekkpunkter av filene dine; synkronisering til et Git-repository gir deg en kopi utenfor byggeverktøyet også.
• Data. Å rulle tilbake koden ruller ikke tilbake databasen. En dårlig migrering eller en feilende slettknapp kan ødelegge rader som ingen kodesjekkpunkt får tilbake.

For data setter du opp jevnlige sikkerhetskopier som lagres et annet sted enn appens egen hosting – for en Postgres-database er vanlig praksis en planlagt pg_dump til separat lagring, og mange administrerte databasetjenester tilbyr automatiske sikkerhetskopier eller gjenoppretting til et bestemt tidspunkt. Gjør så steget de fleste hopper over: gjenopprett en sikkerhetskopi til en testdatabase og kontroller at dataene er der.

Be også AI-en gjøre destruktive handlinger tryggere: et bekreftelsestrinn for sletting, og «myk sletting» (å markere rader som slettet i stedet for å fjerne dem) for alt brukerne kan ønske å få tilbake.

Steg 6: Ytelse som holder på en telefon

Prototyper føles raske fordi du er den eneste brukeren og datamengden er liten. Før lansering:

• Last inn data i reell størrelse. Be AI-en fylle inn noen tusen rader og se hvilke sider som blir trege. Lister trenger vanligvis paginering, og databasen trenger vanligvis indekser på kolonnene du filtrerer og sorterer etter.
• Krymp bilder. Store bilder er den vanligste grunnen til at en side laster sakte. Be om endrede størrelser, komprimerte bilder og lat lasting under det synlige området.
• Mål. Kjør Lighthouse i Chromes utviklerverktøy på den live adressen i mobilmodus. Googles Core Web Vitals er et fornuftig mål: Largest Contentful Paint innen 2,5 sekunder, Interaction to Next Paint på 200 ms eller mindre, og Cumulative Layout Shift på 0,1 eller mindre.
• Se etter «oppvåkningsforsinkelser». Hosting som sover når den er inaktiv sparer penger, men gjør første besøk etter en rolig periode tregere. Det er ofte en god avveining for en ny app; vit at det skjer.

Prosjektsiden er treg med 5000 rader. Legg til paginering på serveren (25 per side), legg til databaseindekser for kolonnene vi filtrerer og sorterer etter, og vis en lastetilstand mens neste side lastes.

Steg 7: Grunnleggende drift

Noen få små ting skiller en hobbyapp fra en app folk stoler på:

• Et eget domene med HTTPS. Se slik kobler du til et eget domene.
• Transaksjonell e-post fra et verifisert domene for bekreftelser ved registrering og tilbakestilling av passord – dekket i slik sender du e-post fra appen din.
• Personvernerklæring og vilkår som beskriver hva du faktisk samler inn. Ikke kopier overholdelseserklæringer du ikke har gjort deg fortjent til.
• En støttekanal – selv en overvåket e-postadresse.
• Separate test- og live-nøkler for betaling og e-post, og et tydelig notat om hvilket miljø som bruker hvilke.

Steg 8: En ryddig overlevering

Før eller senere vil noen andre jobbe med appen: en frilanser, en ny medgründer, eller deg selv om seks måneder. Gjør det enkelt:

• En README som forklarer hvordan appen kjøres, hvilke miljøvariabler den trenger (bare navnene, aldri verdiene), og hvordan den publiseres.
• Sjekklisten for hovedflyter og de automatiserte testene.
• En kort arkitekturnotat: klientsiden, serveren, databasen, tredjepartstjenester, og hvor hver er hostet.
• Tilgangsliste: hvem som har administratortilgang til domenet, hostingen, databasen, betalings- og e-postkontoene. Legg disse kontoene under en forretningsadresse, ikke en privat.
• Koden i Git, helst synkronisert til et repository du eier. Hvis du kanskje flytter hostingen senere, les slik eksporterer du en AI-bygd app og er vert for den selv.

AI-en kan utarbeide mesteparten av dette for deg:

Skriv en README for dette prosjektet for en utvikler som aldri har sett det: hva appen gjør, teknologistakken, hvordan den kjøres lokalt, alle miljøvariabler den leser (kun navn og formål), hvordan databaseskjemaet er organisert, og hvordan den publiseres.

Sjekkliste for produksjonsklarhet

• Hovedflyter skrevet ned og testet, inkludert «kan ikke få tilgang til andres data»
• Autorisasjon og validering på serveren for alle dataruter
• Ingen hemmelige nøkler i kode på klientsiden; lekkede nøkler rotert
• Begrenset antall forsøk på innlogging og alt som koster penger
• Feilsporing og oppetidsvarsler som peker til en innboks du leser
• Databasesikkerhetskopier utenfor appens hosting, med én vellykket testgjenoppretting
• Paginering og indekser kontrollert med realistiske data
• Eget domene, verifisert avsenderdomene, personvernerklæring
• README og tilgangsliste for den som kommer etter

Å gjøre dette med Mythex

Hvis du bygde prototypen i Mythex, er de fleste av disse stegene prompter i samme prosjekt. Skriv /test, så klikker Mythex seg gjennom den live forhåndsvisningen som en bruker og rapporterer ødelagte flyter – se App-testing. Nøkler legges i prosjekthemmeligheter i stedet for i chatten, hver vellykkede agenttur lagrer et sjekkpunkt av filene dine som du kan gå tilbake til, og publisering gir deg en live adresse med hosting, og databasen faktureres fra samme kredittsaldo (grenser for hosting forklarer hvordan apper og databaser sover og våkner). Sjekkpunkter dekker filer, ikke databaseradene, så planlegg sikkerhetskopiene av dataene dine likevel. På Pro kan du koble til et eget domene og eksportere koden eller synkronisere den til ditt eget GitHub-repository for en overlevering.

Spørsmål