AI agenti mijenjaju oblik rada na softveru. Prvi val AI alata pomogao je programerima napisati funkciju, objasniti pogrešku ili izraditi nacrt testa. Korisno, svakako — ali ograničeno. Značajniji pomak ide prema agentima koji mogu raditi kroz sustav: čitati zahtjeve, pratiti ovisnosti, predlagati promjene, pokretati provjere i voditi zapis o razlozima donošenja odluke.

To ne znači da agent zamjenjuje arhitekta, tehničkog voditelja ili inženjera odgovornog za ishod. Znači da ljudi odgovorni za sustav mogu trošiti manje vremena na prikupljanje raspršenog konteksta, a više na donošenje odluka koje zahtijevaju prosudbu.

Od lokalne pomoći do rada na razini sustava

Pomoćnik za kod uglavnom radi na razini datoteke, funkcije ili upita. Agent radi na cilju i u radnom okruženju. Uz odgovarajuće dozvole i ograničenja, može pregledati repozitorij, utvrditi pogođene usluge, pripremiti plan migracije, izmijeniti kod, pokrenuti testove i izvijestiti o onome što ostaje neizvjesno.

Razlika nije samo u autonomiji. Ona je u opsegu i povratnoj informaciji. Agent postaje vrijedan kada se može kretati kroz sljedeći ciklus:

1. Razumjeti željeni ishod i relevantna ograničenja.
2. Pregledati trenutačno stanje koda, konfiguracije, testova i dokumentacije.
3. Planirati malu promjenu koju je moguće pregledati.
4. Izvršiti promjenu putem odobrenih alata.
5. Provjeriti rezultat i istaknuti iznimke za ljudski pregled.

Taj ciklus čini agente obećavajućim dizajnerima nacrta sustava. Mogu pomoći pretvoriti nejasan zahtjev poput „dodaj rukovanje regionalnim podacima” u konkretnu mapu usluga, granica pohrane, API-ja, postavki implementacije, testova, rizika i odluka kojima još treba dodijeliti odgovornu osobu.

Nacrt je više od arhitektonskog dijagrama

Timovi arhitekturu često tretiraju kao dijagram izrađen prije implementacije i ponovno razmatran nakon incidenta. U stvarnosti je koristan nacrt živi opis načina na koji se sustav ponaša: što je vlasnik podataka, kako zahtjevi teku, gdje se obrađuju neuspjesi, koji su ugovori javni i kako se sustav koristi u radu.

Učinkovit agent može pomoći održavati taj opis jer može usporediti namjeravani dizajn s implementacijom. Primjerice, kada nova funkcionalnost usmjerena korisnicima zahtijeva podatke iz sustava za naplatu i identitet, agent može prepoznati vjerojatne točke integracije i postaviti pitanja koja određuju je li dizajn siguran:

• Koja je usluga izvor istine za svako polje?
• Što se događa kada jedna ovisnost nije dostupna?
• Je li operaciju sigurno ponovno pokušati ili ponovni pokušaji mogu stvoriti dvostruke učinke?
• Koji će događaji, zapisnici i upozorenja pokazati da funkcionalnost radi?
• Koji su podaci osjetljivi i gdje ih treba redigirati ili čuvati na drugačiji način?

To nisu pitanja na koja bi agent trebao sam odgovoriti. To su pitanja koja može učiniti teško previdljivima. To je značajno poboljšanje u odnosu na arhitektonski proces vođen pamćenjem i nepotpunim bilješkama sa sastanaka.

Gdje agenti pružaju praktičnu vrijednost

Analiza utjecaja prije promjene koda

Mnoge skupe pogreške počinju podcijenjenom promjenom. Zahtjev koji se čini da utječe na jednu krajnju točku može utjecati i na sheme, klijente, provjere dozvola, poslove izvještavanja, definicije infrastrukture i operativne priručnike.

Agent može sastaviti izvješće o utjecaju prateći reference kroz bazu koda i njezinu konfiguraciju. Izlaz treba tretirati kao polazište, a ne dokaz potpunosti, ali recenzentima daje bolju osnovu za raspravu. Korisno izvješće navodi vjerojatne datoteke i komponente, opisuje promjene ugovora te ističe pretpostavke umjesto da ih potajno donosi.

Pretvaranje odluka u zadatke implementacije

Nakon što ljudi odluče o dizajnu, agenti mogu tu odluku prevesti u strukturiran rad. Dobar plan razlikuje preduvjete, korake implementacije, provjeru, uvođenje i povratak na prethodno stanje. Također treba prepoznati ovisnosti koje se ne mogu riješiti kodom, poput odobrenja nove politike zadržavanja podataka ili vlasništva nad ugovorom vanjskog API-ja.

Za promjenu potkrijepljenu bazom podataka plan može zahtijevati aditivnu migraciju sheme, podršku aplikacije za stara i nova polja, praćenje popunjavanja podataka, a tek zatim uklanjanje naslijeđene putanje. To je sigurnije nego tražiti od agenta da „ažurira shemu” i prihvatiti opsežnu promjenu bez strategije migracije.

Održavanje operativnog znanja blizu sustava

Dokumentacija obično zaostaje jer se natječe s radom na isporuci. Agenti mogu smanjiti taj jaz izradom nacrta bilješki o izdanju, ažuriranjem operativnog priručnika nakon pregledane promjene implementacije ili generiranjem kontrolne liste iz stvarne konfiguracije usluge. Ljudski vlasnik i dalje treba provjeriti rezultat, posebno oko odgovora na incidente i sigurnosti, ali početni nacrt više ne počinje od prazne stranice.

Osmislite granice agenta prije nego što mu dodijelite rad

Najvažniji izbor pri dizajnu agenta nije model. To je granica oko rada. Sposoban model s prekomjernim dozvolama nije inženjerska strategija. Timovi bi trebali početi s uskim zadacima, ograničenim vjerodajnicama, vidljivim zapisnicima i jasnom točkom odobrenja prije bilo kakve nepovratne radnje.

Praktičan je napredak prijeći s analize samo za čitanje, na predložene zakrpe, zatim na promjene u izoliranom okruženju, a tek potom na strogo kontrolirane operativne radnje. Svaka faza trebala bi zaslužiti povjerenje kroz ponovljive dokaze.

Primjerice, agentu se može dopustiti pokretanje testova i izrada zahtjeva za povlačenje, dok implementacije u produkciju ostaju radni tijek u vlasništvu ljudi. Ako može predložiti naredbu poput npm test, okolni sustav i dalje treba zabilježiti rezultat, sigurno prekinuti nakon isteka vremena i izbjeći tretiranje uspješnog paketa testova kao dokaza da je uvođenje bezopasno.

Pouzdanost proizlazi iz radnog tijeka, a ne iz samopouzdanja

Agenti mogu zvučati sigurno kada je dostupan kontekst nepotpun. Zato je provjera ključni dio dizajna. Tražite od agenta da navede što je pregledao, što je promijenio, što nije mogao provjeriti i koje su pretpostavke vodile njegove izbore. Zahtijevajte da testovi, provjere tipova, linteri, sigurnosna skeniranja i ljudski pregled koda ostanu neovisne zaštitne mjere.

Postupanje u slučaju neuspjeha također zaslužuje izričit dizajn. Poziv alata može ne uspjeti zbog isteka vremena, nedostajuće dozvole, prolazne pogreške usluge ili promijenjenog sučelja. Nasumično ponavljanje može duplicirati zapis ili otežati dijagnosticiranje sustava. Radni tijekovi agenata trebali bi definirati koje je operacije sigurno ponoviti, koliko puta, kako se neuspjesi bilježe i kada agent mora stati i eskalirati.

Drugim riječima, prema agentu se odnosite kao prema novoj produkcijskoj integraciji. Osigurajte mu opažljivost, pristup s najmanjim potrebnim ovlastima, predvidljive ulaze i put izlaza. Ista inženjerska disciplina koja štiti tijek plaćanja ili cjevovod implementacije trebala bi štititi radni tijek omogućen AI-jem.

Ljudska uloga postaje vrjednija, a ne manje važna

Kako agenti preuzimaju više rutinske koordinacije, trajne ljudske odgovornosti postaju jasnije: postavljanje prioriteta, definiranje prihvatljivog rizika, rješavanje nejasnoća, zaštita korisnika i odlučivanje o tome što ne treba izgraditi. To su odgovornosti na razini sustava jer uključuju posljedice izvan repozitorija koda.

Najbolji timovi neće mjeriti uspjeh agenta prema broju datoteka koje promijeni. Mjerit će skraćuje li put od namjere do sigurnog, razumljivog rezultata. Mala zakrpa koju je generirao agent, s izvrsnim testovima, jasnim obrazloženjem i jednostavnim povratkom na prethodno stanje, vrjednija je od velikog autonomnog prepisivanja.

AI agenti nisu samo brži pomoćnici za kod. Ako se upotrebljavaju promišljeno, mogu postati partneri u održavanju nacrta živog sustava: povezujući zahtjeve s implementacijom, implementaciju s operacijama i operacije natrag s boljim dizajnom. Prilika nije u predaji arhitekture. Ona je u tome da se arhitektima i inženjerima pruži oštriji, neumorniji način da vide sustave za koje i dalje odgovaraju.