Paano Gawing Production ang AI Prototype

Para gawing production ang AI prototype, isinasara mo ang agwat sa pagitan ng “gumagana kapag sinubukan ko” at “patuloy na gumagana kapag ginagamit ng ibang tao”. Sa praktika, limang bagay ito: subukan ang mga pangunahing daloy sa bawat pagbabago, i-lock kung sino ang makakakita at makakapagbago ng ano, tiyakin na malalaman mo ang mga error bago pa ito iulat ng mga user, i-back up ang datos at patunayang kaya mo itong i-restore, at panatilihing mabilis ang app sa telepono. Walang kailangang i-rewrite — isa itong checklist na sinusundan mo kasama ng parehong AI na gumawa ng prototype.

Prototype vs production: ano ang talagang nagbabago

Iisa lang ang maingat na user ng prototype: ikaw. Alam mo kung aling button ang pipindutin, nagta-type ka ng matinong input, at kapag may sumira, nagkikibit-balikat ka at hinihiling sa AI na ayusin. Sa production, maraming pabayang user, ilang mausisa, at paminsan-minsan isang mapanakit. Hindi kailangang maging “enterprise” ang code; kailangan lang nitong hawakan ang mga sitwasyong hindi nararanasan ng prototype.

Sinusundan ng natitirang bahagi ng gabay na ito ang bawat hanay.

Hakbang 1: I-freeze ang saklaw at isulat ang mga pangunahing daloy

Bago mo patigasin ang anuman, magpasya kung ano ang bersyon uno. Ilista ang tatlo hanggang anim na daloy na pinakamahalaga — halimbawa “mag-sign up, gumawa ng proyekto, mag-imbita ng kasamahan, magbayad”. Ito ang magiging test script mo, ang mga target ng monitoring, at ang mga bagay na sinusuri mo pagkatapos ng bawat pagbabago.

Anumang wala sa listahan ay puputulin o malinaw na lalagyan ng label na beta. Mas madaling gawing maaasahan ang apat na daloy kaysa labing-apat.

Hakbang 2: Subukan na parang estranghero, saka gawing paulit-ulit

Magaling ang mga AI builder sa code na gumagana sa happy path. Ang mga problema sa production ay nasa unhappy path. Subukan ang bawat pangunahing daloy gamit ang:

• Maling input: walang lamang required field, pangalang may 5,000 karakter, email na walang @, negatibong dami, petsang nakaraan.
• Refresh at back button: mag-reload sa kalagitnaan ng checkout; pindutin ang back pagkatapos magsumite ng form. May nagawa bang dalawang beses?
• Dalawang tab, dalawang user: mag-log in gamit ang dalawang magkaibang account at subukang buksan ang pahina ng isa't isa sa pamamagitan ng pagpalit ng ID sa URL.
• Mabagal at maliit: screen na kasing-laki ng telepono at mabagal na koneksyon (kayang gayahin ng browser dev tools).
• Walang laman na estado: bagong account na walang datos. Madalas na may sample data ang prototype kaya mukhang sira kapag wala ito.

Pagkatapos, gawing paulit-ulit ang pagsusuri. Sa pinakakaunti, magtago ng nakasulat na checklist at patakbuhin ito bago ang bawat release. Mas mabuti, hilingin sa AI na sumulat ng automated test para sa mga daloy na pinakamahalaga:

Magdagdag ng automated end-to-end test para sa mga daloy na ito: mag-sign up gamit ang email, gumawa ng proyekto, mag-imbita ng pangalawang user, at kumpletuhin ang checkout sa Stripe test mode. Magdagdag din ng test na nagkukumpirmang hindi makakakita o makakapag-edit ng proyekto ng ibang user ang isang user sa pamamagitan ng pagpalit ng URL.

Ang mga test na nagpapatunay na hindi kayang gawin ng user ang isang bagay ang kadalasang kulang sa mga prototype.

Hakbang 3: Mga pangunahing seguridad na nilalaktawan ng prototype

Hindi kakaiba ang karamihan sa problema sa seguridad ng mga app na gawa ng AI. Kulang lang ang mga tseke. Balikan ang listahang ito, at tingnan ang mas kumpletong security checklist para sa mga app na gawa ng AI:

• Awtorisasyon sa server. Hindi seguridad ang pagtatago ng button. Bawat request na nagbabasa o nagbabago ng datos ay dapat tumingin sa server kung pinapayagan ang naka-login na user. Kung may database na may row-level rules ang app mo, siguraduhing naka-on ito at nasubukan.
• Mga secret na wala sa browser. Ang mga API key para sa bayad, email, o AI provider ay dapat nasa server-side environment variables, hindi sa front-end code. Kung hindi ka sigurado kung ano ang ibig sabihin nito, basahin ang ano ang environment variables at secrets.
• Validation sa server. Maaaring lampasan ang browser, kaya ulitin sa server ang anumang tseke na mahalaga.
• Maayos na login. Gumamit ng well-tested na auth library o serbisyo sa halip na sariling password storage. Sakop ng gabay namin sa pagdaragdag ng login sa app mo ang mga pagpipilian.
• Rate limit sa login, sign-up, password reset, at anumang nagpapadala ng email o tumatawag sa bayad na API.
• Magiliw na error. Dapat makita ng user ang “may nangyaring mali”; ang detalye ay napupunta sa logs mo, hindi sa screen.
• Palitan ang anumang nalantad. Kung na-paste sa chat, commit, o screenshot ang live key, palitan ito sa provider.

Isang prompt na sumasaklaw sa maraming bagay nang sabay:

Suriin ang app na ito para sa seguridad sa production. Tiyakin na bawat API route ay nagbeberipika na pagmamay-ari ng naka-login na user ang record na binabasa o binabago nito, na walang secret key na ipinapadala sa browser, na bineberipika sa server ang mga input, at na may rate limit ang login at password reset. Ilista ang nakita mo bago magbago ng anuman.

Ang paghingi muna ng listahan ay nagbibigay-daan sa iyong makita ang mga problema at magpasya ng pagkakasunod-sunod, sa halip na makatanggap ng isang malaking pagbabago.

Hakbang 4: Malaman kapag may sira — logging at monitoring

Sa preview, nakikita mo ang mga error habang nangyayari. Sa production, kailangang ipaalam ng app sa iyo ang mga ito. Tatlong antas, mula sa pinakamura hanggang sa pinakakapaki-pakinabang:

1. Server logs. Siguraduhing nilo-log ang mga error nang sapat na konteksto para maulit ang mga ito: aling route, aling user ID (hindi password o card), anong hugis ng input. Hilingin sa AI na magdagdag ng structured logging kung console lang ang print ng app.
2. Error tracking. Ang serbisyo gaya ng Sentry o katulad na tool ay kumukuha ng front-end at back-end na exception, pinagpapangkat ang mga ito, at nagpapadala sa iyo ng email. Para sa maliit na app, kadalasang sapat na ang libreng tier ng mga serbisyong ito; tingnan ang kasalukuyang limitasyon sa kanilang site.
3. Uptime check. Panlabas na serbisyo na naglo-load ng home page mo at isang mahalagang API route bawat ilang minuto, at nagbababala kapag pumalya. Nahuhuli nito ang mga problemang pumipigil sa app na mag-log kahit kailan.

Idagdag ang isa pang gawi: pagkatapos ng bawat release, buksan ang live na app at patakbuhin ang checklist ng pangunahing daloy sa totoong URL, hindi lang sa preview.

Hakbang 5: Backup at paraan pabalik

Dalawang magkaibang bagay ang kailangang protektahan, at madaling malito ang mga ito.

• Code. Panatilihin ang proyekto sa version control para mabawi ang anumang pagbabago. Maraming AI builder ang nagtatago ng checkpoint ng mga file mo; ang pag-sync sa Git repository ay nagbibigay ng kopya sa labas ng builder.
• Datos. Hindi naibabalik ng pag-rollback ng code ang database. Ang masamang migration o sirang delete button ay maaaring makasira ng row na hindi maibabalik ng anumang code checkpoint.

Para sa datos, mag-set up ng regular na backup na nakaimbak sa ibang lugar kaysa sa hosting ng app — para sa Postgres database, karaniwang ginagamit ang naka-iskedyul na pg_dump papunta sa hiwalay na storage, at marami sa managed database host ang nag-aalok ng awtomatikong backup o point-in-time recovery. Pagkatapos, gawin ang hakbang na madalas nilalaktawan: i-restore ang backup sa scratch database at tingnan kung naroon ang datos.

Hilingin din sa AI na gawing mas ligtas ang mga mapanirang aksyon: hakbang ng kumpirmasyon para sa delete, at “soft delete” (pagmamarka ng row bilang burado sa halip na tanggalin nang tuluyan) para sa anumang maaaring gustong ibalik ng user.

Hakbang 6: Performance na kaya ng telepono

Mabilis ang pakiramdam ng prototype dahil ikaw lang ang user at maliit ang datos. Bago ilunsad:

• Mag-load ng totoong laki ng datos. Hilingin sa AI na maglagay ng ilang libong row at tingnan kung aling pahina ang bumabagal. Karaniwang kailangan ng pagination ang mga listahan, at karaniwang kailangan ng index sa database ang mga column na sinasala at sinasaayos mo.
• Paliitin ang larawan. Ang sobrang laking larawan ang pinakakaraniwang dahilan ng mabagal na page. Hilingin ang resized at compressed na larawan, at lazy loading sa ibaba ng fold.
• Sukatin. Patakbuhin ang Lighthouse sa Chrome dev tools sa live na URL sa mobile mode. Makatuwirang target ang Core Web Vitals ng Google: Largest Contentful Paint sa loob ng 2.5 segundo, Interaction to Next Paint na 200 ms o mas mababa, at Cumulative Layout Shift na 0.1 o mas mababa.
• Bantayan ang “wake-up” na pagkaantala. Ang hosting na natutulog kapag walang ginagawa ay nakakatipid ng pera pero nagpapabagal sa unang bisita pagkatapos ng tahimik na panahon. Kadalasang katanggap-tanggap ito para sa bagong app; alamin lang na nangyayari ito.

Mabagal ang pahina ng mga proyekto kapag may 5,000 row. Magdagdag ng server-side pagination (25 bawat pahina), magdagdag ng database index para sa mga column na sinasala at sinasaayos natin, at magpakita ng loading state habang nilo-load ang susunod na pahina.

Hakbang 7: Mga batayang operasyon

Ilang maliliit na bagay ang naghihiwalay sa hobby app at sa app na pinagkakatiwalaan ng tao:

• Custom domain na may HTTPS. Tingnan ang paano ikonekta ang custom domain.
• Transactional email mula sa beripikadong domain para sa sign-up confirmation at password reset — sakop ito ng paano magpadala ng email mula sa app mo.
• Privacy policy at terms na naglalarawan kung ano talaga ang kinokolekta mo. Huwag kopyahin ang mga pahayag sa pagsunod na hindi mo pa natutupad.
• Ruta ng suporta — kahit isang binabantayang email address.
• Magkahiwalay na test at live key para sa bayad at email, at malinaw na tala kung aling environment ang gumagamit ng alin.

Hakbang 8: Malinis na handover

Maya-maya ay may ibang gagawa sa app: isang freelancer, bagong co-founder, o ikaw pagkalipas ng anim na buwan. Gawing madali iyon:

• README na nagsasabi kung paano patakbuhin ito, aling environment variables ang kailangan nito (mga pangalan lang, hindi ang halaga), at kung paano ito i-deploy.
• Checklist ng pangunahing daloy at ang mga automated test.
• Maikling tala ng arkitektura: front end, back end, database, third-party na serbisyo, at kung saan naka-host ang bawat isa.
• Listahan ng access: sino ang may admin access sa domain, hosting, database, at mga account ng bayad at email. Ilagay ang mga account na ito sa business email, hindi sa personal.
• Code sa Git, mas mainam na naka-sync sa repository na pagmamay-ari mo. Kung posibleng ilipat mo ang hosting sa hinaharap, basahin ang paano i-export at i-self-host ang app na gawa ng AI.

Maaaring i-draft ng AI ang karamihan nito para sa iyo:

Sumulat ng README para sa proyektong ito para sa developer na hindi pa ito nakikita: ano ang ginagawa ng app, ang tech stack, paano ito patakbuhin nang lokal, bawat environment variable na binabasa nito (mga pangalan at layunin lamang), paano inayos ang database schema, at paano ito i-deploy.

Checklist ng kahandaan sa production

• Nakasulat at nasubukan ang mga pangunahing daloy, kasama ang “hindi makakapasok sa datos ng iba”
• Awtorisasyon at validation sa server sa bawat data route
• Walang secret key sa front-end code; napalitan ang mga nalantad na key
• Rate limit sa auth at anumang nagkakagastos
• Error tracking at uptime alert na nakaturo sa inbox na binabasa mo
• Backup ng database na wala sa hosting ng app, at isang matagumpay na test restore
• Nasuri ang pagination at index gamit ang makatotohanang datos
• Custom domain, beripikadong sending domain, privacy policy
• README at listahan ng access para sa susunod na tao

Paggawa nito gamit ang Mythex

Kung ginawa mo ang prototype sa Mythex, karamihan sa mga hakbang na ito ay prompt sa parehong proyekto. I-type ang /test at kakalikutin ng Mythex ang live preview na parang user at iuulat ang mga sirang daloy — tingnan ang App Testing. Napupunta ang mga key sa project secrets sa halip na sa chat, bawat matagumpay na turn ng agent ay nagse-save ng checkpoint ng mga file mo na maibabalik mo, at ang pag-publish ay nagbibigay ng live na URL na may hosting at database na sinisingil mula sa iisang credit balance (mga limitasyon ng hosting ang nagpapaliwanag kung paano natutulog at gumigising ang mga app at database). Sakop ng checkpoint ang mga file, hindi ang mga row ng database, kaya magplano pa rin ng backup ng datos. Sa Pro, puwede kang magkonekta ng custom domain at mag-export ng code, o mag-sync nito sa sarili mong GitHub repository para sa handover.

Mga tanong