Binago ng vibe coding kung sino ang makakagawa ng mukhang gumaganang aplikasyon. Kayang bumuo ng prompt ng mga screen, magkonekta ng API, at mag-assemble ng kapani-paniwalang workflow bago pa matapos ng tradisyonal na engineering team ang una nitong pagsusuri sa disenyo.

Lumilikha ang bilis na iyon ng bagong problema sa pagkuha ng empleyado at paghahatid: hindi na matibay na ebidensiya na maganda ang software ang isang demo. Mas madalas nang itanong ng mga employer ang mas mahirap na tanong: kaya bang gumana nang tama ng sistemang binuo ng AI kapag magulo ang mga input, pumalya ang mga dependency, inulit ng mga user ang mga aksyon, at nagbago ang pinagbabatayang modelo?

Magmumula ang sagot sa pamantayan ng kalidad na mas kahawig ng disiplinadong beripikasyon ng software kaysa sa biswal na pagpapakinis. Ang mga mamumukod-tangi ay hindi lamang magpapakita ng ginawa ng isang AI coding tool. Ipapakita nila kung paano nila ito sinubukan, kung ano ang hindi nito kayang gawin nang ligtas, at kung paano nila nalaman na walang ibang nasira dahil sa isang pagbabago.

Ang benchmark ay ebidensiya, hindi puntos sa leaderboard

Nag-aalok ng kapaki-pakinabang na panimulang punto ang mga open-source benchmark para sa coding agent, ngunit magkakaibang kakayahan ang sinusukat ng mga ito. Gumagamit ang SWE-bench ng mga totoong isyu sa GitHub at mga snapshot ng repository, kaya nauugnay ito sa gawain sa maintenance. Sinusubok naman ng Terminal-Bench ang pakikipag-ugnayan sa command line. Tinatarget ng iba pang nakalistang benchmark, kabilang ang SlopCodeBench at ProgramBench, ang magkakaibang aspekto ng nabuong code at pag-uugali ng agent.

Makakatulong ang mga benchmark na iyon sa paghahambing ng mga tool o pagtatakda ng baseline, ngunit dapat mag-ingat ang mga employer sa pagtrato sa anumang solong puntos bilang patunay na handa na ito para sa produksyon. Maaaring malutas ng isang modelo ang mga isyu sa repositoryo ngunit makabuo pa rin ng hindi ligtas na lohika ng awtorisasyon. Maaaring matapos ng isang agent ang mga gawain sa terminal ngunit mabigong mapanatili ang estado sa mahabang workflow. Maaaring pumasa ang isang pinakintab na web application sa demo na happy path habang mali ang paghawak nito sa mga retry o dobleng bayad.

Kaya dapat may kasamang set ng pagsusuring partikular sa gawain ang isang kapani-paniwalang portfolio o internal review. Maaaring maglaman ang set ng mga kinatawang ulat ng bug, karaniwang paglalakbay ng user, maling pagkaka-format na input, mga hangganan ng permiso, mga pagpalya ng dependency, at mga dati nang naayos na regression. Dapat may tahasang inaasahang resulta ang bawat kaso, hindi lamang screenshot na mukhang tama.

Ang minimum na test pack para sa software na binuo ng AI

Para sa isang maliit na aplikasyon, makakabuo ng kapaki-pakinabang na quality pack nang hindi nangangailangan ng masalimuot na research lab:

  • Mga acceptance test: sinusuri ang pag-uugaling nakikita ng user para sa pinakamahahalagang workflow, kabilang ang matagumpay at hindi matagumpay na mga resulta.
  • Mga unit at integration test: sinusuri ang mga tuntunin ng negosyo nang hiwalay at kinukumpirma na gumagana nang magkakasama ayon sa nilalayon ang mga database, API, queue, at authentication.
  • Mga negatibong test: nagpapadala ng nawawala, maling pagkaka-format, sobrang laki, doblado, at hindi awtorisadong mga input. Madalas na pinakamaganda ang hitsura ng code na binuo ng AI sa landas na ipinakita sa prompt, kaya mahalaga ang mga landas na hindi hiningi.
  • Mga regression test: ginagawang permanenteng test ang bawat natuklasang depekto. Hindi sapat ang berdeng demo pagkatapos ng isang pag-aayos kung maaaring bumalik ang parehong kabiguan sa susunod na pagbabagong nabuo.
  • Mga pagsusuring pangseguridad: sinusuri ang access control, paghawak sa mga lihim, mga depensa laban sa injection, mga kahinaan sa dependency, at kung maaaring maimpluwensiyahan ng hindi pinagkakatiwalaang content ang mga tool call o pribilehiyadong aksyon.
  • Mga pagsusuring pang-operasyon: tinitiyak ang mga timeout, retry, idempotency, logging, alert, at ligtas na pag-uugali kapag hindi magagamit ang isang dependency.

Malapit ito sa mindset ng QA engineering na inilarawan sa salaysay ng Stack Overflow tungkol sa agentic software development life cycle. Ang mahalagang pagbabago ay pangkultura: ang quality assurance ay hindi panghuling inspeksiyon pagkatapos magsulat ng code ang AI. Ito ang estrukturang ginagawang sapat na ligtas gamitin ang mabilis na pagbuo.

Subukan ang orchestration, hindi lamang ang output

Kapag may AI agent ang software, kailangan ngunit hindi sapat ang mga karaniwang test ng aplikasyon. Maaaring pumalya ang sistema dahil mali ang pagkaunawa ng modelo sa isang kahilingan, ngunit maaari rin itong pumalya dahil nawala ang context sa nakapaligid na orchestration, dalawang beses na tumawag sa isang tool, tumanggap ng maling pagkaka-format na structured output, o hindi kailanman nagtapos.

Ang mga inirerekomendang bahagi ng regression bago ang deployment sa digest ay praktikal na checklist: pagkawala ng context, idempotency ng tool, prompt injection, structured output, hindi pagtatapos, retrieval grounding, at state rehydration. Mga katangiang pang-engineering na nasusuri ang mga ito.

Halimbawa, maaaring magpatakbo ang isang test ng parehong kahilingan nang dalawang beses at tiyaking hindi lumilikha ng dobleng order ang ikalawang pagtatangka. Maaaring gambalain ng isa pang test ang isang agent sa kalagitnaan ng workflow, i-restart ito, at beripikahing nagpapatuloy ito mula sa wastong estado sa halip na ulitin ang isang aksiyong hindi na maibabalik. Maaaring hilingin ng retrieval test na magbanggit o magbalik lamang ang sistema ng impormasyong mula sa aprubadong set ng mga source. Maaaring magbigay ang structured-output test ng hindi balidong tugon at tiyaking ligtas itong tinatanggihan ng aplikasyon sa halip na tahimik na ituring itong wastong datos.

Lalo nang nangangailangan ng malinaw na mga rekord ng pagpalya ang mga sistemang matagal tumakbo at gumagamit ng maraming agent. Nagsasaliksik ang mga mananaliksik sa awtomatikong pagtukoy ng pinagmulan ng pagpalya dahil maaaring mahirap tukuyin kung aling agent ang naging sanhi ng pagpalya at saang punto ng mahabang chain ng interaksiyon ito nangyari. Sa praktikal na mga termino, dapat panatilihin ng mga team ang mga tool call, input, output, bersiyon ng modelo, timestamp, mga paglipat ng estado, at mga panghuling desisyon sa isang audit trail na isinasaalang-alang ang privacy. Kung wala ang ebidensiyang iyon, sinasabi sa iyo ng pulang test na may pumalya ngunit hindi kung saan magsisimulang mag-ayos.

Magiging bentahe sa karera ang reproducibility

Nagbabago-bago ang code na binuo ng AI. Maaaring magbunga ng ibang implementasyon ang muling pagpapatakbo; maaaring magbago ang pag-uugali dahil sa update ng modelo; maaaring mabago ng outage ng provider ang routing o latency. Dahil dito, pahahalagahan ng mga employer ang mga kandidatong kayang gawing nauulit ang mga pagsusuri.

Nangangahulugan iyon ng pag-pin ng mga snapshot ng modelo kung maaari, pagtatala ng mga prompt at configuration, pagkontrol sa randomness kapag pinapayagan ito ng platform, at pagpapatakbo ng maraming trial para sa mga gawaing pabago-bago ang resulta. Partikular na itinuturo ng digest ang mga naka-pin na snapshot, mababa o zero na temperature kung magagamit, at mga confidence-bounded na gate sa CI/CD bilang kapaki-pakinabang na pananggalang.

Dapat tukuyin ng isang praktikal na ulat ang hindi bababa sa tatlong resulta:

  1. Rate ng pagpasa: kung ilang kaso ang nagtagumpay.
  2. Pagiging pare-pareho: kung gaano kadalas nagtatagumpay ang parehong kaso sa mga paulit-ulit na pagtakbo.
  3. Tindi: kung ang mga pagkabigo ay kosmetiko, nakaaabala, nakasisira ng datos, may kaugnayan sa seguridad, o maaaring magdulot ng hindi ligtas na panlabas na pagkilos.

Ang sistemang pumapasa sa 19 sa 20 mababang-panganib na pagsusuri sa pag-format ay hindi nangangahulugang mas mahusay ito kaysa sa sistemang pumapasa sa 18 sa 20 kaso ngunit hindi kailanman lumalampas sa hangganan ng awtorisasyon. Dapat timbangin ng pamantayan sa kalidad ang mga pagkabigo ayon sa kanilang mga kahihinatnan.

Dapat ituon ng pagsusuri ng tao ang panganib, hindi ang bawat linya

Ang layunin ng mas mahusay na awtomasyon ay hindi ang pilitin ang isang tao na basahing muli ang bawat token na ginawa ng AI. Ito ay ang ituon ang atensiyon ng tao sa mga desisyong hindi ganap na malulutas ng mga pagsusuri.

Dapat magtuon ang mga tagasuri sa autentikasyon at awtorisasyon, pagpapanatili ng datos, mga aksiyong pinansyal o kontraktuwal, pagkapribado, mga migration, pagbawi sa error, mga pahintulot ng ikatlong partido, at mga pagbabagong nakaaapekto sa mismong evaluation harness ng sistema. Para sa isang agent, dapat din nilang suriin kung aling mga tool ang maaari nitong tawagan, anong datos ang maaaring ma-access ng bawat tool, at kung kinakailangan ang pag-apruba bago magsagawa ng hindi na maibabalik na aksiyon.

Ang mga nakikitang diff, daloy ng pag-apruba, naka-archive na pag-uusap, at mga audit log—mga tampok na binigyang-diin sa paglalarawan ng Slack Code sa kolaboratibong pagko-code gamit ang AI—ay tumutukoy sa mas malawak na inaasahan: magiging mahalaga ang kasaysayan kung paano ginawa ang software. Dapat maunawaan ng isang tagasuri ang kahilingan, masuri ang nabuong pagbabago, makita ang ebidensiya mula sa mga pagsusuri, at matukoy kung sino ang nag-apruba sa deployment.

Ang rekord na iyon ay hindi burukrasya para sa sarili nitong kapakanan. Ginagawa nitong maiiba ang isang kahanga-hangang demo sa isang kontroladong pagbabagong maaaring panatilihin ng ibang tao.

Ano ang ilalagay sa portfolio o panayam

Para sa mga kandidato, ang pinakamabisang demonstrasyon ay isang maliit na sistemang may sadyang malinaw na kuwento ng kalidad. Isama ang repository, mga tagubilin sa pag-setup, mga tala tungkol sa arkitektura, mga command para sa pagsusuri, mga kinatawang test case, mga alam na limitasyon, at maikling ulat ng pagkabigo. Magpakita ng isa o dalawang bug na natuklasan at ginawang regression test. Ipaliwanag kung anong modelo o coding agent ang ginamit nang hindi inilalarawan ang tool bilang may-akda ng mga desisyong pang-inhinyeriya.

Kung gumagamit ng agent ang aplikasyon, idokumento ang mga pahintulot ng tool, modelo ng estado, patakaran sa muling pagsubok, kundisyon ng pagwawakas, at mga puntong nangangailangan ng pag-apruba ng tao. Kung gumagamit ito ng retrieval, ipakita kung paano pinipili ang mga source at kung ano ang nangyayari kapag nawawala ang ebidensiya. Kung tumatawag ito ng mga panlabas na serbisyo, ipakita ang gawi kapag nag-timeout at kapag may mga duplicate na kahilingan.

Huwag mag-angkin ng pagiging maaasahan batay sa iisang matagumpay na recording. Ang isang nasusuring pahayag ay mas ganito ang dating: “Sa 30 naitalang pagtakbo ng 12 sitwasyong ito, natugunan ng sistema ang mga pamantayan ng pagtanggap sa 28; ang dalawang pagkabigo ay may kinalaman sa malabong input ng petsa, at parehong nakadokumento.” Hindi ang mismong bilang ang pinakamahalaga kundi ang pamamaraan, mga hangganan, at katapatan tungkol sa mga bagay na hindi pa nasusuri.

Ang bagong depinisyon ng mabilis

Pinabababa ng AI ang gastos sa paggawa ng unang bersiyon. Hindi nito inaalis ang gastos ng pag-alam kung karapat-dapat bang pagkatiwalaan ang bersiyong iyon. Sa katunayan, maaaring gawing mas mahalaga ng mas mabilis na pagbuo ang pagsusuri dahil mas maraming pagbabagong hindi nasusuri ang maaaring maipon sa pagitan ng mga deployment.

Ang propesyonal sa panahong post-vibe-coding ay huhusgahan batay sa siklo: tukuyin ang gawi, bumuo o magbago ng code, subukan ang makatotohanan at salungat na mga kaso, suriin ang mga desisyong mataas ang panganib, itala ang mga pagkabigo, at pagbutihin ang sistema nang hindi nawawala ang ebidensiya. Makatutulong ang mga benchmark sa paghahambing ng kakayahan. Ang mga gawain sa QA ang tumutukoy kung magiging maaasahang software ang kakayahang iyon.

Samakatuwid, ang pamantayan sa kalidad ay hindi “Makakagawa ka ba ng app gamit ang AI?” Ito ay “Mapatutunayan mo ba kung ano ang ginagawa ng app, matutukoy kung kailan ito tumigil sa paggawa nito, at makapagdidisenyo ng mga limitasyong pumipigil na maging insidente ang isang pagkabigo?”