Većina softverskog rada ne propada zato što razvojni inženjer ne može napisati funkciju. Propada u prostorima između funkcija: nejasan zahtjev, previdjena ovisnost, migracija koja nikada nije uvježbana, problem podrške koji nije stigao do pravog tima. AI agenti su zanimljivi jer mogu djelovati u tim prostorima. Ako su pravilno dizajnirani, čine više od izvršavanja izoliranih zadataka. Pomažu strukturirati rad.

Ta je razlika važna. Chatbot može odgovoriti na pitanje. Agent može slijediti cilj kroz ograničen niz radnji: pregledati kontekst, odabrati dopušteni sljedeći korak, koristiti alate, provjeriti rezultat i izvijestiti što se dogodilo. U isporuci softvera to agente čini manje sličnima automatskom dovršavanju, a više mlađim operativnim sustavima kojima su potrebne jasne odgovornosti, pouzdani ulazi i nadzor.

Od izvršavanja zadataka do arhitekture rada

Tradicionalna automatizacija izvrsna je kada je put poznat. Proces izgradnje kompajlira kod, pokreće testove i implementira artefakt prema izričitim pravilima. Agent postaje koristan kada je za put potrebna prosudba, ali se prihvatljive radnje i dalje mogu ograničiti.

Razmotrite upozorenje u produkciji zbog povećanih stopa pogrešaka. Konvencionalno pravilo moglo bi pozvati inženjera. Agent može prikupiti nedavnu povijest implementacija, usporediti pogođene krajnje točke, dohvatiti relevantne zapise, sažeti vjerojatne korelacije i pripremiti dijagnostički sažetak. Ne bi trebao neprimjetno mijenjati produkcijski promet ili vraćati izdanje na prethodnu verziju, osim ako organizacija nije namjerno dodijelila i zaštitila tu ovlast.

Vrijednost nije u tome da agent „rješava incidente”. Vrijednost je u tome što smanjuje vrijeme utrošeno na prikupljanje konteksta, a pritom važne odluke ostavlja vidljivima i odgovornima.

Korisni obrasci agenata za softverske timove

Dobri početni slučajevi upotrebe ponavljajući su, obiluju informacijama i lako ih je provjeriti. Također imaju jasnu točku zaustavljanja. Ti obrasci obično stvaraju praktičnu vrijednost bez pretvaranja da je agent autonomna inženjerska organizacija.

• Orijentacija u repozitoriju: sažeti ulazne točke usluge, konfiguraciju, testove i granice ovisnosti za razvojnog inženjera koji se pridružuje kodnoj bazi ili istražuje promjenu.
• Priprema promjene: pretvoriti zahtjev u predloženi plan implementacije, utvrditi pogođene module i izraditi nacrt kontrolne liste testova prije nego što itko uređuje kod.
• Pomoć pri pregledu: usporediti pull request s njegovom navedenom namjerom, označiti testove ili putanje pogrešaka koje nedostaju i postaviti usmjerena pitanja o pretpostavkama.
• Operativna trijaža: prikupiti nadzorne ploče, zapise, tragove, priručnike za postupanje i nedavne promjene u sažetu vremensku crtu incidenta.
• Održavanje dokumentacije: utvrditi odstupanja između koda, konfiguracije i internih vodiča, a zatim predložiti ažuriranja za ljudskog recenzenta.

Uočite zajedničku temu: svaki agent poboljšava kvalitetu sljedeće ljudske odluke. To je trajniji cilj od mjerenja uspjeha prema broju redaka koda koje agent proizvede.

Dizajnirajte tijek rada prije odabira modela

Timovi često započinju odabirom modela i rade unatrag. Snažniji pristup započinje tijekom rada. Definirajte okidač, ulaze koje agent smije čitati, alate koje smije koristiti, radnje koje smije poduzeti i dokaze potrebne prije nego što može proglasiti uspjeh.

Korisni mentalni model je mala upravljačka petlja:

1. Primiti usko definiran cilj.
2. Prikupiti samo kontekst potreban za djelovanje.
3. Predložiti ili izvršiti dopuštenu radnju.
4. Provjeriti ishod neovisnom provjerom.
5. Zabilježiti rezultat, neizvjesnost i potrebnu predaju.

Na primjer, agent kojem je zadano ažuriranje ovisnosti ne bi se trebao zaustaviti nakon uređivanja niza verzije. Trebao bi utvrditi manifest ovisnosti, izvršiti predloženu promjenu u izoliranom radnom prostoru, pokrenuti relevantne provjere projekta, pregledati neuspjehe i izvijestiti je li nadogradnja spremna za pregled. Ako testovi ne prođu zbog nepovezanog problema okruženja, to je rezultat koji treba istaknuti, a ne razlog za izmišljanje uspješnog ishoda.

Cilj: pripremiti nadogradnju ovisnosti za pregled
Dopuštene radnje: čitanje datoteka repozitorija, uređivanje grane, pokretanje odobrenih provjera
Dokazi uspjeha: manifest promijenjen, lockfile dosljedan ako se koristi, provjere prijavljene
Uvjet zaustavljanja: dvosmislena migracija, neuspjela provjera ili nedostajuće vjerodajnice
Predaja: sažetak promijenjenih datoteka, pokrenutih naredbi, rezultata i otvorenih rizika

Ovakva vrsta ugovora olakšava testiranje ponašanja agenta i olakšava povjerenje u njega. Također sprječava čest način neuspjeha: dati agentu širok zahtjev poput „popravi build” bez definicije onoga što smije promijeniti.

Zaštitne ograde su dizajn proizvoda, a ne birokracija

Agentski sustavi trebaju granice jer kombiniraju jezično zaključivanje sa stvarnim alatima. Uvjerljivo objašnjenje nije dokaz da je radnja bila ispravna. Provjera, dozvole i mogućnost revizije moraju biti ugrađene u tijek rada.

Dodijelite najmanji koristan pristup

Odvojite istraživanje samo za čitanje od operacija pisanja. Koristite ograničene vjerodajnice i okruženja koja odgovaraju riziku zadatka. Agentu koji sažima zapise nisu potrebne dozvole za implementaciju. Agentu koji otvara pull request nije potrebna ovlast za njegovo spajanje.

Učinite važne radnje preglednima

Za promjene koda, infrastrukture, podataka korisnika ili vanjske komunikacije zadržite točku ljudskog odobrenja, osim ako je radnja doista niskorizična i reverzibilna. Agent bi trebao predstaviti svoje dokaze, predloženi diff i neizvjesnost jasnim jezikom. Recenzent bi trebao moći razumjeti što će se dogoditi bez rekonstruiranja cijelog lanca razmišljanja agenta.

Provjeravajte sustavima, a ne pouzdanjem

Dajte prednost provjerama koje ne ovise o tome slaže li se agent sam sa sobom: testovima, linterima, provjeri sheme, probnim pokretanjima, provjerama pravila i usporedbama s pouzdanim izvornim podacima. Ako agent ne može pristupiti dokazima potrebnima za provjeru tvrdnje, trebao bi to jasno reći.

Mjerite rad koji se promijenio

Usvajanje može postati teatralno ako timovi mjere samo upotrebu. Velik broj pokretanja agenta može značiti da je tijek rada vrijedan ili da je bučan i loše dizajniran. Pratite ishode bliže radu: vrijeme za pripremu pregleda, vrijeme za prikupljanje konteksta incidenta, stopu prihvaćenih ažuriranja dokumentacije, broj eskalacija i učestalost neuspjelih provjera.

Kvalitativne povratne informacije također su važne. Pitajte inženjere je li izlaz agenta specifičan, navodi li relevantan interni kontekst i čini li sljedeći korak jasnijim. Agent koji uštedi deset minuta, ali redovito usmjerava ljude na pogrešan put, može predstavljati neto gubitak.

Stvarna promjena je organizacijska

AI agenti neće ukloniti potrebu za softverskom prosudbom. Čine prosudbu vidljivijom prisiljavajući timove da definiraju procese koji su prije bili neformalni: što se smatra dokazom, tko može odobriti promjenu, kada stati i kako se oporaviti od pogreške.

Najsposobniji timovi tretirat će agente kao suradnike unutar dobro dizajniranih sustava, a ne kao čarobne zaposlenike. Počnite s uskim tijekom rada, jasno odredite granice, inzistirajte na provjeri i učite iz svake predaje. Kada su agenti izgrađeni na taj način, ne završavaju samo zadatke brže. Pomažu učiniti softverski rad čitljivijim, otpornijim i inteligentnije povezanim.