Kako prebaciti AI prototip u produkciju

Da biste prebacili AI prototip u produkciju, zatvorite razliku između „radi kad ga ja isprobam“ i „radi i kad ga koriste drugi ljudi“. U praksi to znači pet stvari: testirajte glavne tijekove svaki put kad nešto promijenite, osigurajte tko smije vidjeti i mijenjati što, pobrinite se da za greške saznate prije nego što vam ih korisnici jave, sigurnosno kopirajte podatke i dokažite da ih možete vratiti te održite aplikaciju dovoljno brzom na telefonu. Ništa od toga ne traži prepisivanje — riječ je o popisu koji prolazite s istim AI-jem koji je izradio prototip.

Prototip naspram produkcije: što se zapravo mijenja

Prototip ima jednog pažljivog korisnika: vas. Znate koje gumbe pritisnuti, unosite razuman tekst i ako nešto pukne, slegnete ramenima i zamolite AI da to popravi. Produkcija ima mnogo nepažljivih korisnika, neke radoznale i povremeno jednog neprijateljskog. Kod ne mora postati „korporativan“; treba obraditi situacije koje prototip nikad ne doživi.

Ostatak vodiča prolazi kroz svaki redak.

Korak 1: Zamrznite opseg i zapišite glavne tijekove

Prije nego išta ojačate, odlučite što je prva verzija. Popišite tri do šest tijekova koji su najvažniji — na primjer „registracija, izrada projekta, pozivanje suradnika, plaćanje“. Oni postaju vaš testni scenarij, cilj praćenja i stvari koje provjeravate nakon svake promjene.

Sve što nije na popisu ili se izbaci ili se jasno označi kao beta. Puno je lakše učiniti pouzdanim četiri tijeka nego četrnaest.

Korak 2: Testirajte kao nepoznati korisnik, zatim to učinite ponovljivim

AI alati dobro izrađuju kod koji radi na „sretnom putu“. Problemi u produkciji žive na nesretnim putovima. Testirajte svaki glavni tijek s:

• Lošim unosom: prazna obavezna polja, ime od 5.000 znakova, e-adresa bez @, negativna količina, datum u prošlosti.
• Osvježavanjem i gumbom natrag: osvježite na pola blagajne; pritisnite natrag nakon slanja obrasca. Nastaje li nešto dvaput?
• Dvije kartice, dva korisnika: prijavite se s dva različita računa i pokušajte otvoriti tuđe stranice mijenjajući ID u URL-u.
• Sporo i malo: zaslon veličine telefona i ograničena veza (alati za programere u pregledniku mogu je simulirati).
• Prazna stanja: potpuno novi račun bez podataka. Prototipovi se često izrade s primjernim podacima pa izgledaju pokvareno bez njih.

Zatim učinite provjeru ponovljivom. Barem zadržite pisani popis i pokrenite ga prije svakog izdanja. Još bolje, zamolite AI da napiše automatizirane testove za najvažnije tijekove:

Dodaj automatizirane end-to-end testove za ove tijekove: registracija e-poštom, izrada projekta, pozivanje drugog korisnika i dovršetak plaćanja u Stripe testnom načinu rada. Dodaj i testove koji potvrđuju da korisnik ne može vidjeti ili uređivati tuđi projekt mijenjanjem URL-a.

Testovi koji dokazuju da korisnik ne može nešto učiniti upravo su ono što prototipovima najčešće nedostaje.

Korak 3: Osnove sigurnosti koje prototipovi preskaču

Većina sigurnosnih problema u aplikacijama izrađenim uz AI nisu egzotični. Riječ je o nedostajućim provjerama. Prođite ovaj popis i pogledajte potpuniju sigurnosnu listu za aplikacije izrađene uz AI:

• Autorizacija na poslužitelju. Skrivanje gumba nije sigurnost. Svaki zahtjev koji čita ili mijenja podatke mora na poslužitelju provjeriti smije li prijavljeni korisnik to učiniti. Ako vaša aplikacija koristi bazu s pravilima na razini redaka, provjerite jesu li uključena i testirana.
• Tajne izvan preglednika. API ključevi za plaćanja, e-poštu ili AI pružatelje pripadaju varijablama okruženja na poslužitelju, nikad u kodu na prednjoj strani. Ako niste sigurni što to znači, pročitajte što su varijable okruženja i tajne.
• Validacija na poslužitelju. Preglednik se može zaobići, pa svaku važnu provjeru ponovite na poslužitelju.
• Prijava napravljena ispravno. Koristite dobro testiranu biblioteku ili uslugu za autentifikaciju umjesto vlastitog spremanja lozinki. Naš vodič o dodavanju prijave u aplikaciju pokriva mogućnosti.
• Ograničenja broja zahtjeva za prijavu, registraciju, reset lozinke i sve što šalje e-poštu ili poziva plaćeni API.
• Pristojne poruke o greškama. Korisnici trebaju vidjeti „nešto je pošlo po zlu“; pojedinosti idu u vaše zapise, a ne na zaslon.
• Zamijenite sve što je procurilo. Ako je živi ključ ikad zalijepljen u chat, commit ili snimku zaslona, zamijenite ga kod pružatelja.

Upit koji odjednom pokriva puno:

Pregledaj ovu aplikaciju za sigurnost u produkciji. Provjeri da svaka API ruta potvrđuje da prijavljeni korisnik posjeduje zapis koji čita ili mijenja, da se tajni ključevi ne šalju pregledniku, da se unos validira na poslužitelju i da su prijava i reset lozinke ograničeni po broju zahtjeva. Prije bilo kakve promjene popiši što si našao.

Traženje popisa prvo omogućuje da vidite probleme i odlučite redoslijed, umjesto da dobijete jednu golemu promjenu.

Korak 4: Saznajte kad pukne — bilježenje i praćenje

U pregledu vidite greške kako se događaju. U produkciji treba vam da vas aplikacija obavijesti. Tri sloja, od najjeftinijeg do najkorisnijeg:

1. Zapisi poslužitelja. Osigurajte da se greške bilježe s dovoljno konteksta za reprodukciju: koja ruta, koji ID korisnika (ne lozinka ni kartica), kakav oblik unosa. Ako aplikacija samo ispisuje u konzolu, zamolite AI da doda strukturirano bilježenje.
2. Praćenje grešaka. Usluga poput Sentryja ili sličnog alata hvata iznimke na prednjoj i stražnjoj strani, grupira ih i šalje vam e-poštu. Za malu aplikaciju besplatni paketi tih usluga često su dovoljni; provjerite trenutna ograničenja na njihovim stranicama.
3. Provjere dostupnosti. Vanjska usluga koja svakih nekoliko minuta učitava vašu početnu stranicu i jednu ključnu API rutu te vas upozori ako ne uspije. Ovo hvata probleme koji uopće zaustave bilježenje.

Dodajte još jednu naviku: nakon svakog izdanja otvorite živu aplikaciju i pokrenite popis glavnih tijekova na stvarnom URL-u, a ne samo u pregledu.

Korak 5: Sigurnosne kopije i put natrag

Dvije različite stvari trebaju zaštitu i lako ih je zamijeniti.

• Kod. Držite projekt u sustavu za verzioniranje kako bi se svaka promjena mogla poništiti. Mnogi AI alati čuvaju kontrolne točke vaših datoteka; sinkronizacija s Git repozitorijem daje vam kopiju i izvan alata.
• Podaci. Vraćanje koda ne vraća bazu podataka. Loša migracija ili neispravan gumb za brisanje mogu uništiti retke koje nijedna kontrolna točka koda neće vratiti.

Za podatke postavite redovite sigurnosne kopije pohranjene negdje drugdje, a ne na hostingu aplikacije — za Postgres bazu uobičajen pristup je zakazani pg_dump na zasebnu pohranu, a mnogi upravljani hosti baza nude automatske sigurnosne kopije ili oporavak na određeni trenutak. Zatim napravite korak koji većina ljudi preskače: vratite sigurnosnu kopiju u privremenu bazu i provjerite jesu li podaci tamo.

Zamolite AI i da destruktivne radnje učini sigurnijima: korak potvrde za brisanje i „meko brisanje“ (označavanje redaka kao obrisanih umjesto njihova uklanjanja) za sve što bi korisnici mogli poželjeti vratiti.

Korak 6: Performanse koje drže na telefonu

Prototipovi djeluju brzo jer ste vi jedini korisnik i skup podataka je malen. Prije lansiranja:

• Učitajte podatke stvarne veličine. Zamolite AI da napuni nekoliko tisuća redaka i vidi koje se stranice usporavaju. Popisi obično trebaju stranicanje, a baza obično treba indekse na stupcima po kojima filtrirate i sortirate.
• Smanjite slike. Prevelike slike najčešći su razlog sporog učitavanja stranice. Zatražite slike smanjene i komprimirane te lijeno učitavanje ispod linije vidljivosti.
• Izmjerite. Pokrenite Lighthouse u alatima za programere u Chromeu na živom URL-u u mobilnom načinu rada. Googleovi Core Web Vitals su razumna meta: Largest Contentful Paint unutar 2,5 sekunde, Interaction to Next Paint 200 ms ili manje i Cumulative Layout Shift 0,1 ili manje.
• Pazite na kašnjenja „buđenja“. Hosting koji se uspava kad je neaktivan štedi novac, ali prvi posjet nakon mirnog razdoblja je sporiji. To je često dobar kompromis za novu aplikaciju; znajte da se to događa.

Stranica projekata je spora s 5.000 redaka. Dodaj stranicanje na poslužitelju (25 po stranici), dodaj indekse u bazi za stupce po kojima filtriramo i sortiramo te prikaži stanje učitavanja dok se učitava sljedeća stranica.

Korak 7: Operativne osnove

Nekoliko sitnih stvari razlikuje hobi aplikaciju od one kojoj ljudi vjeruju:

• Prilagođena domena s HTTPS-om. Pogledajte kako povezati prilagođenu domenu.
• Transakcijska e-pošta s provjerene domene za potvrde registracije i reset lozinke — pokriveno u kako slati e-poštu iz aplikacije.
• Politika privatnosti i uvjeti koji opisuju što stvarno prikupljate. Ne kopirajte tvrdnje o usklađenosti koje niste zaslužili.
• Kanal za podršku — makar nadzirana adresa e-pošte.
• Odvojeni testni i živi ključevi za plaćanja i e-poštu te jasna bilješka koje okruženje koristi koji ključ.

Korak 8: Uredna primopredaja

Prije ili kasnije na aplikaciji će raditi netko drugi: freelancer, novi suosnivač ili vi za šest mjeseci. Olakšajte to:

• README koji objašnjava kako je pokrenuti, koje varijable okruženja su potrebne (samo nazivi, nikad vrijednosti) i kako je objaviti.
• Popis glavnih tijekova i automatizirani testovi.
• Kratka bilješka o arhitekturi: prednja strana, stražnja strana, baza, vanjske usluge i gdje je svaka hostana.
• Popis pristupa: tko ima administratorski pristup domeni, hostingu, bazi, računima za plaćanja i e-poštu. Stavite te račune pod poslovnu e-poštu, a ne osobnu.
• Kod u Gitu, po mogućnosti sinkroniziran s repozitorijem u vašem vlasništvu. Ako ćete kasnije možda promijeniti hosting, pročitajte kako izvesti i samostalno hostati aplikaciju izrađenu uz AI.

AI može napisati većinu toga umjesto vas:

Napiši README za ovaj projekt za programera koji ga nikad nije vidio: što aplikacija radi, tehnološki stog, kako je pokrenuti lokalno, svaku varijablu okruženja koju čita (samo nazivi i svrha), kako je organizirana shema baze i kako je objaviti.

Popis spremnosti za produkciju

• Glavni tijekovi zapisani i testirani, uključujući „ne može pristupiti tuđim podacima“
• Autorizacija i validacija na poslužitelju na svakoj ruti za podatke
• Nema tajnih ključeva u kodu na prednjoj strani; procurjeli ključevi zamijenjeni
• Ograničenja broja zahtjeva na autentifikaciji i svemu što košta novac
• Praćenje grešaka i upozorenja o dostupnosti šalju na sanducić koji čitate
• Sigurnosne kopije baze izvan hostinga aplikacije, uz jedno uspješno testno vraćanje
• Stranicanje i indeksi provjereni s realnim podacima
• Prilagođena domena, provjerena domena za slanje i politika privatnosti
• README i popis pristupa za sljedećeg tko dolazi

Rad s Mythexom

Ako ste prototip izradili u Mythexu, većina ovih koraka su upiti u istom projektu. Upišite /test i Mythex klikne kroz živi pregled poput korisnika te prijavi neispravne tijekove — pogledajte App Testing. Ključevi idu u tajne projekta, a ne u chat; svaki uspješan zadatak agenta sprema kontrolnu točku vaših datoteka na koju se možete vratiti, a objava vam daje živi URL s hostingom, dok se baza naplaćuje s istog stanja kredita (ograničenja hostinga objašnjavaju kako se aplikacije i baze uspavaju i bude). Kontrolne točke pokrivaju datoteke, a ne retke baze, pa i dalje planirajte sigurnosne kopije podataka. Na Pro planu možete povezati prilagođenu domenu i izvesti kod ili ga sinkronizirati s vlastitim GitHub repozitorijem za primopredaju.

Pitanja