Većina AI alata još se ponaša poput vrlo brzih pripravnika: odgovaraju na pitanja, sastavljaju funkciju, sažimaju tiket i čekaju sljedeći upit. Svakako korisno. No AI agent predstavlja drugačiji inženjerski prijedlog. To je sustav koji može ostvarivati ishod kroz više koraka, koristiti alate, provjeravati rezultate, oporavljati se od uobičajenih neuspjeha i ostaviti projekt u bolje definiranom stanju.

Ta je razlika važna jer softverski projekti nisu skupovi izoliranih zadataka generiranja koda. Oni su lanci odluka: razumjeti zahtjev, pronaći relevantni kod, sigurno ga izmijeniti, pokrenuti provjere, protumačiti neuspjehe, ažurirati dokumentaciju i izvijestiti o onome što ostaje neizvjesno. Ako će agent preuzeti značajne dijelove tog lanca, treba mu više od sposobnog modela. Potrebno mu je pažljivo dizajnirano radno okruženje.

Vlasništvo nije autonomija bez ograničenja

„Preuzmi projekt” ne bi trebalo značiti „daj agentu produkcijske vjerodajnice i nadaj se najboljem.” U zdravom inženjerskom timu vlasništvo uključuje odgovornost, granice, dokaze i eskalaciju. Isto vrijedi i za agente.

Agent može preuzeti ograničen ishod, poput održavanja grane za ažuriranje ovisnosti u ispravnom stanju, pripreme kandidata za izdanje ili implementacije jasno ograničenog zadatka. Trebao bi znati kako izgleda uspjeh, koje su datoteke i sustavi u opsegu, koje su provjere obavezne i kada mora stati radi ljudske revizije.

Korisni mentalni model nije chatbot s dodatnim gumbima. To je ograničeni radnik koji djeluje unutar ponovljivog radnog tijeka. Model pruža prosudbu i jezik; okolni sustav pruža memoriju, alate, pravila i provjeru.

Započnite s ciljem oblikovanim prema projektu

Slabi ciljevi proizvode bučno ponašanje agenta. „Poboljšaj performanse” poziva na široko istraživanje i dvosmislene promjene. Cilj oblikovan prema projektu daje agentu ciljnu crtu: smanjiti ponovljeni rad određenog upita, očuvati postojeći API ugovor, dodati mjerilo performansi i osigurati prolazak testnog paketa.

Dobra definicija zadatka odgovara na nekoliko praktičnih pitanja:

• Koji je ishod potreban i kako će se provjeriti?
• Koji su dijelovi repozitorija ili infrastrukture u opsegu?
• Koja se ponašanja ne smiju promijeniti?
• Koje dozvole agent smije koristiti?
• Što bi trebalo uzrokovati eskalaciju umjesto pokušaja zaobilaznog rješenja?

To nije birokracija. Smanjuje vjerojatnost da agent lokalni simptom protumači kao dozvolu za redizajn cijelog podsustava. Također čini konačni rezultat podložnim reviziji. Recenzent može usporediti izvorni cilj, promjene, dokaze iz testova i otvorena pitanja.

Omogućite agentu pouzdanu radnu petlju

Učinkoviti agenti ne pozivaju alate jednostavno u dugom, improviziranom nizu. Rade kroz petlju koja opažanja pretvara u odluke, a odluke u dokaze.

1. Pročitajte zadatak, smjernice repozitorija i relevantan kontekst.
2. Pregledajte trenutačno stanje prije predlaganja promjene.
3. Napravite najmanju promjenu koja bi mogla ispuniti cilj.
4. Pokrenite odgovarajuće provjere.
5. Dijagnosticirajte neuspjehe koristeći izlaz i kontekst izvornog koda.
6. Pokušajte ponovno samo kada je sljedeća radnja opravdana novim informacijama.
7. Sažmite rezultat, dokaze, ograničenja i potrebnu reviziju.

Ta petlja zvuči poznato jer je to oblik discipliniranog softverskog rada. Razlika je u tome što agentu petlju treba učiniti eksplicitnom. Ako nema pravilo za zaustavljanje, može nastaviti ponovno pokušavati s nedostupnom uslugom. Ako nema pravilo za pregled neuspjeha, može opetovano mijenjati kod kako bi utišao simptom. Ako nema kriterije dovršetka, može proglasiti uspjeh nakon uređivanja datoteka bez pokretanja relevantnih provjera.

Ponovni pokušaji trebaju pravila, a ne optimizam

Prolazni neuspjesi su uobičajeni: registar paketa može isteći, testno okruženje može biti privremeno nedostupno ili udaljeni API može vratiti pogrešku koja dopušta ponovni pokušaj. Agent bi ih trebao razlikovati od determinističkih neuspjeha poput pogreške tipa, nedostajuće varijable okruženja ili odbijanja autorizacije.

Na primjer, naredba ovisna o mreži može se ponoviti uz ograničeno postupno čekanje, ali neuspjeli jedinični test trebao bi potaknuti pregled prije sljedećeg pokretanja. Jednostavno je pravilo: ponovite istu radnju samo kada klasa neuspjeha sugerira da bi vrijeme ili prolazno stanje mogli promijeniti rezultat. U suprotnom prikupite više konteksta ili eskalirajte.

if command_fails_due_to_transient_network_error; then
  retry_with_bounded_backoff
else
  inspect_failure_and_choose_a_new_action
fi

Vrijednost ovdje nije u pseudokodu. Ona je u operativnoj disciplini koja stoji iza njega: agent ne smije zamijeniti ustrajnost s napretkom.

Dizajn alata određuje je li agent siguran

Modeli zaključuju kroz sučelja koja su im dana. Neodređeni shell sa širokim pristupom za pisanje potiče neodređene, široke radnje. Alati izrađeni za određenu svrhu čine namjeru vidljivom, a zaštitne ograde provedivima.

Umjesto izlaganja jedne neograničene radnje implementacije, podijelite radni tijek na alate kao što su „stvori pretpregled”, „pročitaj status implementacije” i „promoviraj odobreno izdanje”. Umjesto dopuštanja proizvoljne izmjene baze podataka, ponudite validator migracija i zahtijevajte izričit korak odobrenja za primjenu migracije. Agent i dalje može ostvariti koristan rad, ali svaki je značajan prijelaz vidljiv i podložan reviziji.

Izlazi alata važni su jednako kao i njihovi ulazi. Gdje je moguće, vratite strukturirane, sažete informacije: status, promijenjene resurse, kategoriju pogreške i siguran sljedeći korak. Zid zapisa može biti potreban za dijagnostiku, ali agent ne bi trebao nagađati je li implementacija uspjela.

Provjera je agentova definicija dovršenosti

Generirani kod je hipoteza. Testovi, statička analiza, izgradnje i ciljane provjere tijekom izvođenja predstavljaju dokaze. Agent koji može uređivati datoteke, ali ne može provjeriti svoj rad, bliži je sustavu za automatsko dovršavanje nego vlasniku projekta.

Provjera bi trebala biti razmjerna riziku. Ispravak dokumentacije može zahtijevati provjeru poveznica i fokusirani pregled. Promjena autentikacije, plaćanja, rukovanja podacima ili logike implementacije zaslužuje snažnije provjere, manje korake uvođenja i jasnije ljudske kontrolne točke. Agent bi trebao izvijestiti što je pokrenuo, što je prošlo, što nije mogao pokrenuti i zašto.

Jednako je važno da treba sačuvati negativne dokaze. „Nisu pokrenuti testovi jer je potrebna usluga bila nedostupna” vrijednije je od neodređene tvrdnje da je promjena dovršena. Iskrena neizvjesnost ljudima daje informacije potrebne za odluku o spajanju, implementaciji ili daljnjoj istrazi.

Memorija bi trebala biti kurirana, a ne gomilana

Vlasništvo nad projektom zahtijeva kontekst, ali neograničena memorija nije strategija. Agentima su potrebne trajne činjenice poput arhitektonskih odluka, konvencija kodiranja, vlasništva nad uslugama, postupaka izdavanja i poznatih načina neuspjeha. Također su im potrebne bilješke lokalne za zadatak: pregledane datoteke, pretpostavke, pokrenute naredbe i neriješena pitanja.

Držite te slojeve odvojenima. Trajno znanje trebalo bi pregledavati i održavati kao dokumentaciju. Memorija lokalna za zadatak trebala bi isteći kada istekne njezina vrijednost. U suprotnom, agent može prenijeti zastarjelo zaobilazno rješenje u novi zadatak ili staru bilješku o incidentu tretirati kao trenutačno ograničenje.

Mjerite pouzdanost prije širenja ovlasti

Razuman put usvajanja je uzak i vođen dokazima. Započnite s ograničenim zadacima u kojima su pogreške reverzibilne: trijažom, prijedlozima za popravak testova, ažuriranjima dokumentacije, održavanjem ovisnosti ili pripremom okruženja za pretpregled. Promatrajte gdje agent uspijeva, gdje se primjereno dvoumi i gdje njegovo sučelje alata stvara zbrku.

Tek tada proširite opseg. Pravo pitanje nije može li agent dovršiti impresivnu demonstraciju. Pitanje je proizvodi li sustav dosljedno promjene koje tim može razumjeti, provjeriti i sigurno prihvatiti.

Trajna prednost je bolji inženjerski sustav

AI agenti neće ukloniti potrebu za tehničkim vodstvom. Učinit će vodstvo vidljivijim. Netko mora definirati ishode, dizajnirati sigurna sučelja, održavati znanje o projektu i odlučiti koji su dokazi dovoljni za rizičnije promjene.

Timovi koji će imati najviše koristi neće biti oni koji od asistenta traže više koda. To će biti oni koji svoje inženjerske prakse pretvore u eksplicitne, provjerljive radne tijekove u kojima agent može sudjelovati. Gradite agente koji stječu povjerenje kroz opseg, provjeru i jasnu eskalaciju, i mogu postati istinski projektni partneri umjesto impresivnih izvora nerevidiranog izlaza.