Zašto brži testovi ne mogu rešiti krizu koju stvaraju programerski agenti
Ekspanzija alata veštačke inteligencije višestruko je povećala obim generisanog koda, stvarajući nezabeležene gužve u sistemima za kontinuiranu integraciju. Ipak, ubrzavanje samih procesa testiranja predstavlja rešavanje pogrešnog problema jer se i dalje proverava samo pojedinačni repozitorijum umes
Tehnološke kompanije moraju pomeriti proveru koda unutar same radne petlje agenata i testirati promene na nivou celog distribuiranog sistema, umesto što samo ubrzavaju tradicionalne CI cikluse.
Izaberi iznos ili skeniraj kod bez iznosa pa ga upiši u banci. Novac ide direktno na račun autora (GoSimple), Trek ne uzima ništa i nije posrednik u plaćanju.
Na telefonu: preuzmi kod, pa ga u aplikaciji banke učitaj iz galerije.
Kako su autonomni agenti opteretili postojeće cevovode
Razvoj softvera se poslednjih meseci suočava sa strukturnim izazovom čiji su uzrok autonomni programerski agenti. Tokom protekle dve decenije, sistemi za kontinuiranu integraciju projektovani su za ograničeni ljudski tempo i ritam rada. Kada bi inženjer otvorio nekoliko zahteva za spajanje koda tokom nedelje, izvršavanje testova trajala je dvadeset minuta, što nikoga nije previše opterećivalo jer se programer već preselio na sledeći zadatak. Dolazak alata zasnovanih na veštačkoj inteligenciji potpuno je narušio ovu ravnotežu i ubrzao stvaranje koda do mere koja prevazilazi kapacitete starih alata.
Kompanije poput Anthropic-a zabeležile su višestruki rast obima poslova kontinuirane integracije u periodu od svega nekoliko meseci. Njihovi programeri danas isporučuju znatno više koda po kvartalu nego ranijih godina, dok platforme koje nude ove usluge potvrđuju konstantan i ogroman nedeljni rast broja izvršenih poslova. Kada jedan inženjer pokrene nekoliko agenata istovremeno, broj zahteva za spajanje raste multiplikativno, a ne linearno. Agenti pišu kod munjevitom brzinom, ali okruženje koje treba da proveri taj kod ostaje sporo i nespremno za takav priliv.
Problem nije samo u pukoj količini generisanog materijala već i u redosledu koraka. Konvencionalna integracija pokreće se tek nakon što je zahtev već kreiran i poslat. Ukoliko agent sačeka dvadeset minuta na negativan ishod provere, on u međuvremenu gubi radni kontekst i svaka greška postaja skupa sa stanovišta utrošenog vremena. Industrija je prirodno odgovorila uvođenjem bržih pokretača i pametnijih izbora testova, ali nijedna od ovih mera nije uspela da reši osnovnu pretpostavku da je sistem zapravo samo jedan izolovani repozitorijum.
Iluzija zelenog signala u modernim distribuiranim sistemima
Za jednostavne i samostalne aplikacije, pojedinačni repozitorijum obično predstavlja kompletan sistem. Pokretanje testova u okviru tog repozitorijuma daje prilično pouzdanu sliku o ispravnosti napisanog koda. Međutim, u savremenim cloud-native arhitekturama situacija je drastično drugačija jer je svaka aplikacija tek jedan delić složene mreže od desetina ili stotina povezanih servisa. Testovi unutar jedne baze koda proveravaju isključivo tu specifičnu komponentu, dok sve ostale zavisnosti simuliraju ili ignorišu.
Zbog ovakvog pristupa česta je pojava da izmena prođe sve unit testove, zabeleži rekordno vreme u sistemu za kontinuiranu integraciju i uspešno prođe testnu verziju, a da zatim obori prvi pravi zahtev koji pređe granicu servisa. Greške koje nanose najviše štete u distribuiranim sistemima dešavaju se na samim spojevima između komponenti. Preimenovano polje u odgovoru koje downstream potrošač i dalje očekuje u originalnom obliku može izazvati kaskadne probleme i nepotrebna ponavljanja zahteva.
Izmene šema podataka koje funkcionišu u lokalnim testnim uslovima mogu lako blokirati tabelu u fazi pripreme. Novoizgrađeni krajnji tački se ponašaju besprekorno kada ih poziva interni testni interfejs, ali zakazuju u komunikaciji sa servisom koji od njih zavisi. Nijedan tradicionalni sistem za proveru koda ne može primetiti ove anomalije jer posmatra isključivo parče koda pred sobom, zanemarujući širi kontekst u kojem taj kod zapravo živi i radi.
Zašto brže izvršavanje testova ne otklanja srž problema
Nedavna istraživanja organizacija koje prate metrike softverskih performansi otkrivaju zabrinjavajući trend koji prati šire usvajanje veštačke inteligencije. Iako veštačka inteligencija značajno povećava brzinu isporuke softvera, ona istovremeno dovodi do rasta nestabilnosti u produkcionom okruženju. Formula je jednostavna i poražavajuća: brži kod, identična verifikacija i veći broj kvarova. Upravo tu se otvara ponor između onoga što alati isporučuju i onoga što sistemi mogu bezbedno da podnesu.
Pokušaji da se problem reši isključivo kroz ubrzavanje procesa predstavljaju lečenje simptoma umesto uzroka. Ako se verifikacioni krug ne promeni suštinski, dobija se samo brže potvrđivanje koda koji nosi iste skrivene rizike. Kompanije koje se oslanjaju samo na brže keširanje i snažnije servere u okviru istog starog modela i dalje propuštaju ključni korak u razumevanju ponašanja celog sistema. Potrebno je promeniti samo pitanje koje se postavlja, i to postaviti ga znatno ranije u procesu.
Kada agenti rade unutar virtuelnih mašina i oblačnih okruženja, oni često uspevaju da spoje značajan procenat novih zahteva. Osnovni razlog leži u činjenici da agenti moraju da koriste softver koji stvaraju, jer bez te mogućnosti dostižu svoj gornji limit. Ipak, ti rani peskovnici najčešće sadrže samo izvorni kod, granu na kojoj se radi i osnovne skripte za instalaciju, dok produkciono okruženje ostaje daleko i nepristupačno do kasnijih faza.
Premeštanje provere u rane faze radne petlje
Suštinska promena koja je neophodna industriji sastoji se u pomeranju fokusa sa provere repozitorijuma na proveru celokupnog sistema pre nego što uopšte dođe do otvaranja zahteva za spajanje koda. To ne znači da su povratne informacije o istom pitanju brže, već da se postavlja potpuno drugačije pitanje u ranijoj fazi razvoja. Agent mora da verifikuje svoju izmenu u direktnoj interakciji sa realnim okruženjem, a ne sa sopstvenom umnoženom kopijom koda.
U distribuiranim sistemima, svaka validacija pre kreiranja zahteva mora da obuhvati celinu. Glavni otpor ovakvom pristupu obično dolazi iz straha od ogromnih troškova i kompleksnosti. Logika nalaže da ukoliko svaki agent zahteva pristup celom sistemu za potrebe testiranja, a jedan inženjer upravlja sa pet agenata, kompaniji bi bila potrebna brojna paralelna produkciona okruženja. Takav finansijski izdatak bio bi neprihvatljiv za većinu organizacija na tržištu.
Međutim, rešenje ovog navodnog problema već postoji i oslanja se na principe koje je industrija usvojila za upravljanje računarskim resursima pre mnogo godina. Umesto dodeljivanja posebne mašine za svako pojedinačno opterećenje, primenjuje se deljenje resursa. Jedinstveni klaster može pokrenuti jednu stabilnu verziju svakog servisa i istovremeno podržati hiljade lakih i brzih testnih okruženja koja se nadovezuju na tu osnovu.
Deljenje resursa i efikasnost testnih okruženja
Arhitektura deljenih resursa omogućava da svako testno okruženje primeni isključivo onu izmenu na servisu koja je predmet trenutnog testiranja. Svi ostali dolazni i odlazni zahtevi automatski se preusmeravaju na stabilne zajedničke verzije sistema. Izmenjeni servis komunicira sa stvarnim zavisnostima, dok te zavisnosti nemaju nikakvu svest o tome da se u okruženju bilo šta promenilo. Cena ovakvog testnog okruženja ravna je ceni jedne lake komponente i ono se podiže za nekoliko sekundi.
Zahvaljujući ovoj tehnici, više desetina agenata koji rade paralelno mogu da dele isto stabilno okruženje umesto da ga kloniraju pedeset puta. Time se troškovi drastično smanjuju, čineći sistemsku verifikaciju unutar agentske petlje finansijski potpuno održivom. Efikasnost ovakvog pristupa omogućava brze provere bez opterećenja hardverske infrastrukture i bez ugrožavanja stabilnosti osnovnih poslovnih procesa u preduzeću.
Pored samih resursa, agentima je neophodan i jasan, strukturiran način da te resurse koriste kroz definisane akcije. Upućivanje zahteva, sakupljanje evidencije o radu, potvrđivanje postojanja ugovora i izveštavanje o rezultatima moraju biti standardizovani. Ukoliko se agentima dozvoli da sami improvizuju procedure provere, svako pokretanje daje drugačije rezultate koji se međusobno ne mogu uporediti.
Upravljanje i bezbednost u radu autonomnih agenata
Model koji donosi najbolje rezultate podrazumeva da timovi zaduženi za infrastrukturu unapred pripreme korake u vidu odobrenih akcija. Te akcije testiraju izmenu u živom sistemu i precizno beleže svaku nastalu promenu. Agenti ove korake pokreću kroz ugrađene veštine i dodatke unutar svojih razvojnih okruženja, čime verifikacija postaje sastavni deo njihove svakodnevne petlje, a ne naknadni teret.
Upravljanje ovim procesima podjednako je važno kao i tehničke mere, jer platformski timovi moraju imati potpunu kontrolu nad bezbednošću u okviru deljenog klastera. Niko ne želi da dozvoli situaciju u kojoj autonomni agent može napraviti neoprezan i rizičan korak koji ugrožava stabilnost produkcije. Pored bezbednosti, izuzetno je važna i preglednost izlaznih podataka koji potvrđuju uspešnost svake akcije.
Jasna evidencija o tome koji su servisi pozvani, koje komponente su trpele izmene i da li su ugovori o komunikaciji ispoštovani predstavlja ključni artefakt. Recenzenti koda i automatske kapije za spajanje mogu unapred da vide da je promena testirana nad živim servisima pre nego što je ijedan čovek pogleda. Na taj način, tradicionalni sistemi za kontinuiranu integraciju ponovo dobijaju svoju pravu ulogu kao završna potvrda, umesto da budu prvo mesto na kojem se uočavaju greške.
Nova paradigma razvoja softvera bez uskih grla
Industrija alata za kontinuiranu integraciju nastaviće da ubrzava svoje procese, baš kao što će i programerski agenti postajati sve sposobniji u izvršavanju složenih zadataka u virtuelnim mašinama. Ipak, nijedan od ovih trendova sam po sebi ne može da zatvori jaz koji postoji između izolovanog repozitorijuma i složenog sistema. Kompanije koje budu prednjačile u razvoju softvera prekinuće trku za pukim skraćivanjem vremena testiranja pojedinačnih baza koda.
Umesto pitanja koliko brzo cevovod može potvrditi da repozitorijum prolazi sopstvene testove, uspešne organizacije će pitati koliko rano agent može dokazati da izmena funkcioniše u harmoniji sa okruženjem. Odgovor na ovo pitanje nalazi se na jednom mestu, a to je unutar same petlje agenta, u direktnom sučeljavanju sa realnim sistemom pre kreiranja zahteva za spajanje. Prelazak na ovaj model donosi stabilnost i otklanja uska grla koja ugrožavaju napredak.
Razvoj softvera ulazi u novu fazu u kojoj brzina više nije jedini parametar uspeha, već kvalitet integracije sa celinom. Timovi koji prilagode svoje platforme ovim principima izbeći će zamku rasta nestabilnosti koda i iskoristiti pun potencijal novih tehnologija. Budućnost pripada onima koji prepoznaju da se efikasnost ne postiže bržim kretanjem kroz iste prepreke, već uklanjanjem samih prepreka na samom početku puta.
Izvor: The New Stack · Fotografija: Pexels / Freepik (ilustracija)