Većini timova ne treba AI agent zato što žele futurističku demonstraciju. Treba im zato što važan posao stalno upada u praznine između sustava: zahtjev za podršku koji treba istražiti, implementacija koju treba provjeriti, sigurnosni nalaz koji treba usmjeriti ili pitanje o proizvodu koje zahtijeva dokaze iz nekoliko izvora.

Tu razgovor nadilazi automatizaciju. Tradicionalna automatizacija izvršava unaprijed definirani put. AI agent može pomoći tumačiti cilj, prikupiti kontekst, odabrati među odobrenim radnjama i izvijestiti što je učinio. Ako se dobro koristi, postaje inženjerski partner: ne autonomna zamjena za prosudbu, nego sposoban suradnik koji djeluje unutar jasnih granica.

Automatizacija slijedi pravila; agenti rade u uvjetima neizvjesnosti

Zakazani zadatak koji rotira zapisnike, pokreće skup testova ili sinkronizira dva polja jest automatizacija. Deterministički je po svojoj namjeni. Njegova je snaga ponovljivost.

Agent je korisniji kada se put ne može u potpunosti unaprijed odrediti. Razmotrite asistenta za trijažu incidenata. Okidač može biti jednostavan: upozorenje premašuje prag. No sljedeći koraci ovise o usluzi, nedavnim implementacijama, obrascima pogrešaka, poznatim priručnicima za postupanje i o tome je li signal stvaran. Agent može prikupiti taj kontekst, sažeti vjerojatne uzroke i predložiti sljedeći siguran korak istrage.

Razlika je važna jer mijenja pitanje dizajna. Umjesto pitanja: „Koji zadatak možemo predati modelu?”, pitajte: „Gdje osoba opetovano troši vrijeme pretvarajući raspršene informacije u ograničenu odluku?”

Počnite s uskim tijekom rada bogatim kontekstom

Široki nalozi poput „učinimo našu inženjersku organizaciju agentskom” stvaraju zbrku. Počnite s jednim tijekom rada koji je čest, mjerljiv i trenutačno usporen prikupljanjem konteksta.

Dobri rani kandidati često uključuju:

• Sažimanje pull requesta uz relevantne tikete, testove i arhitektonske bilješke.
• Klasificiranje dolaznih izvješća podrške i izradu nacrta izvješća o pogrešci koje se može reproducirati.
• Istraživanje neuspjelih buildova prikupljanjem zapisnika, nedavnih promjena i poznatih koraka za otklanjanje problema.
• Pripremu kontrolnog popisa za izdanje na temelju deklariranih promjena i konvencija repozitorija.
• Odgovaranje na interna pitanja iz kurirane baze znanja koja uzima u obzir dozvole.

To nisu glamurozni slučajevi upotrebe, upravo zato su vrijedni. Imaju postojeće ljudske tijekove rada, prepoznatljive ulaze i ishode koje recenzent može procijeniti. Također otkrivaju gdje leži stvarna složenost: dozvole, zastarjela dokumentacija, dvosmisleni zahtjevi i nepouzdani vanjski alati.

Definirajte posao agenta operativnim terminima

Korisna specifikacija agenta sličnija je API ugovoru nego opisu radnog mjesta. Navedite okidač, dostupan kontekst, dopuštene alate, očekivani izlaz, uvjete eskalacije i vlasnika. „Pomozi s implementacijama” neodređeno je. „Za neuspjelu implementaciju u staging okruženju prikupi odobrenu dijagnostiku, usporedi manifest izdanja s prethodnom uspješnom implementacijom i izradi preporuku za oporavak koju je moguće pregledati” jest provedivo.

Jednako je važno definirati što agent ne smije učiniti. Može mu biti dopušteno čitati zapisnike, ali ne i mijenjati infrastrukturu. Može izraditi nacrt tiketa, ali ne i obavještavati korisnike. Može preporučiti vraćanje na prethodnu verziju, ali za izvršenje zahtijevati ovlaštenu osobu.

Gradite agente kao sustave, a ne kao upite

Dobar upit pomaže, ali produkcijsko ponašanje dolazi iz okolnog sustava. Modeli su probabilistički; tijek rada oko njih mora osigurati strukturu, validaciju i vidljivost.

Prvo, modelu pružite autoritativan kontekst umjesto da očekujete da pamti organizacijske činjenice. To može uključivati aktualni priručnik za postupanje, podatke o vlasništvu nad uslugama, odobrenu dokumentaciju ili usko ograničen rezultat pretraživanja. Izvore zadržite pripisivima u izlazu kako bi recenzenti mogli razlikovati dokaze od zaključivanja.

Drugo, alate učinite eksplicitnima i usko usmjerenima. Alat treba imati jasnu svrhu, tipizirane ulaze gdje je to moguće i ograničen opseg dozvola. Izbjegavajte jednu integraciju koja „može učiniti sve”. Odvojite, primjerice, dohvat implementacije samo za čitanje od radnje implementacije kako bi pravila mogla zahtijevati korak potvrde prije bilo kakve promjene.

Treće, validirajte svaki izlaz s posljedicama. Ako agent proizvodi strukturirane podatke, provjerite ih prije daljnje upotrebe. Ako preporučuje naredbu, prikažite naredbu i njezin cilj. Ako stvara problem, zahtijevajte obavezna polja. Modeli mogu proizvesti uvjerljiv tekst; validacija pretvara uvjerljivost u operativno sigurno sučelje.

Cilj: istražiti neuspjelu implementaciju
Dopuštene radnje:
1. Pročitati status implementacije i odobrene zapisnike
2. Pročitati manifest izdanja
3. Pretražiti priručnik za incidente
4. Proizvesti dijagnozu s navedenim dokazima
Eskalirati kada:
- su potrebni vjerodajnice, podaci korisnika ili promjene u produkciji
- su dokazi nepotpuni ili proturječni
- je razina pouzdanosti nedostatna za preporuku

Ovakav ugovor nije birokracija. Sprječava da agent postane neodređen razgovorni sloj oko rizičnih operacija.

Dizajnirajte za neuspjeh prije nego za oduševljenje

Neuspjesi agenata u početku su rijetko dramatični. Češće sustav koristi stari kontekst, poziva pogrešan alat s gotovo ispravnim argumentom, ponovno pokušava radnju koju ne bi trebalo ponovno pokušavati ili samouvjereno popunjava prazninu pretpostavkom. To su uobičajene inženjerske brige, a ne jedinstveni nedostaci AI-ja.

Za svaki poziv alata odlučite je li samo za čitanje, idempotentan, reverzibilan ili destruktivan. Pozivi samo za čitanje često se mogu sigurno ponovno pokušati. Zahtjev koji stvara zapis vidljiv korisniku ili mijenja stanje produkcije zahtijeva snažnije kontrole: ključeve idempotentnosti, potvrdu, zapisivanje revizije i jasno postupanje kada je rezultat neizvjestan.

Kada alat ne uspije, agent ne bi trebao beskonačno improvizirati. Trebao bi prijaviti neuspjeh, sačuvati koristan kontekst koji je prikupio i predati slučaj uz konkretan zahtjev. „Nije moguće dohvatiti povijest implementacije zbog pogreške autorizacije; manifest izdanja navodi verziju X; operater s pristupom za čitanje implementacija trebao bi provjeriti prethodnu uspješnu verziju” korisnije je od izmišljene dijagnoze.

Zadržite ljude u tijeku tamo gdje prosudba nosi posljedice

Ljudski pregled nije znak da je agent podbacio. Često je dio dizajna proizvoda. Prava razina nadzora ovisi o cijeni pogreške, reverzibilnosti radnje, kvaliteti dostupnih dokaza i pogođenoj publici.

Praktičan napredak jest početi s promatranjem i izradom nacrta, zatim prijeći na preporuke, a potom na odobreno izvršavanje radnji niskog rizika. Na primjer, agent bi najprije mogao sažimati incidente, kasnije predlagati relevantan korak iz priručnika, a tek nakon pažljive procjene smio bi ponovno pokrenuti nekritičnu uslugu prema izričitim pravilima.

Recenzentima je potrebno dovoljno informacija za brzu odluku. Prikažite razmotrene dokaze, pokušane radnje, iznesene pretpostavke i točnu predloženu promjenu. Uglađen odgovor bez sljedivosti može izgledati impresivno, ali ne gradi povjerenje.

Mjerite partnerstvo, a ne samo količinu izlaza

Brojanje generiranih sažetaka ili poziva alata može zavarati. Smislenija su pitanja smanjuje li agent vrijeme do ispravne odluke, poboljšava li predaje, uočava li informacije koje nedostaju i izbjegava li stvaranje novog tereta pregleda.

Pratite mali skup mjera specifičnih za tijek rada: stopu prihvaćanja nacrta, vrijeme utrošeno na prikupljanje konteksta, učestalost eskalacija, obrasce ispravaka i incidente koje je proces uzrokovao ili spriječio. Pažljivo pregledajte odbijene izlaze. Oni otkrivaju je li problem u dizajnu upita, nedostajućem kontekstu, lošim granicama alata ili tijeku rada koji bi trebao ostati konvencionalna automatizacija.

Najtrajniji agenti neće biti oni koji izgledaju najneovisnije. Bit će to oni koji sposobne ljude čine bržima, informiranijima i dosljednijima, bez skrivanja neizvjesnosti. To je stvarna promjena: AI agenti ne moraju zamijeniti inženjersko partnerstvo. Uz discipliniran dizajn sustava, mogu postati njegov dio.