Vibe coding je promenio krug ljudi koji mogu da naprave aplikaciju koja deluje funkcionalno. Jedan prompt može da generiše ekrane, poveže API i sastavi uverljiv tok rada pre nego što tradicionalni inženjerski tim završi prvi pregled dizajna.

Ta brzina stvara novi problem pri zapošljavanju i isporuci: demonstracija više nije snažan dokaz da je softver dobar. Poslodavci će sve češće postavljati teže pitanje: može li ovaj sistem izgrađen pomoću veštačke inteligencije ispravno da se ponaša kada su ulazni podaci neuredni, zavisnosti otkažu, korisnici ponavljaju radnje, a osnovni model se promeni?

Odgovor će proisteći iz kriterijuma kvaliteta koji manje liči na vizuelnu doteranost, a više na disciplinovanu verifikaciju softvera. Izdvojiće se ljudi koji neće samo pokazati šta je alat za AI kodiranje proizveo. Pokazaće kako su ga testirali, šta on ne može bezbedno da radi i kako znaju da promena nije pokvarila nešto drugo.

Benchmark je dokaz, a ne rezultat na rang-listi

Benchmarkovi za agente za kodiranje otvorenog koda nude korisne polazne tačke, ali mere različite sposobnosti. SWE-bench koristi stvarne GitHub probleme i snimke repozitorijuma, zbog čega je relevantan za rad na održavanju. Terminal-Bench testira interakciju putem komandne linije. Ostali navedeni benchmarkovi, uključujući SlopCodeBench i ProgramBench, usmereni su na različite aspekte generisanog koda i ponašanja agenata.

Ti benchmarkovi mogu pomoći pri poređenju alata ili uspostavljanju početne vrednosti, ali poslodavci treba da budu oprezni kada bilo koji pojedinačni rezultat tretiraju kao dokaz spremnosti za produkciju. Model koji rešava probleme u repozitorijumu i dalje može da proizvede nebezbednu logiku autorizacije. Agent koji izvršava terminalske zadatke može da ne uspe da očuva stanje tokom dugog toka rada. Doterana veb-aplikacija može proći demonstraciju u idealnom slučaju, a da pritom pogrešno obrađuje ponovne pokušaje ili duplirana plaćanja.

Verodostojan portfolio ili interna revizija zato treba da obuhvati skup evaluacija specifičan za zadatak. Skup može sadržati reprezentativne prijave grešaka, uobičajene korisničke tokove, neispravne ulazne podatke, granice dozvola, otkaze zavisnosti i ranije ispravljene regresije. Svaki slučaj treba da ima izričito očekivani rezultat, a ne samo snimak ekrana koji izgleda ispravno.

Minimalni paket testova za softver izgrađen pomoću veštačke inteligencije

Za malu aplikaciju koristan paket testova kvaliteta može se napraviti bez složene istraživačke laboratorije:

  • Testovi prihvatanja: proveravaju ponašanje vidljivo korisniku u najvažnijim tokovima rada, uključujući uspešne i neuspešne ishode.
  • Jedinični i integracioni testovi: proveravaju poslovna pravila izolovano i potvrđuju da baze podataka, API-ji, redovi i autentifikacija rade zajedno kako je predviđeno.
  • Negativni testovi: šalju nedostajuće, neispravne, prevelike, duplirane i neovlašćene ulazne podatke. Kod generisan pomoću veštačke inteligencije često izgleda najbolje na putanji prikazanoj u promptu, pa su ne zatražene putanje važne.
  • Regresioni testovi: pretvaraju svaki otkriveni nedostatak u trajni test. Zelena demonstracija nakon ispravke nije dovoljna ako se isti problem može vratiti u sledećoj generisanoj promeni.
  • Bezbednosne provere: testiraju kontrolu pristupa, rukovanje tajnama, zaštitu od injekcija, ranjivosti zavisnosti i mogućnost da nepouzdan sadržaj utiče na pozive alata ili privilegovane radnje.
  • Operativne provere: proveravaju vremenska ograničenja, ponovne pokušaje, idempotentnost, evidentiranje, upozorenja i bezbedno ponašanje kada zavisnost nije dostupna.

Ovo je blisko načinu razmišljanja o QA inženjerstvu opisanom u Stack Overflow nalogu o agentnom životnom ciklusu razvoja softvera. Važan pomak je kulturološki: obezbeđivanje kvaliteta nije završna inspekcija nakon što je AI napisao kod. To je struktura koja brzo generisanje čini dovoljno bezbednim za upotrebu.

Testirajte orkestraciju, a ne samo rezultat

Kada softver uključuje AI agenta, uobičajeni testovi aplikacije jesu neophodni, ali nisu dovoljni. Sistem može da otkaže zato što je model pogrešno razumeo zahtev, ali i zato što je okolna orkestracija izgubila kontekst, pozvala alat dvaput, prihvatila neispravan strukturirani izlaz ili se nikada nije završila.

Preporučene oblasti regresije pre puštanja u rad iz ovog pregleda predstavljaju praktičnu kontrolnu listu: gubitak konteksta, idempotentnost alata, prompt injection, strukturirani izlaz, nezavršavanje, utemeljenost u pretraženim podacima i ponovno učitavanje stanja. To su inženjerska svojstva koja se mogu testirati.

Na primer, test može dva puta da pokrene isti zahtev i potvrdi da drugi pokušaj ne stvara dupliranu porudžbinu. Drugi može da prekine agenta usred toka rada, ponovo ga pokrene i proveri da li nastavlja iz važećeg stanja umesto da ponovi nepovratnu radnju. Test pretraživanja može zahtevati od sistema da navede ili vrati samo informacije iz odobrenog skupa izvora. Test strukturiranog izlaza može da prosledi neispravan odgovor i potvrdi da ga aplikacija bezbedno odbija umesto da ga neprimetno tretira kao važeće podatke.

Sistemima koji dugo rade i sistemima sa više agenata potrebni su naročito jasni zapisi o greškama. Istraživači rade na automatizovanom pripisivanju grešaka jer može biti teško utvrditi koji je agent izazvao grešku i u kom trenutku dugog lanca interakcija. U praktičnom smislu, timovi treba da čuvaju pozive alata, ulaze, izlaze, verzije modela, vremenske oznake, prelaze stanja i konačne odluke u revizijskom tragu koji vodi računa o privatnosti. Bez tih dokaza, crveni test vam govori da je nešto otkazalo, ali ne i odakle da počnete sa ispravkom.

Ponovljivost će postati prednost u karijeri

Kod generisan pomoću veštačke inteligencije je promenljiv. Ponovljeno pokretanje može proizvesti drugačiju implementaciju; ažuriranje modela može promeniti ponašanje; prekid rada provajdera može promeniti rutiranje ili kašnjenje. Poslodavci će zato ceniti kandidate koji umeju da učine evaluacije ponovljivim.

To znači fiksiranje snimaka modela gde je to moguće, beleženje promptova i konfiguracije, kontrolisanje slučajnosti kada platforma to dozvoljava i pokretanje više proba za zadatke čiji se ishodi razlikuju. U pregledu se posebno ukazuje na fiksirane snimke, nisku ili nultu temperaturu kada je dostupna i CI/CD kontrolne tačke ograničene nivoom pouzdanosti kao korisne zaštitne mere.

Praktičan izveštaj treba da razlikuje najmanje tri rezultata:

  1. Procenat uspešnosti: koliko je slučajeva uspešno rešeno.
  2. Doslednost: koliko često isti slučaj uspeva u ponovljenim pokretanjima.
  3. Ozbiljnost: da li su neuspešni ishodi kozmetički, nepraktični, štetni po podatke, relevantni za bezbednost ili mogu da izazovu nebezbednu spoljnu radnju.

Sistem koji prolazi 19 od 20 provera formatiranja niskog rizika nije nužno bolji od sistema koji prolazi 18 od 20 slučajeva, ali nikada ne prelazi granicu autorizacije. Prag kvaliteta mora da vrednuje neuspehe prema njihovim posledicama.

Ljudska provera treba da bude usmerena na rizik, a ne na svaki red

Svrha bolje automatizacije nije da primora osobu da ponovo čita svaki token koji proizvede AI. Ona treba da usmeri ljudsku pažnju na odluke koje testovi ne mogu u potpunosti da razreše.

Proveravaoci treba da se usredsrede na autentifikaciju i autorizaciju, zadržavanje podataka, finansijske ili ugovorne radnje, privatnost, migracije, oporavak od grešaka, dozvole trećih strana i promene koje utiču na sam sistem za evaluaciju. Kod agenta treba da provere i koje alate sme da poziva, kojim podacima svaki alat može da pristupi i da li je potrebno odobrenje pre nepovratne radnje.

Vidljive razlike, tokovi odobravanja, arhivirane konverzacije i dnevnici revizije—funkcije istaknute u opisu Slack Code-a za kolaborativno AI programiranje—ukazuju na šire očekivanje: istorija načina na koji je softver napravljen biće važna. Proveravalac treba da može da razume zahtev, pregleda generisanu izmenu, vidi dokaze testiranja i utvrdi ko je odobrio puštanje u rad.

Taj zapis nije birokratija radi same sebe. On omogućava da se impresivna demonstracija razlikuje od kontrolisane izmene koju druga osoba može da održava.

Šta uvrstiti u portfolio ili pripremiti za razgovor za posao

Za kandidate, najubedljivija demonstracija jeste mali sistem sa namerno jasno prikazanom pričom o kvalitetu. Uključite repozitorijum, uputstva za podešavanje, beleške o arhitekturi, komande za testiranje, reprezentativne testne slučajeve, poznata ograničenja i kratak izveštaj o neuspesima. Prikažite jednu ili dve greške koje su pronađene i pretvorene u regresione testove. Objasnite koji je model ili agent za programiranje korišćen, ali nemojte alat predstavljati kao autora inženjerskih odluka.

Ako aplikacija koristi agenta, dokumentujte dozvole alata, model stanja, politiku ponovnih pokušaja, uslov završetka i tačke na kojima je potrebno ljudsko odobrenje. Ako koristi pretraživanje izvora, pokažite kako se izvori biraju i šta se dešava kada dokazi nedostaju. Ako poziva spoljne servise, demonstrirajte ponašanje pri isteku vremena i pri dupliranim zahtevima.

Ne tvrdite da je sistem pouzdan na osnovu jednog uspešnog snimka. Proverljiva tvrdnja zvuči više ovako: „Tokom 30 zabeleženih pokretanja ovih 12 scenarija, sistem je ispunio kriterijume prihvatanja u 28 slučajeva; dva neuspeha odnosila su se na dvosmisleni unos datuma i oba su dokumentovana.“ Sam broj je manje važan od metode, granica i iskrenosti u pogledu onoga što još nije testirano.

Nova definicija brzine

AI smanjuje cenu izrade prve verzije. Ne uklanja cenu utvrđivanja da li ta verzija zaslužuje poverenje. Zapravo, brže generisanje može učiniti evaluaciju još važnijom, jer se između puštanja u rad može nagomilati više neproverenih izmena.

Profesionalca nakon ere „vajb programiranja“ procenjivaće prema petlji: definisati ponašanje, generisati ili izmeniti kod, testirati realistične i protivničke slučajeve, pregledati odluke visokog rizika, beležiti neuspehe i unapređivati sistem bez gubitka dokaza. Referentni testovi mogu pomoći u poređenju sposobnosti. Prakse kontrole kvaliteta određuju da li će ta sposobnost postati pouzdan softver.

Prag kvaliteta stoga nije „Možeš li da napraviš aplikaciju pomoću AI-ja?“ Već glasi: „Možeš li da dokažeš šta aplikacija radi, da otkriješ kada prestane to da radi i da osmisliš ograničenja koja sprečavaju da neuspeh preraste u incident?“