Paano Suriin ang Code na Ginawa ng AI

Para suriin ang code na ginawa ng AI, simulan sa kung ano ang nagbago — aling mga file at bakit — saka subukan mismo ang behaviour bago magbasa ng anumang linya ng code. Pagkatapos nito, tingnan ang mga bahaging madalas magkamali ang AI code: kulang na server-side na permission check, secrets na nakalantad sa browser, input na hindi na-validate, mga package o function na wala, at mga pagbabago sa bagay na hindi mo naman hiniling na galawin.

Madalas gumawa ang AI ng code na gumagana at kadalasang mukhang maayos. Dahil dito, madaling aprubahan ito nang hindi talaga sinusuri. Ito ay isang routine sa pagsusuri na gumagana kahit marunong ka o hindi sa pagbasa ng code.

Itugma ang pagsusuri sa panganib

Hindi lahat ng pagbabago ay nangangailangan ng parehong atensyon.

Hakbang 1: Tingnan kung ano ang nagbago

Bago husgahan ang code, kunin ang listahan ng mga pagbabago:

• Kung nasa Git ang project, tingnan ang diff: ang mga file at linyang nagbago mula sa huling commit. Tingnan ang paano gamitin ang Git sa app na binuo gamit ang AI.
• O direktang itanong sa AI:

Ilista ang bawat file na binago mo sa huling pagbabago, at para sa bawat isa, ipaliwanag sa isang pangungusap kung ano ang nagbago at bakit.

Mga pulang bandila sa yugtong ito: mga file na walang kinalaman sa hiling, mga binurang file, mga pagbabago sa configuration o dependencies na hindi mo hiniling.

Hakbang 2: Subukan muna ang behaviour

Sinasabi sa iyo ng pagbabasa ng code kung ano ang dapat nitong gawin; sinasabi sa iyo ng pagsubok kung ano ang aktuwal nitong ginagawa. Bago magbasa:

• Subukan ang pagbabago bilang normal na user, sa desktop at sa screen na kasing-laki ng telepono.
• Subukan ito ng maling input: walang laman na field, napakahabang teksto, negatibong numero, petsang nakaraan.
• Subukan ito na naka-logout, at bilang ibang user.
• Ulitin ang mga daloy na pinakamahalaga: sign up, log in, pangunahing aksyon, bayad.

Kapag pumalya ang pagsubok, nakatipid ka na ng oras sa pagbabasa — iulat ito nang malinaw at hayaang ayusin ito ng AI. Tingnan ang paano magsulat ng magandang bug report.

Hakbang 3: Suriin ang permissions sa server

Ito ang pinakamahalagang tingnan. Madalas itago ng mga AI tool ang button sa pahina pero iniiwan ang server na handang gawin ang aksyon para sa sinumang humiling.

Para sa bawat route o function na nagbabasa o nagbabago ng data, itanong:

• Tinitiyak ba nitong naka-login ang user?
• Tinitiyak ba nitong pinapayagan ang user na i-access ang partikular na record na ito?
• Nasa server ba ang check na iyon, hindi lang sa pahina?

Para sa bawat API route na idinagdag o binago mo, sabihin mo sa akin anong permission check ang ginagawa nito sa server, at i-quote ang linya. I-flag ang anumang route na walang check.

Pagkatapos, subukan ito: mag-log in bilang user A, itala ang ID ng isang record, mag-log in bilang user B at hilingin ito. Kumpleto ang pagsubok sa security checklist para sa mga app na binuo ng AI.

Hakbang 4: Maghanap ng nakalantad na secrets

• Hanapin sa mga binagong file ang anumang mukhang key o password.
• Tiyaking binabasa ang secret keys mula sa environment variables at ginagamit lamang sa server code.
• Bantayan ang mga public prefix gaya ng VITE_ o NEXT_PUBLIC_ sa mga secret variable — naka-build ang mga iyon sa browser code.

Tingnan ang paano panatilihing ligtas ang API keys.

Hakbang 5: Suriin ang input at mga error

• Validation sa server. Puwedeng laktawan ang mga check sa browser. Dapat ding suriin ng server ang mga kinakailangang field, haba, format at pinapayagang halaga.
• Gumagamit ng parameters ang database queries, hindi tekstong idinudugtong ang input ng user sa query.
• Hindi nilalamon ang mga error. Ang try/catch na walang ginagawa ay nagtatago ng pagkabigo. Dapat ma-log ang mga error, at malinaw na mensahe lang ang makikita ng user.
• Walang detalye ng loob na ipinapakita sa user — stack traces at database errors ay dapat nasa logs.

Hakbang 6: Tiyaking totoo ito

Minsan gumagawa ang AI models ng code na mukhang tama pero tumutukoy sa mga bagay na wala naman.

• Mga package: bawat bagong dependency ay dapat totoo, aktibong pinapanatili, at eksaktong ganoon ang pangalan. Mag-ingat sa mga pangalang mukhang typo ng sikat na package.
• Mga function at API option: kung tumatawag ang code ng library function o external API option na hindi mo pa nakikita, tingnan ang opisyal na dokumentasyon.
• Placeholder na code: hanapin ang TODO, mock, fake, hard-coded na sample data, o mga function na nagbabalik ng nakapirming halaga.

May idinagdag ka bang bagong package? Para sa bawat isa, ibigay ang eksaktong pangalan, para saan ito, at kung kaya nating wala ito.

Hakbang 7: Tingnan kung akma ito

Maaaring gumana ang code at gawing mas mahirap baguhin ang app sa hinaharap:

• Duplication. Ang parehong lohika na kinopya sa ilang lugar ay maghihiwalay sa paglipas ng panahon.
• Pagkakapare-pareho. Dapat sundin nito ang mga pattern na ginagamit ng iba pang bahagi ng app.
• Laki. Ang 20-linyang hiling na gumawa ng 600 linya ay nararapat tanungin.
• Dead code. Mga lumang bersyong naiwan sa tabi ng bago.

May code ba sa project na hindi na ginagamit dahil sa pagbabagong ito, o lohikang nakopya sa ibang lugar? Huwag munang baguhin ang anuman; ilista lang.

Mga karaniwang pagkakamali

• Pag-apruba dahil mukhang malinis. Ang maayos na code ay maaari pa ring lumaktaw sa permission check.
• Pagbabasa sa halip na pagsubok. Subukan muna; basa pagkatapos.
• Pagsubok lamang sa normal na daloy. Subukan ang maling input, maling user, at naka-logout.
• Pagbalewala sa mga hindi kaugnay na pagbabago sa file. Itanong kung bakit nagbago ang bawat file.
• Lubos na pagtitiwala sa sariling pagsusuri ng AI. Gamitin ang review ng AI bilang unang pagsusuri at kumpirmahin sa pagsubok.
• Pagsusuri ng isang linggong pagbabago nang sabay-sabay. Suriin ang maliliit na pagbabago habang nangyayari ang mga ito.

Checklist

• Alam ko kung aling mga file ang nagbago at bakit, at walang hindi kaugnay na nagbago.
• Gumagana ang pagbabago sa desktop at telepono, may maling input, naka-logout at bilang ibang user.
• Bawat data route ay tumitingin ng login at pagmamay-ari sa server.
• Walang secrets sa code o sa browser bundles.
• Sinusuri ang input sa server; gumagamit ng parameters ang queries.
• Nala-log ang mga error, hindi nilalamon, at hindi detalyadong ipinapakita sa user.
• Totoo at kailangan ang mga bagong package; walang imbentong function o placeholder na natitira.
• Ang mga pagbabagong mataas ang panganib ay dumaan sa maingat na pagbasa at, kung kailangan, ikalawang tagasuri.

Pagrepaso ng code sa Mythex

• Ask mode ay sumasagot sa mga tanong tungkol sa code nang hindi ito ine-edit — mainam para sa mga prompt na "ipaliwanag ang bawat pagbabago" at "aling mga route ang walang permission check". Tingnan ang Chat.
• Code view ay nagpapakita ng file tree, editor at terminal sa bawat plan (read-only sa Free, editable sa Pro), para mabasa mo mismo ang mga pagbabago. Tingnan ang Code editor.
• /test ay pinapa-click ng agent ang preview bilang user at iniuulat ang mga sirang daloy.
• Checkpoints ay nagpapahintulot na i-revert ang pagbabagong pumalya sa pagsusuri.

Kung may developer na nagre-review para sa iyo, sakop ng paano makipagtrabaho sa developer sa app na binuo ng AI ang paglilipat ng trabaho; kung may bug na lumabas sa pagsusuri, tingnan ang paano mag-debug ng app na binuo ng AI.

Mga tanong