AI agenti postaju korisni kada prestanu biti novost na rubu razvoja i počnu sudjelovati u tijeku rada. Važan pomak nije „zatražiti od modela da napiše kod”. Riječ je o oblikovanju sustava u kojem agent može primiti ograničen kontekst, poduzeti definiranu radnju, pokazati svoj rad i predati kontrolu osobi u pravom trenutku.

Ta je razlika važna. Nacrt izrađen u prozoru za razgovor može uštedjeti nekoliko minuta, ali agent integriran u tijek rada na softveru može smanjiti ponavljajuću koordinaciju, ubrzati istragu i učiniti rutinske inženjerske zadatke dosljednijima. Također može stvarati uvjerljive pogreške strojnom brzinom ako mu tijek rada daje previše ovlasti, a premalo provjere.

Razmišljajte o tijekovima rada, a ne o upitima

Upit je interakcija. Tijek rada je ponovljiv slijed s ulazima, odlukama, alatima, izlazima i točkama pregleda. Timovi postižu pouzdanije rezultate kada odrede uski tijek rada prije odabira modela ili izrade agenta.

Dobri početni kandidati su česti, strukturirani i lako provjerljivi. Na primjer, agent može sažeti neuspjelu izgradnju, klasificirati pristigle prijave grešaka, izraditi nacrt bilješki o izdanju na temelju spojenih zahtjeva za povlačenje ili predložiti testne slučajeve za izmijenjeni modul. To su vrijedni zadaci, ali ne zahtijevaju da agent samostalno redizajnira proizvod.

Ključno pitanje nije može li agent izvršiti zadatak. Pitanje je ima li zadatak jasnu definiciju dovršenosti i siguran odgovor kada agent nije siguran.

Počnite s izričitim ugovorom

Svakom korisnom agentu potreban je ugovor. Definirajte koje informacije prima, koje alate smije koristiti, što mora proizvesti i kada mora stati. „Istraži ovaj incident u produkciji” preširoko je za prvu integraciju. „Pročitaj ove zapise, utvrdi prvu pogrešku u slijedu, navedi tri vjerojatna uzroka i svaku tvrdnju poveži s dokazima” mnogo je sigurnije i lakše za procjenu.

• Ulazi: putanje repozitorija, tekst zahtjeva, zapisi, dokumentacija ili strukturirani događaji.
• Dopuštene radnje: pretraživanje, čitanje, izrada nacrta, stvaranje grane ili otvaranje predložene izmjene.
• Granice: okruženja kojima ne može pristupiti, datoteke koje ne smije mijenjati i odluke rezervirane za ljude.
• Izlazi: zakrpa, sažetak, kontrolni popis, plan testiranja ili strojno čitljiv rezultat.
• Provjera: testovi, lintanje, provjere pravila, stručni pregled ili korak odobrenja.

Ovaj ugovor pretvara nejasnu automatizaciju u inženjersku komponentu koja se može pregledati, testirati i poboljšavati.

Smjestite agente ondje gdje kontekst već postoji

Prikupljanje konteksta često je skriveni trošak rada na softveru. Razvojni inženjeri prelaze između zahtjeva, izvornog koda, dokumentacije, nadzornih ploča i razgovora prije nego što mogu donijeti dobru odluku. Agent može pomoći kada je povezan sa sustavima koji već sadržavaju relevantan kontekst, uz dozvole primjerene zadatku.

Razmotrite pomoćnika za zahtjeve za povlačenje. Umjesto da ga tražite da pregleda izolirani isječak koda, pružite mu razliku, povezane testove, konvencije repozitorija i problem koji se rješava. Zatražite od njega da označi moguće regresije, objasni nesigurnost i izbjegava tvrditi da je nešto pokvareno bez dokaza. Njegovi komentari mogu postati koristan prvi pregled, ali trebali bi nadopunjavati pregled koda, a ne zamijeniti ga.

Ista se ideja primjenjuje na podršku i operacije. Agent koji prima anonimiziranu vremensku crtu incidenta, pojedinosti upozorenja, metapodatke nedavnih implementacija i priručnik s postupcima može sastaviti brže početno izvješće. Ne bi trebao neprimjetno izvršiti vraćanje na prethodnu verziju samo zato što prepoznaje obrazac. Dijagnoza i izvršavanje nose različite rizike te zaslužuju različite razine ovlasti.

Oblikujte radnje za pregled

Najpouzdanije ponašanje agenta često je predlaganje, a ne izvršavanje. Agent može generirati migraciju baze podataka, ali čovjek bi je trebao pregledati prije pokretanja. Može pripremiti ažuriranje ovisnosti, ali izmjena bi trebala proći uobičajeni proces izgradnje i testiranja. Može izraditi nacrt odgovora korisniku, ali netko odgovoran za odnos trebao bi ga odobriti.

Primjenjujte postupnu autonomiju. Počnite s radom samo za čitanje, zatim dopustite izradu nacrta, a potom omogućite usko ograničene izmjene u kontroliranim okruženjima ako rezultati ostanu pouzdani. To timu daje priliku da promatra načine neuspjeha prije nego što agent može uzrokovati skupe posljedice.

Praktičan obrazac jest zahtijevati od agenta da proizvede i radnju i objašnjenje. Za predloženu izmjenu koda zatražite pogođene datoteke, namjeravano ponašanje, iznesene pretpostavke te pokrenute ili još potrebne testove. Za operativnu preporuku zahtijevajte dokaze, očekivani učinak i put vraćanja na prethodno stanje. Objašnjenja ne jamče točnost, ali pregled čine znatno učinkovitijim.

task: propose-test-cases
inputs:
  - changed_files
  - existing_tests
  - acceptance_criteria
output:
  - suggested_tests
  - uncovered_risks
constraints:
  - do_not_modify_files: true
  - cite_input_for_each_risk: true
  - state_uncertainty: true

Ovo nije potpuna implementacija agenta. To je primjer jasnoće koju vrijedi očuvati kada se tijek rada naposljetku implementira u kodu ili platformi za automatizaciju.

Mjerite tijek rada, a ne demonstraciju

Demonstracije agenata obično su optimizirane za impresivne odgovore. Produkcijski tijekovi rada trebaju drukčija mjerila: koliko se često izlaz prihvaća, koliko vremena pregleda stvara ili štedi, gdje ne uspijeva i mijenja li kvalitetu konačnog rezultata.

Pratite mali skup signala koji odgovaraju zadatku. Pomoćnik za bilješke o izdanju mogao bi se procjenjivati prema potpunosti, stopi ispravaka i vremenu do objave. Pomoćnik za generiranje testova mogao bi se ocjenjivati prema tome jesu li predloženi testovi relevantni i otkrivaju li značajne nedostatke. Pomoćnik za trijažu može biti vrijedan čak i kada nije savršeno točan, pod uvjetom da pouzdano usmjerava nesigurne slučajeve osobi.

Kvaliteta ovisi o kontekstu. Bezopasna pogreška u formulaciji internog sažetka nije isto što i pogrešna preporuka u sigurnosnom pregledu. Zahtjeve za odobrenje dodijelite prema posljedicama pogrešnog odgovora, a ne prema tome koliko odgovor djeluje tečno.

Ugradite zaštitne ograde u sustav

Odgovorno usvajanje uglavnom je uobičajena inženjerska disciplina primijenjena na novu vrstu komponente. Ograničite pristup prema načelu najmanjih ovlasti. Držite tajne izvan upita i zapisa. Vanjski sadržaj tretirajte kao nepouzdan, osobito kada agent može koristiti alate. Zabilježite ulaze, pozive alata, izlaze i odobrenja potrebna za istragu neočekivanog rezultata.

Također je mudro odvojiti upute od podataka. Zahtjev za podršku, dokument ili web-stranica mogu sadržavati tekst koji pokušava preusmjeriti ponašanje agenta. Tijek rada trebao bi definirati koje su upute mjerodavne i osigurati da se dohvaćeni sadržaj obrađuje kao referentni materijal, a ne kao novi izvor naredbi.

Za radnje s važnim posljedicama uključite determinističke kontrole oko modela: provjeru sheme, popis dopuštenih naredbi, provjere okruženja, ograničenja stope i korake odobrenja. Modeli su korisni za tumačenje dvosmislenosti; konvencionalni softver i dalje je bolji u provedbi pravila.

Trajna prednost je bolji dizajn sustava

AI agenti neće ukloniti potrebu za prosudbom. Oni prosudbu čine vrednijom mijenjajući mjesta na koja ljudi usmjeravaju svoju pažnju. Najbolji rezultat nije tim koji sve delegira agentu. To je tim koji manje pažnje troši na ponavljajući rad sastavljanja, a više na dizajn, kompromise, utjecaj na korisnike i teška pitanja koja nijedan upit ne može riješiti.

Počnite dovoljno malo da učite, učinite svaku radnju dovoljno vidljivom da joj možete vjerovati i zadržite odgovornost ljudi za ishode. Iza nacrta, tako izgleda smisleno integriranje AI-ja: ne umjetna autonomija radi nje same, nego tijekovi rada na softveru koji postaju mirniji, jasniji i sposobniji.