Kako preneti AI prototip u produkciju

Da biste prebacili AI prototip u produkciju, zatvorite jaz između „radi kada ga isprobam” i „radi kada ga koriste drugi ljudi”. U praksi to znači pet stvari: testirati glavne tokove pri svakoj promeni, zaključati ko može da vidi i menja šta, osigurati da saznate za greške pre nego što vam korisnici jave, praviti rezervne kopije podataka i dokazati da možete da ih vratite, i zadržati aplikaciju dovoljno brzom na telefonu. Ništa od toga ne zahteva prepisivanje — to je kontrolna lista koju prolazite uz isti AI koji je napravio prototip.

Prototip naspram produkcije: šta se zaista menja

Prototip ima jednog pažljivog korisnika: vas. Znate na koje dugmiće da pritisnete, unosite razuman tekst i ako 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 da postane „korporativni”; treba da se nosi sa situacijama koje prototip nikada ne sretne.

Ostatak ovog vodiča prolazi kroz svaki red.

Korak 1: Zamrznite obim i zapišite glavne tokove

Pre nego što išta ojačate, odlučite šta je prva verzija. Navedite tri do šest tokova koji su najvažniji — na primer „prijava, pravljenje projekta, pozivanje saradnika, plaćanje”. Oni postaju vaša test skripta, cilj praćenja i ono što proveravate posle svake izmene.

Sve što nije na listi ili se odseč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

AI alati dobro prave kod koji radi na srećnoj putanji. Produkcijski problemi žive na nesrećnim putanjama. Testirajte svaki glavni tok sa:

• Lošim unosom: prazna obavezna polja, ime od 5.000 znakova, imejl bez @, negativna količina, datum u prošlosti.
• Osvežavanjem i dugmetom za nazad: osvežite na pola plaćanja; pritisnite nazad posle slanja forme. Da li se nešto kreira dvaput?
• Dva taba, dva korisnika: prijavite se sa dva različita naloga i pokušajte da otvorite tuđe stranice menjajući ID u URL-u.
• Sporo i malo: ekran veličine telefona i usporena veza (alati za programere u pregledaču mogu da simuliraju jednu).
• Prazna stanja: potpuno nov nalog bez podataka. Prototipi se često prave sa primernim podacima i bez njih izgledaju pokvareno.

Zatim učinite proveru ponovljivom. Najmanje, vodite pisanu listu i pokrenite je pre 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: prijava emailom, kreiranje projekta, pozivanje drugog korisnika i završetak plaćanja u Stripe test režimu. Dodaj i testove koji potvrđuju da korisnik ne može da vidi ili menja tuđi projekat menjajući URL.

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

Korak 3: Osnove bezbednosti koje prototipi preskaču

Većina bezbednosnih problema u aplikacijama napravljenim uz AI nije egzotična. Nedostaju provere. Prođite kroz ovu listu, a potpuniju bezbednosnu listu za aplikacije napravljene uz AI pogledajte ovde:

• Autorizacija na serveru. Sakrivanje dugmeta nije bezbednost. Svaki zahtev koji čita ili menja podatke mora da proveri na serveru da li je prijavljen korisnik ovlašćen. Ako vaša aplikacija koristi bazu sa pravilima po redu, proverite da su uključena i testirana.
• Tajne van pregledača. API ključevi za plaćanja, imejl ili AI provajdere pripadaju promenljivama okruženja na serveru, nikada u kodu na frontendu. Ako niste sigurni šta to znači, pročitajte šta su promenljive okruženja i tajne.
• Validacija na serveru. Pregledač može da se zaobiđe, pa ponovite svaku proveru koja je važna i na serveru.
• Prijava urađena kako treba. Koristite dobro testiranu biblioteku za autentifikaciju ili uslugu, a ne ručno čuvanje lozinki. Naš vodič o dodavanju prijave u aplikaciju pokriva opcije.
• Ograničenja broja zahteva za prijavu, registraciju, resetovanje lozinke i sve što šalje imejl ili poziva plaćeni API.
• Pristojne greške. Korisnici treba da vide „nešto nije u redu”; detalji idu u vaše logove, a ne na ekran.
• Zamenite sve što je procurelo. Ako je živi ključ ikada nalepljen u čat, commit ili snimak ekrana, zamenite ga kod provajdera.

Upit koji pokriva dosta terena odjednom:

Pregledaj ovu aplikaciju za bezbednost u produkciji. Proveri da svaka API ruta potvrđuje da prijavljen korisnik poseduje zapis koji čita ili menja, 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 zahteva. Pre bilo kakve izmene izlistaj šta si našao.

Traženje liste prvo omogućava da vidite probleme i odlučite redosled, umesto da dobijete jednu ogromnu izmenu.

Korak 4: Znajte kada pukne — beleženje i praćenje

U pregledu vidite greške kako se dešavaju. U produkciji treba da vas aplikacija obavesti. Tri sloja, od najjeftinijeg do najkorisnijeg:

1. Serverski logovi. Proverite da se greške beleže sa dovoljno konteksta da se reprodukuju: koja ruta, koji ID korisnika (ne lozinka ni kartica), kakav oblik unosa. Zamolite AI da doda strukturisano beleženje ako aplikacija samo ispisuje u konzolu.
2. Praćenje grešaka. Usluga kao što je Sentry ili slična alatka hvata izuzetke na frontendu i backendu, grupiše ih i šalje vam imejl. Za malu aplikaciju besplatni planovi ovih usluga su često dovoljni; proverite aktuelna ograničenja na njihovim sajtovima.
3. Provere dostupnosti. Spoljašnja usluga koja učitava vašu početnu stranicu i jednu ključnu API rutu na svakih nekoliko minuta i šalje upozorenje ako ne uspe. Ovo hvata probleme koji zaustave aplikaciju da uopšte beleži.

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

Korak 5: Rezervne kopije i način za povratak

Dve različite stvari treba zaštititi, a lako ih je pomešati.

• Kod. Držite projekat u kontroli verzija da se svaka izmena može poništiti. Mnogi AI alati čuvaju tačke vraćanja vaših fajlova; sinhronizacija sa Git repozitorijumom daje vam kopiju i van alata.
• Podaci. Vraćanje koda ne vraća bazu podataka. Loša migracija ili pogrešno dugme za brisanje mogu uništiti redove koje nijedna tačka vraćanja koda neće vratiti.

Za podatke, podesite redovne rezervne kopije sačuvane negde van hostinga aplikacije — za Postgres bazu uobičajen je zakazani pg_dump na odvojenom skladištu, a mnogi upravljani hostovi baze nude automatske rezervne kopije ili oporavak do tačke u vremenu. Zatim uradite korak koji većina preskoči: vratite rezervnu kopiju u probnu bazu i proverite da su podaci tu.

Zamolite AI i da destruktivne radnje učini bezbednijim: korak potvrde za brisanje i „meko brisanje” (označavanje redova kao obrisanih umesto njihovog uklanjanja) za sve što korisnici možda žele da vrate.

Korak 6: Performanse koje drže na telefonu

Prototipi deluju brzo jer ste vi jedini korisnik i skup podataka je mali. Pre lansiranja:

• Učitajte podatke realne veličine. Zamolite AI da ubaci nekoliko hiljada redova i vidite koje stranice usporavaju. Liste obično traže 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. Zatražite promenjenu veličinu, kompresiju i lenjo učitavanje ispod linije vidljivog dela.
• Izmerite. Pokrenite Lighthouse u alatima za programere u Chrome-u na živom URL-u u mobilnom režimu. Google-ovi Core Web Vitals su razuman cilj: Largest Contentful Paint unutar 2,5 sekundi, Interaction to Next Paint 200 ms ili manje i Cumulative Layout Shift 0,1 ili manje.
• Pazite na kašnjenje „buđenja”. Hosting koji spava kada je neaktivan štedi novac, ali prva poseta posle tihog perioda je sporija. Za novu aplikaciju to je često prihvatljiva razmena; znajte da se dešava.

Stranica sa projektima je spora sa 5.000 redova. Dodaj paginaciju na serveru (25 po stranici), dodaj indekse baze za kolone koje filtriramo i sortiramo i prikaži stanje učitavanja dok se sledeća stranica učitava.

Korak 7: Operativne osnove

Nekoliko sitnica razdvaja hobi aplikaciju od one kojoj ljudi veruju:

• Prilagođeni domen sa HTTPS-om. Pogledajte kako povezati prilagođeni domen.
• Transakcioni imejl sa verifikovanog domena za potvrde registracije i resetovanje lozinke — obrađeno u kako slati imejlove iz aplikacije.
• Politika privatnosti i uslovi koji opisuju šta zaista prikupljate. Ne kopirajte tvrdnje o usklađenosti koje niste zaslužili.
• Kanal za podršku — makar nadgledana imejl adresa.
• Odvojeni test i živi ključevi za plaćanja i imejl, i jasna beleška koje okruženje koristi koje.

Korak 8: Čista predaja

Pre ili kasnije neko drugi će raditi na aplikaciji: frilenser, novi suosnivač ili vi za šest meseci. Olakšajte to:

• README koji objašnjava kako da je pokrenete, koje promenljive okruženja su potrebne (samo imena, nikada vrednosti) i kako je objaviti.
• Lista glavnih tokova i automatski testovi.
• Kratka beleška o arhitekturi: frontend, backend, baza, spoljašnje usluge i gde je svaka hostovana.
• Lista pristupa: ko ima administratorski pristup domenu, hostingu, bazi, nalozima za plaćanje i imejl. Stavite ove naloge pod poslovni imejl, a ne lični.
• Kod u Git-u, po mogućnosti sinhronizovan sa repozitorijumom koji posedujete. Ako kasnije možda menjate hosting, pročitajte kako izvesti i sami hostovati aplikaciju napravljenu uz AI.

AI može da napiše većinu ovoga za vas:

Napiši README za ovaj projekat za programera koji ga nikada nije video: šta aplikacija radi, tehnološki stek, kako da je pokrene lokalno, svaku promenljivu 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 da pristupi tuđim podacima”
• Autorizacija i validacija na serveru na svakoj ruti sa podacima
• Nema tajnih ključeva u kodu na frontendu; procureli ključevi zamenjeni
• Ograničenja broja zahteva za autentifikaciju i sve što košta novac
• Praćenje grešaka i provere dostupnosti šalju upozorenja u sandučetu koje čitate
• Rezervne kopije baze van hostinga aplikacije, sa jednim uspešnim probnim vraćanjem
• Paginacija i indeksi proverene sa realnim podacima
• Prilagođeni domen, verifikovani domen za slanje i politika privatnosti
• README i lista pristupa za sledećeg koji dolazi

Rad sa Mythex-om

Ako ste prototip napravili u Mythex-u, većina ovih koraka su upiti u istom projektu. Ukucajte /test i Mythex klikne kroz živi pregled kao korisnik i prijavi pokvarene tokove — pogledajte App Testing. Ključevi idu u tajne projekta, a ne u čat; svaka uspešna runda agenta sačuva tačku vraćanja vaših fajlova na koju se možete vratiti, a objavljivanje vam daje živi URL sa hostingom i bazom koji se naplaćuju sa istog kreditnog salda (limiti hostinga objašnjavaju kako se aplikacije i baze uspavljuju i bude). Tačke vraćanja pokrivaju fajlove, a ne redove baze, pa i dalje planirajte rezervne kopije podataka. Na planu Pro možete povezati prilagođeni domen i izvesti kod ili ga sinhronizovati sa sopstvenim GitHub repozitorijumom za predaju.

Pitanja