AI asistent odgovara na pitanja. AI agent preuzima odgovornost za unapređivanje rada.

Ta razlika zvuči maleno sve dok ne dosegne stvarnu inženjersku organizaciju. Sučelje za razgovor može objasniti poruku o pogrešci ili nacrtati funkciju. Agent može pregledati repozitorij, podijeliti zahtjev na zadatke, napraviti ograničene izmjene, pokrenuti provjere, protumačiti neuspjehe i vratiti rezultat spreman za pregled. Ako se dobro koristi, postaje manje nalik automatskom dovršavanju, a više mlađem članu discipliniranog inženjerskog sustava.

Važna je riječ discipliniranog. Agenti ne postaju inženjerski arhitekti zato što mogu proizvesti velike količine koda. Tu ulogu zaslužuju kada mogu zaključivati unutar ograničenja: namjere proizvoda, postojeće arhitekture, testova, sigurnosnih granica, operativnog rizika i troška budućih promjena.

Od odgovora na upit do upravljanog tijeka rada

Tradicionalna AI pomoć obično je jedna razmjena: zatražite objašnjenje, primite odgovor, odlučite što učiniti dalje. Agentski rad je petlja. Sustav promatra trenutačno stanje, oblikuje plan, koristi odobrene alate, provjerava rezultat i prilagođava se kada dokazi proturječe njegovu prvom pristupu.

Razmotrite zahtjev za dodavanje nove postavke računa. Sposoban agent ne bi trebao početi izmišljanjem komponente obrasca. Najprije bi trebao pronaći postojeći model postavki, utvrditi pravila autorizacije, razumjeti kako funkcioniraju validacija i postojanost podataka, pronaći usporedive zaslone i pregledati relevantne testove. Tek tada može predložiti malu, kompatibilnu implementaciju.

To je arhitektonski rad u praktičnom obliku: očuvanje oblika sustava tijekom njegove promjene.

Što agenta čini korisnim u inženjerstvu

Agent postaje vrijedan kada može povezati odluke kroz slojeve, umjesto optimiziranja jedne izdvojene datoteke. Za to su potrebni kontekst, alati i zaštitne ograde.

• Kontekst: konvencije repozitorija, granice ovisnosti, standardi kodiranja, vlasništvo nad servisima i zahtjevi proizvoda.
• Alati: pretraživanje izvornog koda, praćenje zadataka, izvršavanje testova, izlaz izgradnje, dohvaćanje dokumentacije i vidljivost implementacije.
• Ograničenja: izričita ograničenja onoga što smije čitati, mijenjati, izvršavati ili slati izvan organizacije.
• Provjera: testovi, linteri, provjere tipova, provjere pravila i ljudski pregled prije prihvaćanja važnih izmjena.

Bez konteksta agent je sklon uvjerljivim, ali pogrešno usmjerenim izmjenama. Bez alata ne može potvrditi svoje pretpostavke. Bez ograničenja njegova autonomija postaje obveza. Bez provjere timovi mogu zamijeniti tečnost za ispravnost.

Najbolje implementacije tretiraju agenta kao sudionika postojećeg kanala isporuke, a ne kao njegovu zamjenu.

Arhitektura je niz kompromisa

Nazivanje agenta „arhitektom” ne bi trebalo značiti da ima konačnu ovlast nad posljedičnim odlukama. Arhitektura uključuje kompromise koji su često jednako društveni i organizacijski koliko i tehnički: koji tim posjeduje servis, koji je cilj pouzdanosti važan, koji podaci smiju prijeći granicu i gdje privremeni prečac stvara neprihvatljiv dugoročni trošak.

Agent može učiniti te kompromise vidljivijima. Može usporediti opcije s navedenim ograničenjima, utvrditi zahvaćena sučelja, izraditi planove migracije i istaknuti pretpostavke za koje je potrebna odluka vlasnika. To je često korisnije od predstavljanja jednog samouvjerenog odgovora.

Bolji upit za arhitekturu

Umjesto da agenta pitate: „Dizajniraj novi servis za obavijesti”, dajte mu okvir za odluku:

Cilj: isporučiti obavijesti unutar aplikacije autentificiranim korisnicima.

Ograničenja:
- Postojeći API klijenti moraju ostati kompatibilni.
- Sadržaj obavijesti može sadržavati osobne podatke.
- Isporuka je asinkrona i može se ponoviti.
- Prvo izdanje zahtijeva mogućnost revizije i sigurno vraćanje.

Izradi:
1. najmanji održivi dizajn,
2. sučelja koja se mijenjaju,
3. ponašanje pri neuspjehu i ponovnom pokušaju,
4. korake migracije i vraćanja,
5. otvorene odluke koje zahtijevaju ljudsko odobrenje.

Ovo uokviravanje traži od agenta da izloži svoje zaključivanje u terminima isporučivog rezultata. Također znatno olakšava pregled jer recenzenti mogu osporiti određenu pretpostavku umjesto raspravljanja o neodređenom dokumentu dizajna.

Dajte agentima ograničenu autonomiju

Autonomija se treba širiti s dokazima, a ne s entuzijazmom. Počnite sa zadacima čiji je rezultat lako pregledati i čiji neuspjeh ima ograničen radijus utjecaja: sažimanje zahtjeva za povlačenje, predlaganje testova, praćenje putanje zahtjeva, ažuriranje interne dokumentacije ili priprema plana migracije.

Zatim dopustite kontrolirane izmjene u grani ili izoliranom okruženju. Zahtijevajte od agenta da navede koje je datoteke promijenio, koje je provjere pokrenuo i što ostaje neizvjesno. Korisno izvješće o dovršetku nije „gotovo”; ono je sažet zapis dokaza.

• Što se promijenilo i zašto?
• Koji su testovi ili validacije prošli?
• Koje su pretpostavke napravljene?
• Što bi još moglo zakazati u produkciji?
• Koja odluka, ako postoji, treba ljudskog vlasnika?

Za radnje koje uključuju vjerodajnice, produkcijske podatke, komunikaciju s korisnicima, kontrolu pristupa ili nepovratne operacije, zadržite izričitu granicu odobrenja. Agent može pripremiti radnju i objasniti njezine posljedice, ali završni korak treba biti uređen istim kontrolama koje se primjenjuju na ljude.

Pouzdanost dolazi iz povratnih petlji

Agenti su najučinkovitiji kada im njihovo okruženje govori kada griješe. Neuspjeli test, pogreška validacije sheme, provjera implementacije ili odbijanje pravilom nisu tek prepreke; oni su povratne informacije koje sužavaju sljedeću radnju.

To znači da timovi trebaju ulagati u inženjerske osnove koje automatizirani rad čine pouzdanim: jasne testove, reproducibilne izgradnje, strukturirane zapise, stabilna razvojna okruženja, dokumentirano vlasništvo i uska sučelja. Agent ne može pouzdano navigirati sustavom koji su ljudi učinili nemogućim za razumijevanje.

To također znači izbjegavanje česte pogreške: traženje od agenta da nadoknadi nedostatak procesa. Ako su kriteriji prihvaćanja nejasni, nadzor slab i nitko ne posjeduje put implementacije, dodavanje agenta pojačava dvosmislenost. Možda će se kretati brže, ali će se brže kretati kroz neizvjesnost.

Ljudska uloga postaje jasnija, ne manja

Kako agenti preuzimaju više rada na implementaciji i koordinaciji, ljudska se prosudba pomiče prema određivanju smjera i procjeni posljedica. Inženjeri i dalje definiraju kvalitetu. Tehnički voditelji i dalje odlučuju koji su rizici prihvatljivi. Voditelji proizvoda i dalje razjašnjavaju što uspjeh znači za korisnike.

To može biti oslobađajuće kada se pristupi iskreno. Manje se vremena troši na rekonstrukciju rutinskog konteksta ili izradu prvih nacrta. Više vremena može se usmjeriti na pregled dizajna, utjecaj na korisnike, otpornost, održivost i mentorstvo. No to zahtijeva snažnije navike: precizne zahtjeve, izričita ograničenja i spremnost na pregled rezultata umjesto delegiranja razmišljanja.

Gradite sustave koji zaslužuju autonomnu pomoć

Budućnost AI-ja u softverskom radu nije jedan sveznajući agent koji izdaje velike arhitektonske dekrete. To je mreža pažljivo ograničenih agenata koji djeluju unutar sustava oblikovanih za odgovornost. Jedan agent može istraživati incident, drugi može izraditi zakrpu, a treći može provjeriti izmjenu u odnosu na pravila. Ljudi ostaju odgovorni za ishode koje ti sustavi stvaraju.

To je promjena koju vrijedi zapamtiti: cilj nije učiniti softverske timove manje promišljenima. Cilj je izgraditi tijekove rada u kojima je rutinski rad vidljiviji, odluke bolje dokumentirane, a inženjerska pozornost rezervirana za izbore koji uistinu oblikuju proizvod. Agent postaje arhitekt ne kada djeluje sam, nego kada pomaže cijelom sustavu donositi bolje odluke.