Në shumicën e ekipeve që përqafojnë kodimin agjentik, pengesa kalon nga gjenerimi te shqyrtimi; pa përmirësuar këtë cikël, rritja neto e shpejtësisë është thuajse zero.
Në mjedise CI në shkallë të gjerë (miliona teste çdo natë dhe qindra inxhinierë), detyra më e vlefshme për agjentin është përcaktimi i ekipit përgjegjës dhe klasifikimi fillestar, jo gjenerimi i kodit.
Rezultati i dobishëm i agjentit i qëndron shqyrtimit dhe shpjegon shkakësinë, jo vetëm përputhjet e modeleve.
Projektimi i shtresës për mbledhjen e provave dhe ndërtimin e kontekstit ka më shumë rëndësi se shtresa e gjenerimit.
Shumica e diskutimeve për kodimin agjentik ende nisin me një premtim të thjeshtë: të shkruhet më shumë kod, më shpejt.
Ndonjëherë kjo shndërrohet në një vizion më ambicioz, ku agjentët planifikojnë punën, hapin PR dhe publikojnë ndryshime me ndërhyrje minimale njerëzore. Por për shumicën e ekipeve inxhinierike, vlera më e qartë në afat të shkurtër është më e kufizuar. Bëhet fjalë për uljen e kostos së përsëritjes së ciklit.
Ofrimi i softuerit nuk është vetëm gjenerim kodi. Shkrimi i kodit është vetëm një fazë e një cikli më të gjatë, që përfshin shqyrtimin, testimin, vënien në prodhim dhe hetimin kur diçka nuk shkon siç duhet. Shumica e ekipeve që përqafojnë kodimin agjentik pa riprojektuar ciklin e shqyrtimit, thjesht e zhvendosin pengesën në një fazë të mëvonshme.
Vetëm përshpejtimi i gjenerimit nuk e bën automatikisht një ekip më të shpejtë. Ai thjesht mund të zhvendosë më shumë përpjekje te shqyrtimi, verifikimi dhe krijimi i besimit.
Në shumë mjedise inxhinierike, pjesa e kushtueshme nuk është krijimi i variantit të parë, por arritja e sigurisë së nevojshme.
A e zgjidhi vërtet ndryshimi problemin apo e përmirësoi sistemin? A shkaktoi regresion diku tjetër? A qëndron dështimi te kodi, mjedisi, testet apo një varësi? A trajton zgjidhja e propozuar shkakun apo vetëm simptomën e dukshme?
Agjentët mund të ndihmojnë këtu, jo sepse zëvendësojnë inxhinierët, por sepse mund të bëjnë një shqyrtim të parë të strukturuar të provave të çrregullta: të kontrollojnë regjistrat, të krahasojnë ndryshimet e fundit, të përmbledhin sinjalet përkatëse, të gjurmojnë shkaqet e mundshme, të kryejnë kontrolle dhe të japin diçka që një njeri mund ta analizojë më tej.
Në shumë ekipe, përdorimi me ndikimin më të madh i një agjenti nuk është gjenerimi i kodit nga e para. Është ngushtimi i hapësirës së kërkimit rreth një problemi, përpara se dikush të shpenzojë orë duke e bërë këtë manualisht.
Kjo duket veçanërisht qartë në proceset e korrigjimit të gabimeve në shkallë të gjerë. Përfytyroni një CI që çdo natë kryen miliona teste në baza kodi të prekura nga qindra inxhinierë (një realitet për një nga klientët tanë). Kur diçka dështon, është e vështirë të përcaktohet ekipi përgjegjës. Problemi mund të jetë te kodi i aplikacionit, një varësi, struktura e testimit ose diku tjetër në arkitekturën teknologjike. Regjistrat mund të arrijnë disa gigabajt dhe ekipi që e sheh i pari problemin nuk është gjithmonë ai që e ka në përgjegjësi.
Një proces i tillë nuk kërkon natyrshëm që një agjent ta shkruajë zgjidhjen. Ai është i përshtatshëm për një sistem që e ngushton shpejt hapësirën e problemit.
Një proces i dobishëm mund të marrë regjistrat, të përzgjedhë provat përkatëse, të përmbledhë çfarë ka rëndësi, të kontrollojë kodin në një mjedis të izoluar dhe të prodhojë një analizë të strukturuar të shkakut rrënjësor, me vlerësim të sigurisë, gjurmueshmëri dhe hapa të mëtejshëm të sugjeruar. Për të krijuar një rezultat sigurie, një ekspert i fushës vlerëson rezultatin fillestar të agjentit. Më pas, ky vlerësim i jepet një LLM-je që shërben si gjykatës, për ta automatizuar vlerësimin në vijim duke ruajtur përputhjen me gjykimin njerëzor.
Synimi nuk është të eliminohet gjykimi inxhinierik, por t'u jepet shqyrtuesve një pikënisje më e fortë. Klasifikimi fillestar i regresioneve, shqyrtimi i PR-ve, riparimi i testeve, verifikimi i publikimeve dhe hetimi pas vënies në prodhim kanë të njëjtën natyrë. Ato mbështeten shumë te provat dhe shqyrtimi, si dhe janë plot paqartësi. Ato nuk i kërkojnë agjentit të zëvendësojë procesin inxhinierik, por vetëm të ndihmojë në çuarjen e tij përpara.
Kjo është edhe arsyeja pse ekipet duhet të tregohen të kujdesshme në mënyrën se si i vlerësojnë këto sisteme.
Pyetja e gabuar është nëse një agjent mund të prodhojë diçka mbresëlënëse në mënyrë të izoluar. Pyetja më e mirë është nëse ai përmirëson një proces real pa krijuar pengesa diku tjetër.
Kjo do të thotë të shihet nëse rezultati është mjaftueshëm specifik për t'u verifikuar, nëse shpjegon shkakësinë dhe nuk mjaftohet me përputhjen e modeleve, si dhe nëse e bën shqyrtimin më të lehtë, jo më të vështirë. Një përgjigje bindëse nuk është domosdoshmërisht e dobishme. Në praktikë, ekipet i besojnë rezultatit të agjentit kur ai i qëndron shqyrtimit dhe u jep diçka konkrete për të kontrolluar.
Mësimi më i thellë është se sistemet e dobishme agjentike varen nga më shumë sesa vetëm gjenerimi. Ato varen nga mënyra e mbledhjes së provave, e ndërtimit të kontekstit, e kontrollimit të rezultateve dhe e paraqitjes së pasigurisë për shqyrtuesin.
Kjo është arsyeja pse e ardhmja e afërt e inxhinierisë agjentike nuk ka gjasa të jetë një kapërcim i vetëm drejt autonomisë së plotë. Ka më shumë gjasa të jetë një grup ciklesh të projektuara me kujdes, ku agjentët i ndihmojnë ekipet të inspektojnë, shqyrtojnë, verifikojnë dhe përmirësojnë punën e tyre, me më pak përpjekje të çuar dëm ndërmjet hapave.
Kjo mund të jetë më pak dramatike se vizioni më i gjerë i autonomisë, por është shumë më pranë mënyrës se si përqafohen realisht sistemet e dobishme.