May-akda: The Pragmatic Engineer
Isinalin: Deep潮 TechFlow
DeepChao Summary: Ang AI ay nagpapabilis sa paggawa ng code, ngunit ang pagsusuri ng code ay patuloy na gawin ng tao. Ang kontradiksyong ito ay umuunlad bilang isang krisis: ang mga inhinyero ay nakakalubos sa mga PR na ginawa ng AI, o nagiging mahirap magbigay ng sapat na pagsusuri, o kaya'y direktang tinatanggap ang mga ito dahil wala namang error na ipinakita ng AI. Ang mga malalaking kumpanya ay nagtatayo ng kanilang sariling mga kasangkapan upang tumugon, ngunit hanggang sa ngayon, wala pa ring standard na solusyon.
Hi, ako si Gergely, at ito ay isang libreng supplement ng Pragmatic Engineer Newsletter. Sa bawat edition, sinusuri ko ang mga malalaking tech company at startups mula sa pananaw ng mga karanasan na engineer at engineering leaders. Ngayon, tatalakayin natin ang isa sa apat na paksa sa nakaraang The Pulse newsletter. Natanggap ng mga ganap na subscriber ang artikulong ito isang linggo na ang nakalipas. Kung ipinadala sa iyo ang email na ito, maaari mong i-subscribe dito.
Narinig ko ang isang pangunahing pag-aalala ng maraming mga lider sa inhinyeriya ay kung paano harapin ang patuloy na pagdami ng load sa code review. Ang paksa na ito ay umiiral na nang ilang panahon, at ngayon ay lalong dumarami ang ganitong uri ng talakayan.
Para sa akin, nagsimula ito noong Enero ng taong ito, nang magsimula ang Opus 4.5 at GPT 5.4 na isulat ang mas marami at mas magandang code sa karamihan ng mga kumpanya. Mula noon pa, ang mga taong nasa antas ng director ay nagsimulang talakayin na ang bottleneck sa software development ay nagpapalit mula sa pag-code patungo sa pag-review.
Pagsabog ng mga tool sa pagrerebyu ng code na AI
Mula noong Pebrero, may pag-usbong ng mga AI code review tool upang tugunan ang pagtaas ng load, kasama ang mas malawak na pagsubok at paggamit ng mga espesyalisadong AI code review tool tulad ng CodeRabbit, Greptile, Qodo, at SonarQube (ngayon ay may Gitar pa). Mayroon ding mga tool na ibinibigay ng sariling coding tools, tulad ng Claude Code review, Cursor review, at GitHub Copilot review. Pati na rin ang mga tool na dati ay hindi nakikilahok sa code review ngunit may konteksto sa codebase ay nagsisimulang sumali sa larangan, tulad ng Sentry’s Seer AI reviews at Linear code reviews.
Mga panloob na kasangkapan na itinatayo ng malalaking kumpanya: Code Inbox ng Uber
Ang mga malalaking kumpanya ay nagtatayo ng mga panloob na kasangkapan upang mapabuti ang karanasan sa pagrerebyu ng code. Isang halimbawa ay ang Code Inbox ng Uber:
Ang intelligent allocation ay isang tampok sa Code Inbox na ginagamit upang mapabilis ang proseso ng pagsusuri:
Larawan: Ang mga setting ng Smart assignment ng Code Inbox para sa pagpapabilis sa proseso ng pagsusuri. Pinagmulan: The Pragmatic Engineer
Mayroon ding tampok na risk profile para sa pagtataya ng epekto ng mga pagbabago at para paalalahanan ang mga developer na maging mas maingat sa mga mataas na panganib na pagbabago:
Litrat: Ang pagpapatakbo ng Risk Profiles ng Code Inbox, na nagtatantiya ng panganib ng pagbabago sa code at nagpapahiwatig ng mga pansin. Pinagmulan: The Pragmatic Engineer
Ibinabahagi namin kung paano ginagamit ng Uber ang AI sa pagbuo ng software, at hindi lang ang Uber: ang Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick), at marami pang iba ay nagbuo ng mga kasangkapan upang gawing mas maayos ang kanilang proseso ng code review, dahil natuklasan nila na mas masisiguro ang mga loob na implementasyon kaysa sa pag-integrate ng mga solusyon mula sa mga vendor.
Mula sa “pagsusuri” patungo sa “papatotohanan”
Ang isang ibang paraan ay isipin kung paano i-verify ang code, hindi i-review ito. Madali sabihin, mahirap gawin; teoretikal, ang kompletong pagsubok ay dapat makapag-verify na gumagana ang code ayon sa inaasahan. Ngunit ilang pagsubok ang itinuturing na “kompletong”? Ano ang mga uri ng pagsubok na tinutukoy natin? Kasama ba ang integration at end-to-end testing? Ano naman ang fuzz testing? Ang formal methods? Paano i-verify kung ang bagong pagsubok ay nakakapag-coverage ng function ayon sa inaasahan? Paano natin i-connect lahat ng ito sa observability?
Ang sobrang pagsusuri ay nagdudulot ng pagbagsak sa mga inhinyero
Ang sobrang detalyadong code review ay nagpapagod sa mga engineer at nagdudulot ng pagbaba sa kalidad ng pagrereview. Maraming kuwento na ang mga developer ay nakikita na ang iba ay hindi na makakapag-review nang mabuti, at kung walang makabuluhang komento ang AI code review, sila ay direktang pinapayagan ito. Samantala, ang mga developer na patuloy na naglalagay ng parehong pagsisikap at oras sa code review ay nadadamay sa mga PR na puno ng AI na basura.
May problema, ang solusyon ay patuloy na eksperimental
May problema, ngunit ang solusyon ay parang isang eksperimento.