Sa karamihan ng mga team na gumagamit ng agentic coding, naililipat lang ang bottleneck mula pagbuo tungo sa pag-review; halos walang netong pagbilis kung hindi aayusin ang loop.
Sa malalaking CI environment (milyon-milyong test gabi-gabi at daan-daang engineer), ang pinakamahalagang gawain ng agent ay pagtukoy ng responsableng team at pag-triage, hindi pagbuo ng code.
Ang kapaki-pakinabang na output ng agent ay pumapasa sa masusing pagsusuri at nagpapaliwanag ng sanhi, hindi lang nagtutugma ng mga pattern.
Mas mahalaga ang pagdisenyo sa layer para sa pangangalap ng ebidensya at pagbuo ng konteksto kaysa sa layer ng pagbuo.
Nagsisimula pa rin sa isang simpleng pangako ang karamihan ng talakayan tungkol sa agentic coding: mas mabilis na pagsusulat ng mas maraming code.
Kung minsan, lumalawak ito tungo sa mas malaking mithiin kung saan ang mga agent ay nagpaplano ng trabaho, nagbubukas ng mga PR, at naglalabas ng mga pagbabago nang wala masyadong pakikialam ng tao. Pero para sa karamihan ng mga engineering team, mas limitado ang pinakamalinaw na halagang maibibigay nito sa loob ng mas maikling panahon. Layunin nitong bawasan ang gastos sa bawat pag-ulit.
Hindi lang pagbuo ng code ang paghahatid ng software. Ang pagsusulat ng code ay isang yugto lang sa mas mahabang loop na kinabibilangan ng pag-review, pag-test, pag-deploy, at pag-iimbestiga kapag nagkaproblema. Inililipat lang sa downstream ng karamihan ng mga team ang kanilang bottleneck kapag gumagamit sila ng agentic coding nang hindi binabago ang disenyo ng review loop.
Hindi awtomatikong bumibilis ang isang team dahil lang pinabilis ang pagbuo. Maaari lang nitong dagdagan ang pagsisikap sa pag-review, pag-verify, at pagbuo ng tiwala.
Sa maraming engineering environment, hindi paggawa ng unang draft ang magastos na bahagi kundi ang pagkakaroon ng kumpiyansa rito.
Talaga bang naayos ang problema o napahusay ang system dahil sa pagbabago? Nagdulot ba ito ng regression sa ibang bahagi? Nasa code, environment, mga test, o dependency ba ang pagpalya? Tinutugunan ba ng iminungkahing solusyon ang sanhi, o ang nakikitang sintomas lang?
Makakatulong dito ang mga agent, hindi dahil pinapalitan nito ang mga engineer, kundi dahil kaya nitong gumawa ng mga may istrukturang unang pagsusuri sa magulong ebidensya: suriin ang mga log, ihambing ang mga kamakailang pagbabago, ibuod ang mahahalagang signal, tukuyin ang mga posibleng sanhi, magpatakbo ng mga check, at magbigay ng resultang masusuri ng tao.
Sa maraming team, hindi ang pagbuo ng code mula sa simula ang pinakakapaki-pakinabang na gamit ng isang agent. Ito ay ang pagpapaliit ng saklaw ng paghahanap sa problema bago gumugol ang isang tao ng maraming oras sa manu-manong paggawa nito.
Lalo itong malinaw sa malalaking debugging workflow. Isipin ang gabi-gabing CI na nagpapatakbo ng milyon-milyong test sa mga codebase na binabago ng daan-daang engineer (na isang realidad para sa isa naming kliyente). Kapag may pumalya, mahirap tukuyin ang responsableng team. Maaaring nasa application code, isang dependency, test harness, o ibang bahagi ng stack ang problema. Maaaring umabot sa gigabyte ang mga log, at hindi palaging ang team na unang nakakita sa isyu ang responsable rito.
Hindi likas na nangangailangan ang ganitong workflow ng iisang agent na magsusulat ng solusyon. Dinisenyo ito para sa isang system na mabilis na nagpapaliit sa saklaw ng problema.
Maaaring kunin ng isang kapaki-pakinabang na pipeline ang mga log, maaari nitong piliin ang kaugnay na ebidensya, ibuod kung ano ang mahalaga, suriin ang code sa isang sandbox, at gumawa ng may istrukturang root-cause analysis na may confidence score, traceability, at mga mungkahing susunod na hakbang. Upang makabuo ng confidence score, sinusuri ng isang eksperto sa paksa ang paunang output ng agent. Pagkatapos, ipinapasok ito sa isang LLM-as-a-judge para ma-automate ang pagmamarka sa hinaharap habang nananatiling nakaayon sa paghuhusga ng tao.
Hindi nito layuning alisin ang paghuhusga ng mga engineer, kundi bigyan ang mga reviewer ng mas matibay na pagsisimulan. Magkakatulad ang anyo ng regression triage, pag-review ng PR, pagkumpuni ng test, pag-validate ng release, at imbestigasyon pagkatapos ng pag-deploy. Umaasa ang mga ito sa maraming ebidensya at review, at maraming malabo tungkol dito. Hindi nila hinihiling sa agent na palitan ang proseso ng engineering, kundi tulungan lang itong umusad.
Ito rin ang dahilan kung bakit dapat mag-ingat ang mga team sa paraan ng pagtatasa nila sa mga system na ito.
Ang maling tanong ay kung kayang gumawa ng isang agent ng kahanga-hangang bagay nang mag-isa. Ang mas magandang tanong ay kung napapahusay nito ang isang tunay na workflow nang hindi nagdudulot ng pabigat sa ibang bahagi.
Ibig sabihin, dapat suriin kung sapat ang detalye ng output para ma-verify, kung ipinapaliwanag nito ang sanhi sa halip na basta magtugma ng mga pattern, at kung pinapadali nito ang pag-review sa halip na pinapahirap. Hindi porke't kapani-paniwala ang sagot ay kapaki-pakinabang na ito. Sa aktwal na paggamit, nagtitiwala ang mga team sa output ng agent kapag pumapasa ito sa masusing pagsusuri at nagbibigay ito ng kongkretong bagay na masusuri nila.
Ang mas malalim na aral ay hindi lang sa pagbuo nakasalalay ang mga kapaki-pakinabang na agentic system. Nakasalalay ang mga ito sa paraan ng pangangalap ng ebidensya, pagbuo ng konteksto, pagsuri sa mga output, at paglalahad ng kawalan ng katiyakan sa reviewer.
Kaya malamang na hindi isang malaking hakbang tungo sa ganap na awtonomiya ang nalalapit na hinaharap ng agentic engineering. Mas malamang na binubuo ito ng mga loop na maingat ang pagkakadisenyo, kung saan tinutulungan ng mga agent ang mga team na siyasatin, i-review, i-verify, at pinuhin ang kanilang trabaho nang mas kaunti ang nasasayang na pagsisikap sa pagitan ng mga hakbang.
Maaaring hindi ito kasinglaki ng mas malawak na kuwento tungkol sa awtonomiya, pero mas malapit ito sa aktwal na paraan ng paggamit sa mga kapaki-pakinabang na system.