Najkorisniji način razmišljanja o AI agentu nije kao o pametnom okviru za automatsko dovršavanje. To je nova vrsta softverskog suigrača: brz, neumoran, sposoban raditi na definiranim zadacima, ali i dalje ovisan o jasnim uputama i provjeri.

Ta posljednja točka je važna. Timovi dobivaju razočaravajuće rezultate kada od agenta traže da „poboljša aplikaciju” i očekuju da se prosudba, kontekst i odgovornost pojave automatski. Smislen učinak postižu kada mu daju omeđen posao, pouzdane alate, izričita ograničenja i način provjere njegova rezultata.

AI agenti mogu smanjiti trenje povezano sa softverskim radom. Mogu istražiti neuspjeli test, izraditi nacrt plana migracije, ažurirati repetitivnu dokumentaciju, sažeti vremenski slijed incidenta ili pripremiti zahtjev za spajanje. No produktivnost proizlazi iz osmišljavanja sustava koji ih okružuje, a ne samo iz dodavanja modela u tijek rada.

Započnite s radom koji ima jasnu završnu točku

Agent radi najbolje kada se uspjeh može precizno opisati. „Pronađi zašto ovaj test ne prolazi i predloži najmanji siguran popravak” bolji je zadatak od „poboljšaj paket testova”. Prvi ima opseg, dokaze za pregled i granicu odlučivanja. Drugi od agenta traži da zaključi prioritete koji možda nisu vidljivi u repozitoriju.

Dobri početni zadaci za agente obično dijele nekoliko svojstava:

• Dovoljno su česti da ušteda vremena bude važna.
• Imaju dostupan kontekst, poput izvornog koda, tiketa, zapisnika ili operativnih priručnika.
• Stvaraju izlaz koji osoba ili automatizirana provjera mogu procijeniti.
• Neuspjeh je niskog troška, reverzibilan ili se otkriva prije produkcije.

Na primjer, agent može razvrstati prijavu greške tako da pronađe relevantne putanje koda, utvrdi nedostajuće pojedinosti za reprodukciju i sastavi pitanja za prijavitelja. Ne bi smio tiho odlučiti da je produkcijski incident riješen samo zato što je poruka o pogrešci nestala iz malog uzorka zapisnika.

Dajte agentu radno okruženje, a ne samo upit

Korisnom agentu treba više od uputa. Potreban mu je kontroliran pristup sustavima koji sadrže činjenice potrebne za obavljanje posla. To može uključivati repozitorij, sustav za praćenje problema, dokumentaciju, pokretač testova i status implementacije. Pristup bi trebao slijediti isto načelo najmanjih ovlasti koje se primjenjuje na ljudske račune.

Odvojite ono što agent smije čitati, mijenjati i izvršavati. Pristup samo za čitanje često je dovoljan za otkrivanje, analizu i izradu nacrta. Pristup za pisanje može biti prikladan za granu ili komentar na tiketu. Produkcijske promjene, upravljanje vjerodajnicama, destruktivne operacije i vanjska komunikacija zaslužuju strože odobravateljske prepreke.

Upute agentu trebale bi te granice učiniti konkretnima. Umjesto da kažete „implementiraj popravak”, definirajte put: izradi granu, napravi najmanju promjenu, pokreni navedene provjere, sažmi rezultate i zatraži odobrenje prije bilo kakve radnje izdavanja. To ponašanje čini predvidljivijim i recenzentima daje upotrebljiv revizijski trag.

Neka provjera bude dio zadatka

Agent ne bi trebao samo tvrditi da je riješio problem. Trebao bi pokazati kako je rezultat provjeren. U softverskom radu to može značiti pokretanje ciljanih testova, provjera formatiranja, statičke analize ili lokalne izgradnje. Za dokumentaciju to može značiti provjeru poveznica, primjera koda i terminologije prema vjerodostojnom izvoru.

Kompaktan ugovor o zadatku može biti vrjedniji od dugog, otvorenog upita:

Cilj: Popravi neuspjeli test parsera.
Opseg: Mijenjaj samo kod parsera i njegove testove.
Obavezne provjere: Pokreni paket testova parsera i alat za formatiranje.
Ograničenja: Ne mijenjaj javno ponašanje bez objašnjenja zašto.
Izlaz: Sažetak, izmijenjene datoteke, pokrenute provjere i svaki preostali rizik.
Eskaliraj ako: Popravak zahtijeva promjenu sheme ili utječe na pohranjene podatke.

To ne jamči ispravnost. Međutim, stvara ponovljiv proces u kojem se ispravnost može procijeniti.

Upotrijebite agente za jačanje razvojnog ciklusa

Slučajevi upotrebe najveće vrijednosti često se nalaze između faza postojećeg rada, umjesto da zamjenjuju cijelu ulogu. Agent može pretvoriti pristigli problem u bolji inženjerski sažetak, zahtjev za spajanje u fokusirani popis za recenziju ili neuspjele testove u strukturiranu dijagnozu. To su mjesta na kojima prikupljanje konteksta i prvi nacrti troše vrijeme, ali konačna prosudba i dalje pripada timu.

Razmotrite asistenta za pregled koda. Njegov posao nije odobravati promjene. Njegov posao je pregledati diff, utvrditi pogođena sučelja, potražiti testove koji nedostaju i označiti pretpostavke koje zaslužuju ljudsku pozornost. Recenzent tada može trošiti manje vremena na ponovno sastavljanje konteksta, a više na procjenu dizajna, rizika i kompromisa.

Isti se obrazac primjenjuje na operacije. Agent može tijekom incidenta prikupiti nedavne implementacije, upozorenja, zapisnike i relevantne odjeljke operativnih priručnika. Može predložiti hipoteze, ali ih treba označiti kao hipoteze i sačuvati poveznice na temeljne dokaze. Brzi sažeci su korisni; lažna sigurnost je opasna.

Projektirajte za neizvjesnost i neuspjeh

Jezični modeli mogu proizvesti uvjerljiva, ali netočna objašnjenja. Agenti koji koriste alate također mogu zakazati na uobičajenije načine: dozvole mogu nedostajati, naredbama može isteći vrijeme, API može vratiti zastarjele podatke ili ponovni pokušaj može duplicirati radnju. Radni tijek agenta produkcijske kvalitete planira za takve uvjete.

Gdje je moguće, koristite idempotentne radnje, posebno za ponovne pokušaje. Zabilježite što je agent pokušao, što je uočio i što se promijenilo. Zahtijevajte potvrdu prije radnji koje se ne mogu sigurno ponoviti. Ako poziv alata ne uspije, agent bi trebao prijaviti neuspjeh i svoju sljedeću sigurnu opciju umjesto da izmisli uspješan rezultat.

Također pomaže razlikovati „nisu pronađeni dokazi” od „postoji dokaz da nešto ne postoji”. Ako agent ne može pristupiti izvoru zapisnika, nije utvrdio da nije došlo do pogrešaka. Ta je razlika mala u formulaciji, a golema u operativnim posljedicama.

Mjerite radni tijek, a ne demonstraciju

Tečna demonstracija može sakriti slab sustav. Procjenjujte agenta na stvarnim zadacima tijekom vremena: koliko često dolazi do korisnog ishoda, koliko često recenzenti prihvaćaju njegov rad uz manje izmjene, gdje mu je potrebna eskalacija i skraćuje li smisleni ciklus. Uključite trošak recenzije, ispravaka, upotrebe alata i održavanja.

Zadržite mali skup za procjenu reprezentativnih zadataka, uključujući nezgodne slučajeve i poznate načine neuspjeha. Ponovno ga pokrenite pri promjeni upita, modela, alata ili dozvola. To je ekvivalent regresijskom testiranju za agente: sprječava da lokalno poboljšanje neprimjetno naruši sposobnost o kojoj tim ovisi.

Novom suigraču potrebno je dobro upravljanje

AI agenti neće ukloniti potrebu za vještim programerima. Povećavaju vrijednost vještina koje su oduvijek bile važne: dobro definiranje problema, odvajanje činjenica od pretpostavki, projektiranje sigurnih sučelja, pregled promjena i znanje kada ne treba automatizirati.

Timovi koji će imati najviše koristi tretirat će agente kao suradnike kojima se upravlja. Dat će im ograničene ovlasti, koristan kontekst, mjerljiv posao i dosljednu povratnu informaciju. Automatizirat će rutinske dijelove zaključivanja, a da pritom ne automatiziraju odgovornost.

To je trajna prilika. Agent ne mora biti savršen da bi postao produktivan. Treba ga smjestiti unutar sustava u kojem je njegova brzina korisna, njegove pogreške vidljive, a ljudska prosudba ostaje povezana sa svakom važnom odlukom.