Markdown edition

AI-translated from English; not yet reviewed by a fluent editor.

# Sa AI coding, ang susunod na hamon ay maaasahang paghahatid ng software

> Kapag dumami ang nalilikhang code dahil sa AI, kailangang makita ng mga engineering manager kung saan naghihintay ang mga pagbabago, magkano ang pagpapatunay sa mga ito at kung umaasal ayon sa nilalayon ang inilabas na software.

By BIG CHANGE Editorial

Published: 2026-09-22T05:31:05.772Z
Updated: 2026-09-22T05:31:05.772Z
Canonical: https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery

![A large stack of blank work cards waits on a conveyor before a magnifying-glass inspection station, with a smaller stack in the output tray.](https://bigchange.ai/api/media/file/validation-queue-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. More proposed changes can put pressure on validation. Conceptual illustration of a queue and inspection stage; stack sizes are not measurements, and passing checks does not guarantee dependable delivery.

Maaaring matapos ng isang AI coding agent ang patch habang tumatakbo pa ang mga pagsusuri sa naunang patch nito. Nagbubunga ito ng alanganing pagkakaiba para sa engineering manager: mas marami nang nagawang code ang pangkat, pero wala pang natatanggap ang customer.

Kapaki-pakinabang na halimbawa ang Linear. Sa salaysay nito tungkol sa engineering noong Setyembre 21, iniulat ni Mufeez Amjad na halos apat na beses ang itinaas ng mga test suite nito mula simula ng 2026, habang bumaba ang paghihintay sa continuous integration ng mga pull request mula mahigit anim na minuto tungo sa mahigit limang minuto lang. Halos nabawasan sa kalahati ang oras ng runner sa bawat test. Magkakahiwalay na pagbuti ang mga ito; hindi ibig sabihin ng huling bilang na nahati rin sa kalahati ang kabuuang singil sa CI. Iniuugnay ng Linear sa pagbuo ng software sa tulong ng agent ang lumalaking bigat ng pagpapatunay, pero hindi kontroladong eksperimento ang salaysay nito na nagtatatag ng epekto ng AI sa produktibidad. [Salaysay ng Linear tungkol sa engineering](https://linear.app/now/ci-bottleneck-reworked).

Ang continuous integration, o CI, ay nagpapatakbo ng mga awtomatikong pagsusuri sa mga iminungkahing pagbabago sa software. Nasa pagitan ito ng kapani-paniwalang patch at pagbabagong handang tanggapin ng pangkat. Kapag dinagdagan ng AI coding ang suplay ng mga patch, nagiging usaping pangnegosyo ang kapasidad ng pagsusuri: gaano karaming kapaki-pakinabang na gawain ang ligtas na kayang saluhin ng organisasyon?

Sa pananaw namin, dapat sabay na makita ng mga manager ang tatlong resulta: oras bago makakuha ng mapagkakatiwalaang puna, kabuuang paggamit ng kompyutasyon, at pagiging maaasahan ng inilabas na pagbabago. Kapaki-pakinabang lang ang mas mabilis na sagot kung nauunawaan ng pangkat kung ano ang pinatutunayan nito.

## Maaaring mangailangan ng mas maraming trabaho ang mas maikling paghihintay

Isipin ang test suite na nangangailangan ng labindalawang minuto sa iisang makina. Kung hahatiin nang pantay-pantay sa apat na makina, matatapos ito sa loob ng tatlong minuto. Ipinagpapalagay ng kathang-isip na halimbawang ito ang perpektong paghahati at isinasantabi ang lahat ng iba pa. Labindalawang minuto pa rin ng trabaho ang gagawin ng mga makina kapag pinagsama.

Ngayon, maglaan ng isang minutong paghahanda sa bawat makina. Aabutin ng apat na minuto ang bersiyong gumagamit ng apat na makina at gagamit ito ng labing-anim na runner-minute. Aabutin naman ng labintatlong minuto ang bersiyong gumagamit ng isang makina, at labintatlong runner-minute ang konsumo nito. Malaki ang ibinababa ng oras ng paghihintay habang tumataas ang pinagsama-samang paggamit ng mga makina. Nakadepende rin ang aktuwal na singil sa uri ng runner, presyo at mga tuntunin sa pagsingil.

Mahalaga ang pagkakaibang ito kapag ipinagdiriwang ng dashboard ang mas maikling berdeng bar. Bumibili ang manager ng kapasidad para magpatakbo nang sabay-sabay kapalit ng mas maagang puna, na maaaring may dagdag na gastos. Mahusay itong kapalit ng gastos kung tunay na limitasyon ang naaalis nito. Mas mahirap itong bigyang-katwiran kapag ilang oras namang naghihintay ng reviewer ang nakumpletong pagbabago.

Dapat saklawin ng pagsusuri ang higit pa sa iisang CI run. Maaaring mangailangan ng paulit-ulit na rebisyon, muling pagpapatakbo at ikalawang pagsusuri ang isang patch, kaya mas marami itong konsumo kaysa ipinahihiwatig ng pinakamabilis nitong run. Bilangin ang lahat ng pagtatangkang kinailangan para tanggapin ang pagbabago, pati ang mga inabandona. Kung hindi, maaaring ikubli ng mukhang episyenteng pipeline ang magastos na proseso ng pagbuo.

Hindi rin katumbas ng iisang gastos sa paggawa ang bawat minutong paghihintay. Hindi nangangahulugang nasayang na ang buong pagitan ang developer na nagsimula ng isa pang kapaki-pakinabang na gawain habang tumatakbo ang mga pagsusuri. Pero maaari pa ring makasama ang paulit-ulit na pagkaantala at pagbabalik sa gawaing hindi tapos. Kailangang obserbahan kung paano nagtatrabaho ang pangkat para masukat ang mga epektong iyon; hindi sapat na imultiplika ang lumipas na minuto sa sahod.

## Halo-halo ang larawang inilalarawan ng pananaliksik

Iniulat sa pagsusuri ng DORA noong Marso 2026 ang dalawang magkahiwalay na pangkat ng ebidensiya. Iniugnay ng pananaliksik nito noong 2025 ang mas malawak na paggamit ng AI sa mas mataas na daloy ng paghahatid ng software at mas matinding kawalang-tatag. Hiwalay dito, sinuri ng mga mananaliksik ang 1,110 bukas na sagot ng mga inhinyero ng Google na nakalap noong ikatlong kuwarter ng 2025. Inilarawan ng mga inhinyero ang tulong sa pagsulat ng draft at iba pang gawain, kasama ng dagdag na pagsisikap sa pagpapatunay. Hindi kabilang sa populasyong pinagbabatayan ng mas malawak na ugnayan ng DORA ang panloob na kwalitatibong pag-aaral; wala rin sa alinman sa mga ito ang nagtatatag na AI ang sanhi ng problema sa release ng isang partikular na pangkat. [Pagsusuri at pamamaraan ng DORA](https://dora.dev/insights/balancing-ai-tensions/).

Mayroon ding mas matibay na ebidensiyang eksperimental na mas makitid ang saklaw. Sa randomisadong pag-aaral ng METR noong Hulyo 2025, itinalaga ang 246 na gawain sa 16 na bihasang open-source developer na nagtatrabaho sa mga pamilyar na repository. Nang payagang gumamit ng mga AI tool mula sa unang bahagi ng 2025, tumagal nang 19% ang pagkumpleto ng gawain. Gayunman, inakala ng mga kalahok na mas mabilis silang natulungan ng AI. Tungkol lang sa mga developer, gawain at tool na iyon ang natuklasan; hindi nito napagpapasyahan ang halaga ng bawat coding agent na available ngayon. [Orihinal na eksperimento ng METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

Noong Pebrero 2026, sinabi ng METR na hindi maaasahan ang pagtatantiya ng sumunod nitong pag-aaral sa kasalukuyang epekto sa produktibidad. Dumarami ang developer na tumatanggi sa trabahong walang AI o pumipili kung aling gawain ang isusumite; nagpahirap din sa pagsukat ng oras ang sabay-sabay na mga agent. Itinuring ng mga mananaliksik na posible ang mas malaking pagbilis, pero mahina lang daw ang ebidensiyang ipinakikita ng datos tungkol sa laki nito. Makaliligaw sa mga mambabasa ang pag-uulit sa dating bilang ng pagbagal nang walang ganitong paglilinaw. [Karugtong na pag-aaral ng METR](https://metr.org/blog/2026-02-24-uplift-update/).

Para sa manager, makatarungang praktikal na paninindigan ang mga pag-aaral na ito: panatilihin ang mga kapaki-pakinabang na tool, siyasatin ang mga epekto nito at iwasang gawing pangkalahatang tuntunin sa pagkuha ng tauhan ang sigasig o pag-aalinlangan. Malaki ang maaaring pakinabang ng pangkat sa isang uri ng trabaho, pero mawalan naman ito ng oras sa iba. Dapat maipakita ng proseso ng paghahatid ang pagkakaibang iyon.

## Bigyan ng hiwalay na lunas ang bawat limitasyon

Bago bumili ng mas malaking kapasidad sa CI, subaybayan ang isang pagbabago mula sa unang iminungkahing patch hanggang sa produksyon. Ihiwalay ang trabahong tumatakbo sa trabahong naghihintay. Tukuyin kung aling pagsusuri ang talagang nagpapaantala sa pasiya, sinong reviewer ang kailangang magbigay-pansin, at anong mga kundisyon sa release ang kailangan pang matugunan pagkatapos.

Kadalasan, sapat na ang simpleng talaan ng oras para ilantad ang maling pamumuhunan. Kung karamihan ng pagkaantala ay nangyayari bago magsimula ang pagsusuri, hindi ito malulutas ng pagtitipid ng ilang segundo sa mga test. Kung paulit-ulit na naghihintay ang mga reviewer sa mahabang kinakailangang pagsusuri, may tuwirang pakinabang ang pagpapahusay dito. Kung pagkaraang i-deploy nagmumula ang karamihan ng problema, kailangang siyasatin ng pangkat ang mga hindi nahuhuli ng pagpapatunay.

Halimbawa ang pag-cache ng mga dependency kung bakit kailangang sukatin ang isang pamilyar na optimisasyon. Inilalarawan ng dokumentasyon ng GitHub ang caching bilang paraan para magamit muli ang mga file na magastos buuing muli sa malilinis na runner. Sinasabi rin nito na dapat kayang likhain muli o i-download ng mga job ang mga file kapag walang cache. Kaya dapat tasahin ang asal ng cache kapag tumama ito at kapag pumalya. [Dokumentasyon ng GitHub tungkol sa pag-cache ng mga dependency](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching).

Para sa manager, mahalagang malaman kung gaano kapredictable ang puna. Maaaring sabay na umiral ang napakagandang karaniwang oras at paminsan-minsang paghihintay na sapat ang tagal para makagambala sa release. Subaybayan ang mabagal na dulo ng distribusyon at ibukod ang lehitimong bagsak na test sa pumalyang download o naubos na runner. Magkaibang tugon ang kailangan sa bawat isa.

Nagbibigay ang maaasahan at napapanahong puna sa mga tao at agent ng mas maagang pagkakataong magwasto ng pagkakamali. Maaaring makinabang sa pagpapahusay sa iisang imprastrakturang ito ang maraming uri ng gawaing pang-develop, kabilang ang mga pagbabagong hindi isinulat sa tulong ng AI. Dahil dito, may dahilan ang mga manager na pondohan ito kahit nagbabago ang kanilang pinipiling coding tool.

![One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.](/api/media/file/elapsed-aggregate-work-inline-v1.png)

## Kailangan pa ring makahuli ng pagkakamali ang mas mabilis na test

May mga pagbabagong pang-performance na nag-iiba sa kundisyon ng pagpapatakbo ng test. Mas masusi itong dapat siyasatin kaysa sa simpleng pagpapabilis ng processor.

Isang tool sa pagsubok ng JavaScript at TypeScript ang Vitest; bilang default, ibinubukod nito ang mga test file para hindi maapektuhan ng estado ng isang file ang iba. Inilalarawan ng dokumentasyon nito kung paano piling alisin ang pagkakabukod sa mga test na angkop dito, pero tinutukoy din nito ang nababagong estado ng module, nabagong global at iba pang dependency bilang mga dahilan para panatilihin ito. Kaya maaaring baguhin ng setting na nagpapababa sa oras ng paghahanda ang hangganan ng kawastuhan. [Gabay ng Vitest sa pagkakabukod](https://vitest.dev/guide/recipes/disable-isolation).

Pinili ng Linear ang paraang kailangang tahasang paganahin para sa pinagsasaluhang estado, nagdagdag ito ng paglilinis at pinanatili ang pagkakabukod sa mga file na hindi ligtas ilipat. Nakadepende ang pakinabang nito sa performance sa pasiyang aling test ang ligtas gumamit ng iisang kapaligiran. [Pagpapatupad ng Linear](https://linear.app/now/ci-bottleneck-reworked).

May hiwalay pang hamon kapag parehong nagsusulat ng pagbabago at mga test nito ang isang agent. Isipin ang kathang-isip na tuntunin sa diskuwento na para lang sa taunang subscription. Maaaring mali itong ipatupad ng agent para rin sa buwanang plano, tapos magsulat ito ng mga test na nagpapatibay sa sarili nitong pagkaunawa. Ang pagkapasa ng mga test na iyon ay magpapatunay lang na tugma ang mga ito sa pagkakamali.

Kailangan ng reviewer ng ebidensiyang nakabatay sa labas ng implementasyong iyon: ang napagkasunduang rekisito, mga halimbawang nagpapakita ng nilalayong asal, at mga kasong dapat pumalya. Maaaring makatulong ang paghingi sa agent ng karagdagang test, pero hindi patunay na nasubok ang maling pagkaunawa sa rekisito ang mas maraming test lang. Responsibilidad ng tao rito ang pagpapasiya kung ano dapat gawin ng software at kung nasasagot ng ebidensiya ang tanong na iyon.

Nanganganib na bigyan ng mas maraming babasahin at mas kaunting kumpiyansa ang mga reviewer ng mga pangkat na nagbibigay-gantimpala sa dami ng test nang hindi sinusuri kung ano ang pinatutunayan ng mga ito. Dapat maglaan ng oras ang manager para sa pagsusuring iyon sa pagtatalaga pa lang ng trabaho, sa halip na ituring itong di-maipaliwanag na pagkaantala pagkatapos matapos ng agent.

## Sukatin ang pagbabagong nakararating sa mga customer

Kapaki-pakinabang na panukat sa mga susunod na yugto ang mga sukatan ng paghahatid ng DORA. Kabilang dito ang oras mula sa pag-commit ng code hanggang sa produksyon, dalas ng deployment, oras ng pagbangon matapos ang pumalyang deployment, bahagdan ng mga deployment na nangangailangan ng agarang pakikialam, at bahagdan ng mga deployment na kumakatawan sa hindi planadong muling paggawa dahil sa insidente. Inilalarawan ng mga ito ang resulta ng paghahatid na lampas sa simpleng pagkapasa ng test. [Mga depinisyon ng sukatan ng DORA](https://dora.dev/guides/dora-metrics/).

Para sa pangkat na nagsisiyasat sa workflow nitong AI coding, ipapares namin ang mga resultang iyon sa isang maikling talaang pantulong:

- Puna: lumipas na oras bago makumpleto ang mga kinakailangang pagsusuri, kasama ang mababagal na run at paghihintay ng kapasidad.
- Konsumo: pinagsama-samang trabaho ng runner at paulit-ulit na pagtatangkang kaugnay ng tinanggap na pagbabago.
- Pagsusuri: oras ng paghihintay ng atensiyon, mahahalagang rebisyong hiniling at dahilan ng bawat isa.
- Epekto sa customer: kung naihatid ng inilabas na pagbabago ang nilalayong asal at kung kinailangan itong iwasto.

Gamitin ang talaan para siyasatin ang isang partikular na workflow. Hindi dapat ituring na magkaparehong yunit ng produktibidad ang maliit na pagbabago sa dokumentasyon at paglilipat ng database. Kung maaari, ihambing ang magkakatulad na gawain sa paglipas ng panahon at itala ang iba pang pagbabago, gaya ng bagong provider ng runner o binagong proseso ng release. Hindi patunay ng sanhi nito ang paglitaw ng pagbuti kasabay ng paggamit ng AI.

Makagagawa na ang mga manager ng konkretong pasiya: pondohan ang limitasyong pumipigil sa mga kapaki-pakinabang na pagbabago na makarating sa mga customer nang may sapat na kumpiyansa. Kung minsan, mas maraming kapasidad sa kompyutasyon ang kailangan. Kung minsan naman, kailangan ang mas malinaw na rekisito, mas mahuhusay na test o sapat na oras ng pagsusuri ng mga bihasa para maunawaan ang mga mungkahing dumarating na.

## Sources

- [Linear: AI coding at sagabal sa CI](https://linear.app/now/ci-bottleneck-reworked) — Setyembre 21, 2026. Nagbibigay ang salaysay ni Mufeez Amjad tungkol sa implementasyon ng mga paunang bilang at halimbawa ng piling pagkakabukod. Unang-kamay na sukat ito ng sistema ng Linear, hindi kontroladong tantiya sa produktibidad ng AI o kabuuang gastos.
- [DORA: Pagtitimbang sa tensiyon ng AI](https://dora.dev/insights/balancing-ai-tensions/) — Marso 10, 2026. Inihihiwalay ang ugnayang nakita sa DORA noong 2025 sa kwalitatibong pagsusuri sa mga sagot ng mga inhinyero ng Google. Inilalarawan ng panloob na pag-aaral ang mga karanasan, hindi ang nasukat na sanhi at epekto; maaaring nahubog ng mga naunang tanong ang mga sagot.
- [METR: AI mula sa unang bahagi ng 2025 at produktibidad ng bihasang developer](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — Randomisadong eksperimento noong Hulyo 10, 2025 na gumamit ng pamilyar na open-source repository at AI tool mula sa unang bahagi ng 2025. Sinusuportahan nito ang resultang bumagal sa saklaw na iyon at ang pagkakaiba sa pananaw ng mga kalahok. Hindi ito tantiya para sa lahat ng developer o mga modelo ng Setyembre 2026.
- [METR: Pagbabago sa eksperimento sa produktibidad ng developer](https://metr.org/blog/2026-02-24-uplift-update/) — Update noong Pebrero 24, 2026. Ipinapaliwanag ang pagpili sa kalahok at gawain, binagong kabayaran at mga problemang dulot sa pagsukat ng sabay-sabay na trabaho. Itinuturing ng mga mananaliksik na hindi maaasahan ang bagong tantiya; hindi namin ipinakikita ang hilaw na bilang nito bilang kasalukuyang pagbilis.
- [GitHub: Pag-cache ng mga dependency](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — Kasalukuyang dokumentasyong sinuri noong Setyembre 22, 2026. Inilalarawan ang muling paggamit sa malilinis na runner at pangangailangang gumana ang mga job kahit walang cache. Hindi nito itinatatag ang performance o singil ng anumang partikular na repository.
- [Vitest: Mga setting ng pagkakabukod sa bawat file](https://vitest.dev/guide/recipes/disable-isolation) — Kasalukuyang dokumentasyong sinuri noong Setyembre 22, 2026. Ipinapaliwanag ang pagkakabukod bilang default, piling pag-configure at mga dependency sa estado na kailangang protektahan. Sinusuportahan ng teknikal na gabay ang pagtitimbang; hindi nagsagawa ang BIG CHANGE ng benchmark o nagbago ng test suite.
- [DORA: Mga sukatan sa pagganap ng paghahatid ng software](https://dora.dev/guides/dora-metrics/) — In-update noong Enero 5, 2026. Tinutukoy ang limang sukatan ng paghahatid at paggamit ng mga ito sa antas ng serbisyo. Nagbibigay ang mga ito ng panukat sa resulta na lampas sa tagal ng CI; pagsusuri ang mga halimbawang pantulong sa artikulong ito, hindi resulta ng bagong eksperimento.