Kako prototip napravljen uz AI pretvoriti u produkciju

Da prototip napravljen uz AI pretvorite 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 tokove svaki put kad nešto mijenjate, zaključajte ko može šta da vidi i mijenja, pobrinite se da čujete za greške prije nego što vam ih korisnici jave, pravite sigurnosne kopije podataka i dokažite da možete da ih vratite, i održavajte aplikaciju dovoljno brzom na telefonu. Ništa od ovoga ne zahtijeva prepravljanje od nule — to je kontrolna lista koju prolazite s istim AI-jem koji je napravio prototip.

Prototip i produkcija: šta se zaista mijenja

Prototip ima jednog pažljivog korisnika: vas. Znate koja dugmad da pritisnete, unosite razumne podatke, a kad nešto pukne, slegnete ramenima i zamolite AI da popravi. Produkcija ima mnogo nepažljivih korisnika, neke radoznale i povremeno jednog neprijateljskog. Kod ne mora postati „enterprise"; treba da obradi situacije na koje prototip nikada ne naiđe.

Ostatak vodiča prolazi kroz svaki red.

Korak 1: Zamrznite obim i zapišite glavne tokove

Prije nego što išta ojačate, odlučite šta je prva verzija. Navedite tri do šest tokova koji su najvažniji — na primjer „registracija, kreiranje projekta, poziv člana tima, plaćanje". Oni postaju vaš testni scenario, cilj praćenja i ono što provjeravate nakon svake izmjene.

Sve što nije na spisku ili se odsječe ili jasno označi kao beta. Mnogo je lakše učiniti četiri toka pouzdanim nego četrnaest.

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

Alati za izradu uz AI dobro proizvode kod koji radi na „sretnoj putanji". Problemi u produkciji žive na nesretnim putanjama. Testirajte svaki glavni tok ovako:

• Loš unos: prazna obavezna polja, ime od 5.000 znakova, e-adresa bez @, negativna količina, datum u prošlosti.
• Osvježavanje i dugme nazad: osvježite usred plaćanja; pritisnite nazad nakon slanja formulara. Da li se nešto kreira dvaput?
• Dva tabova, dva korisnika: prijavite se s dva različita naloga i pokušajte otvoriti stranice jedno drugog mijenjajući ID u URL-u.
• Sporo i malo: ekran veličine telefona i usporena veza (alati za developere u pregledniku mogu to simulirati).
• Prazna stanja: potpuno nov nalog bez podataka. Prototipi se često prave sa probnim podacima i izgledaju pokvareno bez njih.

Zatim učinite provjeru ponovljivom. Najmanje, držite pisanu kontrolnu listu i pokrećite je prije svakog izdanja. Još bolje, zamolite AI da napiše automatske testove za tokove koji su najvažniji:

Dodaj automatske end-to-end testove za ove tokove: registracija e-poštom, kreiranje projekta, poziv drugog korisnika i završetak plaćanja u Stripe test režimu. Dodaj i testove koji potvrđuju da korisnik ne može pregledati ni mijenjati tuđi projekat promjenom URL-a.

Testovi koji dokazuju da korisnik ne može nešto da uradi su oni koji prototipima najčešće nedostaju.

Korak 3: Osnove sigurnosti koje prototipi preskaču

Većina sigurnosnih problema u aplikacijama napravljenim uz AI nije egzotična. To su nedostajuće provjere. Prođite kroz ovu listu, a potpuniju sigurnosnu listu za aplikacije napravljene uz AI pogledajte:

• Autorizacija na serveru. Sakrivanje dugmeta nije sigurnost. Svaki zahtjev koji čita ili mijenja podatke mora na serveru provjeriti da li je prijavljen korisnik ovlašten. Ako aplikacija koristi bazu s pravilima na nivou reda, provjerite da su uključena i testirana.
• Tajne van pregledača. API ključevi za plaćanja, e-poštu ili AI provajdere pripadaju serverskim varijablama okruženja, nikada u kodu na frontendu. Ako niste sigurni šta to znači, pročitajte šta su varijable okruženja i tajne.
• Validacija na serveru. Pregledač se može zaobići, pa ponovite svaku provjeru koja je bitna i na serveru.
• Prijava uređena kako treba. Koristite dobro testiranu biblioteku ili servis za autentikaciju, a ne ručno čuvanje lozinki. Naš vodič kako dodati prijavu u aplikaciju pokriva opcije.
• Ograničenja broja zahtjeva za prijavu, registraciju, resetovanje lozinke i sve što šalje e-poštu ili poziva plaćeni API.
• Prijateljske greške. Korisnici treba da vide „nešto nije u redu"; detalji idu u logove, a ne na ekran.
• Promijenite sve što je procurilo. Ako je živi ključ ikada zalijepljen u chat, commit ili snimak ekrana, zamijenite ga kod provajdera.

Upit koji pokriva mnogo odjednom:

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 pregledaču, da se unosi validiraju na serveru i da su prijava i resetovanje lozinke ograničeni po broju zahtjeva. Prvo napiši šta si našao, pa tek onda mijenjaj.

Traženje liste prvo omogućava da vidite probleme i odlučite redoslijed, umjesto da dobijete jednu ogromnu izmjenu.

Korak 4: Saznajte kada nešto pukne — logovanje i praćenje

U pregledu vidite greške čim se dese. U produkciji aplikacija mora da vas obavijesti. Tri nivoa, od najjeftinijeg do najkorisnijeg:

1. Serverski logovi. Pobrinite se da greške budu zabilježene s dovoljno konteksta da se reprodukuju: koja ruta, koji ID korisnika (ne lozinka ni kartica), kakav oblik unosa. Zamolite AI da doda strukturisano logovanje ako aplikacija samo ispisuje u konzolu.
2. Praćenje grešaka. Servis kao što je Sentry ili sličan alat hvata izuzetke na frontendu i backendu, grupiše ih i šalje vam e-poštu. Za malu aplikaciju besplatni planovi tih servisa su često dovoljni; provjerite trenutna ograničenja na njihovim sajtovima.
3. Provjere dostupnosti. Spoljašnji servis koji učitava vašu početnu stranicu i jednu ključnu API rutu svakih nekoliko minuta i javlja vam ako ne uspiju. Ovo hvata probleme koji zaustave aplikaciju da uopšte loguje.

Dodajte još jednu naviku: nakon svakog izdanja otvorite živu aplikaciju i prođite kroz kontrolnu listu glavnih tokova na pravom URL-u, ne samo u pregledu.

Korak 5: Sigurnosne kopije i način da se vratite

Treba zaštititi dvije različite stvari, i lako ih je pomiješati.

• Kod. Držite projekat u sistemu verzija tako da se svaka izmjena može poništiti. Mnogi alati za izradu čuvaju kontrolne tačke fajlova; sinhronizacija s Git repozitorijumom daje vam kopiju i izvan alata.
• Podaci. Vraćanje koda ne vraća bazu podataka. Loša migracija ili dugme za brisanje koje greškom radi može uništiti redove koje nijedna kontrolna tačka koda neće vratiti.

Za podatke podesite redovne sigurnosne kopije sačuvane negdje drugdje, a ne na hostingu aplikacije — za Postgres bazu uobičajen pristup je zakazani pg_dump na odvojeno skladište, a mnogi upravljani hosting baza nude automatske sigurnosne kopije ili oporavak na tačku u vremenu. Zatim uradite korak koji većina ljudi preskoči: vratite sigurnosnu kopiju u privremenu bazu i provjerite da su podaci tu.

Takođe zamolite AI da učini destruktivne radnje sigurnijim: korak potvrde za brisanje i „meko brisanje" (označavanje redova kao obrisanih umjesto njihovog uklanjanja) za sve što korisnici možda žele da vrate.

Korak 6: Performanse koje drže na telefonu

Prototipi djeluju brzo jer ste jedini korisnik i skup podataka je mali. Prije lansiranja:

• Učitajte podatke realne veličine. Zamolite AI da unese nekoliko hiljada redova i vidite koje stranice usporavaju. Liste obično trebaju paginaciju, a baza obično treba indekse za kolone po kojima filtrirate i sortirate.
• Smanjite slike. Prevelike slike su najčešći razlog sporog učitavanja stranice. Zamolite za promijenjenu veličinu, kompresiju slika i lijeno učitavanje ispod linije ekrana.
• Izmjerite. Pokrenite Lighthouse u alatima za developere u Chromeu na živom URL-u u mobilnom režimu. Googleove Core Web Vitals su razuman cilj: Largest Contentful Paint unutar 2,5 sekunde, Interaction to Next Paint od 200 ms ili manje i Cumulative Layout Shift od 0,1 ili manje.
• Pazite na kašnjenje „buđenja". Hosting koji spava kad je neaktivan štedi novac, ali prva posjeta nakon tihog perioda je sporija. Za novu aplikaciju to je često prihvatljiva razmjena; samo znajte da se to dešava.

Stranica projekata je spora s 5.000 redova. Dodaj paginaciju na serveru (25 po stranici), dodaj indekse u bazi za kolone po kojima filtriramo i sortiramo, i prikaži stanje učitavanja dok se učitava sljedeća stranica.

Korak 7: Osnove rada

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

• Prilagođeni domen s HTTPS-om. Pogledajte kako povezati prilagođeni domen.
• Transakciona e-pošta s verifikovanog domena za potvrde registracije i resetovanje lozinke — obrađeno u kako slati e-poštu iz aplikacije.
• Politika privatnosti i uslovi koji opisuju šta zaista prikupljate. Ne kopirajte tvrdnje o usklađenosti koje niste zaslužili.
• Podrška — makar praćena adresa e-pošte.
• Odvojeni testni i živi ključevi za plaćanja i e-poštu, i jasna zabilješka koje okruženje koristi koje ključeve.

Korak 8: Čista predaja

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

• README koji kaže kako se pokreće, koje varijable okruženja su potrebne (samo imena, nikada vrijednosti) i kako se objavljuje.
• Kontrolna lista glavnih tokova i automatski testovi.
• Kratka bilješka o arhitekturi: frontend, backend, baza podataka, spoljašnji servisi i gdje je hostovan svaki.
• Spisak pristupa: ko ima administratorski pristup domenu, hostingu, bazi, nalozima za plaćanja i e-poštu. Stavite ove naloge pod poslovnu, a ne ličnu e-poštu.
• Kod u Gitu, po mogućnosti sinhronizovan s repozitorijumom koji posjedujete. Ako ćete kasnije možda mijenjati hosting, pročitajte kako izvesti i samostalno hostovati aplikaciju napravljenu uz AI.

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

Napiši README za ovaj projekat za programera koji ga nikada nije video: šta aplikacija radi, tehnološki stek, kako se pokreće lokalno, svaka varijabla okruženja koju čita (samo imena i svrha), kako je organizovana šema baze i kako se objavljuje.

Kontrolna lista spremnosti za produkciju

• Glavni tokovi zapisani i testirani, uključujući „ne može pristupiti tuđim podacima"
• Autorizacija i validacija na serveru na svakoj ruti za podatke
• Nema tajnih ključeva u kodu na frontendu; procureli ključevi zamijenjeni
• Ograničenja broja zahtjeva za prijavu i sve što košta novac
• Praćenje grešaka i provjere dostupnosti šalju obavještenja na sanduče koje čitate
• Sigurnosne kopije baze van hostinga aplikacije, s jednim uspješnim testnim vraćanjem
• Paginacija i indeksi provjereni s realnim podacima
• Prilagođeni domen, provjereni domen za slanje i politika privatnosti
• README i spisak pristupa za sljedeću osobu

Rad s Mythexom

Ako ste prototip napravili u Mythexu, većina ovih koraka su upiti u istom projektu. Ukucajte /test i Mythex prolazi kroz živi pregled kao korisnik i prijavljuje pokvarene tokove — pogledajte App Testing. Ključevi idu u tajne projekta, a ne u chat; svaki uspješan potez agenta čuva kontrolnu tačku vaših fajlova na koju se možete vratiti, a objavljivanje vam daje živi URL s hostingom, a baza se naplaćuje iz istog kreditnog stanja (ograničenja hostinga objašnjavaju kako se aplikacije i baze uspavljuju i bude). Kontrolne tačke pokrivaju fajlove, a ne redove baze, pa i dalje planirajte sigurnosne kopije podataka. Na Pro planu možete povezati prilagođeni domen i izvesti kod ili ga sinhronizovati s vašim GitHub repozitorijumom za predaju.

Pitanja