AI агенти за код: 70% от изискванията, 26% готови задачи

Една от задачите в новия тест за AI агенти, които пишат код, звучи почти скучно: вземи сумата от касова бележка и обнови всички тотали в приложението, които зависят от нея. Да прочетеш числото е лесно. Трудната част е думата „всички“. Агентът може да оправи основния тотал, да пропусне едно зависимо поле и пак да върне нещо, което изглежда готово.

Точно това е най-важното в Co-Design Bench – изследване на екипа Token Hub в Alibaba и няколко университета (Fudan, Zhejiang, CUHK, Shanghai Jiao Tong, NTU), публикувано в arXiv на 26 октомври 2026 г. и широко коментирано, откакто The Decoder писа за него на 8 ноември. Най-добрият от десетте тествани модела, GPT-6 Astra, е изпълнил средно 69,9% от критериите за приемане на задача. Изцяло е изпълнил само 26,4% от задачите.

Двете числа са от едни и същи опити. Взети заедно, те казват, че агентът обикновено свършва по-голямата част от работата и оставя поне едно нещо недовършено. Според авторите в 73,6% от задачите е останал поне един критерий, който не е покрит напълно.

Какво точно е тествано

Задачите са 273, подбрани от 37 463 уникални заявки в 26 314 реални сесии, в които хора са искали промени по свои приложения. Авторите нарочно са търсили заявки, които вече са създавали проблеми: потребителят е преформулирал едно и също искане два-три пъти, връщал се е многократно или е отменил промяната. След това експерти са прецизирали всяка заявка и са ѝ написали скрити критерии за приемане. Общо 2331, средно около осем и половина на задача.

Тестът има две части. В първата промените са локални, понякога със снимка, аудио, видео или документ като вход. Във втората трябва да се направят съгласувани промени в цяло хранилище с код. Втората е много по-трудна: най-добрият модел е решил изцяло 41,0% от локалните задачи и 17,9% от тези в хранилище. И десетте модела са се справили по-зле, когато една промяна в хранилището комбинира три или четири типа изменения, отколкото при един или два.

Всички модели са работили в една и съща среда, Claude Code, с еднакви инструкции и инструменти. AI „съдия“ е отварял готовото приложение в браузър и е проверявал кода, а втори AI проверител е оспорвал всяка положителна оценка.

Ограниченията са важни колкото резултатите. Заявките са фиксирани и агентите не са можели да зададат уточняващ въпрос или да получат корекция по средата. Съдиите са модели и могат да грешат. А задачите са избрани именно защото вече са били проблемни. Затова 26,4% не бива да се чете като „агентите се провалят в три от четири ежедневни задачи“ – предупреждение, което прави и един внимателен преглед в DEV.

Къде се крие цената

Следващото е нашият прочит, не изводът на авторите. Скъпата част от работата с агенти за код са последните 30%, защото не се виждат от пръв поглед. Промяна, която покрива седем от осем изисквания, изглежда завършена на демонстрация. Липсващото осмо излиза наяве по-късно, обикновено като тотал, който вече не излиза, или екран, който никой не е погледнал отново.

Тестът вижда тази разлика само защото някой е записал критериите предварително. Точно тази стъпка фирмите обикновено пропускат. Заявка като „добави поле за отстъпка във формата за фактура“ носи пет-шест неизказани очаквания: къде стои полето, как се закръгля, какво става с ДДС, променят ли се старите фактури, какво излиза в PDF-а. Човекът, който пита, ги знае. Агентът не ги знае. Не ги знае и този, който проверява, ако не са записани някъде.

Инструментът около модела също има значение

Авторите са пуснали два от моделите и през три различни среди. При промените в хранилище Qwen3.8-27B има резултат 0,560 в едната и 0,749 в другата – при същите задачи. Разликата между двата модела се мени с до 16,2 процентни пункта според средата, а при локалните промени подредбата на средите е напълно обърната за двата модела.

За всеки, който избира инструмент, това е практично предупреждение. Публичните класации сравняват модели в една конкретна постановка. Вашият екип ще работи с модел в определен продукт, който по свой начин чете файлове, пуска код и решава кога е приключил. Сравнение, което казва нещо полезно, е само това: тази комбинация върху вашите задачи.

Какво бихме променили на практика

Ако екипът ви вече ползва агенти за код или предстои да започне, изследването подсказва няколко навика, които струват малко:

• Пишете критериите за приемане преди заявката. Пет до десет кратки реда за задача, всеки от които може да се провери. Помагат на агента, а прегледът става списък за отмятане вместо „изглежда наред“.
• Разделяйте заявки, които смесват няколко вида промени. Спадът при промени с три-четири типа изменения е най-ясният сигнал в данните. Две малки заявки се проверяват по-лесно от една голяма.
• Оставете агента да пита. В теста уточняващите въпроси бяха забранени. В реалната работа не е нужно да е така. Инструмент, който спира и пита при неясно изискване, струва повече, отколкото подсказва мястото му в класациите.
• Проверявайте работещия резултат, а не обобщението. Съдията в теста отваря приложението в браузър. Ако четете само описанието на агента какво е променил, проверявате неговата увереност.
• Измерете собствения си дял на изцяло готови задачи. Вземете двадесет реални заявки от последния месец, пуснете ги и пребройте колко са излезли напълно верни без човешка намеса. Това число казва колко време за преглед да планирате. Средният процент покрити изисквания не го казва.

Нищо от това не прави агентите по-малко полезни. Да покриеш 70% от изискванията в трудни, реални заявки е много свършена работа. Просто ролята на човека до агента се измества: по-малко писане на код, повече определяне какво значи „готово“ и проверка дали е постигнато.

Ако екипът ви тепърва започва с агенти за код и искате тези навици да са налице от първата седмица, това е част от нашето AI обучение за технически екипи.