Ni Kwame Boateng
Ang coding na tinutulungan ng AI ay madalas ilarawan bilang mas mabilis na bersyon ng pair programming. Masyado nang makitid ang paghahambing na iyon. Kapag kayang suriin ng isang agent ang isang repository, baguhin ang ilang file, magpatakbo ng mga tool, lumikha ng preview, at magbukas ng pull request, ang pangunahing problema sa pakikipagtulungan ay hindi na simpleng “Kaya ba nitong magsulat ng code?” Ito ay “Nakikita ba, nasusuri, naaaprubahan, at kalaunan ay muling nabubuo ng mga tao ang nangyari?”
Ito ang dahilan kung bakit ang pinakamahalagang pagbabago sa disenyo ng mga software team na gumagamit ng agent ay maaaring ang paglipat mula sa mga pribadong prompt tungo sa mga nakikitang workspace. Ang Slack Code, halimbawa, ay inilalarawan bilang pinagsasama ang mga channel ng proyekto sa mga coding agent, pag-audit ng code diff, mga live na HTML preview, mga workflow para sa feedback at pag-apruba, awtomatikong pag-archive, at mga audit log. Nagdagdag din ang Copilot app ng GitHub ng pane na “My work” para sa pag-aayos ng mga issue at pull request sa iba’t ibang proyekto. Itinuturo ng mga feature na ito ang isang praktikal na prinsipyo: ang trabaho ng isang agent ay dapat mas mukhang isang change set na dumaraan sa isang kontroladong proseso ng produksyon kaysa sa isang malabong sagot.
Ang chat ay hindi talaan ng trabaho
Maaaring maging kapaki-pakinabang ang pakikipag-usap sa isang agent sa paggalugad ng isang ideya, ngunit mahina itong system of record. Maaaring matabunan sa mahabang thread ang mahahalagang detalye: aling mga file ang binago, aling mga command ang pinatakbo, anong mga palagay ang ginawa ng agent, ano ang tinanggihan ng reviewer, at kung naiiba ba ang huling resulta sa unang panukala.
Ginagawang masusuri ng isang matibay na workspace ang mga detalyeng iyon. Dapat nitong iugnay ang kahilingan sa isang partikular na repository o proyekto, panatilihin ang plano ng agent, ipakita ang mga aksyon ng tool at mga pagbabago sa file, mag-link sa mga test at preview, at itala kung sino ang nag-apruba sa resulta. Maaaring mag-iba ang eksaktong interface—issue tracker, pull request, collaboration channel, o agent console—ngunit dapat manatili ang impormasyon kahit matapos ang session.
Mahalaga ito para sa mga karaniwang dahilan sa engineering, hindi lamang para sa compliance. Kung lumitaw ang isang bug makalipas ang dalawang linggo, kailangan ng team ng higit pa sa huling diff. Maaaring kailangan nitong malaman ang orihinal na requirement, ang nabuong plano, ang ebidensiya mula sa mga test, ang mga komento ng reviewer, at kung tahasang tinanggap ng isang tao ang isang mapanganib na trade-off. Pinaiikli ng isang matibay na tala ang imbestigasyong iyon.
Limang layer ng nakikitang trabaho
Maaaring ituring ng mga team na gumagamit ng coding agent ang bawat pagbabago bilang isang maliit at masusuring case file. Limang layer ang partikular na kapaki-pakinabang:
- Layunin: ang issue, acceptance criteria, mga constraint, at hinihiling na saklaw.
- Plano: ang iminungkahing paraan ng agent bago nito baguhin ang mga file. Para sa isang hindi payak na gawain, isa itong checkpoint para sa pag-apruba, hindi palamuti.
- Diff: ang eksaktong mga idinagdag, binura, binagong dependency, binagong configuration, at nabuong asset.
- Ebidensiya: mga resulta ng test, output ng lint, mga security check, screenshot, at isang live o maaaring i-deploy na preview kung may kaugnayan.
- Talaan ng desisyon: mga komento ng reviewer, mga hiningi na pagbabago, pag-apruba, pagtanggi, rollback, o follow-up na trabaho.
Ang punto ay hindi piliting dumaan ang bawat pagbabago sa isang mabigat na komite. Hindi dapat magkapareho ang mga kontrol para sa isang typo at sa pagbabago sa payment flow. Ang punto ay gawing proporsyonal ang antas ng pagsusuri sa posibleng epekto.
Dapat nakatali ang mga pag-apruba sa mga aksyon
Masyadong malabo ang “human in the loop” para maging kapaki-pakinabang na kontrol. Maaaring aprubahan ng isang tao ang plano nang hindi nakikita ang nagresultang diff, o aprubahan ang pagbabago sa code nang hindi napapansin na binago rin ng agent ang isang deployment file. Dapat malinaw na sabihin ng mas mabubuting workflow kung ano ang pinapahintulutan ng isang pag-apruba.
Halimbawa, maaaring payagan ng isang team ang agent na awtomatikong magbasa ng repository at magpatakbo ng mga lokal na test, mangailangan ng pag-apruba bago magsulat sa labas ng itinalagang branch, at mangailangan ng hiwalay na pag-apruba bago mag-merge o mag-deploy. Maaaring magmungkahi ang isang agent ng database migration ngunit pagbawalan itong isagawa sa production. Sumasalamin ang iminungkahing paraan ng UAE sa pag-uuri kung aling mga gawain ang maaaring tapusin ng mga agent at alin ang maaari lamang nilang irekomenda sa mas malawak na padron na ito: dapat italaga ang awtonomiya ayon sa gawain, hindi ipagpalagay sa kabuuan.
Kailangan din ng mga pag-apruba ng saklaw at expiration. Ang pag-apruba para sa “i-update ang copy ng landing page” ay hindi dapat tahimik na magbigay ng pahintulot sa pagdaragdag ng isang bagong analytics package. Ang planong inaprubahan kahapon ay hindi dapat awtomatikong sumaklaw sa isang diff na malaki ang ipinagbago ngayon. Dapat gawing nakikita ng interface ang mga hangganang iyon.
Ginagawang inspeksiyon ng mga preview ang pagsusuri
Madalas mas madali ang code review kapag nasusuri ng mga tao ang resulta sa halip na hulaan ito mula sa mga source file. Maaaring ibunyag ng isang live na HTML preview ang sirang spacing, nawawalang state, mga kontrol na hindi naa-access, o hindi sinasadyang pagbabago sa navigation na maaaring hindi mapansin ng reviewer sa isang text diff.
Ang mga preview ay hindi patunay ng kawastuhan. Dapat nasa tabi ang mga ito ng mga test at pagsusuri sa source, hindi kapalit ng mga ito. Ngunit lumilikha ang mga ito ng isang pangkaraniwang bagay na maaaring pag-usapan: maaaring tumukoy ang reviewer sa isang partikular na screen, state, o interaction at mag-iwan ng feedback na nakakabit sa iminungkahing pagbabago.
Partikular itong mahalaga kapag kabilang sa pagsusuri ang mga hindi espesyalista. Maaaring hindi masuri ng isang product manager ang pagbabago sa framework, ngunit maaaring siya ang tamang taong magkumpirma na tumutugma ang workflow sa requirement. Maaaring patunayan ng isang designer ang isang visual regression. Maaaring tumuon ang isang security specialist sa mga pahintulot at paghawak ng data. Maaaring i-route ng workspace na tinutulungan ng agent ang bawat tanong sa taong pinakamainam na makasagot dito.
Kailangan ng konteksto ang mga diff, hindi kulay lamang
Mahalaga pa rin ang pamilyar na red-and-green diff, ngunit maaaring sapat ang lawak ng mga pagbabagong binuo ng agent upang mabigla ang reviewer. Dapat hilingin ng mga team sa mga agent na panatilihing makitid ang mga commit o grupo ng pagbabago, ipaliwanag kung bakit binago ang bawat malaking file, at hiwalay na tukuyin ang mga nabuong file o vendor file.
Kabilang sa mga kapaki-pakinabang na tanong sa pagsusuri ang:
- Anong pag-uugaling nakikita ng user ang nagbago?
- Aling mga file ang binago lamang upang suportahan ang implementasyon?
- Anong mga pagpapalagay ang ginawa ng agent tungkol sa umiiral na pag-uugali?
- Aling mga test ang idinagdag, binago, o hindi pinatakbo?
- Maaari bang maapektuhan ng pagbabagong ito ang mga pahintulot, pagpapanatili ng data, pagsingil, o mga external API?
Ginagawang paulit-ulit na pagsusuri ng mga tanong na ito ang review, sa halip na malabong kahilingang “tingnan mo ito.” Nakakatulong din ang mga ito na ilantad ang isang karaniwang pagkukulang: isang kapani-paniwalang feature na may kasamang kulang na pag-update ng mga test o hindi sinasadyang pagbabago sa configuration.
I-archive ang mahahalagang bahagi ng pangangatwiran
Hindi awtomatikong kapaki-pakinabang ang pagpapanatili ng bawat token ng bawat pag-uusap ng modelo. Maaaring magastos iimbak at mahirap hanapin ang mahahabang history, habang nagbababala ang pananaliksik sa context compaction na maaaring mawala sa mga buod ang mahahalagang impormasyon. Kaya dapat panatilihin ng isang praktikal na audit trail ang mga artifact na mahalaga sa mga desisyon, sa halip na walang pinipiling i-save ang lahat.
Sa pinakamababa, panatilihin ang kahilingan, inaprubahang plano, huling diff, mga resulta ng tool at test, reference ng preview o deployment, mga desisyon ng reviewer, at anumang ipinagkaloob na eksepsiyon. Kung gumamit ang isang agent ng mga external source o kumuha ng mga internal na dokumento, itala ang mga nauugnay na reference ng source at ang puntong nakaimpluwensiya ang mga ito sa pagbabago. Para sa trabahong mataas ang panganib, maaaring makatuwirang panatilihin ang kumpletong log ng interaksiyon at pagpapatupad.
Gawing makikitang pinakialaman ang mga record kung kinakailangan ng bigat ng usapin, at tukuyin ang mga tuntunin sa retention bago magkaroon ng krisis. Ang audit trail na nawawala kapag na-archive ang isang channel—o hindi matukoy kung ang isang binagong resulta ay iba sa orihinal—ay hindi makakatulong sa isang seryosong imbestigasyon.
Ano ang binabago nito para sa mga karera sa software
Ang umuusbong na kasanayan ay hindi lamang ang pagsulat ng mas mahuhusay na prompt. Ito ay ang pagdidisenyo ng trabahong maaaring siyasatin at pagkatiwalaan ng ibang tao. Kailangang maging komportable ang mga developer sa pagtukoy ng acceptance criteria, paghahati-hati ng mga gawain, pagsusuri ng mga diff sa malakihang saklaw, pagbuo ng makabuluhang mga test, at pagpapasya kung saan kailangang huminto ang isang agent at magtanong.
Magkakaroon ng mas malaking papel ang mga propesyonal sa produkto at disenyo sa pagsusuri ng mga preview at paglilinaw ng layunin. Makakatulong ang mga QA engineer sa pagtukoy ng mga approval gate at failure case. Kailangang sukatin ng mga engineering manager ang throughput nang hindi ginagantimpalaan ang di-nakikitang pagkuha ng panganib. Makapag-aambag ang mga technical writer at operations specialist sa pamamagitan ng pagpapanatiling matibay ng mga desisyon, eksepsiyon, at runbook.
Isang kapaki-pakinabang na pagsasanay ang pumili ng isang karaniwang feature at imapa ang chain of evidence nito: kahilingan, plano, branch, diff, mga test, preview, pag-apruba, release, at rollback. Pagkatapos, itanong kung saan mapipilitang manghula ang isang magiging kasamahan sa hinaharap. Bawat panghuhula ay maaaring maging batayan para sa mas mahusay na workspace, mas malinaw na pahintulot, o mas matibay na record.
Isang simpleng tuntunin sa pagpapatakbo
Hayaang kumilos nang mabilis ang mga agent sa loob ng isang nakikita at naibabalik na daanan. Bigyan sila ng tinukoy na workspace, paghigpitan ang mga sensitibong aksiyon, humingi ng pag-apruba sa mahahalagang hangganan, ilakip ang ebidensiya sa pagbabago, at panatilihin ang huling desisyon. Ang layunin ay hindi pabagalin ang automation hanggang maging kahawig ito ng manu-manong pagko-code. Ang layunin ay gawing tugma ang bilis sa pananagutan.
Sa pagbuo ng software na tinutulungan ng agent, ang pinakamainam na katuwang ay hindi ang sistemang bumubuo ng pinakamaraming code nang mag-isa. Ito ang sistemang ang gawain ay maaaring maunawaan, kuwestiyunin, aprubahan, bawiin, at pagkunan ng aral.
