Агенттік бағдарламалауды енгізген командалардың көбінде тар орын код жасаудан оны тексеруге ауысады; бұл цикл түзетілмесе, жалпы жылдамдық өсімі нөлге жуық болады.
Ауқымды CI орталарында (түн сайын миллиондаған сынақ, жүздеген инженер) агент атқаратын ең пайдалы міндет — код жасау емес, жауапты топқа бағыттау және бастапқы талдау.
Агенттің пайдалы нәтижесі мұқият тексеруден өтеді әрі жай ғана үлгі сәйкестігін емес, себеп-салдарды түсіндіреді.
Дерек жинау және мәнмәтін құрастыру қабатын жобалау генерация қабатынан маңыздырақ.
Агенттік бағдарламалау туралы талқылаулардың көбі әлі де қарапайым уәдеден басталады: көбірек кодты жылдамырақ жазу.
Кейде бұл агенттер жұмысты жоспарлап, PR ашып, адамның араласуын барынша азайтып, өзгерістерді өндіріске енгізетін әлдеқайда өршіл тұжырымға ұласады. Алайда инженерлік командалардың көбі үшін таяу мерзімдегі ең айқын пайда бұдан нақтырақ әрі шектеулі: итерация құнын азайту.
Бағдарламалық жасақтаманы жеткізу тек код жасаумен шектелмейді. Код жазу — тексеру, сынау, өрістету және ақау шыққанда зерттеу жүргізілетін ұзақ циклдің бір кезеңі ғана. Тексеру циклін қайта жобаламай агенттік бағдарламалауды енгізген командалардың көбі тар орынды үдерістің кейінгі кезеңіне ғана жылжытады.
Генерацияны жеделдетудің өзі команданың жұмысын автоматты түрде жылдамдатпайды. Ол тексеруге, растауға және сенімділік қалыптастыруға көбірек күш жұмсауға әкелуі мүмкін.
Көптеген инженерлік ортада ең көп шығын алғашқы нұсқаны жасауға емес, оның дұрыстығына сенімді болуға кетеді.
Өзгеріс мәселені шынымен түзетті ме немесе жүйені жақсартты ма? Ол басқа жерде регрессия туғызған жоқ па? Ақау кодта ма, ортада ма, сынақтарда ма, әлде тәуелділікте ме? Ұсынылған түзету себепті жоя ма, әлде тек көзге көрінетін белгісін бе?
Агенттер инженерлерді алмастырғандықтан емес, ретсіз деректерді құрылымды түрде бастапқы талдаудан өткізе алатындықтан көмектеседі: журналдарды қарап, соңғы өзгерістерді салыстырады, маңызды белгілерді қорытындылайды, ықтимал себептердің ізін анықтайды, тексерістер жүргізеді және адам әрі қарай талдай алатын нәтиже береді.
Көптеген командада агентті қолданудың ең тиімді жолы — кодты нөлден жасау емес. Ол адам бірнеше сағат бойы қолмен іздеуге кіріспес бұрын, мәселені шешуге қатысты іздеу кеңістігін тарылтады.
Бұл ауқымды жөндеу және ақау іздеу үдерістерінде әсіресе анық көрінеді. Жүздеген инженер өзгеріс енгізетін кодтық базаларда түн сайын миллиондаған сынақ орындайтын CI жүйесін елестетіңіз (клиенттеріміздің бірінде бұл — нақты жағдай). Бір нәрсе істен шыққанда, оны жауапты топқа бағыттау қиын. Мәселе қолданба кодында, тәуелділікте, сынақ жүйесінде немесе технологиялық стектің басқа бөлігінде болуы мүмкін. Журналдардың көлемі гигабайтқа жетуі мүмкін, ал мәселені алғаш байқаған команда оған әрдайым жауапты бола бермейді.
Мұндай жұмыс үдерісі бір агенттің түзету жазуына арналмаған. Оған мәселе аясын жылдам тарылтатын жүйе қажет.
Пайдалы конвейер журналдарды алып, тиісті деректерді іріктеп, маңыздысын қорытындылап, кодты оқшауланған ортада тексеріп, сенімділік бағасы, қадағалау мүмкіндігі және ұсынылған келесі қадамдары бар құрылымды түпкі себеп талдауын ұсына алады. Сенімділік бағасын қалыптастыру үшін пәндік сала маманы агенттің бастапқы нәтижесін бағалайды. Одан кейін бұл нәтиже адамның бағалауымен сәйкестікті сақтай отырып, алдағы бағалауды автоматтандыру үшін төреші рөліндегі LLM (үлкен тілдік модель) жүйесіне беріледі.
Мақсат — инженерлік пайымды жою емес, тексерушілерге жұмысты сенімдірек негізден бастауға мүмкіндік беру. Регрессияны бастапқы талдау, PR тексеру, сынақтарды түзету, шығарылымды растау және өрістетуден кейінгі зерттеу — бәріне ортақ сипат бар. Олардың бәрі дерек пен тексеруді көп қажет етеді әрі белгісіздікке толы. Олар агенттен инженерлік үдерісті алмастыруды емес, оны алға жылжытуға көмектесуді ғана талап етеді.
Сондықтан командалар бұл жүйелерді бағалау тәсіліне де мұқият қарауы керек.
Агент жеке өзі әсерлі нәтиже жасай ала ма деген сұрақ қою — қате. Дұрысы — ол басқа жерде кедергі туғызбай, нақты жұмыс үдерісін жақсарта ма деп сұрау.
Яғни нәтиженің тексеруге жеткілікті дәрежеде нақты болуын, жай үлгі сәйкестігін емес, себеп-салдарды түсіндіруін және тексеруді қиындатпай, жеңілдетуін бағалау қажет. Шындыққа жанасатын жауап пен пайдалы жауап бір нәрсе емес. Іс жүзінде командалар агенттің нәтижесіне ол мұқият тексеруден өтіп, нақты тексеруге болатын дерек ұсынғанда сенеді.
Бұдан шығатын маңызды сабақ: пайдалы агенттік жүйелерге генерацияның өзі жеткіліксіз. Олардың тиімділігі деректердің қалай жиналатынына, мәнмәтіннің қалай құрастырылатынына, нәтижелердің қалай тексерілетініне және белгісіздіктің тексерушіге қалай көрсетілетініне байланысты.
Сондықтан агенттік инженерияның таяу болашағы бірден толық дербестікке өтетін алып секіріс болуы екіталай. Оның орнына агенттер командаларға кезеңдер арасында босқа жұмсалатын күш-жігерді азайтып, жұмысын қарап шығуға, тексеруге, растауға және жетілдіруге көмектесетін мұқият жобаланған циклдер жиынтығы қалыптасуы ықтимал.
Бұл толық дербестік туралы кең ауқымды идеядай әсерлі көрінбеуі мүмкін, бірақ пайдалы жүйелердің іс жүзінде қалай енгізілетініне әлдеқайда жақын.