Većina automatizacije softvera slijedi jednostavan ugovor: primi ulaz, primijeni definiran proces, vrati izlaz. Agenti umjetne inteligencije mijenjaju taj ugovor. Mogu tumačiti cilj, birati među alatima, provjeravati međurezultate i prilagoditi sljedeću radnju kada prvi pokušaj ne uspije.

To agente ne čini minijaturnim zaposlenicima niti uklanja potrebu za inženjerskom disciplinom. Čini ih novom vrstom suradnika: korisnima kada je njihova autonomija ograničena, njihov rad vidljiv, a osoba i dalje odgovorna za ishod.

Od skriptirane automatizacije do rada usmjerenog na cilj

Tradicionalni proces izgradnje točno zna koje naredbe treba pokrenuti. Uobičajeni chatbot može objasniti kako dijagnosticirati neuspjelu izgradnju. Agentu se može zadati ograničen cilj poput „utvrdi koji test ne prolazi, predloži minimalan popravak i otvori nacrt izmjene za pregled”. Može pročitati pogrešku, pregledati relevantne datoteke, pokrenuti dopuštene provjere i revidirati svoj pristup.

Razlika nije samo u tome što sustav koristi jezični model. Razlika je u petlji: razumjeti zadatak, djelovati putem alata, promatrati rezultat i odlučiti što učiniti sljedeće. Ta je petlja moćna jer je stvarni rad na softveru prepun nepotpunih informacija i iznimaka.

Tu također ulazi rizik. Sustav koji može odabrati radnje može odabrati nekorisnu radnju, ponoviti neuspješnu ili iznijeti uvjerljivu, ali netočnu pretpostavku. Dobar dizajn agenta tretira to kao inženjerski problem, a ne kao problem pisanja promptova.

Promatrajte agenta kao suradnika s jasnim ograničenjima

Najpouzdaniji tijekovi rada s agentima imaju usku ulogu i jasnu definiciju dovršenosti. „Poboljšaj našu bazu koda” nije operativni zadatak. „Sažmi nova izvješća o pogreškama, grupiraj vjerojatne duplikate i izradi nacrte prijava spremne za pregled bez mijenjanja produkcijskih postavki” mnogo je bolje.

Korisne granice obično uključuju:

• Opseg: Koje repozitorije, usluge, dokumente ili prijave agent smije pregledati?
• Dozvole: Smije li čitati podatke, stvarati nacrte, mijenjati granu, implementirati u testno okruženje ili samo preporučivati radnje?
• Alati: Koji su API-ji, naredbe i integracije dostupni?
• Uvjeti za zaustavljanje: Kada mora zatražiti pomoć umjesto da nastavi?
• Dokazi: Koji zapisnici, diffovi, rezultati testova ili citati moraju pratiti njegov izlaz?

Ovaj je okvir produktivniji od rasprave o tome je li agent „potpuno autonoman”. Autonomija nije jedna sklopka. To je skup delegiranih odluka, od kojih svaka ima cijenu pogreške.

Gdje agenti sada pomažu softverskim timovima

Agenti su posebno korisni u tijekovima rada koji kombiniraju mnogo malih koraka zaključivanja s rutinskim korištenjem alata. Mogu smanjiti trenje oko posla koji inženjeri već razumiju, ali za koji nemaju uvijek vremena dosljedno ga obavljati.

Orijentacija u repozitoriju i održavanje

Agent za kodiranje može mapirati bazu koda, pratiti konfiguracijsku vrijednost kroz njezine korisnike, identificirati testove povezane s izmjenom i pripremiti sažeto objašnjenje za recenzenta. To je vrijedno ne zato što zamjenjuje prosudbu o dizajnu, nego zato što skraćuje put od pitanja do korisnog konteksta.

Za malu, dobro ograničenu izmjenu, produktivna petlja može izgledati ovako:

Cilj: dodati validaciju za neobavezno konfiguracijsko polje.

1. Pronaći konfiguracijsku shemu i postojeće konvencije validacije.
2. Identificirati pozivatelje i pogođene testove.
3. Napraviti najmanju kompatibilnu izmjenu.
4. Pokrenuti ciljani skup testova.
5. Predstaviti diff, rezultat testa i svaku nerazriješenu pretpostavku na pregled.

Ljudski recenzent i dalje treba provjeriti je li sam zahtjev ispravan, odgovara li predloženo ponašanje očekivanjima proizvoda i pokrivaju li testovi smislene slučajeve. Prolazni testovi dokazuju samo ono što ti testovi tvrde.

Operativna trijaža

Agent može prikupiti nedavna upozorenja, povezati ih s metapodacima implementacije, sažeti ponavljajuće potpise pogrešaka i predložiti korak iz operativnog priručnika. To je često korisnije nego tražiti od njega da „riješi incident”. Tijekom incidenta brzina je važna, ali važni su i jasno vlasništvo te kontrolirane izmjene.

Sigurniji obrazac agentu najprije daje pristup za čitanje. Može prikupiti činjenice i izraditi nacrt vremenske crte. Određeni operater odlučuje hoće li pokrenuti naredbu za otklanjanje problema. Ako se pristup za pisanje kasnije opravda, trebao bi biti ograničen na reverzibilne radnje uz izričito odobrenje.

Rad sa znanjem povezan s inženjerstvom

Agenti mogu pretvoriti sirovi tehnički materijal u korisne interne artefakte: nacrte bilješki o izdanju, kontrolne popise za migraciju, nacrte odgovora podršci ili objašnjenja zahtjeva za povlačenje za nestručnjake. To su primjene s velikim učinkom jer osoba može brzo pregledati izlaz i jer izvorni materijal može ostati vidljiv.

Dizajnirajte za provjeru, a ne za pouzdanost

Jezični modeli mogu dati odgovor koji zvuči sigurno čak i kada su dokazi oskudni. Agenta zato treba procjenjivati prema sljedivosti njegova rada, a ne prema tečnosti njegove završne poruke.

Zatražite od agenta da razlikuje činjenice koje je uočio od zaključaka koje je izveo. Zahtijevajte da navede datoteke, zapisnike, naredbe ili izlaze alata koji podupiru preporuku. Kada uređuje kod, zahtijevajte diff i točne provjere koje je pokrenuo. Kada ne može provjeriti pretpostavku, treba to jasno reći.

To pregled mijenja iz „Vjerujem li agentu?” u „Mogu li pregledati zaključivanje i potvrditi rezultat?” To je daleko zdraviji odnos prema bilo kojem automatiziranom sustavu.

Putevi neuspjeha zaslužuju prvoklasan dizajn

Mnoge demonstracije agenata usredotočene su na idealan put: poziv alata uspije, podaci su čisti, a odgovor očit. Produkcijski rad je drukčiji. Alatima istekne vrijeme. Dozvole ne uspiju. Podaci su zastarjeli. Naredba se može djelomično izvršiti. Model može pogrešno razumjeti nejasnu uputu.

Izgradite izričito ponašanje za ove slučajeve:

• Pokušajte ponovno samo kod prolaznih neuspjeha, uz malo ograničenje i jasan zapis svakog pokušaja.
• Nemojte automatski ponavljati destruktivne ili izvana vidljive radnje.
• Zaustavite se kada nedostaje potreban kontekst umjesto da prazninu popunite nagađanjem.
• Držite vjerodajnice i osjetljive podatke izvan promptova, zapisnika i generiranih sažetaka.
• Eskalirajte kada radnja prelazi granicu pravila, troška ili pristupa.

U praksi je dobar agent često onaj koji zna kada zastati. Sažeta eskalacija s dokazima vrijednija je od samouvjerenog niza upitnih radnji.

Započnite s tijekom rada, a ne s osobnošću

Timovi ponekad počinju pokušajem stvaranja pomoćnika opće namjene sa širokim pristupom. Takav pristup otežava evaluaciju, a dizajn dozvola čini krhkim. Umjesto toga, započnite s jednim ponavljajućim tijekom rada koji ima mjerljivo usko grlo i jasnog recenzenta.

Na primjer, tim bi najprije mogao automatizirati pripremu zahtjeva za povlačenje u prvom prolazu: sažeti izmjenu, identificirati pogođene komponente, navesti testove i označiti dokumentaciju koja nedostaje. Usporedite izlaz s postojećom praksom pregleda. Pratite gdje agent štedi vrijeme, gdje stvara šum i koje upute stalno zahtijevaju ispravak.

Tek tada proširite njegovu odgovornost. Najbolja sljedeća sposobnost obično je susjedna provjerenoj, a ne skok prema neograničenom pristupu.

Kolaborativna inteligencija prava je prilika

Trajna vrijednost agenata umjetne inteligencije neće proizaći iz pretvaranja da rad na softveru nema dvosmislenosti, odgovornosti ni ljudske prosudbe. Proizaći će iz izgradnje sustava koji obavljaju ponavljajuće pretraživanje, sintezu i koordinaciju oko te prosudbe.

Programeri koji će imati najviše koristi bit će oni koji neuredne ciljeve mogu pretvoriti u vidljive tijekove rada, definirati sigurne granice alata i strogo pregledavati rezultate. U tom modelu agent nije ni magija ni zamjena za stručnost. On je suradnik koji omogućuje da stručnost dosegne dalje — pod uvjetom da je inženjering oko njega dostojan ukazanog povjerenja.