LLM postaje istinski koristan u radu na softveru kada prestane biti domišljata kutija za odgovore i počne sudjelovati u kontroliranoj petlji: razumjeti cilj, pregledati relevantan kontekst, poduzeti ograničenu radnju, provjeriti rezultat i izvijestiti o tome što se dogodilo. To je praktično obećanje AI agenata.

Ta je razlika važna. Asistent za razgovor može objasniti regularni izraz ili predložiti refaktoriranje. Agent može pomoći pretvoriti prijavu greške u ponovljiv test, predložiti zakrpu, pokrenuti relevantne provjere i ostaviti sažet pregled za recenziju. Nije zamjena za inženjersku prosudbu. To je sustav za ubrzavanje rutinskog zaključivanja i koordinacije bez prepuštanja odgovornosti.

Razmišljajte o radnim tijekovima, a ne o magiji

Najpouzdaniji projekti s agentima počinju uskim radnim tijekom koji već postoji. „Poboljšajmo produktivnost našeg inženjerskog tima” previše je neodređeno. „Razvrstajmo novoprijavljene pogreške u kategorije vjerojatnih duplikata, onih na koje se može djelovati ili onih kojima nedostaju informacije” dovoljno je konkretno za dizajniranje, testiranje i mjerenje.

Koristan agent ima četiri dijela: model, upute, alate i zaštitne ograde. Model tumači jezik i donosi odluke unutar zadatka. Upute definiraju ulogu, granice i željeni izlaz. Alati mu omogućuju dohvaćanje odobrenih informacija ili izvođenje usko ograničenih radnji. Zaštitne ograde ograničavaju čemu može pristupiti, što može promijeniti i što može tvrditi.

Bez tih granica agent je često samo uvjerljiv improvizator sa širokim ovlastima. S njima može postati pouzdan pomoćnik za određeni dio posla.

Počnite sa zadacima samo za čitanje i bogatim kontekstom

Rana uvođenja agenata trebala bi favorizirati zadatke kod kojih je pogrešan odgovor jeftin, a čovjek može lako provjeriti rezultat. Pristup samo za čitanje posebno je vrijedan: omogućuje agentu pretraživanje koda, sažimanje incidenata, analizu zapisa ili sastavljanje kontrolnog popisa za izdanje bez mijenjanja produkcijskih sustava ili repozitorija.

Dobri početni slučajevi upotrebe uključuju:

• Sažimanje pull requesta i prepoznavanje područja koja zaslužuju detaljniju recenziju.
• Praćenje značajke kroz repozitorije, usluge, konfiguraciju i dokumentaciju.
• Pretvaranje prijave problema u korake za reprodukciju, pretpostavke i pitanja za pojašnjenje.
• Izdvajanje vjerojatnih obrazaca pogrešaka iz zapisa dostavljenih agentu.
• Izrada nacrta testnih slučajeva na temelju kriterija prihvaćanja i postojećih projektnih konvencija.
• Priprema plana migracije koji navodi ovisnosti, rizike i pitanja o povratu na prethodno stanje.

Ti su zadaci vrijedni jer agent smanjuje vrijeme pretraživanja i sinteze, dok programer ostaje donositelj odluka. Također otkrivaju stvarnu kvalitetu sustava: pronalazi li pravi kontekst, razlikuje li dokaze od zaključaka i govori li kada informacije nedostaju.

Dajte agentu alate s ugovorima

Alati su ono što agenta čini operativnim, ali svaki bi alat trebao imati jasan ugovor. Alat za pretraživanje trebao bi navesti što pretražuje i vratiti strukturirane rezultate. Alat za implementaciju trebao bi zahtijevati izričito okruženje i prijaviti identifikator rezultirajuće implementacije. Alat za bazu podataka trebao bi odvajati upite za čitanje od pisanja.

Dajte prednost malim, namjenski izrađenim alatima umjesto jedne neograničene ljuske ili administrativne vjerodajnice. Ako agent treba pregledati neuspjeh izgradnje, dajte mu sučelje za dohvaćanje zapisa izgradnje i rezultata testova. Nemojte pretpostaviti da mu je potreban proizvoljan pristup svakom hostu, tajni i naredbi dostupnima ljudskom operateru.

Rezultate alata treba tretirati kao dokaze, a ne kao upute. Vanjski sadržaj može sadržavati obmanjujući tekst, zastarjelu dokumentaciju ili zlonamjerne pokušaje preusmjeravanja agenta. Agent bi trebao slijediti vlastite pouzdane upute za zadatak i dohvaćeni sadržaj tumačiti kao podatke.

Učinite radnje izričitima i reverzibilnima

Praktičan obrazac jest podijeliti rad na planiranje i izvršavanje. U načinu planiranja agent prikuplja kontekst i stvara predloženi slijed radnji. U načinu izvršavanja može izvesti samo odobrene korake i mora zabilježiti rezultat svakog od njih.

Za operacije s većim utjecajem zahtijevajte ljudsku potvrdu na granici. Agent može pripremiti migraciju baze podataka, prikazati točnu naredbu i zahvaćeno okruženje te čekati odobrenje prije izvršavanja. To nije trenje radi samog trenja; stvara jasnu točku odlučivanja na kojoj odgovorna osoba može provjeriti opseg, vremenski raspored i spremnost za povrat na prethodno stanje.

Cilj: sigurno ažurirati ovisnost usluge

1. Pregledajte manifest ovisnosti i lockfile.
2. Identificirajte izravne upotrebe na koje utječe promjena verzije.
3. Predložite najmanje kompatibilno ažuriranje.
4. Pokrenite definirani skup testova.
5. Sažmite promijenjene datoteke, rezultate testova i preostale rizike.
6. Nemojte objavljivati, implementirati niti mijenjati produkcijske postavke.

Takva je uputa korisnija od „nadogradi ovu ovisnost”. Ona agentu govori kako izgleda uspjeh i, jednako važno, gdje treba stati.

Provjera je razlika između demonstracije i kolege iz tima

LLM-ovi mogu proizvesti uvjerljiv kod koji je nepotpun, nedosljedan lokalnim konvencijama ili jednostavno pogrešan. Agent bi stoga trebao provjeriti svoj izlaz koristeći iste mehanizme koje bi koristio pažljiv programer: provjeru tipova, jedinične testove, integracijske testove, linting, statičku analizu i ciljanu inspekciju.

Provjera mora odgovarati zadatku. Ažuriranje dokumentacije može zahtijevati provjeru poveznica i recenziju nepodržanih tvrdnji. Refaktoriranje može zahtijevati testove koji pokazuju nepromijenjeno ponašanje. Produkcijska promjena može zahtijevati signale postupnog uvođenja i plan povrata na prethodno stanje. „Naredba je uspjela” dokaz je, ali rijetko dovoljan sam po sebi.

Zatražite od agenta da u završnom izvješću razlikuje tri kategorije: činjenice koje je uočio, promjene koje je napravio i neizvjesnosti koje trebaju ljudsku recenziju. Ova jednostavna struktura obeshrabruje nagađanja koja zvuče samouvjereno i pomaže recenzentima usmjeriti pozornost.

Dizajnirajte za neuspjeh prije proširivanja pristupa

Svaki će agent naići na dvosmislenost, nedostupne alate, nepotpun kontekst i proturječne signale. Sustav bi te uobičajene uvjete trebao učiniti vidljivima, umjesto poticati model da praznine popunjava samouvjerenim tekstom.

Unaprijed definirajte sigurno ponašanje pri neuspjehu. Ako pretraživanje repozitorija ne vrati odgovarajuću konfiguraciju, agent bi to trebao reći i zatražiti lokaciju koja nedostaje. Ako naredba za testiranje ne uspije, trebao bi zabilježiti relevantan izlaz, izbjegavati tvrdnju o uspjehu i stati prije nego što nepovezani popravci prošire opseg. Ako poziv alata istekne, trebao bi prijaviti istek vremena i ponoviti pokušaj samo kada je poznato da je operaciju sigurno ponoviti.

Ovlasti zaslužuju istu disciplinu. Primjenjujte načelo najmanjih ovlasti, odvajajte okruženja, štitite tajne od upita i zapisa te čuvajte revizijski trag poziva alata i odobrenja. Što je radnja važnija po posljedicama, kontrole bi trebale biti snažnije.

Mjerite rad, a ne novost

Agent bi trebao zaslužiti širu odgovornost poboljšavanjem stvarnog radnog tijeka. Pratite praktične ishode: vrijeme pripreme recenzije, postotak stavki razvrstavanja kojima je potrebna ispravka, neuspjehe testova uhvaćene prije recenzije ili vrijeme obrade rutinskih zahtjeva. Kombinirajte kvantitativne signale s ljudskim povratnim informacijama, jer brz radni tijek koji stvara skriveni posao recenzije nije poboljšanje.

Redovito pregledavajte neuspjehe. Oni otkrivaju je li problem nedostajući kontekst, slabe upute, nepouzdan alat, nedovoljna validacija ili zadatak koji bi trebao ostati pod ljudskim vodstvom. Odgovor je često suziti radni tijek, a ne dodati složenije promptanje.

Bolja podjela rada

Najjača vizija AI agenata nije autonomni razvoj softvera bez ljudi. To je bolja podjela rada. Agenti su prikladni za prikupljanje konteksta, izvođenje ponavljajućih provjera, izradu nacrta alternativa i održavanje kontinuiteta kroz rutinske korake. Ljudi ostaju odgovorni za prioritete, arhitekturu, kompromise, sigurnost i posljedice promjene.

Gradite agente koje je lako pregledati, lako zaustaviti i koji su korisni čak i kada su nesigurni. Počnite s jednim ograničenim radnim tijekom, dajte mu pravi kontekst i alate, zahtijevajte provjeru i proširujte ga samo kada to dokazi podupiru. Tako LLM postaje manje novotarija, a više pouzdan partner u razvoju softvera.