Chatbot može objasniti stack trace, izraditi nacrt testa ili sažeti pull request. Agent ide korak dalje: prima cilj, prolazi kroz niz koraka, koristi alate, provjerava rezultate i odlučuje što učiniti sljedeće. Ta je razlika mjesto na kojem umjetna inteligencija počinje utjecati na rad na softveru umjesto da mu samo pomaže.

Prilika je stvarna, ali stvarna je i inženjerska odgovornost. Koristan agent nije model s dugim promptom i širokim pristupom. To je namjerno ograničen sustav s jasnim ciljevima, pouzdanim granicama alata, vidljivim ponašanjem i sigurnim načinima otkazivanja.

Razmišljajte o radnim tijekovima, a ne o osobnostima

Najvrjedniji softverski agenti obično počinju s uskim radnim tijekom koji već ima jasnog vlasnika i ponavljajuće poteškoće. Primjeri uključuju razvrstavanje pristiglih bugova, pripremu pull requestova za ažuriranje ovisnosti, istraživanje neuspjelih buildova ili pretvaranje odobrene specifikacije u okvirni plan implementacije.

Neodređen zahtjev poput „napravite agenta za inženjering” obično rezultira dojmljivim demoom nejasne vrijednosti. Bolje je krenuti od ovoga: „Kada build ne uspije, prikupi relevantne logove, utvrdi vjerojatnu odgovornost, usporedi s nedavnim promjenama i pripremi nacrt sažetka incidenta za ljudsku provjeru.”

Takav radni tijek ima granicu, ulazne i izlazne podatke te jasnu definiciju uspjeha. Također olakšava odlučivanje o tome gdje agent može djelovati samostalno, a gdje mora stati.

Agentima je potrebna upravljačka petlja

Robustan agent najbolje je shvatiti kao petlju, a ne kao jedan poziv modelu. Prima kontekst, bira sljedeću radnju, koristi odobreni alat, promatra rezultat te nastavlja ili vraća kontrolu osobi. Model pruža prosudbu i jezik; okolna aplikacija pruža strukturu.

goal -> gather context -> choose action -> execute tool
     ^                                             |
     |------------- inspect result <---------------|
                         |
                    finish or escalate

Petlja treba imati izričita ograničenja. Postavite najveći broj poziva alata, vremenski proračun i definirani uvjet zaustavljanja. Bez njih agent može nejasnu situaciju pretvoriti u dug, skup niz radnji s niskom razinom pouzdanosti.

Također mu je potrebno trajno stanje. Ako se od agenta zatraži da istraži neuspjeh implementacije, trebao bi zadržati identifikator implementacije, već pokušane naredbe, ključna opažanja i razlog trenutačne hipoteze. Stanje bi trebalo biti strukturirano gdje god je moguće, umjesto skriveno u rastućem prijepisu razgovora.

Dajte alatima uske, tipizirane ugovore

Dizajn alata često je važniji od dizajna prompta. Alat naziva run_command koji prihvaća proizvoljan tekst ljuske daje agentu golemu moć i malo smjernica. Alat naziva get_build_logs(build_id) ili rerun_failed_test(test_id) lakše je osigurati, testirati, revidirati i ispravno koristiti.

Dobri ugovori alata čine valjane radnje očitima, a nevaljane radnje teškima. Trebali bi validirati ulaze, vraćati strukturirane rezultate i izlagati smislene pogreške. Na primjer, agentu za kontrolu izvornog koda možda će trebati alati za čitanje datoteke, pretraživanje repozitorija, stvaranje grane i otvaranje nacrta pull requesta. Ne treba automatski dopuštenje za spajanje, brisanje grana ili mijenjanje postavki repozitorija.

• Odvojite alate samo za čitanje od alata koji mijenjaju stanje.
• Zahtijevajte potvrdu prije nepovratnih ili izvana vidljivih radnji.
• Koristite ograničene vjerodajnice umjesto jednog svemoćnog tokena.
• Uz poruke čitljive ljudima vraćajte strojno čitljiva polja statusa.
• Bilježite naziv alata, ulaze, rezultat i identitet izvršitelja radi kasnije provjere.

Ta ograničenja ne čine agenta manje sposobnim. Njegovu sposobnost čine dovoljno pouzdanom za korištenje u stvarnom radu.

Dizajnirajte za neizvjesnost i neuspjeh

Modeli mogu pogrešno razumjeti zahtjev, odabrati neprikladan alat ili iznijeti uvjerljivo objašnjenje koje ne odgovara dokazima. Vanjski sustavi mogu isteći, vratiti nepotpune podatke ili promijeniti ponašanje. Dizajn agenta koji pretpostavlja da će svaki korak uspjeti nije spreman za produkciju.

Izgradite izričite putove oporavka. Ako pretraga ne vrati koristan rezultat, agent može jednom proširiti upit, a zatim prijaviti da nema dovoljno dokaza. Ako API za implementaciju istekne, trebao bi razlikovati „implementacija nije uspjela” od „status nije bilo moguće dohvatiti”. Ako nedostaje potrebna potvrda, trebao bi se uredno zaustaviti umjesto da pokušava zaobići kontrolu.

Ponovna pokušavanja zaslužuju posebnu pažnju. Ponovite samo operacije koje je sigurno ponoviti, poput dohvaćanja statusa ili čitanja logova. Za radnju koja mijenja stanje upotrijebite ključ idempotentnosti ili najprije provjerite je li se namjeravana promjena već dogodila. Slijepo ponovno pokušavanje može stvoriti duplikate tiketa, ponovljene obavijesti ili više implementacija.

Koristite ljude kao donositelje odluka u pravim trenucima

Ljudska provjera nije znak da agent nije uspio. Često je riječ o ispravnom dizajnu proizvoda. Zatražite odobrenje kada odluka ima značajan utjecaj na korisnike, financijski utjecaj, sigurnosne posljedice ili nepovratan operativni učinak.

Postoji korisna sredina između potpune automatizacije i ručnog rada: neka agent prikupi dokaze, predloži plan, pripremi zakrpu ili izradi nacrt. Programer zatim pregledava rezultat i odobrava posljedični korak. Time se zadržava brzina, a odgovornost ostaje vidljiva.

Procjenjujte ponašanje, a ne samo odgovore

Uglancan odgovor može prikriti slab radni tijek. Procjena bi trebala testirati je li agent odabrao odgovarajuće alate, poštovao dozvole, rješavao nejasnoće i zaustavio se kada dokazi nisu bili dovoljni.

Izradite mali, ali reprezentativan skup scenarija prije proširivanja pristupa. Uključite jednostavne slučajeve, nepotpune zahtjeve, proturječne upute, nedostupne alate, neispravne odgovore alata i zahtjeve koji bi trebali zahtijevati eskalaciju. Pregledajte konačni izlaz i trag radnji.

Za agente za programiranje korisne provjere mogu uključivati kompilira li se predložena promjena, prolaze li relevantni testovi, ostaje li zakrpa unutar opsega i opisuje li objašnjenje točno što se promijenilo. Pravi cilj procjene jest dovršen rad, a ne samo rječitost.

Integrirajte agente u postojeću inženjersku praksu

Agent bi se trebao uklopiti u isti operativni model kao i ostatak vašeg softvera: verzionirani promptovi i politike, testna okruženja, telemetrija, pregledi pristupa, putovi vraćanja na prethodno stanje i vlasništvo. Promjene alata, dozvola i uputa tretirajte kao produkcijske promjene.

Započnite sa zadacima koji se pretežno oslanjaju na čitanje i s nacrtima izlaza. Mjerite smanjuje li agent vrijeme ciklusa, poboljšava li dosljednost ili oslobađa ljude od repetitivnog istraživanja. Zatim proširujte samo ondje gdje to dokazi podržavaju. Cilj nije maksimizirati autonomiju; cilj je steći autonomiju pouzdanim radom.

Najbolji agenti neće zamijeniti promišljene inženjere. Uklonit će administrativni teret oko promišljenog inženjerstva: prikupljanje konteksta, snalaženje u sustavima, pripremu prvih nacrta i prenošenje rutinskog rada preko granica. Kada su dizajnirani kao disciplinirani softverski sustavi, a ne kao čarobni suradnici, AI agenti mogu timove učiniti bržima, a da njihov rad ne bude manje pažljiv.