Markdown izdanje

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

# AI programiranje čini pouzdanu isporuku sledećim inženjerskim izazovom

> Kada AI poveća količinu proizvedenog koda, rukovodioci inženjerskih timova moraju da vide gde izmene čekaju, koliko košta provera i da li objavljeni softver radi kako je zamišljeno.

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.

AI agent za programiranje može da završi zakrpu dok se provere prethodne zakrpe još izvršavaju. Za rukovodioca inženjerskog tima to stvara nezgodnu razliku: tim je proizveo više koda, ali kupac još nije dobio ništa.

Linear je koristan primer. U inženjerskom izveštaju od 21. septembra Mufiz Amjad navodi da se broj njihovih testova gotovo učetvorostručio od početka 2026, dok je čekanje na CI za zahteve za spajanje koda palo sa više od šest minuta na nešto više od pet. Vreme izvršavanja po testu prepolovilo se približno. To su zasebna poboljšanja; poslednji podatak ne znači da se ukupan račun za CI prepolovio. Linear rastući pritisak na proveru pripisuje razvoju uz pomoć agenata, ali njihov izveštaj nije kontrolisani eksperiment koji utvrđuje uticaj AI-ja na produktivnost. [Linearov inženjerski izveštaj](https://linear.app/now/ci-bottleneck-reworked).

Kontinuirana integracija, odnosno CI, automatski pokreće provere predloženih izmena softvera. Ona se nalazi između zakrpe koja deluje uverljivo i izmene koju je tim spreman da prihvati. Kada AI programiranje poveća broj zakrpa, kapacitet provere postaje poslovno pitanje: koliko korisnog rada organizacija može bezbedno da obradi?

Smatramo da rukovodioci treba istovremeno da prate tri ishoda: vreme do pouzdane povratne informacije, ukupan obim računarskog rada i pouzdanost objavljenih izmena. Brži odgovor vredi samo ako tim razume šta taj odgovor potvrđuje.

## Kraće čekanje može zahtevati više rada

Zamislimo paket testova koji na jednoj mašini zahteva dvanaest minuta rada. Ako se ravnomerno podeli na četiri mašine, mogao bi da se završi za tri minuta. Ovaj hipotetički primer pretpostavlja savršenu raspodelu i zanemaruje sve ostalo. Mašine i dalje ukupno obavljaju dvanaest minuta rada.

Dodajmo sada po minut pripreme za svaku mašinu. Verzija sa četiri mašine završava za četiri minuta i troši šesnaest minuta rada izvršivača. Verzija na jednoj mašini traje trinaest minuta i troši trinaest minuta rada. Vreme čekanja se znatno skraćuje, dok ukupna potrošnja mašina raste. Stvarni troškovi zavise i od vrste izvršivača, cena i pravila obračuna.

Ova razlika je važna kada kontrolna tabla slavi kraću zelenu traku. Rukovodilac koji kupuje paralelni kapacitet plaća raniju povratnu informaciju, uz mogući dodatni trošak. To može biti odlična pogodba ako uklanja stvarno usko grlo. Teže ju je opravdati ako završena izmena potom satima čeka dostupnog recenzenta.

Jedinica analize treba da obuhvati više od jednog CI pokretanja. Zakrpa koja izazove više krugova izmena, ponovnih pokretanja i još jedan pregled može zahtevati znatno više rada nego što pokazuje najbrže pojedinačno pokretanje. Brojite pokušaje potrebne da bi izmena bila prihvaćena, uključujući napuštene pokušaje. U suprotnom, naizgled efikasan proces može prikriti skup razvojni rad.

Ni svaki minut čekanja ne predstavlja isti trošak rada. Programer koji tokom provere započne drugi koristan zadatak nije nužno izgubio ceo taj interval. Ipak, ponovljeni prekidi i vraćanje nedovršenim zadacima mogu da škode. Za merenje tih posledica treba posmatrati način rada tima, a ne množiti protekle minute sa platama.

## Istraživanja pokazuju mešovitu sliku

Analiza DORA-e iz marta 2026. iznosi dva zasebna skupa dokaza. Njeno istraživanje iz 2025. povezalo je veću primenu AI-ja i sa većom propusnošću isporuke softvera i sa većom nestabilnošću. Zasebno, istraživači su analizirali 1.110 otvorenih odgovora Guglovih inženjera prikupljenih u trećem kvartalu 2025. Inženjeri su opisali pomoć pri pisanju nacrta i drugim zadacima, ali i dodatni teret provere. Ta interna kvalitativna studija ne obuhvata populaciju iz šire DORA-ine povezanosti; nijedan od tih nalaza ne dokazuje da je AI izazvao probleme sa izdanjima određenog tima. [DORA-ina analiza i metodologija](https://dora.dev/insights/balancing-ai-tensions/).

Postoje i čvršći eksperimentalni dokazi užeg obima. U nasumično raspoređenoj studiji iz jula 2025. METR je dodelio 246 zadataka 16 iskusnih programera otvorenog koda koji su radili u poznatim repozitorijumima. Kada su mogli da koriste AI alate s početka 2025, izvršenje zadataka trajalo je 19 odsto duže. Ipak, učesnici su verovali da im je AI pomogao da rade brže. Nalaz se odnosi na te programere, zadatke i alate; ne može da utvrdi vrednost svakog današnjeg AI agenta za programiranje. [Izvorni eksperiment METR-a](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

METR je u februaru 2026. saopštio da je naknadna studija dala nepouzdanu procenu aktuelnog uticaja AI-ja na produktivnost. Programeri su sve češće odbijali posao bez AI-ja ili birali koje zadatke da prijave; istovremeno korišćenje agenata otežalo je merenje vremena. Istraživači su smatrali da je veće ubrzanje moguće, ali su rekli da podaci pružaju samo slabe dokaze o njegovoj veličini. Ponavljanje ranijeg podatka o usporavanju bez ove ograde navelo bi čitaoce na pogrešan zaključak. [Naknadna studija METR-a](https://metr.org/blog/2026-02-24-uplift-update/).

Rukovodiocima ove studije opravdavaju praktičan pristup: zadržite korisne alate, istražite njihove efekte i ne pretvarajte ni oduševljenje ni skepticizam u univerzalnu formulu za broj zaposlenih. Tim može ostvariti veliku korist na jednoj vrsti posla, a gubiti vreme na drugoj. Proces isporuke treba da pokaže tu razliku.

## Svako usko grlo traži svoje rešenje

Pre nego što kupe dodatni CI kapacitet, pratite jednu izmenu od prve predložene zakrpe do produkcije. Razdvojte rad koji se izvršava od vremena provedenog u čekanju. Utvrdite koja provera zaista odlaže odluku, čija je pažnja potrebna i koji uslovi za izdanje tek predstoje.

Jednostavna evidencija vremena često je dovoljna da otkrije pogrešno ulaganje. Ako se najveće kašnjenje dešava pre početka pregleda, skraćivanje testova za nekoliko sekundi neće rešiti problem. Ako recenzenti stalno čekaju na dugu obaveznu proveru, njeno ubrzavanje ima jasan cilj. Ako se greške uglavnom javljaju posle objave, tim mora da ispita šta provere propuštaju.

Keširanje zavisnosti pokazuje zašto poznatu optimizaciju treba izmeriti. GitHub navodi da keširanje omogućava ponovno korišćenje datoteka koje bi na čistim izvršivačima bilo skupo iznova napraviti. Takođe upozorava da poslovi moraju moći da naprave ili preuzmu te datoteke kada keš nije dostupan. Zato treba procenjivati i pogotke i promašaje keša. [GitHubova dokumentacija o keširanju zavisnosti](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching).

Za rukovodioca je korisno pitanje koliko povratne informacije postaju predvidljive. Odličan prosek može da prikrije povremena čekanja dovoljno duga da poremete izdanje. Pratite spori kraj raspodele i razlikujte opravdan neuspeh testa od neuspešnog preuzimanja ili iscrpljenog izvršivača. Svaki slučaj zahteva drugačije rešenje.

Brza i pouzdana povratna informacija omogućava ljudima i agentima da ranije isprave greške. Unapređenje te zajedničke infrastrukture može koristiti mnogim vrstama razvoja, uključujući izmene napisane bez AI-ja. Zato rukovodioci imaju razlog da ulažu u nju čak i kada menjaju izbor programerskih alata.

![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)

## Brži testovi i dalje moraju da otkrivaju greške

Neke promene performansi menjaju uslove u kojima se test izvršava. To zahteva pažljiviju proveru nego brži procesor.

Vitest, alat za testiranje JavaScripta i TypeScripta, podrazumevano izoluje datoteke sa testovima kako stanje jedne datoteke ne bi uticalo na drugu. Dokumentacija opisuje mogućnost selektivnog isključivanja izolacije za odgovarajuće testove i navodi promenljivo stanje modula, izmenjene globalne objekte i druge zavisnosti kao razloge da se izolacija zadrži. Postavka koja skraćuje pripremu može, dakle, promeniti granicu ispravnosti. [Vitestove smernice za izolaciju](https://vitest.dev/guide/recipes/disable-isolation).

Linear je uveo deljenje stanja kao opciju, dodao čišćenje i zadržao izolaciju za datoteke koje nije mogao bezbedno da premesti. Dobitak u performansama zavisio je od procene koji testovi mogu bezbedno da dele to okruženje. [Linearova implementacija](https://linear.app/now/ci-bottleneck-reworked).

Postoji i poseban izazov kada agent napiše i izmenu i njene testove. Zamislimo hipotetičko pravilo popusta koje važi samo za godišnje pretplate. Agent bi mogao pogrešno da ga primeni i na mesečne pakete, pa zatim napiše testove koji potvrđuju njegovo tumačenje. Uspešni testovi bi samo potvrdili doslednost te greške.

Recenzentu su potrebni dokazi koji nisu izvedeni iz same implementacije: dogovoreni zahtev, primeri željenog ponašanja i slučajevi koji treba da padnu. Traženje dodatnih testova od agenta može pomoći, ali veći broj testova sam po sebi ne pokazuje da je osporeno pogrešno shvaćeno pravilo. Čovek ostaje odgovoran da odluči šta softver treba da radi i da li dokazi odgovaraju na to pitanje.

Timovi koji nagrađuju broj testova, a ne proveravaju šta oni potvrđuju, rizikuju da recenzentima daju više materijala, ali manje razloga za poverenje. Rukovodilac treba da odvoji vreme za tu proveru pri dodeli posla, umesto da je kasnije tretira kao neobjašnjivo kašnjenje nakon što agent završi.

## Merite izmenu koja stiže do korisnika

Metrike isporuke DORA-e korisna su naknadna provera. Obuhvataju vreme od predaje koda do produkcije, učestalost objava, oporavak posle neuspele objave, udeo objava koje zahtevaju hitnu intervenciju i udeo neplaniranog rada na ispravljanju incidenata. One opisuju ishode isporuke koji prevazilaze uspešno izvršen test. [Definicije metrika DORA-e](https://dora.dev/guides/dora-metrics/).

Tim koji istražuje svoj AI razvojni proces mogao bi te ishode da upari sa malom dijagnostičkom evidencijom:

- Povratna informacija: proteklo vreme do obaveznih provera, uključujući spora pokretanja i čekanje na kapacitet.
- Potrošnja: ukupni rad izvršivača i ponovljeni pokušaji povezani sa prihvaćenom izmenom.
- Pregled: vreme čekanja na pažnju recenzenta, tražene veće izmene i razlog za svaku od njih.
- Uticaj na korisnike: da li je objavljena izmena ostvarila očekivano ponašanje i da li je bilo potrebno dodatno ispravljanje.

Koristite evidenciju za ispitivanje konkretnog procesa. Sitnu izmenu dokumentacije i migraciju baze podataka ne treba tretirati kao uporedive jedinice produktivnosti. Gde je izvodljivo, upoređujte sličan rad kroz vreme i beležite druge promene, poput novog dobavljača izvršivača ili izmenjenog postupka objave. Poboljšanje koje se pojavi zajedno sa uvođenjem AI-ja ne dokazuje da ga je AI izazvao.

Rukovodioci zatim mogu doneti konkretnu odluku: finansirati usko grlo koje sprečava da korisne izmene stignu do korisnika uz dovoljno pouzdanosti. Nekad će to značiti veći računarski kapacitet. Nekad će biti potrebni jasniji zahtevi, bolji testovi ili dovoljno vremena iskusnih recenzenata da procene predloge koji već pristižu.

## Sources

- [Linear: AI programiranje i usko grlo u CI-ju](https://linear.app/now/ci-bottleneck-reworked) — 21. septembar 2026. Izveštaj Mufiza Amjada o implementaciji pruža početne brojke i primer selektivne izolacije. Merenja iz prve ruke opisuju Linearov sistem; ona nisu kontrolisana procena produktivnosti AI-ja niti ukupne potrošnje.
- [DORA: Usklađivanje suprotstavljenih efekata AI-ja](https://dora.dev/insights/balancing-ai-tensions/) — 10. mart 2026. Razdvaja povezanost iz istraživanja DORA-e za 2025. od kvalitativne analize odgovora Guglovih inženjera. Interna studija beleži iskustva, ne izmerene uzročne efekte; prethodna pitanja mogla su da utiču na odgovore.
- [METR: AI alati s početka 2025. i produktivnost iskusnih programera](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — 10. jul 2025. Nasumični eksperiment sa poznatim repozitorijumima otvorenog koda i alatima s početka 2025. Potkrepljuje ograničeni nalaz o usporavanju i razliku u percepciji. Nije procena za sve programere ili modele iz septembra 2026.
- [METR: Promene u eksperimentu za merenje produktivnosti programera](https://metr.org/blog/2026-02-24-uplift-update/) — Ažuriranje od 24. februara 2026. Objašnjava izbor učesnika i zadataka, promenu naknade i probleme u merenju istovremenog rada. Istraživači novu procenu smatraju nepouzdanom; sirove brojke ne predstavljamo kao aktuelno ubrzanje.
- [GitHub: Keširanje zavisnosti](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — Aktuelna dokumentacija, pregledana 22. septembra 2026. Opisuje ponovno korišćenje datoteka na čistim izvršivačima i potrebu da poslovi funkcionišu i bez keša. Ne utvrđuje performanse niti trošak za neki konkretan repozitorijum.
- [Vitest: Postavke izolacije po datoteci](https://vitest.dev/guide/recipes/disable-isolation) — Aktuelna dokumentacija, pregledana 22. septembra 2026. Objašnjava podrazumevanu izolaciju, selektivno podešavanje i zavisnosti od stanja koje treba zaštititi. Tehničke smernice objašnjavaju kompromis; BIG CHANGE nije sproveo test performansi niti menjao skup testova.
- [DORA: Metrike performansi isporuke softvera](https://dora.dev/guides/dora-metrics/) — Ažurirano 5. januara 2026. Definiše pet metrika isporuke i njihovu primenu na nivou usluge. One mere ishode izvan trajanja CI-ja; dijagnostički primeri u članku predstavljaju analizu, a ne rezultate novog eksperimenta.