AI agenti nadišli su fazu noviteta. Zanimljivo pitanje više nije može li model napisati funkciju, sažeti pull request ili odgovoriti na pitanje korisničke podrške. Pitanje je može li tim oblikovati te sposobnosti u pouzdan sustav koji pomaže softveru prijeći put od ideje do produkcije.

Ta je razlika važna. Chatbot daje odgovor. Agent radi prema ishodu: prima cilj, koristi definirane alate, procjenjuje međurezultate te ili dovršava zadatak ili traži pomoć kada dosegne granicu. Ako se dobro koriste, agenti postaju dio razvojnog pogona. Ako se koriste nepažljivo, postaju brz način za stvaranje grešaka koje izgledaju uvjerljivo.

Promatrajte agente kao sustave, a ne kao magiju

Učinkovit agent nije jednostavno „moćan model s promptom”. To je mali softverski sustav s ulazima, ograničenjima, alatima, stanjem, provjerom i jasnim vlasništvom. Model omogućuje prosudbu nad jezikom i nepotpunim informacijama; okolni sustav osigurava pouzdanost.

Na primjer, agentu zaduženom za rješavanje greške možda će trebati pristup opisu problema, relevantnim izvornim datotekama, naredbama za testiranje i izoliranom razvojnom okruženju. Trebao bi moći pregledati neuspjehe, predložiti usku izmjenu, pokrenuti postojeći skup testova i predočiti dokaze na pregled. Ne bi trebao potajno spojiti izmjenu, mijenjati produkcijske podatke niti proširiti svoj zadatak zato što je pronašao nešto povezano.

Ovo je načelo dizajna jednostavno: agentima dajte dovoljno ovlasti za koristan napredak, ali ne toliko ovlasti da mogu prouzročiti skupo iznenađenje.

Počnite ondje gdje su povratne informacije brze

Najbolje rane primjene agenata obično imaju tri svojstva: zadatak je ograničen, očekivani je rezultat vidljiv, a čovjek može lako pregledati rezultat. Razvoj softvera nudi mnogo takvih prilika.

• Navigacija repozitorijem: utvrđivanje gdje je određeno ponašanje implementirano, praćenje zahtjeva kroz usluge ili objašnjavanje nepoznatog modula.
• Pomoć pri testiranju: generiranje ciljanih testnih slučajeva prema postojećem obrascu, istraživanje neuspješnog testa ili predlaganje nedostajućih rubnih slučajeva.
• Održavanje koda: ažuriranje ponavljajućih mjesta poziva, poboljšavanje poruka o pogreškama, migriranje male API površine ili priprema usko ograničenog refaktoriranja.
• Priprema za pregled: sažimanje skupa izmjena, isticanje vjerojatnih regresija i uspoređivanje implementacije s kriterijima prihvaćanja.
• Operativna podrška: pretvaranje priručnika za rad u vođene kontrolne popise za incidente, uz zadržavanje produkcijskih radnji iza izričitog odobrenja.

To nisu glamurozni slučajevi primjene, ali su vrijedni jer smanjuju trenje u stvarnom radu. Agent koji uštedi dvadeset minuta traženja, postavljanja i rutinskog uređivanja može poboljšati tijek rada cijelog tima, a da od ikoga ne traži da se odrekne inženjerske prosudbe.

Definirajte ugovor zadatka prije prompta

Timovi često počinju s formulacijom prompta kada bi trebali početi s ugovorom zadatka. Prije pokretanja agenta odlučite kako izgleda uspjeh, kojim ulazima smije vjerovati, koje alate smije koristiti i što mora vratiti.

Dobar ugovor za agenta koji mijenja kod mogao bi navesti da smije uređivati samo navedene datoteke, da mora očuvati javno ponašanje osim ako problem ne navodi drukčije, da mora pokrenuti imenovanu naredbu za testiranje i da mora stati ako se testovi ne mogu pokrenuti. Njegov završni odgovor trebao bi uključivati izmijenjene datoteke, obrazloženje izmjene, provedenu provjeru i sve neriješeno.

Cilj: Ispravite pogrešku validacije opisanu u problemu.

Dopušteni opseg:
- Datoteke pod src/validation/
- Povezani testovi pod tests/validation/

Obavezna provjera:
- Pokrenite: npm test -- validation
- Prijavite neuspjehe bez pokušaja nepovezanih popravaka

Eskalirajte kada:
- Popravak zahtijeva migraciju baze podataka
- Ponašanje javnog API-ja nije jasno
- Čini se da su potrebne više od tri datoteke izvan dopuštenog opsega

Ovdje je manje riječ o kontroliranju modela, a više o stvaranju sučelja kojem ljudi mogu vjerovati. Jasne granice također čine neuspjehe informativnima. Ako agent eskalira zato što je zahtjev dvosmislen, to je često koristan signal da je i ljudski zadatak bio dvosmislen.

Ugradite provjeru u tijek rada

Agenti mogu generirati uvjerljiv kod koji je na suptilne načine pogrešan. Mogu pogrešno razumjeti lokalnu konvenciju, netočno zaključiti ponašanje biblioteke ili riješiti vidljivi simptom umjesto temeljnog problema. Provjera stoga nije završna faza; ona je dio radne petlje agenta.

Za zadatke povezane s kodom prednost dajte provjerama koje već odražavaju standarde tima: jediničnim testovima, provjeri tipova, lintingu, koracima izgradnje i ciljanim integracijskim testovima. Za zadatke dokumentacije zahtijevajte poveznice na dostavljeni izvorni materijal ili označite nepotkrijepljene tvrdnje kao otvorena pitanja. Za operativne zadatke koristite probna pokretanja, upite samo za čitanje i točke odobrenja.

Korisni obrazac jest odvojiti generiranje od prosudbe. Jedan agent ili korak tijeka rada priprema prijedlog; drugi ga provjerava prema rubrici; čovjek donosi konačnu odluku kada to rizik opravdava. Recenzent ne mora biti drugi AI sustav. U mnogim su slučajevima sažeti diff i dobro strukturirano izvješće o testiranju najučinkovitije sučelje za pregled.

Uskladite autonomiju s cijenom pogreške

Ne zaslužuje svaki zadatak istu razinu samostalnosti. Promjena oblikovanja u nekritičnom internom alatu razlikuje se od promjene konfiguracije implementacije, politike kontrole pristupa ili financijskog tijeka rada usmjerenog prema korisnicima.

Koristite postupni model autonomije. Dopustite agentima da široko izrađuju nacrte i analiziraju. Dopustite im izvršavanje reverzibilnih radnji u izoliranim okruženjima. Zahtijevajte pregled za izmjene koje utječu na zajedničke grane, vanjske sustave, podatke korisnika, sigurnosne granice ili produkcijsku infrastrukturu. Zadržite mogućnost pregleda onoga što se dogodilo i zaustavljanja tijeka rada.

Dozvole bi trebale biti specifične, gdje je praktično vremenski ograničene i povezane sa zadatkom. Agent kojem je potrebno čitati zapisnike ne treba automatski i ponovno pokretati usluge. Agent koji može otvoriti pull request ne treba dopuštenje za njegovo spajanje. Načelo najmanjih ovlasti nije birokracija; ono timovima omogućuje da tijekom vremena sigurno učine automatizaciju sposobnijom.

Mjerite rad, a ne spektakl

Primamljivo je AI inicijativu mjeriti impresivnim demonstracijama ili brojem generiranih redaka. Te mjere malo govore o tome poboljšava li se rad doista. Bolja pitanja uključuju: Je li se vrijeme pregleda smanjilo? Otkrivaju li se nedostaci ranije? Je li uvođenje novih članova postalo lakše? Provode li inženjeri manje vremena na ponavljajuću koordinaciju? Je li sustav stvorio nove redove za čišćenje i provjeru?

Pratite i skrivene troškove. Agent koji stvara mnogo pull requestova niske kvalitete može prebaciti posao s implementacije na pregled. Sustav koji samouvjereno odgovara bez pouzdanog konteksta može oslabiti odluke. Usvajanje je uspješno kada se poboljša cijeli tijek rada, a ne kada jedna faza samo izgleda brže izolirano.

Trajna prednost je bolja inženjerska praksa

Najobećavajuća budućnost AI agenata nije potpuno autonomna tvornica softvera. To je razvojno okruženje u kojem je rutinski trud smanjen, kontekst je lakše obnoviti, a stručni ljudi mogu više vremena posvetiti arhitekturi, kompromisima proizvoda, kvaliteti i teškim razgovorima koje softver uvijek zahtijeva.

Počnite malim koracima. Dajte agentu stvaran, ali ograničen posao. Definirajte njegov ugovor, povežite ga sa smislenom provjerom, pregledajte njegove neuspjehe i poboljšajte tijek rada prije proširivanja njegovih ovlasti. Organizacije koje će imati najviše koristi neće biti one koje agente tretiraju kao prečac oko inženjerstva. Bit će to one koje agente koriste kako bi zdrave inženjerske prakse bilo lakše provoditi svaki dan.