При повечето екипи, които възприемат агентното кодиране, тясното място се измества от генерирането към прегледа и без подобряване на този цикъл почти няма нетно увеличение на скоростта.
В мащабни среди за непрекъсната интеграция (милиони тестове всяка нощ и стотици инженери) най-ценната задача за Агента е да определи отговорния екип и да извърши първоначален анализ, а не да генерира код.
Полезният резултат от Агента издържа на щателна проверка и обяснява причинно-следствените връзки, а не просто разпознава закономерности
Проектирането на слоя за събиране на доказателства и изграждане на контекст е по-важно от слоя за генериране.
Повечето дискусии за агентното кодиране все още започват с просто обещание: повече код за по-малко време.
Понякога това прераства в по-амбициозна визия, при която агенти планират работата, създават заявки за сливане и внедряват промени с минимална човешка намеса. За повечето инженерни екипи обаче най-ясната краткосрочна полза е по-конкретна. Тя се състои в намаляване на разходите за итерации.
Доставянето на софтуер не се изчерпва с генерирането на код. Писането на код е само един етап от по-дълъг цикъл, включващ преглед, тестване, внедряване и разследване при възникване на проблеми. Повечето екипи, които възприемат агентното кодиране, без да преработят цикъла за преглед, просто преместват тясното място към следващ етап.
Самото ускоряване на генерирането не прави автоматично екипа по-бърз. То може просто да прехвърли повече усилия към прегледа, проверката и изграждането на доверие.
В много инженерни области най-скъпата част не е изготвянето на първия проект, а постигането на увереност.
Действително ли промяната отстрани проблема или подобри системата? Доведе ли до регресия на друго място? На какво се дължи неизправността — на кода, средата, тестовете или някоя зависимост? Предложената корекция отстранява ли причината, или само видимия симптом?
Агентите могат да помогнат тук не защото заменят инженерите, а защото могат да извършат структуриран първоначален преглед на разнородните данни: да прегледат логовете, да сравнят последните промени, да обобщят относимите сигнали, да проследят вероятните причини, да изпълнят проверки и да представят резултат, който човек може да проучи допълнително.
В много екипи най-голяма полза от агента има не когато той генерира код от нулата, а когато стеснява пространството за търсене около даден проблем, преди човек да е прекарал часове в ръчното му проучване.
Това се вижда особено ясно при мащабни процеси за отстраняване на грешки. Представете си непрекъсната интеграция, която всяка нощ изпълнява милиони тестове в кодови бази, по които работят стотици инженери — реалност за един от клиентите ни. Когато възникне грешка, е трудно да се определи отговорният екип. Проблемът може да е в кода на приложението, в зависимост, в тестовата рамка или другаде в технологичния стек. Логовете могат да достигнат обем от няколко гигабайта, а екипът, който пръв забележи проблема, невинаги е отговорният за него.
Такъв работен процес поначало не изисква един агент да напише корекцията. Той е предназначен за система, която бързо стеснява проблемното пространство.
Един полезен процес може да извлече логовете, да подбере относимите данни, да обобщи същественото, да провери кода в изолирана среда и да изготви структуриран анализ на първопричината с оценка на увереността, проследимост и препоръчани следващи стъпки. За да се създаде оценка на увереността, експерт в съответната област оценява първоначалния резултат от агента. След това оценката се подава към система, в която големи езикови модели действат като съдия, за да се автоматизира бъдещото оценяване, като то остане съгласувано с човешката преценка.
Целта не е да се премахне инженерната преценка, а да се осигури по-добра отправна точка за проверяващите. Първоначалният анализ на регресии, прегледът на заявки за сливане, поправянето на тестове, валидирането на версии и разследването след внедряване следват една и съща схема. Всички те изискват много доказателства и прегледи и са изпълнени с неясноти. Те не изискват от агент да замени инженерния процес, а само да спомогне за напредъка му.
Затова екипите трябва да внимават и как оценяват тези системи.
Погрешният въпрос е дали един агент може самостоятелно да създаде нещо впечатляващо. По-добрият въпрос е дали той подобрява реален работен процес, без да създава затруднения другаде.
Това означава да се прецени дали резултатът е достатъчно конкретен за проверка, дали обяснява причинно-следствените връзки, вместо само да разпознава закономерности, и дали улеснява прегледа, вместо да го затруднява. Правдоподобният отговор невинаги е полезен. На практика екипите се доверяват на резултата от агента, когато той издържа на щателна проверка и им дава нещо конкретно, което да проверят.
По-важният извод е, че полезните агентни системи зависят от нещо повече от генерирането. Те зависят от начина, по който се събират доказателствата, изгражда се контекстът, проверяват се резултатите и несигурността се представя на проверяващия.
Затова близкото бъдеще на агентното инженерство едва ли ще бъде един огромен скок към пълна автономност. По-вероятно е то да включва набор от внимателно проектирани цикли, в които агенти помагат на екипите да проверяват, преглеждат, валидират и усъвършенстват работата си с по-малко излишни усилия между отделните стъпки.
Това може да звучи по-малко впечатляващо от по-мащабната визия за автономност, но е много по-близо до начина, по който действително се възприемат полезните системи.