Разработката на AI агенти получава надграждане с подход „първо тестове“
Разработката на AI агенти направи практична крачка напред тази седмица, след като.NET екипът на Microsoft отвори кода на code-testing-generator — polyglot агент за unit тестове, който планира, пише, изпълнява и проверява тестове в локални хранилища. Водещият бенчмарк е важен, но по-дълбоката промяна е структурна: екипите започват да третират агентите за генериране на код по-малко като autocomplete и повече като workflow системи с изрични стъпки за проучване и валидиране. На практика това означава, че следващите подобрения в разработката на AI агенти може да идват не толкова от по-добри модели сами по себе си, а от по-добра логика на внедряване около тези модели.
Според репортажа на MarkTechPost за пускането, агентът на Microsoft е изпълнил 140 от 152 вътрешни бенчмарк задачи, срещу 120 за стандартния GitHub Copilot при същия модел и същите подкани. Кодът се публикува като дефиниция на агент в MIT-лицензираното dotnet/skills repository, а не като хоствана услуга, което е важно за екипи, които се нуждаят от локално изпълнение.
Microsoft превръща генерирането на тестове в проблем на внедряването
Повечето coding инструменти все още представят генерирането на тестове като функция тип prompt-response. Искаш unit тестове, получаваш unit тестове. Този модел на взаимодействие работи при чисти примери, но често се проваля в реални хранилища със смесени конвенции, частично покритие, legacy build скриптове и особености при CI откриването.
Пускането от Microsoft е забележително, защото третира тестването като проблем за AI automation agent. Агентът прочита хранилището, преди да напише каквото и да е, открива езика и вероятния framework, проверява съществуващите тестове и идентифицира build и test командите, които реално се използват в тази кодова база. За product и platform екипи това е много по-близо до реалната delivery работа, отколкото еднократно дописване.
Именно затова разликата в бенчмарка заслужава внимание. Подобрението не е равномерно разпределено. При детайлни подкани агентът и стандартният Copilot на практика са изравнени. При неясни подкани и заявки, насочени към diff, разликата рязко се увеличава. Това подсказва, че основният източник на стойност е проучването на хранилището, а не суровата „креативност“ на модела.
Защо еднократното генериране на тестове се проваля в реални хранилища
Практическият сценарий на провал при test automation обикновено не е „моделът не може да напише assertion“. По-често моделът пише грешния тест, на грешното място, по грешните конвенции — и въпреки това обявява успех.
В реални хранилища три проблема редовно подкопават AI workflow automation за инженерни екипи:
- Неяснота около framework-а. Подканата рядко уточнява дали JavaScript хранилище използва Jest, Vitest или Mocha, или дали Python услуга очаква pytest fixtures или unittest класове.
- Конвенции в хранилището. Екипите се различават по разположение на файловете, именуване, setup helpers, mocking patterns и стил на assertion-ите.
- Реалност на изпълнението. Един тест може да изглежда правилен, но все пак да се провали в CI, защото build-ът на workspace-а е счупен, проектът не се открива автоматично или пътят на командата се различава от локалните предположения.
Собственото описание на Microsoft, както е предадено от MarkTechPost, формулира това ясно: обща заявка като generate unit tests не казва на системата кой framework, коя локация на файловете или кои assertion-и да използва. Именно този липсващ контекст е мястото, където много custom AI agents се провалят в production.
От playbook-а на Encorp: Най-голямата грешка при внедряване в инженерната автоматизация е да се приема, че генерирането на код е самата работа. На практика работата е интерпретация на хранилището плюс верификация. Екипите, които оценяват AI DevOps workflow automation, трябва да оценяват агентите по точността на откриване и изпълнение, а не само по качеството на генерирания код.
Оттук следва и вторичен ефект. С нарастващото приемане на AI integration architecture за софтуерна доставка, тесното място се измества от достъпа до модели към приземяването на workflow-а в реалния контекст. Печелившите системи ще бъдат онези, които разбират достатъчно добре локалния контекст, toolchain-а и сценарии на провал, за да действат предвидимо.
Как pipeline-ът Research-Plan-Implement променя workflow-а
Pipeline-ът Research-Plan-Implement, или RPI, е най-важният избор в дизайна на това пускане. Той налага последователност, която много екипи в момента пропускат.
По време на research етапа агентът претърсва хранилището за код без тестове, извежда езика и framework-а за тестване, прочита съществуващи тестове, за да разбере конвенциите, и намира командите, които хранилището реално използва. По време на planning етапа той избира между директна, еднопроходна или итеративна стратегия според обхвата. По време на implementation етапа пише тестове и ги валидира, без да променя production кода.
Това звучи процедурно, но има по-широки последици за AI platform integration. Полезният инженерен агент вече не е просто chat слой върху модел. Той се нуждае от достъп до контекста на хранилището, build инструменти, среди за изпълнение и feedback цикли. С други думи, моделът е само един компонент от системата.
Пазарът започва да се разделя по две линии. Едната е асистенти, оптимизирани за скорост при прости задачи. Другата е агенти, оптимизирани за довършване на работа в хаотични, силно контекстни сценарии. Пускането на Microsoft е категорично във втората категория.
AI агентите трябва да се оценяват по завършената работа, а не по елегантни демонстрации.
— адаптирано от насоките за оценка на Andrew Ng, чиято рамка за operator-и все повече пасва на оценката на enterprise агенти
За mid-market софтуерните екипи това разграничение е по-важно от движението в leaderboard-ите на моделите. Малко подобрение в разбирането на хранилището може да надмине голямо подобрение в суровото качество на генериране, ако целта е тестовете да минат през CI.
Какво улавя verification gate-ът, преди да обяви успех
Verification слоят е мястото, където това пускане надхвърля обикновеното генериране на код. Преди да отчете завършване, агентът изпълнява пет проверки: reasoning от тип mutation дали малки промени в кода би трябвало да накарат тестовете да се провалят, проверка за слаби assertion-и, съпоставяне на поисканите сценарии с реалните тестове, изпълнение на пълен workspace build и test suite, и потвърждение, че собствената test команда на хранилището открива новите тестове.
Този подход отразява по-широка промяна в AI implementation services: все по-голяма част от стойността идва от логиката за отхвърляне, а не от логиката за генериране. За модела е по-лесно да произведе правдоподобен изход, отколкото да докаже, че този изход е валиден в заобикалящата го система.
Това е особено важно в регулирани или силно одитирани софтуерни среди като financial services, здравеопазване, застраховане и публичен сектор. Тези екипи често се интересуват по-малко от това да генерират повече тестове и повече от това да намалят фалшивата увереност. Тестов файл, който съществува, но никога не се изпълнява, е оперативно по-лош от липсата на файл, защото изкривява предположенията за покритие.
Компромисът е ясен. Повече verification означава повече сложност в оркестрацията и умерено по-висока употреба на токени. MarkTechPost съобщава, че потреблението на токени за завършена задача е било с 3.2% по-високо. За много инженерни организации това е приемлива цена, ако намалява тихите провали и нуждата от преработка.
Къде всъщност са концентрирани подобренията в бенчмарка
Числата от бенчмарка са най-силни, когато се четат по сегменти, а не само по водещото число.
- Общо изпълнение: 92.1% за агента срещу 78.9% за стандартния Copilot.
- Неясни подкани: 88.8% срещу 66.3%.
- Детайлни подкани: 96.8% и за двата.
- Задачи, насочени към diff: 15 от 15 срещу 0 от 15.
- Средно време за задача: 359 секунди срещу 380 секунди.
- Покритие: 72.4% срещу 72.2%, при 2.3% по-малко генерирани тестове.
Тези числа показват, че агентът не просто произвежда повече изход. Той произвежда повече изход, който е уместен спрямо контекста. Това е критично разграничение за всеки, който оценява разработката на AI агенти отвъд демо сценариите.
Полезни са и резултатите по модели. Според източника Claude Opus 4.8 е достигнал 43 от 45.NET задачи с агента срещу 35 от 45 без него; GPT-5.5 е достигнал 41 от 45 срещу 36 от 45. При външния SWE Atlas benchmark изпълнението се е повишило от 12 от 44 на 16 от 44. Външният резултат все още е умерен, но сочи в същата посока: scaffolding-ът около модела променя резултатите.
Сравнителният ъгъл тук е важен. Ако подкани на екипа вече са силно специфични и хранилищата му са добре стандартизирани, увеличението може да е ограничено. Ако подканите са недостатъчно конкретни, repo-тата са на смесени езици или CI конвенциите са крехки, ползата вероятно ще е по-голяма. Именно затова startup и mid-market екипите може да спечелят по-бързо от големите enterprise организации, въпреки че enterprise средите имат повече код. По-малките екипи често нямат капацитет да кодифицират конвенциите ръчно, така че repository-aware AI automation agents компенсират този дефицит незабавно.
Какво е разумно да направят екипите с този клас агенти
Краткосрочната възможност не е да се заменят test инженерите. Тя е да се пренасочи работата на агентите към модули и workflow-и, където контекстът на хранилището има най-голямо значение.
Открояват се три модела за rollout:
Първо, използвайте тези агенти за backfill на тестове в legacy модули, където конвенциите съществуват, но покритието е слабо. Второ, използвайте ги върху pull-request diff-ове, където обхватът е тесен и сигналът от verification е по-ясен. Трето, използвайте ги преди release gate-ове, където откриването и изпълнението на тестове са по-важни от чистия обем на генерирания изход.
Enterprise организациите трябва да добавят още една стъпка: да адаптират езиковите насоки и framework правилата към вътрешните си стандарти. Именно тук AI integration architecture става решаваща. Колкото по-специфична е средата, толкова повече агентът трябва да отразява локалните build команди, approval потоци и политики за тестване.
По-широкият извод е, че разработката на AI агенти узрява от prompt engineering към systems engineering. Разграничителният фактор все повече е workflow-ът около модела: research, planning, execution и proof. Пускането на Microsoft е ранен, но конкретен пример за тази промяна.
За екипите, които оценяват подобни внедрявания, полезният въпрос не е дали агентът може да пише тестове. А дали може да произведе тестове, които оцеляват в собствената реалност на хранилището.
FAQ
Какво е code-testing-generator?
Това е open-source polyglot агентът на Microsoft за unit тестове в dotnet-test plugin-а в dotnet/skills repository. Той проучва хранилище, избира вероятния framework и конвенции, пише тестове, изпълнява ги и проверява дали самото хранилище действително открива тези тестове.
С какво се различава от стандартния GitHub Copilot?
Основната разлика е в разбирането на хранилището и дълбочината на verification. Вместо само да генерира test код от подкана, агентът проучва repo-то, проверява командите, валидира assertion-ите и потвърждава откриването на тестовете. В бенчмарка на Microsoft това повишава изпълнението от 78.9% до 92.1% при същия модел и същите подкани.
Кой е най-добрият първи сценарий за rollout?
Най-силните начални сценарии са backfill на тестове в legacy модули, генериране на тестове за pull-request diff-ове и повишаване на покритието преди release gate. Тези случаи печелят най-много от агент, който може да изведе конвенциите на хранилището, вместо да разчита на обща подкана.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation