Si të shqyrtosh kodin e gjeneruar nga AI

Për të shqyrtuar kodin e gjeneruar nga AI, fillo me atë që ndryshoi — cilat skedarë dhe pse — pastaj testo sjelljen vetë përpara se të lexosh ndonjë rresht kodi. Pas kësaj, kontrollo zonat ku kodi i AI-së më shpesh gabon: mungesën e kontrolleve të lejeve në server, sekretet e ekspozuara ndaj shfletuesit, inpute të pavalidueshme, paketa ose funksione që nuk ekzistojnë, dhe ndryshime në gjëra që nuk i ke kërkuar kurrë të prekë.

AI shkruan kod që zakonisht funksionon dhe shpesh duket i pastër. Kjo e bën të lehtë për ta miratuar pa e kontrolluar me të vërtetë. Ky udhëzues është një rutinë shqyrtimi që funksionon nëse e lexon kodin rrjedhshëm ose aspak.

Përshtat shqyrtimin me rrezikun

Nuk çdo ndryshim ka nevojë për të njëjtën vëmendje.

Hapi 1: Shiko çfarë ndryshoi

Para se të gjykosh kodin, merr listën e ndryshimeve:

• Nëse projekti është në Git, shiko diff-in: skedarët dhe rreshtat që kanë ndryshuar që nga commit-i i fundit. Shih si të përdorësh Git me një aplikacion të ndërtuar me AI.
• Ose pyet AI-në drejtpërdrejt:

Listo çdo skedar që ke ndryshuar në ndryshimin e fundit, dhe për secilin shpjego në një fjali çfarë ndryshoi dhe pse.

Sinjale alarmi në këtë fazë: skedarë që nuk lidhen me kërkesën, skedarë të fshirë, ndryshime në konfigurim ose varësi që nuk i ke kërkuar.

Hapi 2: Testo sjelljen fillimisht

Leximi i kodit të tregon çfarë synon të bëjë; testimi të tregon çfarë bën me të vërtetë. Përpara leximit:

• Provo ndryshimin si përdorues normal, në desktop dhe në një ekran me madhësinë e telefonit.
• Provo me inpute të gabuara: fusha bosh, tekst shumë i gjatë, numra negativë, një datë të kaluar.
• Provo të çkyçur, dhe si një përdorues tjetër.
• Rifillo rrjedhat më të rëndësishme: regjistrimi, login-i, veprimi kryesor, pagesa.

Nëse testimi dështon, ke kursyer kohën e leximit — raporto qartë dhe lëre AI-në ta rregullojë. Shih si të shkruash një raport të mirë gabimi.

Hapi 3: Kontrollo lejet në server

Diçka më e rëndësishme për t’u kontrolluar. Mjetet e AI-së shpesh fshehin një buton në faqe, por e lënë serverin të gatshëm ta kryejë veprimin për këdo që e kërkon.

Për çdo rrugë ose funksion që lexon ose ndryshon të dhëna, pyet:

• A kontrollon që përdoruesi është kyçur?
• A kontrollon që ky përdorues ka leje të hyjë në këtë regjistrim?
• A është ky kontroll në server, jo vetëm në faqe?

Për çdo rrugë API që shtove ose ndryshove, më thuaj çfarë kontrolli leje bën në server, duke cituar rreshtin. Shëno çdo rrugë pa të.

Pastaj testoje: kyçu si përdoruesi A, shëno ID-në e një regjistrimi, kyçu si përdoruesi B dhe kërkoje atë. Lista e kontrollit të sigurisë për aplikacionet e ndërtuara me AI ka testin e plotë.

Hapi 4: Kërko sekrete të ekspozuara

• Kërko në skedarët e ndryshuar çdo gjë që duket si çelës ose fjalëkalim.
• Kontrollo që çelësat sekretë lexohen nga variablat e mjedisit dhe përdoren vetëm në kodin e serverit.
• Shiko për prefikse publike si VITE_ ose NEXT_PUBLIC_ te variablat sekretë — ato futen brenda kodit që shkarkon shfletuesi.

Shih si t’i mbash të sigurta çelësat API.

Hapi 5: Kontrollo inputet dhe gabimet

• Validimi në server. Kontrollet në shfletues mund të anashkalohen. Fushat e detyrueshme, gjatësitë, formatet dhe vlerat e lejuara duhet t’i kontrollojë edhe serveri.
• Query-t e bazës së të dhënave përdorin parametra, jo tekst të ndërtuar duke bashkuar input-in e përdoruesit në një query.
• Gabimet nuk fshihen. Një try/catch që nuk bën asgjë fsheh dështimet. Gabimet duhet të regjistrohen, dhe përdoruesit duhet të shohin një mesazh të qartë.
• Asnjë detaj i brendshëm nuk shfaqet te përdoruesit — stack trace-et dhe gabimet e bazës së të dhënave i takojnë logëve.

Hapi 6: Kontrollo që është real

Modelet e AI-së ndonjëherë prodhojnë kod që duket i saktë por i referohet gjërave që nuk ekzistojnë.

• Paketat: çdo varësi e re duhet të jetë një paketë reale, e mirëmbajtur, me emrin e saktë. Ki kujdes me emra që duken si gabime shkrimi të atyre të njohura.
• Funksionet dhe opsionet e API-t: nëse kodi thërret një funksion libërie ose një opsion API të jashtëm që nuk e ke parë kurrë, kontrollo dokumentacionin zyrtar.
• Kod placeholder: kërko për TODO, mock, fake, të dhëna shembull të ngurtësuara, ose funksione që kthejnë një vlerë fikse.

A ke shtuar ndonjë paketë të re? Për secilën jep emrin e saktë, për çfarë është, dhe nëse mund të bëjmë pa të.

Hapi 7: Kontrollo nëse përshtatet

Kodi mund të funksionojë dhe prapëseprapë ta bëjë aplikacionin më të vështirë për t’u ndryshuar më vonë:

• Përsëritja. E njëjta logjikë e kopjuar në disa vende do të shkëputet me kohën.
• Konsistenca. Duhet të ndjekë modelet që përdor pjesa tjetër e aplikacionit.
• Madhësia. Një kërkesë 20-rreshtëshe që prodhoi 600 rreshta meriton një pyetje.
• Kodi i vdekur. Versione të vjetra të lëna pranë atyre të reja.

A ka ndonjë kod në projekt që tani nuk përdoret për shkak të këtij ndryshimi, ose logjikë të dyfishuar diku tjetër? Mos ndrysho asgjë; thjesht listoje.

Gabimet e zakonshme

• Miratimi sepse duket i pastër. Kodi i rregullt mund të anashkalojë ende një kontroll leje.
• Lexo në vend që të testosh. Testo së pari; lexo pas.
• Testimi vetëm i rrjedhës së suksesshme. Provo inpute të këqija, përdoruesin e gabuar dhe të çkyçur.
• Injorimi i ndryshimeve të padashura të skedarëve. Pyet pse ndryshoi çdo skedar.
• Besimi i plotë te vetë-shqyrtimi. Përdore shqyrtimin e AI-së si kalim të parë dhe konfirmo me testim.
• Shqyrtimi i një jave ndryshimesh njëherësh. Shqyrto ndryshime të vogla ndërsa ndodhin.

Lista e kontrollit

• E di cilët skedarë ndryshuan dhe pse, dhe asgjë e pakërkuar nuk ndryshoi.
• Ndryshimi funksionon në desktop dhe në telefon, me inpute të gabuara, të çkyçur dhe si përdorues tjetër.
• Çdo rrugë e të dhënave kontrollon login-in dhe pronësinë në server.
• Asnjë sekret në kod ose në paketat e shfletuesit.
• Inputi validohet në server; query-t përdorin parametra.
• Gabimet regjistrohen, nuk fshihen, dhe nuk shfaqen në detaje te përdoruesit.
• Paketat e reja janë reale dhe të nevojshme; nuk mbeten funksione të shpikura ose placeholder.
• Ndryshimet me rrezik të lartë u lexuan me kujdes dhe, kur duhej, u shqyrtuan nga një person i dytë.

Shqyrtimi i kodit në Mythex

• Ask mode përgjigjet pyetjeve për kodin pa e ndryshuar — ideale për kërkesa si “shpjego çdo ndryshim” dhe “cilat rrugë nuk kanë kontroll leje”. Shih Chat.
• Pamja e kodit shfaq pemën e skedarëve, editorin dhe terminalin në çdo plan (vetëm për lexim në Free, i redaktueshëm në Pro), kështu që mund të lexosh vetë çfarë ndryshoi. Shih Code editor.
• /test e bën agjentin të klikojë nëpër pamjen paraprake si përdorues dhe të raportojë rrjedhat e prishura.
• Checkpoint-et të lejojnë të kthesh një ndryshim që dështon në shqyrtim.

Nëse një zhvillues po shqyrton për ty, si të punosh me një zhvillues mbi një aplikacion të ndërtuar me AI mbulon procesin e dorëzimit; nëse shqyrtimi zbulon një gabim, shih si të korrigjosh një aplikacion të ndërtuar me AI.

Pyetje