Агент за програмирање са вештачком интелигенцијом може да заврши закрпу док провере претходне закрпе још трају. То за инжењерског руководиоца ствара незгодну разлику: тим је направио више кода, али купац још ништа није добио.
Linear пружа користан пример. У инжењерском осврту од 21. септембра, Муфиз Амџад наводи да се број тестова скоро учетворостручио од почетка 2026, док је чекање на CI за захтеве за спајање пало са више од шест минута на нешто више од пет. Време извршавања тестова на извршиоцима смањило се отприлике напола. То су одвојена побољшања; последњи број не значи да се укупан CI рачун преполовио. Linear приписује све већи притисак на проверу развоју уз помоћ агената, али њихов приказ није контролисани експеримент који утврђује утицај вештачке интелигенције на продуктивност. Инжењерски осврт компаније Linear.
Континуирана интеграција, или CI, покреће аутоматске провере предложених измена софтвера. Она стоји између уверљиве закрпе и измене коју је тим спреман да прихвати. Када програмирање уз помоћ вештачке интелигенције повећа прилив закрпа, капацитет за проверу постаје пословно питање: колико корисног посла организација може безбедно да прихвати?
Сматрамо да руководиоци треба заједно да прате три исхода: време до поуздане повратне информације, укупан рачунарски рад и поузданост објављених измена. Бржи одговор вреди само ако тим разуме шта он доказује.
Краће чекање може да захтева више рада
Замислимо скуп тестова који на једној машини захтева дванаест минута рада. Равномерна подела на четири машине могла би да скрати трајање на три минута. Овај хипотетички пример претпоставља савршену расподелу и занемарује све остало. Машине и даље обаве укупно дванаест минута рада.
Ако сада свакој машини треба по минут за припрему, верзија са четири машине завршава за четири минута и троши шеснаест машинских минута на извршиоцима. Верзија са једном машином траје тринаест минута и троши тринаест машинских минута. Чекање се нагло смањује, а укупна потрошња машина расте. Стварни трошкови зависе и од врсте извршилаца, цена и правила обрачуна.
Ова разлика је важна када контролна табла истакне краћу зелену траку. Руководилац који купује капацитет за паралелно извршавање плаћа ранију повратну информацију, потенцијално уз додатни трошак. То може бити одлична размена ако отклања стварно уско грло. Теже је оправдати је када завршена измена затим сатима чека доступног рецензента.
Јединица анализе треба да обухвати више од једног покретања CI-ја. Закрпа која изазове поновљене измене, поновна покретања и други круг прегледа може захтевати знатно више посла него што сугерише њено најбрже појединачно извршавање. Бројте покушаје потребне за прихватање измене, укључујући напуштене. У супротном, наизглед ефикасан процес може да прикрије скуп развојни рад.
Ни сваки минут чекања не представља исти трошак рада. Програмер који за то време започне други користан задатак није нужно изгубио цео интервал. Понављани прекиди и враћање незавршеном послу и даље могу да штете. За мерење тих ефеката треба посматрати начин рада тима, уместо множити протекле минуте платама.
Истраживања показују сложенију слику
Анализа DORA-е из марта 2026. представља два различита скупа доказа. У истраживању из 2025. веће усвајање вештачке интелигенције повезано је и са већим протоком испоруке софтвера и са већом нестабилношћу. Одвојено од тога, истраживачи су анализирали 1.110 отворених одговора Google-ових инжењера прикупљених у трећем тромесечју 2025. Инжењери су описивали помоћ при писању нацрта и другим задацима, као и додатни посао провере. Та интерна квалитативна студија не обухвата исту популацију као шира повезаност у истраживању DORA-е, а ниједан налаз не доказује да је вештачка интелигенција проузроковала проблеме са издањима у конкретном тиму. Анализа и методологија DORA-е.
Постоје и снажнији експериментални докази ужег обухвата. У рандомизованој студији из јула 2025, METR је распоредио 246 задатака на 16 искусних програмера отвореног кода који су радили у познатим спремиштима. Уз дозвољене алате вештачке интелигенције с почетка 2025, задаци су трајали 19% дуже. Учесници су ипак веровали да им је вештачка интелигенција помогла да раде брже. Налаз се односи на те програмере, задатке и алате; не одређује вредност сваког данашњег агента за програмирање. Изворни експеримент METR-а.
У фебруару 2026, METR је саопштио да је накнадна студија дала непоуздану процену актуелног утицаја на продуктивност. Програмери су све чешће одбијали посао без вештачке интелигенције или бирали које ће задатке пријавити; паралелни агенти додатно су отежали мерење времена. Истраживачи су сматрали да је веће убрзање могуће, али да подаци пружају само слаб доказ о његовој величини. Понављање старог налаза о успоравању без овог ограничења довело би читаоце у заблуду. Накнадна студија METR-а.
За руководиоца, ове студије оправдавају практичан приступ: задржати корисне алате, испитати њихове ефекте и не претварати ни одушевљење ни скепсу у универзалну формулу за број запослених. Тим може знатно да добије на једној врсти посла, а изгуби време на другој. Процес испоруке треба да открије ту разлику.
Свако уско грло захтева посебно решење
Пре куповине већег CI капацитета, пратите једну измену од прве предложене закрпе до продукције. Раздвојте посао који се извршава од посла који чека. Утврдите која провера заиста одлаже одлуку, чија је пажња потребна за преглед и који услови за издавање остају након тога.
Једноставна евиденција времена често је довољна да открије погрешну инвестицију. Ако се већина кашњења јавља пре почетка прегледа, скраћивање тестова за неколико секунди то неће решити. Ако рецензенти стално чекају дугу обавезну проверу, њено унапређење има непосредну сврху. Ако се грешке углавном јављају после распоређивања, тим треба да испита шта провере пропуштају.
Кеширање зависности показује зашто познато унапређење треба мерити. GitHub описује кеширање као начин поновне употребе датотека које је скупо поново направити на чистим извршиоцима. Такође наводи да послови морају да могу да поново направе или преузму те датотеке када кеш није доступан. Зато кеширање треба процењивати и када успе и када не успе. Документација GitHub-а о кеширању зависности.
Руководиоцу је корисно питање колико су повратне информације предвидљиве. Одличан просек може да коегзистира са повременим чекањем довољно дугим да поремети издање. Пратите и спорији крај расподеле и разликујте стварни неуспех теста од неуспелог преузимања или исцрпљеног извршиоца. За сваки случај потребан је други одговор.
Поуздана и брза повратна информација пружа и људима и агентима прилику да раније исправе грешке. Унапређење заједничке инфраструктуре може да користи разним врстама развоја, укључујући измене написане без вештачке интелигенције. То руководиоцима даје разлог да у њу улажу и док мењају избор програмерских алата.
Бржи тестови и даље морају да откривају грешке
Неке измене перформанси мењају услове под којима се тест извршава. То заслужује пажљивију проверу него бржи процесор.
Vitest, алат за тестирање JavaScript-а и TypeScript-а, подразумевано изолује датотеке тестова како стање једне датотеке не би утицало на другу. Документација описује селективно искључивање изолације за одговарајуће тестове, али наводи променљиво стање модула, измењене глобалне променљиве и друге зависности као разлоге да се она задржи. Подешавање које скраћује припрему зато може да промени границу исправности. Смернице Vitest-а за изолацију.
Linear је изабрао добровољни приступ дељеном стању, додао чишћење и задржао изолацију датотека које није могао безбедно да пребаци. Добитак у перформансама зависио је од процене који тестови могу безбедно да деле окружење. Linear-ова имплементација.
Посебан изазов настаје када агент напише и измену и њене тестове. Замислимо хипотетичко правило попуста које важи само за годишње претплате. Агент би могао погрешно да га примени и на месечне пакете, па затим напише тестове који потврђују његово тумачење. Ти тестови би прошли, али би тиме потврдили исту грешку.
Рецензенту су потребни докази независни од саме имплементације: договорени захтев, примери жељеног понашања и случајеви који треба да падну. Тражење додатних тестова од агента може да помогне, али већи број тестова сам по себи не показује да је погрешно схваћен захтев проверен. Одговорност човека је да одреди шта софтвер треба да ради и да ли докази одговарају на то питање.
Тимови који награђују број тестова, а не испитују шта они доказују, ризикују да рецензентима дају више материјала, а мање сигурности. Руководилац треба да одвоји време за такву проверу док додељује посао, уместо да је третира као необјашњиво кашњење након што агент заврши.
Мерите измену која стиже до купаца
Показатељи испоруке DORA-е пружају корисну накнадну проверу. Обухватају време од предаје кода до продукције, учесталост распоређивања, опоравак после неуспешног распоређивања, удео распоређивања која захтевају хитну интервенцију и удео непланираног рада на инцидентима. Они описују исходе испоруке изван успешног покретања тестова. Дефиниције показатеља DORA-е.
Тим који испитује радни ток програмирања уз помоћ вештачке интелигенције могао би те исходе да упари са кратком дијагностичком евиденцијом:
- Повратне информације: протекло време до обавезних провера, укључујући спора извршавања и чекање на капацитет.
- Потрошња: укупан рад извршилаца и поновљени покушаји повезани са прихваћеном изменом.
- Преглед: време чекања на пажњу, тражене веће измене и разлог за сваку.
- Утицај на купце: да ли је објављена измена остварила намеравано понашање и захтевала корективни рад.
Користите евиденцију за испитивање конкретног радног тока. Мању измену документације и миграцију базе података не треба сматрати упоредивим јединицама продуктивности. Када је могуће, упоредите сличан посао током времена и забележите друге измене, као што су нови добављач извршилаца или измењен поступак издавања. Побољшање које се поклопило са усвајањем вештачке интелигенције не доказује узрок.
Руководиоци затим могу да донесу конкретну одлуку: финансирати уско грло које спречава да корисне измене стигну до купаца уз довољно поузданости. Понекад ће то значити већи рачунарски капацитет. Други пут ће значити јасније захтеве, боље тестове или довољно времена искусних рецензената да разумеју већ пристигле предлоге.
