Кај повеќето тимови што усвојуваат кодирање со агент, тесното грло се преместува од генерирањето кон прегледувањето, а без подобрување на целиот циклус, нето-добивката во брзината е речиси нула.
Во големи CI-опкружувања (милиони тестови секоја ноќ и стотици инженери), највредната задача за агентот е насочување до одговорниот тим и првична анализа, а не генерирање код.
Корисниот резултат од агентот издржува темелна проверка и ја објаснува причинско-последичната врска, наместо само да препознава обрасци.
Осмислувањето на слојот за собирање докази и составување контекст е поважно од слојот за генерирање.
Повеќето дискусии за кодирање со агент сè уште почнуваат со едноставно ветување: пишување повеќе код за пократко време.
Понекогаш тоа прераснува во поамбициозна визија во која агентите ја планираат работата, отвораат PR-барања и објавуваат промени со минимална човечка интервенција. Но за повеќето инженерски тимови, најјасната краткорочна вредност има потесен опсег. Станува збор за намалување на трошокот за повторување на работниот циклус.
Испораката на софтвер не се сведува само на генерирање код. Пишувањето код е само една фаза од подолг циклус што опфаќа прегледување, тестирање, пуштање во употреба и истражување кога нешто ќе тргне наопаку. Повеќето тимови што усвојуваат кодирање со агент без да го преосмислат циклусот на прегледување само го преместуваат тесното грло во подоцнежна фаза.
Самото забрзување на генерирањето не значи дека и тимот автоматски ќе работи побрзо. Тоа може само да префрли повеќе работа врз прегледувањето, проверката и градењето доверба.
Во многу инженерски опкружувања, скапиот дел не е изработката на првата верзија, туку стекнувањето сигурност во неа.
Дали промената навистина го реши проблемот или го подобри системот? Дали предизвика регресија на друго место? Дали дефектот е во кодот, опкружувањето, тестовите или во некоја зависност? Дали предложената поправка ја отстранува причината или само видливиот симптом?
Агентите можат да помогнат тука, не затоа што ги заменуваат инженерите, туку затоа што можат структурирано да ги прегледаат неуредните докази: да ги испитаат дневниците, да ги споредат неодамнешните промени, да ги сумираат релевантните сигнали, да ги проследат веројатните причини, да извршат проверки и да понудат резултат што човек може детално да го испита.
Во многу тимови, најкорисната примена на агентот не е генерирање код од почеток. Туку стеснување на просторот за пребарување околу проблемот пред човек да потроши часови правејќи го тоа рачно.
Ова е особено очигледно кај работните текови за отстранување грешки во голем обем. Замислете CI што секоја ноќ извршува милиони тестови низ бази на код на кои работат стотици инженери (реалност за еден од нашите клиенти). Кога нешто ќе откаже, тешко е проблемот да се насочи до одговорниот тим. Проблемот може да биде во апликацискиот код, некоја зависност, рамката за тестирање или на друго место во технолошкиот стек. Дневниците може да зафаќаат гигабајти, а тимот што прв ќе го забележи проблемот не е секогаш тимот што е одговорен за него.
Таквиот работен тек природно не бара еден агент да ја напише поправката. Тој е наменет за систем што брзо го стеснува просторот на можни причини.
Корисен процес би можел да ги преземе дневниците, да ги избере релевантните докази, да го сумира важното, да го испита кодот во изолирано опкружување и да подготви структурирана анализа на основната причина со оцена на сигурноста, следливост и предложени следни чекори. За да се создаде оцена на сигурноста, стручен експерт го оценува првичниот резултат на агентот. Потоа тоа се внесува во големи јазични модели (LLM) во улога на судија, за понатамошното оценување да се автоматизира, а притоа да остане усогласено со човечката процена.
Целта не е да се отстрани инженерското расудување, туку на рецензентите да им се обезбеди подобра почетна основа. Првичната анализа на регресии, прегледувањето PR-барања, поправката на тестови, валидацијата на изданија и истражувањето по пуштањето во употреба имаат иста структура. Сите бараат многу докази и прегледување и се полни со нејаснотии. Тие не бараат од агентот да го замени инженерскиот процес, туку само да помогне тој да напредува.
Затоа тимовите треба да внимаваат и како ги оценуваат овие системи.
Погрешно е да се праша дали агентот може самостојно да создаде нешто впечатливо. Подобро е да се праша дали тој подобрува вистински работен тек без да создава пречки на друго место.
Тоа значи да се провери дали резултатот е доволно конкретен за да се потврди, дали ја објаснува причинско-последичната врска наместо само да препознава обрасци и дали го олеснува прегледувањето наместо да го отежнува. Веродостоен одговор не е исто што и корисен одговор. Во практиката, тимовите му веруваат на резултатот од агентот кога тој издржува темелна проверка и им нуди нешто конкретно што можат да го проверат.
Подлабоката поука е дека корисните системи со агенти зависат од многу повеќе од генерирањето. Тие зависат од тоа како се собираат доказите, како се составува контекстот, како се проверуваат резултатите и како неизвесноста јасно му се прикажува на рецензентот.
Затоа е малку веројатно дека блиската иднина на инженерството со агенти ќе биде еден огромен скок кон целосна автономија. Поверојатно е дека ќе се состои од низа внимателно осмислени циклуси во кои агентите им помагаат на тимовите да ја испитуваат, прегледуваат, проверуваат и усовршуваат својата работа со помалку залудно вложен труд меѓу чекорите.
Тоа можеби е помалку драматично од пошироката визија за автономија, но е многу поблиску до начинот на кој навистина се усвојуваат корисните системи.