Заявката за изтегляне (pull request) пристига с вече изпълнени тестове и написано описание – дело на ИИ агент, който е свършил цялата работа сам. Все пак някой трябва да я прочете. В GitHub този някой обикновено е един-единствен разработчик, който преглежда разликите в кода (diff) сам, а останалата част от проекта никога не вижда кода.

Малиха Ноушин Раида и Дацин Хоу от Рочестърския технологичен институт класифицираха 25 264 заявки за изтегляне, генерирани от ИИ агенти, според това кой ги е прегледал и кой е направил промените (commits). Всички хранилища имат поне 100 звезди, агентите са тези, с които повечето разработчици вече са се срещали – GitHub Copilot, OpenAI Codex и Claude Code, а периодът на изследването обхваща месеците от май до юли 2025 г.

Един разработчик прави прегледа и корекциите

Повечето заявки за изтегляне от ИИ агенти преминават през ръцете на един разработчик, който чете кода на агента, коригира уязвимостите или грешките при нужда и го слива (merges). Този модел обхваща 78,9% от заявките за изтегляне в базата данни.

Това повтаря начина, по който много поддръжници на проекти вече работят. Задаваш подкана (prompt) на агента, чакаш заявката за изтегляне, отваряш я, редактираш няколко реда и я пускаш. Ако добавим и случаите, в които някой преглежда работата на агента и я оставя непроменена, едноличният надзор покрива близо девет от десет случая.

Груповият преглед остава рядкост при проекти от всякакъв мащаб. Малките екипи разчитат най-много на соловата практика, докато по-големите екипи разпределят работата по-често, но без напълно да я изместват.

Повечето хранилища изпращат по една или две заявки на тримесечие

Медианното хранилище е отворило една или две заявки за изтегляне от ИИ агенти в рамките на три месеца. Това е цяло тримесечие. За повечето проекти в GitHub агентът се появява от време на време и отново утихва, а само малка част от сътрудниците някога се докосват до работата му.

Интензивното използване принадлежи на малките екипи. Хранилищата с един до петима сътрудници отчитат средно по 50,2 заявки за изтегляне от ИИ агенти на проект – многократно повече от това, което постигат средните и големите екипи, благодарение на няколко изключения, които натоварват агентите изключително много. Когато подредим малките проекти, този в средата изглежда като всички останали.

Раида се върна към малките екипи, преминали границата от 30 заявки за изтегляне от ИИ агенти в разглеждания период, за да провери кой ги преглежда.

„Дори сред най-активните малки хранилища (т.е. малки екипи с повечето от 30 ИИ заявки за изтегляне), по-голямата част от тях продължават да следват работния процес с един проверяващ“, сподели Раида пред Help Net Security. „Това предполага, че повишената активност на ИИ агентите не води непременно до по-разпределени практики за преглед.“

Агентът мащабира дейността, но бюрото за прегледи остава широко колкото за един човек.

Уловката е в самия преглед. Прегледът на код вече изяжда голяма част от работната седмица за повечето разработчици, а всяка заявка за изтегляне от ИИ агент все още трябва да бъде прочетена, тествана и оценена като годна за сливане. Тази работа се пада на човек, а часовете за нея са ограничени.

Лимитът се вижда в цифрите. Само 25 проекта в извадката генерират заявки от ИИ агенти със скоростта, с която работещ разработчик доставя код, съгласно бенчмарка за професионална производителност на Worklytics. Всички останали остават под тази граница.

Соловият и груповият преглед завършват по един и същи начин

Заявките за изтегляне, обработвани от един човек, се сливат с почти същия темп като тези, обработвани от няколко души.

„Процентът на сливане беше много сходен между двата модела на сътрудничество: 81,2% за заявки с един проверяващ и 80,3% за заявки с множество проверяващи/сътрудници“, казва Раида.

Двете групи обаче вършат различна работа. Според Раида „най-често срещаният тип заявка за изтегляне при работните процеси с един проверяващ е свързан с добавянето на нови функционалности, докато заявките, свързани с отстраняване на проблеми и корекции, са най-често срещани при работните процеси с участието на повече хора.“ Соловите разработчици насочват своите агенти към нови функционалности, докато групата се събира за ремонтните дейности.

Тези числа покриват одобрението в рамките на прозореца на проучването и спират дотук. Отмяната на промените (reverts), последващите корекции на грешки и това колко добре се задържа във времето слетият код от ИИ агенти остават извън рамките на набора от данни.

Този модел е обичайна практика, позната на всеки, който е сливал собствен код от Copilot в тих следобед, и се запазва дори при голямо натоварване. Малките екипи, изпълняващи десетки заявки за изтегляне от ИИ агенти, държат по един човек в процеса през цялото време. Малко проекти са натиснали този таван достатъчно силно, за да разберат къде ще поддаде той.