Kako preveriti kodo, ki jo je ustvaril AI, če ne znate brati kode: 7 preverjanj za neprogramerje v letu 2026

AI je za vas v enem večeru sestavil spletno mesto ali bota. Vse se odpre, gumbi delujejo in zdi se, da vse teče. Projekt pokažete ljudem, dan pozneje pa ugotovite, da plačilni obrazec zaračuna denar, naročila pa nikoli ne prispejo. Ali pa da je zbirka podatkov s telefonskimi številkami strank odprta za ves internet.

Tudi sam sem tako objavljal svoje prve projekte: stvari, ki so bile videti delujoče, so presenetile resnične uporabnike. Zdaj pred vsako predstavitvijo projekta drugim preverim projekt po istem kontrolnem seznamu. Pri tem ne preberem niti ene vrstice kode — nisem prišel zaradi tega, pa verjetno tudi vi ne.

In to ni paranoja. Anthropic je analiziral 400.000 sej Claude Code: v sedmih mesecih se je delež dela, namenjenega odpravljanju nedelujoče kode, zmanjšal s 33% na 19%. Delež se je zmanjšal, vendar ni izginil. Vsaka peta seja je še vedno namenjena temu, da »popravi, kar je pokvaril AI«.

Pisanje kode samo po sebi ni več ozko grlo. Zdaj je pomembno, kako dobro razumete nalogo in kako dobro znate preveriti rezultat.

Dodatna gradiva o nastavitvi orodij so na voljo v dokumentaciji Ailoot.

Zakaj preverjati kodo, ki jo je ustvaril AI, če že deluje?#

AI napiše kodo, ki je na prvi pogled videti v redu. Zažene se, zaslon se prikaže in predstavitev je prepričljiva. Toda zagon vam ne pove, ali se denar izračunava pravilno, ali je vaša zbirka podatkov izpostavljena navzven ali pa se bo vse sesulo, ko prispe stoti uporabnik.

Številke to potrjujejo. Preizkus FrontierCode je junija 2026 preveril, kako pripravljena je bila koda, ki jo je ustvaril AI, za resnično delo brez sprememb. Tudi pri najboljših modelih za najtežje naloge je bil delež približno 13%. Z drugimi besedami, pri zahtevnih nalogah je treba večino kode, ki jo ustvari AI, ročno dodelati, preden se lahko zanesete nanjo.

Dobra novica je, da lahko preverjanje opravi vsakdo. To je Anthropic ugotovil na podlagi istih 400.000 sej:

Vaša prednost pred katerim koli programerjem, ki ga najamete, je v tem, da razumete svojo nalogo. Tudi preverjanje temelji na razumevanju; kode vam za to ni treba brati. Spodaj so ravno takšna preverjanja, ki jih lahko brez težav opravite sami.

Kaj gre lahko narobe pri kodi, ki jo ustvari AI?#

Pred preverjanjem je koristno vedeti, kaj iščete. Koda, ki jo ustvari AI, ima pet tipičnih težav. Vseh pet lahko opazite brez branja kode, tako da spremljate, kako se projekt obnaša.

Sledi sedem preverjanj po vrsti. Prvo odkrije težavi »ne deluje« in »deluje napačno«; srednja se osredotočajo na varnost in izmišljotine; zadnja pa so varovalke pred objavo. Najbolje jih je opraviti zaporedno: vsako temelji na tem, da je bilo prejšnje preverjanje dokončano.

Preverjanje 1: Prosite AI, naj svojo kodo pojasni z običajnimi besedami#

Nalogo ste opisali z besedami. AI jo je prevedel v kodo. Med tema korakoma se lahko pomen izgubi: AI vas je morda razumel drugače, se odločil namesto vas ali ubiral bližnjice. Neskladje lahko odkrijete brez branja kode — samo prosite ga, naj z običajnimi besedami opiše, kaj je naredil.

Z običajnimi besedami in brez kode natančno pojasni, kaj si pravkar naredil:

katero nalogo rešuje ta koda

kaj se bo zgodilo, ko uporabnik klikne gumb ali pošlje obrazec

kje so shranjeni podatki in kdo ima dostop do njih

kaj bi lahko šlo narobe in v kateri situaciji

Piši, kot da bi pojasnjeval nekomu, ki še nikoli ni programiral. Če za kateri koli del nisi prepričan, da je pravilen, to jasno povej.

Preberite odgovor in ga primerjajte s tem, kar ste imeli v mislih. Če se ujema, nadaljujte. Če AI »blebeta«, se zmede v lastni razlagi ali opisuje nekaj drugega od tega, kar ste zahtevali, pomeni, da ne razume povsem, kaj je ustvaril. Zahtevajte popravke in pojasnite, kaj ste mislili, namesto da mu preprosto verjamete.

Mimogrede, če AI pogosto naredi nekaj drugega od tega, kar ste zahtevali, je težava pogosto v tem, kako ste oblikovali nalogo, in ne v samem modelu. Ločeno sem razčlenil, zakaj Claude ne naredi tega, kar ste zahtevali.

Preverjanje rezultatov AI je del inženiringa konteksta: nadzorujete tako to, kaj AI-ju posredujete kot vhod, kot tudi to, kako ocenite rezultat kot izhod.

Preverjanje 2: Preizkusite scenarije tako, kot bi jih resnični uporabnik#

Predstavitev AI vedno sledi idealnemu scenariju: pravilni podatki, en klik, vse se izide. Resnični uporabnik se ne vede tako. Naredi napako, klikne napačno stvar ali v polje za telefon vnese emoji. Vaša naloga je, da greste skozi projekt tako, kot bi šel uporabnik.

1. Izvedite glavni scenarij od začetka do konca

   Naredite to, čemur je projekt namenjen: registrirajte se, oddajte naročilo, pošljite zahtevo. Pojdite do konca, ne ustavite se na polovici.

2. Plačilo preverite ločeno in v praksi

   Če projekt sprejema denar, v testnem načinu sami izvedite plačilo najmanjšega zneska. Prepričajte se, da je bilo naročilo ustvarjeno, da se je stanje spremenilo in da ste vi in stranka prejeli e-pošto. Plačilo, ki »gre skozi«, vendar ne ustvari naročila, je klasična tiha napaka.

3. Namenoma povzročite težave

   Pustite polja prazna. Namesto številk vnesite črke. Dvakrat zapored kliknite »Pošlji«. Naložite datoteko v napačnem formatu. Dober projekt bo vljudno sporočil: »tega ne morete narediti«; slab se bo sesul ali tiho zavrgel podatke.

4. Odprite projekt na telefonu

   Polovica uporabnikov bo prišla prek telefona. Preverite, ali je postavitev še vedno urejena in ali tam delujejo isti gumbi.

Vse, kar ste odkrili, AI-ju podajte v enem seznamu: »To se je v teh korakih pokvarilo; popravi in pojasni, zakaj se je to zgodilo.« Težav ne obravnavajte eno po eno — posredujte mu celoten seznam, da bo videl širšo sliko in manj verjetno pokvaril eno stvar, medtem ko popravlja drugo.

Preverjanje 3: Vprašajte AI o varnosti — tukaj je poziv#

Nedelujoč gumb opazite takoj. Varnostne luknje ne: projekt deluje, kot da je vse v redu, dokler je nekdo ne izkoristi. Najpogostejše težave pri projektih, ustvarjenih z vibe codingom, so skrivni ključi, zapisani neposredno v kodi, zbirka podatkov, izpostavljena internetu, in obrazci, ki nekomu omogočajo pošiljanje zlonamernih vnosov. AI lahko vse to najde, če ga vprašate neposredno.

Preglej ta projekt glede varnostnih težav in vsako ugotovitev pojasni z običajnimi besedami, brez žargona. Preveri naslednji seznam:

Preveri, ali so v kodi neposredno zapisani skrivni ključi, gesla ali žetoni. Zasebne skrivnosti se smejo uporabljati samo na strežniku, lokalna konfiguracija, kot je .env, pa mora biti izključena iz Gita. Datoteka .env in .gitignore ne preprečita vključitve javnih spremenljivk frontenda v gradnjo za brskalnik. Preglejte dejanski JavaScript, zemljevide izvorne kode, HTML in omrežne odgovore za odjemalca ter preverite odsotnost zasebnih ključev.

Preveri, ali je zbirka podatkov izpostavljena internetu in kdo ima dostop do nje.

Preveri, ali lahko vnos pokvari obrazce: z vstavljanjem v poizvedbe zbirke podatkov ali z dodatno kodo v besedilnih poljih.

Kaj se bo zgodilo, če uporabnik pošlje zlonamerne podatke?

Preveri, ali so katere notranje strani ali skrbniška plošča izpostavljene brez gesla.

Za vsako točko povej, ali obstaja težava, navedi jasen primer tveganja in pojasni, kako jo odpraviti. Začni z najnevarnejšo težavo.

Preverite tudi, ali vaš projekt slepo naredi vse, kar prejme od zunaj. Temu pravimo posredna prompt injection: ukaz je skrit v e-pošti, komentarju ali datoteki nekoga drugega, vaš agent AI pa mu sledi, ker ga zamenja za nalogo. Če projekt bere zunanje podatke in na njihovi podlagi ukrepa, vprašajte AI, kaj bi se zgodilo, če bi ti podatki vsebovali skrito navodilo.

To je obsežna tema, ki je en sam poziv ne more v celoti pokriti. Če projekt obdeluje denar ali osebne podatke strank, preberite ločen vodnik o varnosti vibe codinga.

Preverjanje 4: Ali si je AI izmislil knjižnice ali podatke?#

AI samozavestno napiše stvari, ki ne obstajajo. Morda doda knjižnico z verjetnim imenom, ki v resnici ne obstaja. V projektu lahko pusti testna nadomestila: izdelek z imenom »Example«, e-poštni naslov example@example.com ali nadomestno besedilo namesto prave vsebine. V predstavitvi to zlahka spregledate, za resničnega uporabnika pa je to neprijetno ali pa ne deluje.

To lahko odkrijete v dveh korakih. Najprej vprašajte neposredno:

Preglej projekt in pošteno preveri:

Ali vsa zunanja orodja in knjižnice, ki si jih dodal, zares obstajajo in se pravilno namestijo? Si si kaj izmislil?

Ali so namesto resničnih podatkov še vedno prisotna testna nadomestila, primeri ali nadomestno besedilo?

Ali so vse povezave, naslovi in kontaktni podatki v projektu resnični in ne nadomestila?

Naštej, kaj si našel, in predlagaj, s čim to nadomestiti.

Drugič preprosto zaženite projekt in si ga oglejte. Izmišljena knjižnica ob zagonu skoraj vedno povzroči napako. Nadomestila pa zlahka opazite: če na strani piše »Izdelek 1«, jih še niste zamenjali.

Izmišljene knjižnice so še posebej nevarne, ker napadalci namenoma registrirajo orodja z imeni, ki si jih AI rad izmisli. Če tako orodje namestite, v vaš projekt pride tuja koda. Zato vprašanje »ali ta knjižnica sploh obstaja?« vzemite resno — neposredno gre za varnost vašega projekta.

Preverjanje 5: Naj drugi model preveri prvega#

AI ima neprijetno lastnost: strinja se. Vprašajte: »Je tukaj vse v redu?« in potrdil bo, da je, ker se prilagodi pričakovanemu odgovoru. Temu pravimo prilizovanje AI-ja, o katerem sem pisal v ločenem članku. Tak sogovornik bo do lastnega dela prizanesljiv.

Rešitev je preprosta: pridobite drugo mnenje. Odprite novo sejo ali uporabite drug model in mu dajte projekt v pregled z istim pozivom iz 3. preverjanja ter dodatkom: »to kodo je napisal drug AI; poišči njene šibke točke«. Nov model ni vezan na prejšnji pogovor in bo verjetneje opozoril na težave.

1. Odprite čisto sejo ali uporabite drug model

   Uporabite drugi model ali istega v novem oknu brez zgodovine nalog.

2. Predajte mu projekt in ga pravilno usmerite

   Jasno povejte: »to kodo je napisal drug AI; tvoja naloga je poiskati napake in tveganja, ne pa je hvaliti«. Tako omejite prilizovanje.

3. Primerjajte obe mnenji

   Če se obe ujemata, imata verjetno prav. Če se ne strinjata, preverite to točko — tam postane zanimivo.

Točno to se zdaj dogaja v panogi: AI piše, AI preverja, končna odločitev pa ostane človeku. Odločitve ne morete prepustiti modelu — to je vaša naloga.

Preverjanje 6: Kako povrniti stanje, če sprememba kaj pokvari?#

Preverjanja s tega seznama pogosto vodijo do sprememb, spremembe pa včasih pokvarijo nekaj, kar je delovalo. Da se to ne sprevrže v katastrofo, pred vsakim krogom popravkov shranite delujočo različico v git. To je kot shranjevanje igre: če kaj pokvarite, naložite zadnjo shranjeno točko.

Za to vam ni treba brati kode. Samo prosite AI: »preden kaj spremeniš, shrani trenutno delujočo različico v git z jasno oznako«. Če se po spremembah vse podre: »povrni projekt na prej shranjeno različico«.

Če vam je git še vedno tuj, imam za vas dva vodnika: kako povrniti spremembe v Claude Code in kaj storiti, če je AI izbrisal vašo zbirko podatkov. Drugi je namenjen primeru, ko je za povrnitev že prepozno, vendar lahko podatke še vedno obnovite.

Preverjanje 7: Kaj nazadnje preveriti pred objavo?#

Prvih šest preverjanj se nanaša na to, kaj počne koda. Sedmo preveri, ali je projekt pripravljen na srečanje z ljudmi. Tu se ljudje najpogosteje spotaknejo: projekt deluje, vendar pozabijo plačilo preklopiti s testnega ključa na produkcijskega, zato prve stranke plačajo »zares-nezares«.

1. Plačilo: s testnega na produkcijsko

   Če sprejemate plačila, se prepričajte, da je povezan produkcijski ključ plačilnega sistema in ne testni. Opravite eno resnično plačilo z najmanjšim zneskom in ga vrnite sami sebi.

2. Skrivnosti so tam, kamor sodijo

   Vprašajte AI: »Ali se zasebni ključi uporabljajo samo na strežniku in je .env izključen iz Gita? Ali dejanska gradnja za brskalnik ali kateri odgovor odjemalcu vsebuje zasebni ključ, tudi prek javnih spremenljivk frontenda ali zemljevidov izvorne kode?« Preverite zgrajene datoteke in omrežne odgovore brskalnika, ne samo izvorne .env. Izključitev iz Gita vrednosti ne odstrani iz paketa frontenda.

3. Varnostno kopirajte podatke

   Poskrbite, da se zbirka podatkov nekje samodejno shranjuje. Če se projekt izvaja na vašem strežniku, v vodniku Coolify pojasnjujem, kaj storiti glede objave.

4. Objavljeni projekt deluje tudi zunaj vaše naprave

   Projekt odprite v telefonu prek zunanje povezave, ne le v svojem računalniku. Nekaj, kar deluje lokalno, po objavi ne deluje vedno.

Opravite vse štiri korake in projekt boste lahko brez skrbi pokazali ljudem. Če kaj ne prestane preverjanja, je bolje zdaj porabiti pol ure, kot se pozneje ukvarjati z nezadovoljnimi strankami.

Kaj če preverjanje traja predolgo — ali naj AI preprosto zaupate?#

Razumem skušnjavo. Preverjanje se zdi dolgočasno in »ne zato sem dobil AI«. Toda za rezultat ste odgovorni vi, ne model. AI nima ugleda in ne nosi posledic: ustvaril je kodo in nanjo pozabil. Vi boste odgovarjali stranki, ki ji plačilo ni bilo izvedeno.

Ustvarjalec Claude Code ima še širši pogled:

Pisanje kode ni več ozko grlo — za to je poskrbel AI. Zdaj je vrednost drugje: v razumevanju naloge in preverjanju nastalega. To je vaša prednost — bolje kot kateri koli zunanji razvijalec veste, kakšen mora biti rezultat za vašo stranko.

Zakaj je preverjanje veščina in ne enkratna naloga?#

Teh sedem preverjanj je minimum, ki ločuje »zagnal sem in upam« od »zagnal sem in vem, da deluje«. Opravite jih enkrat in večino presenečenj boste odkrili, še preden jih odkrijejo vaše stranke.

Od tam naprej to postane navada. AI-ju za vhod podajte pravi kontekst, rezultat pa preverite kot izhod, in vsak nov projekt bo nastal hitreje, ker ne boste začenjali od začetka.

Dodatna gradiva o uporabi orodij najdete v dokumentaciji Ailoot.