AI agenti postaju koristan inženjerski obrazac, ne zato što mogu zamijeniti prosudbu, nego zato što mogu obavljati ograničen posao putem alata u kojima se prosudba već odvija. Važan je pomak suptilan: umjesto da od modela tražite jedan odgovor, sustavu dajete cilj, radni kontekst, pristup pažljivo odabranim radnjama i način provjere je li njegov rad dovoljno dobar.

Zbog toga su agenti posebno zanimljivi softverskim timovima. Dobro osmišljen agent može naučiti oblik tijeka rada tima: kako problemi postaju zahtjevi za spajanje, koje provjere moraju proći, gdje se bilježe odluke i kada čovjek mora uskočiti. Ne mora biti mističan ni autonoman u svakom smjeru. Zapravo, najbolji agenti obično su ograničeni, promatrivi i namjerno dosadni u onome što je važno.

Od upita u chatu do sustava tijeka rada

Chat model izvrstan je u pomaganju nekome da promisli problem. Agent je sustav koji ga okružuje i pomaže pretvoriti to zaključivanje u slijed radnji. Može dohvatiti relevantne dokumente, pregledati ticket, pozvati internu uslugu, izraditi nacrt promjene, pokrenuti test i prijaviti rezultat.

Model je samo jedna komponenta. Pouzdan agent također treba jasnu granicu zadatka, upravljanje stanjem, dozvole za alate, pravila provjere i put eskalacije. Bez tih dijelova, „agentsko” ponašanje često znači dugačak upit koji stvara tekst koji izgleda samouvjereno, ali nema pouzdanu vezu sa stvarnošću.

Razmotrite zahtjev za pripremu sažetka izdanja. Osnovni asistent mogao bi sažeti bilo koji tekst koji mu se zada. Agent za tijek rada mogao bi umjesto toga:

• prikupiti spojene zahtjeve za spajanje unutar definiranog raspona izdanja;
• grupirati ih prema utjecaju na korisnike, radovima održavanja i popravcima;
• prepoznati stavke kojima nedostaje jasan opis;
• izraditi nacrt bilješki o izdanju u formatu koji tim preferira; i
• vratiti neizvjesne stavke na ljudski pregled umjesto nagađanja.

To je značajno poboljšanje, ali nije čarobna zamjena za odgovornost za izdanje. Agent obavlja prikupljanje, klasifikaciju i izradu nacrta. Osoba i dalje potvrđuje jezik proizvoda, rizik i potpunost.

Što znači naučiti tijek rada

„Učenje” ne treba miješati s tihim ponovnim treniranjem modela na svakoj radnji. U praktičnim sustavima agent uči tijek rada putem eksplicitnog konteksta i povratnih informacija. Taj kontekst može uključivati predloške, primjere, odobrenu terminologiju, konvencije repozitorija, operativne priručnike i pravila o tome tko smije što odobriti.

Na primjer, asistent za pregled koda može se podučiti da usluga zahtijeva testove za promjene autorizacije, da migracije baze podataka trebaju napomenu o vraćanju na prethodno stanje i da se generirane datoteke ne smiju ručno uređivati. To su činjenice o tijeku rada. One pripadaju dostupnim, održavanim uputama, a ne samo sjećanju iskusnih inženjera.

Povratne informacije zatim usavršavaju sustav. Ako recenzenti opetovano odbijaju određenu vrstu preporuke, istražite zašto. Možda agentu nedostaje arhitektonski kontekst. Možda je kriterij pregleda previše nejasan. Možda zadatak nikada nije trebalo delegirati bez ljudske kontrolne točke. Ispravke tretirajte kao signale o proizvodu, a ne samo kao neuspjehe modela.

Počnite s ponovljivim preprekama

Najbolji prvi slučajevi upotrebe su ponavljajući, ograničeni i lako provjerljivi. Tražite posao koji troši pozornost bez potrebe za širokim ovlastima: pretvaranje bilješki o incidentu u vremensku crtu, izdvajanje akcijskih stavki iz tehničke odluke, pripremanje testnih slučajeva iz kriterija prihvaćanja ili pronalaženje dokumentacije koja više ne odgovara sučelju.

Korisna provjera je jednostavna: možete li definirati kako dobar rezultat izgleda prije nego što agent počne? Ako je odgovor ne, tijek rada možda je još uvijek previše dvosmislen. Počnite standardiziranjem ljudskog procesa, a zatim automatizirajte stabilne dijelove.

Izgradite upravljačku ravninu prije dodavanja autonomije

Agenti su najvrjedniji kada je njihove radnje lakše pregledati nego ručni proces koji podržavaju. To zahtijeva upravljačku ravninu: zapis ulaza, dohvaćenog konteksta, poziva alata, međukoraka odlučivanja, izlaza i događaja odobravanja. Točna implementacija varirat će, ali načelo je dosljedno: agent treba ostaviti revizijski trag.

Pristup alatima zaslužuje jednaku pažnju kao dozvole aplikacija. Agentu dajte najmanji skup mogućnosti koji može dovršiti njegov posao. Čitanje sustava za praćenje problema razlikuje se od promjene statusa ticketa. Izrada nacrta komentara na zahtjev za spajanje razlikuje se od spajanja koda. Promjene u produkciji trebaju jače zaštitne mjere od ažuriranja dokumentacije.

Također je mudro odvojiti planiranje od izvršavanja. Agent može predložiti plan, navesti datoteke ili zapise koje namjerava dirati i čekati odobrenje prije izvođenja nepovratne radnje. To čini neuspjehe jeftinijima i ljudima daje prirodno mjesto za primjenu konteksta koji sustav možda nema.

Cilj: Pripremiti zahtjev za spajanje za ažuriranje ovisnosti

Dopuštene radnje:
- Čitanje manifesta ovisnosti i lockfileova
- Pokretanje odobrene naredbe za testiranje
- Izrada nacrta zahtjeva za spajanje

Obavezne provjere:
- Sažeti promijenjene pakete
- Uključiti rezultate testova
- Zaustaviti se ako testovi ne prođu
- Ne spajati ni uvoditi u produkciju

Ovakva specifikacija vrjednija je od razrađenog upita za osobnost. Definira ovlasti, očekivane dokaze i siguran način neuspjeha.

Oblikujte za neizvjesnost, a ne samo za uspjeh

Jezični modeli mogu stvarati uvjerljiva objašnjenja kada su dokazi nepotpuni. U agentu za tijek rada ta tendencija postaje opasna kada je uparena sa stvarnim alatima. Sustav treba biti oblikovan tako da kaže „Ne mogu ovo provjeriti” i da se zaustavi kada se njegova sigurnost ne može utemeljiti na dostupnim informacijama.

Provjera treba odgovarati zadatku. Za promjene koda koristite postojeće testove, lintere, provjere tipova i pregled. Za podatkovne zadatke usporedite izlaze sa shemama, poznatim invarijantama i uzorcima zapisa. Za podršku ili operativni rad zahtijevajte citate dohvaćenog izvornog materijala i usmjerite iznimke odgovornoj osobi.

Ponovni pokušaji zahtijevaju jednako pažljivo oblikovanje. Ponovni pokušaj prolaznog mrežnog zahtjeva može biti razuman. Ponovni pokušaj destruktivne radnje nakon dvosmislenog rezultata može stvoriti duplikate ili oštetiti podatke. Svaka integracija alata treba razlikovati neuspjeli zahtjev, dovršeni zahtjev s izgubljenim odgovorom i radnju koja mora biti pregledana prije ponavljanja.

Mjerite tijek rada, a ne spektakl

Timovi često procjenjuju agente prema tome koliko demonstracija djeluje impresivno. Vrijednost u produkciji bolje se mjeri ishodima tijeka rada: manje vremena utrošenog na rutinsku pripremu, manje pogrešaka pri predaji, brže povratne informacije, jasnija dokumentacija i bolja vidljivost neriješenog posla.

Vodite malu tablicu rezultata za svaki slučaj upotrebe. Pratite gdje je agent trebao ljudsku ispravku, koji su ulazi nedostajali i je li izlaz nakon pregleda doista uštedio vrijeme. Tijek rada koji stvara više provjeravanja nego što uklanja nije automatizacija; to je još jedno sučelje kojim treba upravljati.

Također pomaže očuvati ručni put. Ljudi moraju dovoljno dobro razumjeti temeljni tijek rada da ga mogu upravljati tijekom prekida rada, istražiti pogreške i poboljšati pravila. Agent treba učiniti stručnost dostupnijom, a ne sakriti proces iza crne kutije.

Trajna prednost je operativna jasnoća

AI agenti neće učiniti softverski rad bez napora. Otkrivat će gdje je rad nedovoljno specificiran, gdje je znanje zarobljeno u razgovorima i gdje su dozvole rasle bez jasnog vlasništva. To razotkrivanje je korisno. Timovima daje razlog da neformalne navike pretvore u eksplicitne, provjerljive sustave.

Najuspješniji agenti neće biti oni kojima je dodijeljeno najviše slobode. Bit će to oni koji duboko razumiju uzak tijek rada, prikupljaju prave dokaze, djeluju unutar jasnih granica i znaju kada odluku vratiti čovjeku. Gradite prema tom standardu i agent postaje više od pametnog sučelja: postaje pouzdana infrastruktura za način na koji se posao obavlja.