Većini softverskih timova AI agenti nisu potrebni da bi pisali više koda. Potrebni su im da uklone posao koji iskusne ljude sprečava da jasno razmišljaju.

Ta je razlika važna. Tim može generirati tisuće redaka uvjerljivog koda, a i dalje donositi spore i skupe odluke. Prava je prilika rutinsko izvršavanje prenijeti u dobro osmišljene radne tokove agenata, a zatim više ljudske pozornosti usmjeriti na arhitekturu: granice, kompromise, pouzdanost, sigurnost i dugoročni oblik proizvoda.

Kad se koriste na taj način, AI agenti nisu zamjena za inženjersku prosudbu. Oni su sustavi za pretvaranje ponovljivih inženjerskih obaveza u nadzirane procese.

Izvršavanje nije isto što i inženjerstvo

Rad na softveru sadrži veliku količinu izvršavanja: pronalaženje relevantnih datoteka, sažimanje problema, izradu nacrta testova, ažuriranje repetitivne dokumentacije, provjeru plana migracije ili pripremu opisa zahtjeva za povlačenje. Ti su zadaci važni, ali rijetko zaslužuju neprekinuti fokus na razini seniora.

Arhitektura je drukčija. Postavlja pitanja s posljedicama koje možda neće postati vidljive mjesecima kasnije: Gdje bi trebalo biti vlasništvo? Koji su načini otkaza prihvatljivi? Je li ovo sučelje dovoljno stabilno za druge timove? Koji podaci nikada ne bi smjeli prijeći granicu povjerenja? Kako se sustav može razvijati bez rizičnog prepisivanja?

Agent može pomoći pri prikupljanju dokaza za te odluke. Ne bi ih trebao neprimjetno donositi samo zato što je dao samouvjeren odgovor.

Dodijelite agentima ograničene, provjerljive zadatke

Najjači radni tokovi agenata namjerno su uski. Umjesto da agenta zamolite da „poboljša servis”, definirajte ishod, dopušteni opseg, alate koje smije koristiti i uvjete koji zahtijevaju ljudsku provjeru.

Korisni zadatak za agenta često ima četiri dijela:

• Kontekst: relevantno područje repozitorija, ticket, bilješke o dizajnu i ograničenja.
• Cilj: konkretan rezultat, poput utvrđivanja pogođenih korisnika API-ja ili izrade nacrta testova za određeno ponašanje.
• Zaštitne ograde: datoteke koje smije mijenjati, naredbe koje smije pokretati i radnje koje nikada ne smije poduzeti.
• Provjera: testovi, statičke provjere, kriteriji pregleda ili izričit izvještaj o neizvjesnosti.

Ova struktura olakšava povjerenje u rezultat agenta jer ga olakšava preispitati. Recenzent može vidjeti što je od agenta zatraženo, koje je dokaze koristio i gdje je radni tok stao.

Primjer: pretvorite prijavu greške u paket za istragu

Razmotrite prijavu greške u produkciji s nejasnim simptomom: povremena dvostruka obavijest. Općeniti upit može vratiti spekulativan popravak. Bolji radni tok dodjeljuje agentu istraživačku ulogu.

• Pratite zahtjev za obavijest kroz bazu koda.
• Navedite uključene putanje ponovnih pokušaja, korisnike reda, provjere idempotentnosti i upise u trajnu pohranu.
• Utvrditi pretpostavke koje trebaju potvrdu iz zapisa ili metrika.
• Predložiti usmjerene testove koji bi razlikovali vjerojatne uzroke.
• Ne mijenjati kôd niti tvrditi da postoji temeljni uzrok bez dokaza.

Rezultat ne zamjenjuje otklanjanje pogrešaka. Sažima skupu fazu orijentacije kako bi inženjer mogao prije procijeniti hipoteze i osmisliti ispravan popravak.

Izgradite radni tok, a ne ritual chatbota

Prozor za chat koristan je za istraživanje, ali ponovljiv inženjerski rad zaslužuje ponovljiv sustav. Tretirajte agenta kao bilo koju drugu komponentu u procesu isporuke: definirajte ulaze, izlaze, dopuštenja, vidljivost i ponašanje pri neuspjehu.

Na primjer, agent koji izrađuje nacrte zahtjeva za povlačenje za ažuriranja ovisnosti mogao bi slijediti ovaj redoslijed:

1. Pročitajte manifest ovisnosti i lockfile.
2. Utvrdite tražene promjene verzija i njihove izravne reference u kodu.
3. Primijenite najmanje kompatibilno ažuriranje unutar dopuštenog opsega.
4. Pokrenite postojeće naredbe za provjeru valjanosti.
5. Sažmite promijenjene datoteke, pokrenute naredbe, rezultate i nerazriješene neuspjehe.
6. Zaustavite se radi pregleda prije spajanja ili implementacije.

Ključna značajka nije autonomija. To je pouzdana primopredaja. Ako provjera valjanosti ne uspije, agent bi trebao sačuvati pojedinosti o neuspjehu i zaustaviti se, umjesto da opetovano mijenja nepovezani kôd dok nešto ne izgleda zeleno.

Neka provjera bude dio ugovora

Kôd koji je generirao agent treba procjenjivati istim mehanizmima koji se koriste za kôd koji su generirali ljudi, uz dodatnu pozornost na opseg i pretpostavke. Testovi, linteri, provjere tipova, sigurnosno skeniranje, pregled koda i kontrole implementacije i dalje su vrijedni jer izvor promjene ne mijenja njezin operativni rizik.

Kad agent predloži naredbu, mentalno odvojite naredbe koje pregledavaju stanje od naredbi koje ga mijenjaju. Na primjer, naredba za status samo za čitanje može biti prikladna tijekom istrage, dok bi naredba koja mijenja infrastrukturu ili produkcijske podatke trebala zahtijevati izričito odobrenje i pažljivo pregledan plan.

Dobri radni tokovi također zahtijevaju od agenata da prijave ono što nisu mogli provjeriti. „Nisam pronašao pozivatelje” slabije je od „Pretražio sam ove repozitorije i putanje; vanjski korisnici nisu bili dostupni za pregled.” Preciznost o ograničenjima značajka je, a ne isprika.

Sačuvajte ljudsku pozornost za izbore s velikim utjecajem

Kako izvršavanje postaje jeftinije, usko grlo se pomiče. Timovima su potrebne snažnije navike u oblikovanju problema i tehničkom usmjeravanju.

Prije delegiranja implementacije, tehnički voditelj može se zapitati:

• Koje ponašanje korisnika ili poslovanja mora ostati istinito?
• Koja su sučelja, podatkovni ugovori i sigurnosne granice pogođeni?
• Koji je put povratka ako se promjena ponaša neočekivano?
• Koji bi dokazi nakon izdanja pokazali da dizajn funkcionira?
• Koje su odluke reverzibilne, a koje je skupo poništiti?

Ova su pitanja arhitektonska čak i kada je promjena mala. Ona su također izvrsni ulazi za agenta. Jasna namjera daje korisnije nacrte; nejasna namjera daje uglađenu zbunjenost.

Započnite s utjecajem niskog rizika

Prvi projekti s agentima trebali bi biti korisni, ali oporavljivi. Održavanje dokumentacije, kosturi testova, trijaža problema, interna navigacija bazom koda, nacrti bilješki o izdanju i prijedlozi repetitivnog refaktoriranja često su bolje početne točke od nenadziranih promjena u produkciji.

Mjerite uspjeh praktičnim mjerilima: ušteđeno vrijeme tijekom istrage, manje propuštenih stavki kontrolnog popisa, brža priprema pregleda ili bolja dosljednost u rutinskom radu. Ne procjenjujte agenta prema tome zvuči li sposobno. Procjenjujte ga prema tome može li se tim sigurno osloniti na njegov radni tok.

Kako povjerenje raste, polako proširujte dopuštenja. Sustav koji može pripremiti promjenu i provjeriti je u izoliranom okruženju vrlo se razlikuje od sustava kojem je dopušteno spajanje, implementacija ili mijenjanje podataka korisnika. Te faze nikada se ne bi trebale tretirati kao jedan skok.

Arhitektonska korist

Najbolji ishod nije tim koji radi bez ljudi. To je tim u kojem ljudi troše manje vremena prevodeći očit posao u pritiske tipki, a više vremena poboljšavajući odluke sustava.

AI agenti mogu ubrzati izvršavanje. Vodstvo određuje hoće li ta brzina postati tehnički dug ili arhitektonski napredak. Dajte agentima ograničen posao, zahtijevajte vidljive dokaze, zadržite odgovornost ljudi za odluke s posljedicama i iskoristite vraćenu pozornost za izgradnju softvera koji ostaje razumljiv kada stigne sljedeća promjena.