Navigasi utama

Ngatasi kendala paninjauan ing pangodean agentik

Pangodean agentik mindhah kendala saka nggawe kode menyang paninjauan, mula alur paninjauan sing bisa dipercaya dadi penting.

Ringkesan eksekutif

  • Umume tim sing nggunakake pangodean agentik mung mindhah kendala utama saka nggawe kode menyang paninjauan; tanpa mbenerake sikluse, kenaikan kacepetan neto meh nol.

  • Ing lingkungan CI skala gedhe (mayuta-yuta tes saben wengi lan atusan insinyur), tugas agen sing paling migunani yaiku ngarahake kepemilikan lan nindakake triase, dudu nggawe kode.

  • Asil agen sing migunani tetep bisa dipercaya sawise ditliti lan nerangake sebab-akibat, ora mung nyocogake pola.

  • Ngrancang lapisan kanggo ngumpulake bukti lan nyusun konteks luwih penting tinimbang lapisan kanggo ngasilake konten.

Umume rembugan babagan pangodean agentik isih diwiwiti saka janji prasaja: nulis luwih akeh kode kanthi luwih cepet.

Kadhang kala, janji kasebut tuwuh dadi visi sing luwih ambisius: agen ngrancang pakaryan, mbukak PR, lan ngrilis owah-owahan kanthi campur tangan manungsa seminimal mungkin. Nanging kanggo umume tim rekayasa, manfaat jangka cedhak sing paling cetha luwih winates. Intine yaiku nyuda biaya iterasi.

Pangiriman piranti lunak ora mung babagan nggawe kode. Nulis kode mung salah siji tahap ing siklus dawa sing uga nyakup paninjauan, pangujian, deployment, lan investigasi nalika ana masalah. Umume tim sing nggunakake pangodean agentik tanpa ngrancang ulang siklus paninjauan mung mindhah kendala utamane menyang tahap sabanjure.

Mung nyepetake proses nggawe kode ora kanthi otomatis ndadekake tim luwih cepet. Iki malah bisa nambah gaweyan kanggo paninjauan, verifikasi, lan mbangun kapercayan.

Kendala sing sejatine yaiku kapastian

Ing akeh lingkungan rekayasa, bagean sing larang dudu nggawe draf kapisan, nanging nggayuh kapastian.

Apa owah-owahan kasebut pancen ngrampungake masalah utawa ningkatake sistem? Apa owah-owahan kasebut nyebabake regresi ing panggonan liya? Apa kegagalane ana ing kode, lingkungan, tes, utawa dependensi? Apa solusi sing diusulake ngrampungake sababe, utawa mung gejala sing katon?

Agen bisa mbantu ing kene, dudu amarga ngganteni insinyur, nanging amarga bisa nindakake pamriksaan awal sing runtut marang bukti sing semrawut: mriksa log, mbandhingake owah-owahan anyar, ngringkes sinyal sing relevan, nglacak sabab sing mungkin, nglakokake pamriksaan, lan menehi asil sing bisa ditliti manungsa.

Ing akeh tim, panggunaan agen sing menehi dampak paling gedhe dudu nggawe kode saka nol. Manfaate yaiku nyempitake ruang telusur masalah sadurunge manungsa kudu ngentekake pirang-pirang jam kanggo nindakake kanthi manual.

Apa sebabe alur kerja sing akeh paninjauane cocog

Bab iki katon cetha banget ing alur kerja debugging skala gedhe. Bayangna CI saben wengi nglakokake mayuta-yuta tes ing basis kode sing diowahi atusan insinyur (iki nyata dialami salah siji klien kita). Nalika ana kegagalan, angel nemtokake tim sing tanggung jawab. Masalahe bisa ana ing kode aplikasi, dependensi, piranti tes, utawa bagean liya ing tumpukan sistem. Ukuran log bisa nganti gigabita, lan tim sing sepisanan weruh masalah durung mesthi tim sing tanggung jawab.

Alur kerja kaya mangkono ora mesthi mbutuhake siji agen kanggo nulis solusine. Alur kasebut luwih cocog kanggo sistem sing bisa nyempitake ruang masalah kanthi cepet.

Pipeline sing migunani bisa njupuk log, milih bukti sing relevan, ngringkes bab penting, mriksa kode ing sandbox, lan ngasilake analisis akar masalah sing runtut, jangkep karo skor kapercayan, keterlacakan, lan saran langkah sabanjure. Kanggo ngasilake skor kapercayan, pakar ing bidang kasebut menehi biji marang asil awal agen. Biji iki banjur dilebokake menyang LLM minangka juri supaya pambiji sabanjure bisa diotomatisasi lan tetep selaras karo pambiji manungsa.

Diagram sing nuduhake sebab alur kerja sing akeh paninjauane cocog.

Tujuane dudu ngilangi pambiji insinyur, nanging menehi titik wiwitan sing luwih kuwat marang paninjau. Triase regresi, paninjauan PR, ndandani tes, validasi rilis, lan investigasi sawise deployment kabeh duwe pola sing padha. Kabeh mbutuhake akeh bukti lan paninjauan, sarta kebak kahanan sing ora cetha. Tugas kasebut ora njaluk agen ngganteni proses rekayasa, nanging mung mbantu supaya proses terus maju.

Gatekna alur kerja sing luwih apik, dudu asile

Iki uga dadi sebab tim kudu ngati-ati nalika mbiji sistem kasebut.

Pitakon sing kliru yaiku apa agen bisa ngasilake samubarang sing nggumunake nalika makarya dhewe. Pitakon sing luwih becik yaiku apa agen bisa ningkatake alur kerja nyata tanpa nggawe proses liyane dadi luwih abot.

Tegese, perlu dipriksa apa asile cukup spesifik kanggo diverifikasi, apa asile nerangake sebab-akibat lan ora mung nyocogake pola, sarta apa asile nggampangake paninjauan tinimbang malah nggawe luwih angel. Wangsulan sing katon mlebu nalar durung mesthi migunani. Ing praktik, tim percaya marang asil agen yen asil kasebut tetep bisa dipercaya sawise ditliti lan menehi bab nyata sing bisa dipriksa.

Diagram sing nuduhake supaya fokus marang alur kerja sing luwih apik, dudu asile.

Bagean sing angel yaiku ngrancang sikluse

Piwulang sing luwih jero yaiku sistem agentik sing migunani ora mung gumantung marang proses ngasilake konten. Sistem kasebut gumantung marang cara ngumpulake bukti, nyusun konteks, mriksa asil, lan nuduhake kahanan sing durung mesthi marang paninjau.

Mula, masa cedhak rekayasa agentik kayane ora bakal langsung mlumpat menyang otonomi lengkap. Sing luwih mungkin yaiku kumpulan siklus sing dirancang kanthi tliti, ing ngendi agen mbantu tim mriksa, nliti, verifikasi, lan nyempurnakake pakaryane kanthi nyuda gaweyan muspra ing antarane tahap.

Iki bisa uga ora sedramatis gagasan otonomi sing luwih jembar, nanging luwih cedhak karo cara sistem sing migunani tenan digunakake.

Para panulis

Atharva Tidke, George Montagu