Si ta çosh një prototip AI në prodhim

Për ta çuar një prototip AI në prodhim, mbyll hendekun mes “punon kur e provoj unë” dhe “vazhdon të punojë kur e përdorin të tjerët”. Në praktikë kjo do të thotë pesë gjëra: testo rrjedhat kryesore sa herë ndryshon diçka, kyç kush mund të shohë dhe ndryshojë çfarë, sigurohu që të dish për gabimet para se t’i tregojnë përdoruesit, bëj kopje rezervë të të dhënave dhe provo që mund t’i rikthesh, dhe mbaje aplikacionin mjaft të shpejtë në telefon. Asnjëra prej tyre nuk kërkon rishkrim — është një listë kontrolli që e kalon me të njëjtën AI që e ndërtoi prototipin.

Prototip kundrejt prodhimit: çfarë ndryshon vërtet

Një prototip ka një përdorues të kujdesshëm: ti. Di cilat butona të shtypësh, shkruan input të arsyeshëm, dhe nëse diçka prishet, ngre supet dhe i kërkon AI-së ta rregullojë. Prodhimi ka shumë përdorues të pakujdesshëm, disa kureshtarë, dhe rrallë një armiqësor. Kodi nuk ka nevojë të bëhet “i nivelit ndërmarrje”; ka nevojë të trajtojë situatat që një prototip nuk i takon kurrë.

Pjesa tjetër e këtij udhëzuesi kalon çdo rresht.

Hapi 1: Ngrije fushën dhe shkruaj rrjedhat kryesore

Para se të forcosh diçka, vendos çfarë është versioni i parë. Listo tre deri në gjashtë rrjedha që kanë më shumë rëndësi — për shembull “regjistrohu, krijo një projekt, fto një kolegë, paguaj”. Këto bëhen skripti yt i testimit, objektivat e monitorimit dhe gjërat që kontrollon pas çdo ndryshimi.

Çdo gjë që nuk është në listë ose hiqet, ose shënohet qartë si beta. Është shumë më e lehtë të bësh katër rrjedha të besueshme sesa katërmbëdhjetë.

Hapi 2: Testo si një i huaj, pastaj bëje të përsëritshëm

Mjetet e ndërtimit me AI janë të mira në prodhimin e kodit që funksionon në rrugën e drejtë. Problemet e prodhimit jetojnë në rrugët e pa-drejta. Testo çdo rrjedhë kryesore me:

• Input të keq: fusha të detyrueshme bosh, një emër me 5.000 karaktere, një email pa @, një sasi negative, një datë në të kaluarën.
• Rifreskime dhe butona kthimi: rifresko në mes të checkout-it; shtyp kthimin pas dërgimit të një formulari. A krijohet diçka dy herë?
• Dy skeda, dy përdorues: hyr me dy llogari të ndryshme dhe provo të hapësh faqet e njëri-tjetrit duke ndryshuar ID-në në URL.
• Ngadalë dhe i vogël: një ekran sa një telefon dhe një lidhje e kufizuar (mjetet e zhvilluesit të shfletuesit mund ta simulojnë atë).
• Gjendje bosh: një llogari krejt e re pa të dhëna. Prototipet shpesh ndërtohen me të dhëna shembull dhe duken të prishura pa to.

Pastaj bëje kontrollin të përsëritshëm. Të paktën, mbaj një listë kontrolli me shkrim dhe ekzekuto para çdo lançimi. Më mirë, kërko nga AI të shkruajë teste automatike për rrjedhat që kanë më shumë rëndësi:

Shto teste automatike nga fillimi në fund për këto rrjedha: regjistrim me email, krijim projekti, ftesë për një përdorues të dytë, dhe checkout në modalitetin test të Stripe. Shto gjithashtu teste që konfirmojnë se një përdorues nuk mund të shohë ose redaktojë projektin e një tjetri duke ndryshuar URL-në.

Testet që provojnë se një përdorues nuk mund të bëjë diçka janë ato që prototipet më shpesh i mungojnë.

Hapi 3: Bazat e sigurisë që prototipet i kalojnë

Shumica e problemeve të sigurisë në aplikacionet e ndërtuara me AI nuk janë ekzotike. Janë kontrolle që mungojnë. Kalo këtë listë, dhe shiko listën e plotë të sigurisë për aplikacionet e ndërtuara me AI:

• Autorizimi në server. Fshehja e një butoni nuk është siguri. Çdo kërkesë që lexon ose ndryshon të dhëna duhet të kontrollojë, në server, që përdoruesi i hyrë lejohet ta bëjë atë. Nëse aplikacioni yt përdor një bazë të dhënash me rregulla në nivel rreshti, kontrollo që janë të aktivizuara dhe të testuara.
• Sekretet jashtë shfletuesit. Çelësat API për pagesa, email ose ofrues AI u përkasin variablave të mjedisit në server, kurrë në kodin e frontend-it. Nëse nuk je i sigurt se çfarë do të thotë kjo, lexo çfarë janë variablat e mjedisit dhe sekretet.
• Validimi në server. Shfletuesi mund të anashkalohet, kështu që përsërit çdo kontroll që ka rëndësi edhe në server.
• Hyrje e bërë siç duhet. Përdor një bibliotekë ose shërbim autentikimi të testuar mirë, në vend të ruajtjes së fjalëkalimeve me dorë. Si të shtosh hyrje në aplikacionin tënd mbulon opsionet.
• Kufij shpejtësie për hyrjen, regjistrimin, rivendosjen e fjalëkalimit dhe çdo gjë që dërgon email ose thërret një API me pagesë.
• Gabime miqësore. Përdoruesit duhet të shohin “diçka shkoi keq”; detajet shkojnë te regjistrat e tu, jo në ekran.
• Rrotullo çdo gjë që ka rrjedhur. Nëse një çelës live është ngjitur ndonjëherë në një bisedë, commit ose screenshot, zëvendëso te ofruesi.

Një kërkesë që mbulon shumë tokë njëherësh:

Rishiko këtë aplikacion për siguri në prodhim. Kontrollo që çdo rrugë API verifikon se përdoruesi i hyrë zotëron regjistrimin që lexon ose ndryshon, që asnjë çelës sekret nuk dërgohet te shfletuesi, që input-et validohen në server, dhe që hyrja dhe rivendosja e fjalëkalimit kanë kufi shpejtësie. Listo çfarë gjen para se të ndryshosh ndonjë gjë.

Kërkimi i një liste fillimisht të lejon të shohësh problemet dhe të vendosësh renditjen, në vend që të marrësh një ndryshim të madh.

Hapi 4: Dije kur prishet — regjistrimi dhe monitorimi

Në pamjen paraprake sheh gabimet ndërsa ndodhin. Në prodhim, aplikacioni duhet të të tregojë. Tri shtresa, nga më e lira te më e dobishmja:

1. Regjistrat e serverit. Sigurohu që gabimet regjistrohen me kontekst të mjaftueshëm për ta riprodhuar: cila rrugë, cili ID përdoruesi (jo fjalëkalimi ose kartela), çfarë forme ka input-i. Kërko nga AI të shtojë regjistrim të strukturuar nëse aplikacioni vetëm printon në console.
2. Gjurmimi i gabimeve. Një shërbim si Sentry ose një mjet i ngjashëm kap përjashtimet e frontend-it dhe të backend-it, i grupon dhe të dërgon email. Për një aplikacion të vogël, planet falas të këtyre shërbimeve shpesh mjaftojnë; kontrollo kufijtë aktualë në faqet e tyre.
3. Kontrolle disponueshmërie. Një shërbim i jashtëm që ngarkon faqen kryesore dhe një rrugë kryesore API çdo disa minuta dhe të njofton nëse dështon. Kjo kap problemet që ndalojnë aplikacionin së regjistruari fare.

Shto edhe një zakon: pas çdo lançimi, hap aplikacionin live dhe ekzekuto listën e rrjedhave kryesore në URL-në reale, jo vetëm në pamjen paraprake.

Hapi 5: Kopjet rezervë dhe një rrugë kthimi

Dy gjëra të ndryshme duhen mbrojtur, dhe është e lehtë t’i ngatërrosh.

• Kodi. Mbaje projektin në kontroll versioni, që çdo ndryshim të mund të zhbëhet. Shumë ndërtues AI mbajnë pika kontrolli të skedarëve; sinkronizimi me një repo Git të jep një kopje jashtë ndërtuesit.
• Të dhënat. Kthimi i kodit nuk kthen bazën e të dhënave. Një migrim i keq ose një buton fshirjeje me gabim mund të shkatërrojë rreshta që asnjë pikë kontrolli kodi nuk do t’i kthejë.

Për të dhënat, vendos kopje rezervë të rregullta të ruajtura diku tjetër përveç hostimit të aplikacionit — për një bazë Postgres, një pg_dump i planifikuar në hapësirë ruajtjeje të veçantë është qasja e zakonshme, dhe shumë host-e të menaxhuara të bazës ofrojnë kopje automatike ose rikthim në një pikë të caktuar kohore. Pastaj bëj hapin që shumica e njerëzve e harrojnë: rikthe një kopje rezervë në një bazë të përkohshme dhe kontrollo që të dhënat janë aty.

Kërko gjithashtu nga AI të bëjë veprimet shkatërruese më të sigurta: një hap konfirmimi për fshirjet, dhe “fshirje e butë” (shënim i rreshtave si të fshirë në vend që t’i heqësh) për gjëra që përdoruesit mund të dëshirojnë t’i rikthejnë.

Hapi 6: Performancë që qëndron në telefon

Prototipet duken të shpejta sepse ti je i vetmi përdorues dhe grupi i të dhënave është i vogël. Përpara lançimit:

• Ngarko të dhëna me madhësi reale. Kërko nga AI të mbjellë disa mijëra rreshta dhe shiko cilat faqe ngadalësohen. Listat zakonisht kanë nevojë për faqosje (pagination), dhe baza e të dhënave zakonisht ka nevojë për indekse në kolonat që filtron dhe renditen sipas tyre.
• Zvogëlo imazhet. Imazhet e mëdha janë arsyeja më e shpeshtë që një faqe ngarkohet ngadalë. Kërko imazhe të ripërmasuara, të kompresuara dhe ngarkim të vonuar poshtë dukshmërisë fillestare.
• Mat. Ekzekuto Lighthouse te mjetet e zhvilluesit të Chrome në URL-në live, në modalitet celulari. Metrikat Core Web Vitals të Google janë objektiv i arsyeshëm: Largest Contentful Paint brenda 2.5 sekondash, Interaction to Next Paint 200 ms ose më pak, dhe Cumulative Layout Shift 0.1 ose më pak.
• Kujdes për vonesat e “zgjimit”. Hostimi që fle kur nuk përdoret kursen para, por e bën vizitën e parë pas një periudhe të qetë më të ngadaltë. Për një aplikacion të ri, ky është shpesh një kompromis i mirë; dije që ndodh.

Faqja e projekteve është e ngadaltë me 5.000 rreshta. Shto faqosje në server (25 për faqe), shto indekse në bazën e të dhënave për kolonat që filtrohen dhe renditen, dhe shfaq një gjendje ngarkimi kur ngarkohet faqja tjetër.

Hapi 7: Gjërat e vogla operative

Disa gjëra të vogla e ndajnë një aplikacion hobi nga një që njerëzit e besojnë:

• Një domen të personalizuar me HTTPS. Shiko si të lidhësh një domen të personalizuar.
• Email transaksional nga një domen i verifikuar për konfirmimet e regjistrimit dhe rivendosjet e fjalëkalimit — i mbuluar në si të dërgosh email-e nga aplikacioni yt.
• Politikë privatësie dhe kushte që përshkruajnë atë që mbledh realisht. Mos kopjo pretendime pajtueshmërie që nuk i ke fituar.
• Një rrugë mbështetjeje — edhe një adresë email e monitoruar.
• Çelësa të ndarë testi dhe live për pagesat dhe email-in, dhe një shënim të qartë se cili mjedis përdor cilët.

Hapi 8: Një dorëzim i pastër

Herët a vonë dikush tjetër do të punojë në aplikacion: një freelancer, një bashkëthemelues i ri, ose ti pas gjashtë muajsh. Bëje të lehtë:

• Një README që thotë si ta ekzekutosh, cilat variabla mjedisi u nevojiten (vetëm emrat, kurrë vlerat), dhe si ta deployosh.
• Listën e rrjedhave kryesore dhe testet automatike.
• Një shënim të shkurtër arkitekture: frontend, backend, baza e të dhënave, shërbimet e palëve të treta, dhe ku hostohet secila.
• Listë qasjeje: kush ka qasje admin te domeni, hostimi, baza e të dhënave, llogaritë e pagesave dhe email-it. Vendosi këto llogari nën një email biznesi, jo atë personal.
• Kodi në Git, më mirë i sinkronizuar me një repo që zotëron ti. Nëse mund të zhvendosësh hostimin më vonë, lexo si të eksportosh dhe të hostosh vetë një aplikacion të ndërtuar me AI.

AI mund ta hartojë shumicën e kësaj për ty:

Shkruaj një README për këtë projekt për një zhvillues që nuk e ka parë kurrë: çfarë bën aplikacioni, stack-u teknik, si ta ekzekutosh lokalisht, çdo variabël mjedisi që lexon (vetëm emrat dhe qëllimin), si është organizuar skema e bazës së të dhënave, dhe si ta deployosh.

Listë kontrolli për gatishmërinë në prodhim

• Rrjedhat kryesore shkruara dhe të testuara, përfshirë “s’mund të qasë të dhënat e dikujt tjetër”
• Autorizim dhe validim në server në çdo rrugë të të dhënave
• Asnjë çelës sekret në kodin e frontend-it; çelësat e rrjedhur të rrotulluar
• Kufij shpejtësie në autentikim dhe në çdo gjë që kushton para
• Gjurmimi i gabimeve dhe alarmet e disponueshmërisë që tregojnë në një inbox që lexon
• Kopje rezervë të bazës së të dhënave jashtë hostimit të aplikacionit, me një rikthim të suksesshëm testi
• Faqosja dhe indekset të kontrolluara me të dhëna reale
• Domen i personalizuar, domen i verifikuar për dërgim email, politikë privatësie
• README dhe listë qasjeje për atë që vjen pas

Ta bësh këtë me Mythex

Nëse e ke ndërtuar prototipin në Mythex, shumica e këtyre hapave janë kërkesa në të njëjtin projekt. Shkruaj /test dhe Mythex klikon nëpër pamjen paraprake live si përdorues dhe raporton rrjedhat e prishura — shiko App Testing. Çelësat shkojnë te sekretet e projektit, jo në bisedë; çdo turn i suksesshëm i agjentit ruan një pikë kontrolli të skedarëve tu, ku mund të kthehesh, dhe publikimi të jep një URL live me hostim, ndërsa baza e të dhënave faturohet nga i njëjti balancë kredie (kufijtë e hostimit shpjegon si fle dhe zgjohet aplikacionet dhe bazat e të dhënave). Pikat e kontrollit mbulojnë skedarët, jo rreshtat e bazës së të dhënave, kështu që planifiko ende kopjet rezervë të të dhënave. Në Pro mund të lidhësh një domen të personalizuar dhe të eksportosh kodin ose ta sinkronizosh me repon tënd GitHub për dorëzim.

Pyetje